4789f9d3 | 20-Nov-2023 |
Greg Manning <gmanning@rapitasystems.com> |
plugins: fix win plugin tests on cross compile
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1972
Cross compile gcc is more picky about argument order than msys. Changed the meson command
plugins: fix win plugin tests on cross compile
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1972
Cross compile gcc is more picky about argument order than msys. Changed the meson command to take the (now renamed) libqemu_plugin_api.a as a lib, rather than an object. This puts it in the right place on both native and cross compile gcc commands
Reenable plugins on crossbuilds
Signed-off-by: Greg Manning <gmanning@rapitasystems.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20231109124326.21106-2-gmanning@rapitasystems.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231120150833.2552739-5-alex.bennee@linaro.org>
show more ...
|
8e721c32 | 20-Nov-2023 |
Alex Bennée <alex.bennee@linaro.org> |
tests/docker: merge debian-native with debian-amd64
debian-native isn't really needed and suffers from the problem of tracking a distros dependencies rather than the projects. With a little surgery
tests/docker: merge debian-native with debian-amd64
debian-native isn't really needed and suffers from the problem of tracking a distros dependencies rather than the projects. With a little surgery we can make the debian-amd64 container architecture neutral and allow people to use it to build a native QEMU.
Rename it so it follows the same non-arch pattern of the other distro containers.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Anders Roxell <anders.roxell@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231120150833.2552739-4-alex.bennee@linaro.org>
show more ...
|
7528ef73 | 20-Nov-2023 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
.gitlab-ci.d/cirrus: Upgrade macOS to 13 (Ventura)
macOS 14 "Sonoma" was released on September 2023 [1].
According to QEMU's support policy, we stop supporting the previous major release two years
.gitlab-ci.d/cirrus: Upgrade macOS to 13 (Ventura)
macOS 14 "Sonoma" was released on September 2023 [1].
According to QEMU's support policy, we stop supporting the previous major release two years after the the new major release has been published. Replace the macOS 12 (Monterey) testing by macOS 13 (Ventura, released on October 2022, [2]).
Refresh the generated files by running:
$ make lcitool-refresh
[1] https://www.apple.com/newsroom/2023/09/macos-sonoma-is-available-today/ [2] https://www.apple.com/newsroom/2022/10/macos-ventura-is-now-available/
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20231108162022.76189-1-philmd@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231120150833.2552739-3-alex.bennee@linaro.org>
show more ...
|
7ccb4153 | 29-Oct-2023 |
Alex Bennée <alex.bennee@linaro.org> |
tests/docker: use debian-all-test-cross for sparc64
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat conta
tests/docker: use debian-all-test-cross for sparc64
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat containers built by lcitool we might as well merge the other random debian based compilers into the same one used on gitlab.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-15-alex.bennee@linaro.org>
show more ...
|
26025d8e | 29-Oct-2023 |
Alex Bennée <alex.bennee@linaro.org> |
tests/docker: use debian-all-test-cross for riscv64
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat conta
tests/docker: use debian-all-test-cross for riscv64
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat containers built by lcitool we might as well merge the other random debian based compilers into the same one used on gitlab.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-14-alex.bennee@linaro.org>
show more ...
|
b09bb6d1 | 29-Oct-2023 |
Alex Bennée <alex.bennee@linaro.org> |
tests/docker: use debian-all-test-cross for mips
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat containe
tests/docker: use debian-all-test-cross for mips
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat containers built by lcitool we might as well merge the other random debian based compilers into the same one used on gitlab.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-13-alex.bennee@linaro.org>
show more ...
|
92a3165e | 29-Oct-2023 |
Alex Bennée <alex.bennee@linaro.org> |
tests/docker: use debian-all-test-cross for mips64
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat contai
tests/docker: use debian-all-test-cross for mips64
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat containers built by lcitool we might as well merge the other random debian based compilers into the same one used on gitlab.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-12-alex.bennee@linaro.org>
show more ...
|
9d9a5736 | 29-Oct-2023 |
Alex Bennée <alex.bennee@linaro.org> |
tests/docker: use debian-all-test-cross for m68k
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat containe
tests/docker: use debian-all-test-cross for m68k
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat containers built by lcitool we might as well merge the other random debian based compilers into the same one used on gitlab.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-11-alex.bennee@linaro.org>
show more ...
|
95f5bf95 | 29-Oct-2023 |
Alex Bennée <alex.bennee@linaro.org> |
tests/docker: use debian-all-test-cross for hppa
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat containe
tests/docker: use debian-all-test-cross for hppa
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat containers built by lcitool we might as well merge the other random debian based compilers into the same one used on gitlab.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-10-alex.bennee@linaro.org>
show more ...
|
eb4cb4ed | 29-Oct-2023 |
Alex Bennée <alex.bennee@linaro.org> |
tests/docker: use debian-all-test-cross for power
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat contain
tests/docker: use debian-all-test-cross for power
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat containers built by lcitool we might as well merge the other random debian based compilers into the same one used on gitlab.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-9-alex.bennee@linaro.org>
show more ...
|
d004e27b | 29-Oct-2023 |
Alex Bennée <alex.bennee@linaro.org> |
tests/docker: use debian-legacy-test-cross for alpha
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat cont
tests/docker: use debian-legacy-test-cross for alpha
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat containers built by lcitool we might as well merge the other random debian based compilers into the same one used on gitlab.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-7-alex.bennee@linaro.org>
show more ...
|
6f6c3999 | 29-Oct-2023 |
Alex Bennée <alex.bennee@linaro.org> |
gitlab: clean-up build-soft-softmmu job
Having dropped alpha we also now drop xtensa as we don't have the compiler in this image. It's not all doom and gloom though as a number of other targets have
gitlab: clean-up build-soft-softmmu job
Having dropped alpha we also now drop xtensa as we don't have the compiler in this image. It's not all doom and gloom though as a number of other targets have gained softmmu TCG tests so we can add them. We will take care of the other targets with their own containers in future commits.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-5-alex.bennee@linaro.org>
show more ...
|
78ebc00b | 09-Oct-2023 |
Alex Bennée <alex.bennee@linaro.org> |
gitlab: shuffle some targets and reduce avocado noise
We move a couple of targets out of the avocado runs because there are no tests to run. Tricore already has some coverage. The cris target only
gitlab: shuffle some targets and reduce avocado noise
We move a couple of targets out of the avocado runs because there are no tests to run. Tricore already has some coverage. The cris target only really has check-tcg tests but its getting harder to find anything that packages the compiler.
To reduce the noise of CANCEL messages we also set AVOCADO_TAGS appropriately so we filter down the number of tests we attempt.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231009164104.369749-5-alex.bennee@linaro.org>
show more ...
|
eca74afd | 14-Sep-2023 |
Daniel P. Berrangé <berrange@redhat.com> |
gitlab: make Cirrus CI jobs gating
The Cirrus CI jobs have been non-gating for a while to let us build confidence in their reliability. Aside from periodic dependancy problems when FreeBSD Ports swi
gitlab: make Cirrus CI jobs gating
The Cirrus CI jobs have been non-gating for a while to let us build confidence in their reliability. Aside from periodic dependancy problems when FreeBSD Ports switches to be based on a new FreeBSD image version, the jobs have been reliable. It is thus worth making them gating to prevent build failures being missed during merges.
Signed-off-by: "Daniel P. Berrangé" <berrange@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230912184130.3056054-5-berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20230914155422.426639-8-alex.bennee@linaro.org>
show more ...
|
c576d8bf | 14-Sep-2023 |
Daniel P. Berrangé <berrange@redhat.com> |
gitlab: make Cirrus CI timeout explicit
On the GitLab side we're invoking the Cirrus CI job using the cirrus-run tool which speaks to the Cirrus REST API. Cirrus sometimes tasks 5-10 minutes to actu
gitlab: make Cirrus CI timeout explicit
On the GitLab side we're invoking the Cirrus CI job using the cirrus-run tool which speaks to the Cirrus REST API. Cirrus sometimes tasks 5-10 minutes to actually schedule the task, and thus the execution time of 'cirrus-run' inside GitLab will be slightly longer than the execution time of the Cirrus CI task.
Setting the timeout in the GitLab CI job should thus be done in relation to the timeout set for the Cirrus CI job. While Cirrus CI defaults to 60 minutes, it is better to set this explicitly, and make the relationship between the jobs explicit
Signed-off-by: "Daniel P. Berrangé" <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230912184130.3056054-4-berrange@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20230914155422.426639-7-alex.bennee@linaro.org>
show more ...
|