qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: QEMU's FreeBSD 13 CI job is failing


From: Warner Losh
Subject: Re: QEMU's FreeBSD 13 CI job is failing
Date: Tue, 20 Sep 2022 14:21:46 -0600



On Tue, Sep 20, 2022 at 2:57 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
On Tue, Sep 20, 2022 at 10:23:56AM +0200, Thomas Huth wrote:
> On 20/09/2022 10.21, Daniel P. Berrangé wrote:
> > On Tue, Sep 20, 2022 at 08:44:27AM +0200, Thomas Huth wrote:
> > >
> > > Seen here for example:
> > >
> > > https://gitlab.com/qemu-project/qemu/-/jobs/3050165356#L2543
> > >
> > > ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by
> > > /usr/local/lib/libpython3.9.so.1.0 not found
> > > ERROR: Cannot use '/usr/local/bin/python3', Python >= 3.6 is required.
> > >
> > > ... looks like the Python binary is not working anymore? Does anybody know
> > > what happened here?
> >
> > FreeBSD ports is only guaranteed to work with latest minor release
> > base image. The python binary recently started relying on symbols
> > in the 13.1 base image, and we're using 13.0.
> >
> > I updated lcitool last week to pick 13.1, so we just need a refresh
> > on the QEMU side to pick this up.
>
> OK ... Alex, IIRC you have a patch queued to update the files that are
> refreshed by lcitool ... does that already contain the update for FreeBSD,
> too?

Oh actually, I'm forgetting that QEMU doesn't use the 'lcitool manifest'
command for auto-generating the gitlab-ci.yml file. In QEMU's case just
manually edit .gitlab-ci.d/cirrus.yml to change

    CIRRUS_VM_IMAGE_NAME: freebsd-13-0

FreeBSD's support policy is that we EOL minor dot releases a few months after
the next minor release is final. Part of that process involves moving the build
of packages to that new minor version (which is what's not guaranteed to work
on older versions... only old binaries on new versions is guaranteed)...  And that's
the problem that was hit here.

I'll try to submit changes after the next minor release in that 'few month' window
to update this in the future. In general, doing so would be the best fit with FreeBSD's
support model...  It's one of those things I didn't think of at the time, but is obvious in
hindsight.

Warner

reply via email to

[Prev in Thread] Current Thread [Next in Thread]