Re: gitlab-ci: Do not use the standard container images from gitlab

[Thomas Huth <thuth@redhat.com>]

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