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
