Re: snapshots 13 and 14 are gone

On Fri, 7 Jan 2022 17:20:45 +0000
Glen Barber <gjb@freebsd.org> wrote:

> On Fri, Jan 07, 2022 at 06:16:15PM +0100, Emmanuel Vadot wrote:
> > On Fri, 7 Jan 2022 17:13:11 +0000
> > Glen Barber <gjb@freebsd.org> wrote:
> > 
> > > On Fri, Jan 07, 2022 at 06:07:34PM +0100, Emmanuel Vadot wrote:
> > > > On Fri, 7 Jan 2022 12:55:21 +0000
> > > > Glen Barber <gjb@freebsd.org> wrote:
> > > > 
> > > > > On Fri, Jan 07, 2022 at 01:37:07PM +0100, Ronald Klop wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > The FreeBSD 13 and 14 snapshots are gone at https://download.freebsd.org/ftp/snapshots/arm64/ .
> > > > > > 
> > > > > > Is this a known issue? Can I help putting them back?
> > > > > > 
> > > > > 
> > > > > Yes, this is a known issue.  The qemu-user-static port had been failing
> > > > > to build on main and stable/13.  A commit to address that failure had
> > > > > been added yesterday, so we should have arm64 snapshots next week.
> > > > 
> > > >  But qemu is only needed for VM images, so why other thing like
> > > > snapshots and memstick image are missing ?
> > > > 
> > > 
> > > Hmm.  They're there, just not at the top-level directory Ronald pointed
> > > to.
> > > 
> > > https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/
> > > 
> > > I'll have to take a look at why that top-level directory does not have
> > > the appropriate symlinks.
> > > 
> > 
> >  There is no memstick images here, only the SBC images.
> > 
> 
> Ah, I see what is going on.  Since the VM image builds failed, the rest
> of the build fails, even though the memstick images are created.  I'll
> look into the logic in this failure case.
> 
> Glen
> 

 Honestly this isn't acceptable to not have images because of one
failure.
 This is also not acceptable as it's not the first time that someone
reports that some images are missing and each time you don't seems to
be aware of the problems, isn't there some verification that all the
images are built and published at the end of the re@ script and if not
a report is sent ?
 I've offered my help in the past and still do.

 I've talked with Colin this week and said to him that using
qemu-user-static was a big mistake. It was an absolute nice thing to
have when all we had was small armv7/arm64 SBC but now we have some big
iron thing that can build things natively fast.
 Using pkg(8) -r here is the solution, it works fine even when the arch
is different as long as the packages don't have postexec thing, and all
the packages that we need for VMs don't. And even if they have some
those could be converted to use pkg triggers for most of the case.
 There is only two calls to chroot which aren't pkg(8) related in
the script :
        chroot ${DESTDIR} ${EMULATOR} /usr/bin/newaliases
        chroot ${DESTDIR} ${EMULATOR} /bin/sh /etc/rc.d/ldconfig
forcestart

 The ldconfig is not necessary as we do it on boot, and the newaliases
I don't think it's needed too (and if it is we could always do
a /etc/rc.d/newaliases that is run on firstboot).

 The other easy solution would be to build the release images for arm64
on arm64.

 Cheers,

-- 
Emmanuel Vadot <manu@bidouilliste.com> <manu@FreeBSD.org>