Taylor R Campbell <riastradh%NetBSD.org@localhost> writes:
>> Date: Sun, 14 Jul 2024 08:53:29 -0400
>> From: Greg Troxel <gdt%lexort.com@localhost>
>>
>> The netbsd-10 official package builds for i386 and amd64 are troubled.
>> There is a PR open about this, which I was not aware of. I'm posting
>> the link in the hopes that someone who understands python has a useful
>> comment.
>>
>> http://gnats.netbsd.org/58401
>
> If we had a process with a well-defined criterion for when we switch
> the symlink, a well-defined target that people could collaboratively
> focus on and work on fixing, maybe we would have noticed this before
> switching the symlink and putting egg all over our faces like we seem
> to do every quarter.
It is well defined; you just don't like the definition. Please stop the
misinformation.
We have not switched the symlink, and your complaints about process are
totally orthogonal to the current situation. The 10 builds for
i386/amd64 had about half the packages as usual. It turns out it was
already fixed, but that the pullups for the regreSSHion problem caused
some minor trouble, now also fixed.
> Apparently the pkg_summary.gz for the amd64 10.0_2024Q2 directory has
> also failed to update for weeks:
>
> -rw-rw-r-- 1 pkgmastr netbsd 3315698 Jun 28 17:24 pkg_summary.gz
huh, interesting and I suspect once pointed out that will be resolved.
> So, I have suggestions for how to proceed.
>
> 1. Endorse bulk-test-essential as a target.
We had this discussion before. The adopted policy values freshness for
security purposes over availability. That's not going to change on my watch.
However, if you read the other message, it says "firefox doesn't build
on 10 i386; does it build for anybody, and does anybody even try to use
it on that platform?". Which is exactly what you are suggesting.
> This way, we can either fix its dependencies, or discuss changing
> its dependencies if it can't be fixed -- but it's a conscious
> decision in reaction to an early alarm that we can collaborate on
> as a shared target, not a delayed reaction to weeks of festering
> problems that nobody noticed because we have no concretely testable
> quality assurance criteria.
Nbody noticed because apparently nobody is really using netbsd 10 i386 as
a desktop. Which is what I would expect.
Well, I de-installed firefox-esr from my virtual netbsd 9.x install because it was taking too much space ... And I never tried to install 10.0 i386, while I think it will be interesting branch (mostly due to udf work). I am a bit afraid about too fresh things breaking something I can't fix.
As far as I see Slackware -current still have firefox for i586:
64252680 Jul 09 20:05 mozilla-firefox-128.0esr-i686-1.txz
> bulk-test-essential is already tailored to the plausible successful
> package on various different architectures and operating systems,
> e.g. it doesn't expect firefox to build on m68k but it does expect
> it to build on amd64 and aarch64.
My perception is that it is overly resistant to adjusting to reality.