On Tue, Jun 24, 2025 at 1:41 PM Warner Losh <[email protected]> wrote: > > On Tue, Jun 24, 2025 at 11:16 AM Stefan Hajnoczi <[email protected]> wrote: > > > > On Tue, Jun 24, 2025 at 12:28 PM Warner Losh <[email protected]> wrote: > > > > > > On Tue, Jun 24, 2025 at 10:02 AM Thomas Huth <[email protected]> wrote: > > > > > > > > On 22/06/2025 03.46, Warner Losh wrote: > > > > > > > > > > > > > > > On Sat, Jun 21, 2025, 6:01 PM Stefan Hajnoczi <[email protected] > > > > > <mailto:[email protected]>> wrote: > > > > > > > > > > On Sat, Jun 21, 2025 at 7:59 PM Stefan Hajnoczi > > > > > <[email protected] > > > > > <mailto:[email protected]>> wrote: > > > > > > > > > > (I forgot to CC qemu-devel) > > > > > > > > > > > > > > > > > Hi, > > > > > > This might only be temporary, but the CI is getting HTTP 404 > > > > > Not Found > > > > > > for the following URL: > > > > > > > > > > > https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/14.1/ > > > > > FreeBSD-14.1-RELEASE-arm64-aarch64-bootonly.iso <https:// > > > > > download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/14.1/ > > > > > FreeBSD-14.1-RELEASE-arm64-aarch64-bootonly.iso> > > > > > > > > > > > > https://gitlab.com/qemu-project/qemu/-/jobs/10424901718#L848 > > > > > <https://gitlab.com/qemu-project/qemu/-/jobs/10424901718#L848> > > > > > > > > > > > > Stefan > > > > > > > > > > > > > > > Time to bump the version to 14.3. > > > > > > > > Hmm, while we're used to refresh the CI images for the *host* > > > > environments, > > > > it's rather ugly to see images for the *guests* of the functional tests > > > > disappear. Maybe we should rather remove that test if the URL is not > > > > stable? > > > > > > Yes. Most of our images have a shelf life of about a year to 18 months. > > > And QEMU > > > should be testing all the 'supported' FreeBSD images, just like for > > > other projects. > > > The question becomes how can we, the FreeBSD Project, remove the friction > > > that's > > > here now because we timeout / move the older images as they pass out of > > > support. > > > > > > We've also just shifted to a more frequent release cadence, so the > > > releases have gone > > > from living for 18-24 months down to just 12. We just released > > > FreeBSD 14.3, and 14.1 > > > is only a year old. So what's the best way of dealing with this? We > > > could have a 14-latest > > > but the md5 would change... > > > > > > So I'm open to making a change, but I need help crafting something > > > that will work, since > > > I'm not clever enough to suggest something here. > > > > A test run should be repeatable. If a test passes on a given qemu.git > > commit then it should continue to pass when run again. Using -latest > > breaks this property, so let's avoid it. > > > > Ideas: > > 1. FreeBSD provides convenient permanent URLs. > > 2. QEMU uses a permanent FreeBSD ISO mirror URL instead. Need to find > > a mirror that is fast and reliable. > > 3. Someone agrees to regularly update the URL in QEMU's test suite so > > that breakage isn't exposed. IMO the least desirable solution because > > an old copy of the test will start failing after 12 months. > > So there's two issues at play. > > FreeBSD does maintain all our archival releases forever. They never change. > But, we don't have permanent links to them today. We start with one URL and > then migrate to a second one when they transition from supported to > unsupported. > We do this, in part, to make sure people upgrade. So in effect, this breakage > means that our notion is "working" in the sense that the FreeBSD project's > goals > of making people "keep up to date." > > This does, I realize, clash with the views that QEMU wants to have some stable > way to test images over time, even if the upstream's notion of supported or > not > changes. > > One easy idea might be to 'prestage' the 'legacy' releases when they > are supported > on the 'legacy' server so that tests can be written with the legacy > path so that these > tests always work, now and in the future. > > So, this is terrible from a FreeBSD point of view. We'd like it if > qemu always tested > all of our releases, as well as snapshots of the tip of the spear. > There's got to be some > way to have some shared responsibility that we can automate. FreeBSD could > test > the most recent release of qemu against a bunch of images in our CI > cluster. But we > don't actually have a CI cluster we could put that into (our focus is > just a little different) > today. Ideally, your (3) above would happen as we rotate in new > versions and out old > versions of FreeBSD. But honestly, I'm the person (or one of the > people) that should > be keeping his eye on the ball, but we see how well that has worked > out. So the question > becomes is this a management failure (eg, someone/something needs to prompt me > or others in the FreeBSD project to update it via reminders, release > checklists, etc)? > Or is it something that can fixed by automations somehow? I don't know...
How about doing both: 1. Making the "legacy" URL available immediately so that anything that needs a permalink can use it (but they will explicitly specify the word "legacy" in the URL, which is a hint that it's not the latest and greatest release). 2. You set up a calendar reminder to send a patch updating QEMU's test suite to the latest FreeBSD release every 12 months. A shell script could perform the steps of updating the URL, committing the change, and sending a patch email. That way FreeBSD's latest release will be tested in a timely manner and a snapshot of the QEMU test suite will still pass after 12 months. What do you think? Stefan
