Re: snapshots 13 and 14 are gone

On Jan 8, 2022, at 5:27 AM, Emmanuel Vadot <manu@bidouilliste.com> wrote:
> 
> 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>
> 

Noted.

Glen
Sent from my phone.
Please excuse my brevity and/or typos.