All of lore.kernel.org
 help / color / mirror / Atom feed
From: Warner Losh <imp@bsdimp.com>
To: Gerd Hoffmann <gerd@kraxel.org>
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Ed Maste" <emaste@freebsd.org>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Li-Wen Hsu" <lwhsu@freebsd.org>
Subject: Re: FreeBSD build regressions
Date: Fri, 19 Feb 2021 09:08:18 -0700	[thread overview]
Message-ID: <CANCZdfqx+kCTkkw3jbDUwJB77DH0Qm3q8BpOY6-YJzKdY1eJeQ@mail.gmail.com> (raw)
In-Reply-To: <20210219152408.34ibwagyqzgye4yd@sirius.home.kraxel.org>

[-- Attachment #1: Type: text/plain, Size: 3660 bytes --]

First off, sorry for the hassles this caused... The problem is a failure to
upgrade for reasons explained below... While the reasons make sense, it's
still a bit of a hassle, for which I apologize.

On Fri, Feb 19, 2021 at 8:51 AM Gerd Hoffmann <gerd@kraxel.org> wrote:

> On Fri, Feb 19, 2021 at 10:41:44AM +0000, Peter Maydell wrote:
> > On Fri, 19 Feb 2021 at 10:39, Alex Bennée <alex.bennee@linaro.org>
> wrote:
> > >
> > >
> > > Hi,
> > >
> > > It looks like the build has been broken on Cirrus since at least
> 7b2c4c:
> > >
> > >   https://cirrus-ci.com/github/qemu/qemu
> > >
> > > I did attempt to have a look but "vm-build-freebsd" seems to be failing
> > > with a different error
> >
> > FWIW the vm-build-freebsd build-and-test works for me, as I
> > continue to run it as part of the merge tests. Is this something
> > to do with whether you already have a freebsd image cached
> > as opposed to it getting re-built from scratch (perhaps with
> > a newer FreeBSD)?
>
> The base image should be the same no matter what (updating that needs a
> tests/vm/freebsd update which in turn triggers a rebuild).  The addon
> package versions may differ though, so in case a broken package enters
> the freebsd package repos it may happen that old, existing vm images
> continue to work whereas newly created images don't ...
>
> Trying to rebuild the freebsd image here results in this:
>
> [ ... ]
> ### Installing packages ...
> Bootstrapping pkg from pkg+
> http://pkg.FreeBSD.org/FreeBSD:12:amd64/quarterly, please wait...
> Verifying signature with trusted certificate pkg.freebsd.org.2013102301...
> done
> Installing pkg-1.16.1...
> Newer FreeBSD version for package pkg:
> To ignore this error set IGNORE_OSVERSION=yes
> - package: 1202000                          <- freebsd 12.2 expected ?
> - running kernel: 1201000                   <- freebsd 12.1 running ?
> Ignore the mismatch and continue? [y/N]:
>
> So it seems the freebsd 12.1 images tries to fetch 12.2 packages when
> running "pkg install -y <list>", which would explain why they don't
> work.
>

FreeBSD 12.1 images fetch the FreeBSD 12 packages. This works until FreeBSD
12.1 hits end of life and the packages are built on newer versions. There's
no long-term support for releases once a new minor release happens. The
economics of this quickly get out of hand as the testing matrix explodes
and the number of machines needed to support all old versions (even on
supported branches) would be prohibitively expensive.


> Switching to freebsd 12.2 should solve this, at least until 12.3 is
> released, but I'm wondering why the freebsd pkg utility fetches
> incompatible packages in the first place and whenever there is any
> way to avoid this ...
>

FreeBSD builds packages on the oldest supported version in the stable
branch. Due to forward compatibility, that means all supported versions of
FreeBSD 12.x will work. Recently, FreeBSD 12.1 became unsupported, so the
build machines clicked forward to 12.2. Since there's no 'forward
compatibility' guarantees, this problem was hit. While you can run binaries
compiled on old versions of the software on new versions of the system, you
can't necessarily do the inverse because new symbols are introduced (in
this case close_range).

The base FreeBSD image should be rolled when new versions are released to
avoid this issue. tests/vm/freebsd should be updated. I have a full
morning, but if nobody has beat me to it, I'll submit a patch this
afternoon to fix this and add it to my list of things to do when FreeBSD
creates a new release.

Warner

[-- Attachment #2: Type: text/html, Size: 4658 bytes --]

  reply	other threads:[~2021-02-19 16:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-19 10:29 FreeBSD build regressions Alex Bennée
2021-02-19 10:41 ` Peter Maydell
2021-02-19 10:58   ` Alex Bennée
2021-02-19 15:05     ` Warner Losh
2021-02-19 15:24   ` Gerd Hoffmann
2021-02-19 16:08     ` Warner Losh [this message]
2021-02-19 16:13       ` Peter Maydell
2021-02-19 18:28         ` Warner Losh
2021-02-19 10:42 ` Daniel P. Berrangé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANCZdfqx+kCTkkw3jbDUwJB77DH0Qm3q8BpOY6-YJzKdY1eJeQ@mail.gmail.com \
    --to=imp@bsdimp.com \
    --cc=alex.bennee@linaro.org \
    --cc=emaste@freebsd.org \
    --cc=gerd@kraxel.org \
    --cc=lwhsu@freebsd.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.