Re: [main has a fix for] armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023

On Jul 31, 2024, at 07:46, void <void@f-m.fm> wrote:

> On Fri, Jul 26, 2024 at 05:14:31PM -0700, Mark Millard wrote:
>> 
>> I assume that this wording is about having amd64 with qemu attempting
>> bulk -a for building amv7 packages, not about having aarch64 (without
>> qemu) bulk -a with armv7 jails do so (which are now being done). Have
>> I got that right?
>> 
>> If spreading the package-building load around more to amd64 contexts
>> was a goal, and if amd64 with qemu worked well for aarch64, one could
>> imagine having some of the aarch64 package builds on amd64 but all
>> the armv7 ones on the ampere*'s. This may be more likely to work
>> better overall than amd64 with qemu ever handling a 32-bit context
>> well (armv7 here).
> 
> Sort of adjacent to this discussion, but here's an idea:
> 
> Don't have tier2 platforms building on the same machinery as tier1.
> That way, issues like armv7 builds (for ports) running forever
> will never delay aarch64. Sure to be other issues that can be sidestepped
> with such an approach.

There are only 3 aarch64 build servers, all armv7 jail capable.
As stands, they are partitioned for building thus:

) ampere1 that builds for releng/1[34].* quarterly ( arm64 and armv7 )
) ampere2 that builds for main           latest    ( arm64 and armv7 )
) ampere3 that builds for releng/1[34].* latest    ( arm64 and armv7 )

===
Mark Millard
marklmi at yahoo.com