Currently all pipelines of the gitlab CI are failing, except for the
"build-user" pipeline. There is an issue with the default container
image (likely Debian stable) where they imported something bad in one
of the system headers:
/usr/include/linux/swab.h: In function '__swab':
/builds/huth/qemu/include/qemu/bitops.h:20:34: error: "sizeof" is not
defined, evaluates to 0 [-Werror=undef]
#define BITS_PER_LONG (sizeof (unsigned long) * BITS_PER_BYTE)
We could maybe work-around this issue or wait for the default containers
to get fixed, but considering that we use Ubuntu (and thus Debian-style)
CI in Travis already to a very large extent, we should consider to use
some RPM-based distros in our gitlab CI instead. Thus let's change the
failing pipelines to use Fedora and CentOS (and also one Ubuntu 19.10,
since 20.04 is broken, too) now.
Message-Id: <20200525131823.715-6-thuth@redhat.com>
Acked-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
.gitlab-ci.yml | 37 +++++++++++++++++++++++++------------
1 file changed, 25 insertions(+), 12 deletions(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 5208d93ff8..559ec2ab4d 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -5,9 +5,17 @@ include:
.update_apt_template: &before_script_apt
before_script:
- apt-get update -qq
- - apt-get install -y -qq libglib2.0-dev libpixman-1-dev genisoimage
+ - apt-get install -y -qq git gcc libglib2.0-dev libpixman-1-dev make
+ genisoimage
+
+.update_dnf_template: &before_script_dnf
+ before_script:
+ - dnf update -y
+ - dnf install -y bzip2 diffutils gcc git genisoimage findutils glib2-devel
+ make python3 perl-podlators perl-Test-Harness pixman-devel zlib-devel
build-system1:
+ image: ubuntu:19.10
<<: *before_script_apt
script:
- apt-get install -y -qq libgtk-3-dev libvte-dev nettle-dev libcacard-dev
@@ -21,11 +29,12 @@ build-system1:
- make -j2 check
build-system2:
- <<: *before_script_apt
+ image: fedora:latest
+ <<: *before_script_dnf
script:
- - apt-get install -y -qq libsdl2-dev libgcrypt-dev libbrlapi-dev libaio-dev
- libfdt-dev liblzo2-dev librdmacm-dev libibverbs-dev libibumad-dev
- libzstd-dev
+ - yum install -y SDL2-devel libgcrypt-devel brlapi-devel libaio-devel
+ libfdt-devel lzo-devel librdmacm-devel libibverbs-devel libibumad-devel
+ libzstd-devel
- mkdir build
- cd build
- ../configure --enable-werror --target-list="tricore-softmmu unicore32-softmmu
@@ -35,7 +44,8 @@ build-system2:
- make -j2 check
build-disabled:
- <<: *before_script_apt
+ image: fedora:latest
+ <<: *before_script_dnf
script:
- mkdir build
- cd build
@@ -50,9 +60,10 @@ build-disabled:
- make -j2 check-qtest SPEED=slow
build-tcg-disabled:
- <<: *before_script_apt
+ image: centos:8
+ <<: *before_script_dnf
script:
- - apt-get install -y -qq clang libgtk-3-dev libusb-dev
+ - dnf install -y clang gtk3-devel libusbx-devel libgcrypt-devel
- mkdir build
- cd build
- ../configure --cc=clang --enable-werror --disable-tcg --audio-drv-list=""
@@ -79,10 +90,11 @@ build-user:
- make run-tcg-tests-i386-linux-user run-tcg-tests-x86_64-linux-user
build-clang:
- <<: *before_script_apt
+ image: fedora:latest
+ <<: *before_script_dnf
script:
- - apt-get install -y -qq clang libsdl2-dev libattr1-dev libcap-ng-dev
- xfslibs-dev libiscsi-dev libnfs-dev libseccomp-dev gnutls-dev librbd-dev
+ - yum install -y clang SDL2-devel libattr-devel libcap-ng-devel xfsprogs-devel
+ libiscsi-devel libnfs-devel libseccomp-devel gnutls-devel librbd-devel
- mkdir build
- cd build
- ../configure --cc=clang --cxx=clang++ --enable-werror
@@ -92,7 +104,8 @@ build-clang:
- make -j2 check
build-tci:
- <<: *before_script_apt
+ image: centos:8
+ <<: *before_script_dnf
script:
- TARGETS="aarch64 alpha arm hppa m68k microblaze moxie ppc64 s390x x86_64"
- mkdir build
--
2.18.1
Hi, I am using debian 10 container to compile qemu too. I think that what happens here is that /usr/include/linux/swab.h Uses BITS_PER_LONG instead of __BITS_PER_LONG which is actually defined before in qemu at: include/qemu/bitops.h:#define BITS_PER_LONG (sizeof (unsigned long) * BITS_PER_BYTE) which injects this definition into the linux swab.h header. By changing BITS_PER_LONG to __BITS_PER_LONG in the linux headers, I managed to successfully compile qemu. A different approach would be to move the linux header includes (#include <linux/cdrom.h>) in file-posix.c above all other includes - which in some way makes more sense (since we probaly don't want qemu defines to control linux headers) but it requires a more complex refactoring.
Sam Eiderman <sameid@google.com> writes: > Hi, > > I am using debian 10 container to compile qemu too. > > I think that what happens here is that > > /usr/include/linux/swab.h > > Uses BITS_PER_LONG instead of __BITS_PER_LONG which is actually defined before > in qemu at: That is indeed the error - we are just waiting for Debian to update linux-libc-dev with the fix to the kernel headers: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960271 > > include/qemu/bitops.h:#define BITS_PER_LONG (sizeof (unsigned long) * BITS_PER_BYTE) > > which injects this definition into the linux swab.h header. > > By changing BITS_PER_LONG to __BITS_PER_LONG in the linux headers, I managed to > successfully compile qemu. > > A different approach would be to move the linux header includes > (#include <linux/cdrom.h>) in file-posix.c above all other includes - which in > some way makes more sense (since we probaly don't want qemu defines to control > linux headers) but it requires a more complex refactoring. -- Alex Bennée
Thanks for the link I do believe that the correct approach for me is to rename BITS_PER_LONG to __BITS_PER_LONG (I just added a sed command in my Dockerfile) and move on with my particular usage, however I am just wondering whether dropping debian10/ubuntu20 in the official qemu ci/ pipeline until it's fixed is the correct approach instead of keep failing it until the error resolves, in a way we want to always know on which OSs the compilation fails for visibility, no? Thanks again! On Sat, Jun 6, 2020 at 2:49 PM Alex Bennée <alex.bennee@linaro.org> wrote: > > > Sam Eiderman <sameid@google.com> writes: > > > Hi, > > > > I am using debian 10 container to compile qemu too. > > > > I think that what happens here is that > > > > /usr/include/linux/swab.h > > > > Uses BITS_PER_LONG instead of __BITS_PER_LONG which is actually defined before > > in qemu at: > > That is indeed the error - we are just waiting for Debian to update > linux-libc-dev with the fix to the kernel headers: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960271 > > > > > include/qemu/bitops.h:#define BITS_PER_LONG (sizeof (unsigned long) * BITS_PER_BYTE) > > > > which injects this definition into the linux swab.h header. > > > > By changing BITS_PER_LONG to __BITS_PER_LONG in the linux headers, I managed to > > successfully compile qemu. > > > > A different approach would be to move the linux header includes > > (#include <linux/cdrom.h>) in file-posix.c above all other includes - which in > > some way makes more sense (since we probaly don't want qemu defines to control > > linux headers) but it requires a more complex refactoring. > > > -- > Alex Bennée
On 06/06/2020 14.38, Sam Eiderman wrote: > Thanks for the link > > I do believe that the correct approach for me is to rename > BITS_PER_LONG to __BITS_PER_LONG (I just added a sed command in my > Dockerfile) and move on with my particular usage, however I am just > wondering whether dropping debian10/ubuntu20 in the official qemu ci/ > pipeline until it's fixed is the correct approach instead of keep > failing it until the error resolves, in a way we want to always know > on which OSs the compilation fails for visibility, no? Hi, that bug was only one reason to move the pipelines to another OS. The other reason is that we are already extensively testing various Ubuntu (and thus Debian-based) versions in the Travis CI - but did not test any RPM-based distros in the CI yet. Since Travis is bound to Ubuntu, we can not test Fedora/CentOS there, thus the Gitlab CI pipelines have now been moved to RPM-based distros (except for the "build-user" pipeline which is still using Debian, and the "build-system1" which is now using Ubuntu 19.04 instead, so I think we still have a good mix there). Note that the problem with Ubuntu 20.04 is also something completely different: It hangs in an interactive prompt during update and waits for user input, so that the pipelines finally times out: https://gitlab.com/huth/qemu/-/jobs/584573287#L800 If you know a work-around for that, we can move the build-system1 pipeline from 19.04 to 20.04 ... or if Debian gets finally fixed, we can also move that pipeline back to Debian. I'm fine either way, as long as the pipelines do not fail due to non-QEMU bugs in the distros. Thomas
I see, thanks for the clarification. However sometimes builds usually do tend to work on Ubuntu but fail to work on Debian since it's not always a 1-1 (as in this case) - so you might want to consider to keep testing Debian together with Ubuntu. Regarding the Ubuntu 20 problem - have you tried "export DEBIAN_FRONTEND=noninteractive"? didn't see it in the logs Sam On Sun, Jun 7, 2020 at 8:39 AM Thomas Huth <thuth@redhat.com> wrote: > > On 06/06/2020 14.38, Sam Eiderman wrote: > > Thanks for the link > > > > I do believe that the correct approach for me is to rename > > BITS_PER_LONG to __BITS_PER_LONG (I just added a sed command in my > > Dockerfile) and move on with my particular usage, however I am just > > wondering whether dropping debian10/ubuntu20 in the official qemu ci/ > > pipeline until it's fixed is the correct approach instead of keep > > failing it until the error resolves, in a way we want to always know > > on which OSs the compilation fails for visibility, no? > > Hi, > > that bug was only one reason to move the pipelines to another OS. The > other reason is that we are already extensively testing various Ubuntu > (and thus Debian-based) versions in the Travis CI - but did not test any > RPM-based distros in the CI yet. Since Travis is bound to Ubuntu, we can > not test Fedora/CentOS there, thus the Gitlab CI pipelines have now been > moved to RPM-based distros (except for the "build-user" pipeline which > is still using Debian, and the "build-system1" which is now using Ubuntu > 19.04 instead, so I think we still have a good mix there). > > Note that the problem with Ubuntu 20.04 is also something completely > different: It hangs in an interactive prompt during update and waits for > user input, so that the pipelines finally times out: > > https://gitlab.com/huth/qemu/-/jobs/584573287#L800 > > If you know a work-around for that, we can move the build-system1 > pipeline from 19.04 to 20.04 ... or if Debian gets finally fixed, we can > also move that pipeline back to Debian. I'm fine either way, as long as > the pipelines do not fail due to non-QEMU bugs in the distros. > > Thomas >
© 2016 - 2025 Red Hat, Inc.