On Tue, Sep 20, 2022 at 02:21:46PM -0600, Warner Losh wrote:
> 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.
It would be nice if something in the ports tool / packages was
able to report the incompatibility at time of install, rather
than leaving a later runtime failed.
Indeed. I've suggested it to the authors... There's some technical issues
around this and the package format they need to work out.
> 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.
Note, we're reliant on Cirrus CI actually publishing the new images
for use. I've not previously checked before how quickly they publish
them after FreeBSD does the upstream release, but anyway I go by what
they list here:
https://cirrus-ci.org/guide/FreeBSD/
Yea. They have been pretty good in the past about getting new images up
quickly after the release.
Warner