On Sat, Jul 27, 2024 at 6:01 AM Mark Millard <mark...@yahoo.com> wrote: > > > > On Jul 26, 2024, at 20:28, Philip Paeps <phi...@freebsd.org> wrote: > > > On 2024-07-27 07:57:38 (+0800), Mark Millard wrote: > >> Michal Meloun <mmel_at_FreeBSD.org> wrote on > >> Date: Thu, 25 Jul 2024 16:25:09 UTC : > >> > >>> The branch main has been updated by mmel: > >>> > >>> URL: > >>> https://cgit.FreeBSD.org/src/commit/?id=5670b8cc3672d5a6bc2c41eb48d7d01343c43ad0 > >>> > >>> commit 5670b8cc3672d5a6bc2c41eb48d7d01343c43ad0 > >>> Author: Michal Meloun <m...@freebsd.org> > >>> AuthorDate: 2024-07-24 15:11:27 +0000 > >>> Commit: Michal Meloun <m...@freebsd.org> > >>> CommitDate: 2024-07-25 16:24:22 +0000 > >>> > >>> libthr: Preresolve selected EABI symbols on arm. > >>> > >>> Add the ability to pre-resolve architecture-specific EABI symbols and > >>> use it on arm for selected EABI functions. These functions can be > >>> called > >>> with rtld bind lock write-locked, so they should be resolved in > >>> forward. > >>> > >>> Reported by: Mark Millard <mark...@yahoo.com>, John F Carr > >>> <j...@mit.edu> > >>> Reviewed by: kib, imp > >>> MFC after: 1 week > >>> Differential Revision: https://reviews.freebsd.org/D46104 > >> > >> Philip Paeps is likely going to want to know if any releng/13.* or > >> releng/14.* > >> that would be in some jail(s) on ampere1 or ampere3 will be updated to have > >> the change. He likely would do a round of updating the jail content > >> vintages > >> in use for any such updated releng/13.* or releng/14.* . > >> > >> So: Any plans to have any already-supported release builds updated? > >> > >> Similarly: What of the upcoming 13.4-RELEASE that has made it to > >> -PRERELEASE > >> so far? > >> > >> (I'm not aware of active port building runs based on stable/13 or > >> stable/14 . But, if there are some, they would likely track the MFC updates > >> sometime after the MFC update was in place.) > > > > We don't build packages on stable branches. > > Not normally. But there the following existed at one time: > > 14stable-i386-default on beefy11.nyi.freebsd.org > <http://beefy11.nyi.freebsd.org/> > 14stable-amd64-default on beefy12.nyi.freebsd.org > <http://beefy12.nyi.freebsd.org/> > > They may have been very temporary and only for special test > runs for all I know. While the actual build history is gone > now, https://portsfallout.com/server still shows the names > under "build environment".
They were temporary when stable/14 was branched and releng/14.0 didn't exist yet > > Packages are produced on the earliest supported releng/x branch. > > Yep. My questions for releng/1[34].* do get into what will > be the definition of "supported versions" for at least > armv7. > > The armv7 jails need the fix if they are to avoid being > brittle, which gets into if a EN would be done to change > the definition of "support version" in order to avoid the > armv7 status. The rule about "earliest supported" would > then need to track the update if that gets such an EN > update. > > > I don't actually know how/when the builder jails get upgraded. > > For main to be fixed, the jails have to have been updated. > The host version of main does not (at least relative to > the code at hand). > > For any existing, supported releng/1[34].* to avoid being > brittle like main was, it would need an EN update and > both the base installation and the jails that would then > been intended to have avoided the armv7 status would need > to be updated. > > > That's a question for Antoine (Cc:ed) who manages the actual building. > > clusteradm only manages the base installations. The jails track releng branches, so if there is no EN they won't get the fix. Antoine > It may be that only main will be fixed unless an example > of the brittle status is observed in some supported > version (or new releng/*.* branch not yet released). > > === > Mark Millard > marklmi at yahoo.com
