mirrors/mesa
0
0
Fork 0
mirror of https://gitlab.freedesktop.org/mesa/mesa.git synced 2025-01-09 15:24:58 +08:00
Code Issues Packages Projects Releases Wiki Activity
4c1cef68cf
mesa/.gitlab-ci/debian-arm64-install.sh

49 lines
1.1 KiB
Bash
Raw Normal View History

freedreno: Introduce gitlab-based CI. Since freedreno's kernel and GPU reset seem to be totally solid, we don't need to have the complexity of the LAVA setup that panfrost has. Instead, we can register some boards as shared gitlab runners and have the jobs run out of a docker container just like we do for llvmpipe. Just make sure that the DRI device node is passed through to the containers in the gitlab config ('devices = ["/dev/dri"]' under runners.docker). If a runner fails (networking dies, kernel panic, etc.) it'll take out one build but the rest can keep going since gitlab-runner is what pulls jobs. Since the runner pulls jobs, it also means that they can live behind firewalls instead of needing some public address to be accessed by gitlab.fd.o. For now, enable it just on db410c (A307) and cheza (A630) as those are the hardware that I have plenty of. A307 is only testing GLES2 since running all of GLES3 takes too long for the number of boards I've brought up. Acked-by: Rob Clark <robdclark@chromium.org> Acked-by: Kenneth Graunke <kenneth@whitecape.org>
2019-06-29 07:35:32 +08:00
#!/bin/bash
set -e
set -o xtrace
############### Install packages for building
apt-get -y install ca-certificates
gitlab-ci: Bring ARM docker image install script in line with x86_64 Use https:// URLs in the APT configuration. Drop --no-install-recommends, the image generation template disables installation of recommended packages in /etc/apt/apt.conf. Run apt-get autoremove at the end, cleaning up packages which were installed to satisfy dependencies but are no longer needed. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-10-10 16:56:08 +08:00
sed -i -e 's/http:\/\/deb/https:\/\/deb/g' /etc/apt/sources.list
gitlab-ci: Enable llvmpipe in ARM build jobs v2: * Use LLVM 8 from buster-backports v3: * Use LLVM 7 again for armhf, llvmpipe is still broken there with LLVM 8 Acked-by: Eric Engestrom <eric.engestrom@intel.com>
2019-10-09 01:48:41 +08:00
echo 'deb https://deb.debian.org/debian buster-backports main' >/etc/apt/sources.list.d/backports.list
gitlab-ci: Use native aarch64 runner for ARM build jobs This allows running the regression tests. One downside is that we can't easily build the Vulkan overlay layer, because only x86 binaries of the glslang validator are available. If that's important, we could either use those binaries via qemu, or build it from source. v2: * Add :amd64 suffix to existing debian-9/10 job names (Eric Engestrom) Acked-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-10-09 01:46:11 +08:00
dpkg --add-architecture armhf
gitlab-ci: Bring ARM docker image install script in line with x86_64 Use https:// URLs in the APT configuration. Drop --no-install-recommends, the image generation template disables installation of recommended packages in /etc/apt/apt.conf. Run apt-get autoremove at the end, cleaning up packages which were installed to satisfy dependencies but are no longer needed. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-10-10 16:56:08 +08:00
apt-get update
apt-get -y install \
gitlab-ci: Sort ARM docker image packages in alphabetical order No functional change. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-10-10 00:48:17 +08:00
bc \
bison \
gitlab-ci: Use native aarch64 runner for ARM build jobs This allows running the regression tests. One downside is that we can't easily build the Vulkan overlay layer, because only x86 binaries of the glslang validator are available. If that's important, we could either use those binaries via qemu, or build it from source. v2: * Add :amd64 suffix to existing debian-9/10 job names (Eric Engestrom) Acked-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-10-09 01:46:11 +08:00
ccache \
crossbuild-essential-armhf \
gitlab-ci: Sort ARM docker image packages in alphabetical order No functional change. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-10-10 00:48:17 +08:00
flex \
freedreno: Introduce gitlab-based CI. Since freedreno's kernel and GPU reset seem to be totally solid, we don't need to have the complexity of the LAVA setup that panfrost has. Instead, we can register some boards as shared gitlab runners and have the jobs run out of a docker container just like we do for llvmpipe. Just make sure that the DRI device node is passed through to the containers in the gitlab config ('devices = ["/dev/dri"]' under runners.docker). If a runner fails (networking dies, kernel panic, etc.) it'll take out one build but the rest can keep going since gitlab-runner is what pulls jobs. Since the runner pulls jobs, it also means that they can live behind firewalls instead of needing some public address to be accessed by gitlab.fd.o. For now, enable it just on db410c (A307) and cheza (A630) as those are the hardware that I have plenty of. A307 is only testing GLES2 since running all of GLES3 takes too long for the number of boards I've brought up. Acked-by: Rob Clark <robdclark@chromium.org> Acked-by: Kenneth Graunke <kenneth@whitecape.org>
2019-06-29 07:35:32 +08:00
g++ \
gitlab-ci: Sort ARM docker image packages in alphabetical order No functional change. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-10-10 00:48:17 +08:00
gettext \
gitlab-ci: Don't build libdrm for ARM The Debian packages work fine. Saves a little bit of time and disk space. Reviewed-by: Eric Anholt <eric@anholt.net>
2019-11-05 23:24:35 +08:00
libdrm-dev \
gitlab-ci: Use native aarch64 runner for ARM build jobs This allows running the regression tests. One downside is that we can't easily build the Vulkan overlay layer, because only x86 binaries of the glslang validator are available. If that's important, we could either use those binaries via qemu, or build it from source. v2: * Add :amd64 suffix to existing debian-9/10 job names (Eric Engestrom) Acked-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-10-09 01:46:11 +08:00
libdrm-dev:armhf \
libelf-dev \
libelf-dev:armhf \
libexpat1-dev \
libexpat1-dev:armhf \
gitlab-ci: Sort ARM docker image packages in alphabetical order No functional change. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-10-10 00:48:17 +08:00
libssl-dev \
gitlab-ci: Enable llvmpipe in ARM build jobs v2: * Use LLVM 8 from buster-backports v3: * Use LLVM 7 again for armhf, llvmpipe is still broken there with LLVM 8 Acked-by: Eric Engestrom <eric.engestrom@intel.com>
2019-10-09 01:48:41 +08:00
llvm-7-dev:armhf \
llvm-8-dev \
gitlab-ci: Use native aarch64 runner for ARM build jobs This allows running the regression tests. One downside is that we can't easily build the Vulkan overlay layer, because only x86 binaries of the glslang validator are available. If that's important, we could either use those binaries via qemu, or build it from source. v2: * Add :amd64 suffix to existing debian-9/10 job names (Eric Engestrom) Acked-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-10-09 01:46:11 +08:00
meson \
freedreno: Introduce gitlab-based CI. Since freedreno's kernel and GPU reset seem to be totally solid, we don't need to have the complexity of the LAVA setup that panfrost has. Instead, we can register some boards as shared gitlab runners and have the jobs run out of a docker container just like we do for llvmpipe. Just make sure that the DRI device node is passed through to the containers in the gitlab config ('devices = ["/dev/dri"]' under runners.docker). If a runner fails (networking dies, kernel panic, etc.) it'll take out one build but the rest can keep going since gitlab-runner is what pulls jobs. Since the runner pulls jobs, it also means that they can live behind firewalls instead of needing some public address to be accessed by gitlab.fd.o. For now, enable it just on db410c (A307) and cheza (A630) as those are the hardware that I have plenty of. A307 is only testing GLES2 since running all of GLES3 takes too long for the number of boards I've brought up. Acked-by: Rob Clark <robdclark@chromium.org> Acked-by: Kenneth Graunke <kenneth@whitecape.org>
2019-06-29 07:35:32 +08:00
pkg-config \
python \
gitlab-ci: Use native aarch64 runner for ARM build jobs This allows running the regression tests. One downside is that we can't easily build the Vulkan overlay layer, because only x86 binaries of the glslang validator are available. If that's important, we could either use those binaries via qemu, or build it from source. v2: * Add :amd64 suffix to existing debian-9/10 job names (Eric Engestrom) Acked-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-10-09 01:46:11 +08:00
python3-mako \
freedreno: Introduce gitlab-based CI. Since freedreno's kernel and GPU reset seem to be totally solid, we don't need to have the complexity of the LAVA setup that panfrost has. Instead, we can register some boards as shared gitlab runners and have the jobs run out of a docker container just like we do for llvmpipe. Just make sure that the DRI device node is passed through to the containers in the gitlab config ('devices = ["/dev/dri"]' under runners.docker). If a runner fails (networking dies, kernel panic, etc.) it'll take out one build but the rest can keep going since gitlab-runner is what pulls jobs. Since the runner pulls jobs, it also means that they can live behind firewalls instead of needing some public address to be accessed by gitlab.fd.o. For now, enable it just on db410c (A307) and cheza (A630) as those are the hardware that I have plenty of. A307 is only testing GLES2 since running all of GLES3 takes too long for the number of boards I've brought up. Acked-by: Rob Clark <robdclark@chromium.org> Acked-by: Kenneth Graunke <kenneth@whitecape.org>
2019-06-29 07:35:32 +08:00
wget \
gitlab-ci: Sort ARM docker image packages in alphabetical order No functional change. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-10-10 00:48:17 +08:00
zlib1g-dev
freedreno: Introduce gitlab-based CI. Since freedreno's kernel and GPU reset seem to be totally solid, we don't need to have the complexity of the LAVA setup that panfrost has. Instead, we can register some boards as shared gitlab runners and have the jobs run out of a docker container just like we do for llvmpipe. Just make sure that the DRI device node is passed through to the containers in the gitlab config ('devices = ["/dev/dri"]' under runners.docker). If a runner fails (networking dies, kernel panic, etc.) it'll take out one build but the rest can keep going since gitlab-runner is what pulls jobs. Since the runner pulls jobs, it also means that they can live behind firewalls instead of needing some public address to be accessed by gitlab.fd.o. For now, enable it just on db410c (A307) and cheza (A630) as those are the hardware that I have plenty of. A307 is only testing GLES2 since running all of GLES3 takes too long for the number of boards I've brought up. Acked-by: Rob Clark <robdclark@chromium.org> Acked-by: Kenneth Graunke <kenneth@whitecape.org>
2019-06-29 07:35:32 +08:00
gitlab-ci: Use native aarch64 runner for ARM build jobs This allows running the regression tests. One downside is that we can't easily build the Vulkan overlay layer, because only x86 binaries of the glslang validator are available. If that's important, we could either use those binaries via qemu, or build it from source. v2: * Add :amd64 suffix to existing debian-9/10 job names (Eric Engestrom) Acked-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-10-09 01:46:11 +08:00
############### Generate cross build file for Meson
cross_file="/cross_file-armhf.txt"
/usr/share/meson/debcrossgen --arch armhf -o "$cross_file"
# Explicitly set ccache path for cross compilers
sed -i "s|/usr/bin/\([^-]*\)-linux-gnu\([^-]*\)-g|/usr/lib/ccache/\\1-linux-gnu\\2-g|g" "$cross_file"
# Don't need wrapper for armhf executables
sed -i -e '/\[properties\]/a\' -e "needs_exe_wrapper = False" "$cross_file"
freedreno: Introduce gitlab-based CI. Since freedreno's kernel and GPU reset seem to be totally solid, we don't need to have the complexity of the LAVA setup that panfrost has. Instead, we can register some boards as shared gitlab runners and have the jobs run out of a docker container just like we do for llvmpipe. Just make sure that the DRI device node is passed through to the containers in the gitlab config ('devices = ["/dev/dri"]' under runners.docker). If a runner fails (networking dies, kernel panic, etc.) it'll take out one build but the rest can keep going since gitlab-runner is what pulls jobs. Since the runner pulls jobs, it also means that they can live behind firewalls instead of needing some public address to be accessed by gitlab.fd.o. For now, enable it just on db410c (A307) and cheza (A630) as those are the hardware that I have plenty of. A307 is only testing GLES2 since running all of GLES3 takes too long for the number of boards I've brought up. Acked-by: Rob Clark <robdclark@chromium.org> Acked-by: Kenneth Graunke <kenneth@whitecape.org>
2019-06-29 07:35:32 +08:00
apt-get purge -y \
gitlab-ci: Use native aarch64 runner for ARM build jobs This allows running the regression tests. One downside is that we can't easily build the Vulkan overlay layer, because only x86 binaries of the glslang validator are available. If that's important, we could either use those binaries via qemu, or build it from source. v2: * Add :amd64 suffix to existing debian-9/10 job names (Eric Engestrom) Acked-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-10-09 01:46:11 +08:00
wget
gitlab-ci: Bring ARM docker image install script in line with x86_64 Use https:// URLs in the APT configuration. Drop --no-install-recommends, the image generation template disables installation of recommended packages in /etc/apt/apt.conf. Run apt-get autoremove at the end, cleaning up packages which were installed to satisfy dependencies but are no longer needed. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-10-10 16:56:08 +08:00
apt-get autoremove -y --purge
Reference in New Issue Copy Permalink