Re: [PATCH v1] automation: provide example for downloading an existing container

[Olaf Hering <olaf@xxxxxxxxx>]

Am Tue, 16 May 2023 11:46:00 -0700 (PDT)
schrieb Stefano Stabellini <sstabellini@xxxxxxxxxx>:

> I think you have a point that automation/build/README.md should also
> describe how to do what gitlab-ci does but locally (i.e. call
> automation/scripts/build). It should not only describe
> automation/scripts/containerize.

Meanwhile I have figured this out, additional variables must be set. I
already sent a patch for the example. That way I was able to
understand and reproduce the error seen in the CI build.

> https://gitlab.com/xen-project/xen/-/jobs/4284741849

It turned out this bug in qemu is triggered by debug=y vs. debug=n in
the build environment. I have not checked which commit exactly fixed it
in upstream qemu.git, it should probably be backported. Or qemu should
be moved forward to v8.x at some point. I think I have not seen this
specific failure in my own qemu.git builds.

The reason is: --enable-debug will disable _FORTIFY_SOURCE, so the build
succeeds. Without that flag, configure will enable _FORTIFY_SOURCE.

> Sure I see your point. On the other hand Tumbleweed jobs are the ones
> and only with "allow_failure". So among all the possible choices as
> example, do we really need to pick the one and only that has been
> failing for months? :-)

Yeah, this is exactly the point, to give copy&paste commands so that
contributors can investigate such failures locally.

I did not follow the state of the openSUSE builds in the past months. I
think Tumbleweed did succeed a few weeks ago because the last snapshot
was meanwhile one year old, and all gcc12 bugs are already fixed by now.


Olaf

Attachment: pgp8yCQ5WBx5c.pgp
Description: Digitale Signatur von OpenPGP