[Just a couple of corrections to my preliminary list of beefy* and anoterh note.]
On Apr 24, 2025, at 00:59, Mark Millard <mark...@yahoo.com> wrote: > On Apr 23, 2025, at 20:10, Mark Millard <mark...@yahoo.com> wrote: > >> On Apr 23, 2025, at 19:25, Mark Millard <mark...@yahoo.com> wrote: >> >>> On Apr 23, 2025, at 15:22, Mark Millard <mark...@yahoo.com> wrote: >>> >>>> On Apr 23, 2025, at 14:38, Einar Bjarni Halldórsson <ei...@isnic.is> wrote: >>>>> >>>>> On 23 Apr 2025, at 18:44, Mark Millard <mark...@yahoo.com> wrote: >>>>>> >>>>>> pkg 2.1.1 used: 0e22efc407eaaaf0154cde4507fba27c9e3ca237 >>>>>> >>>>>> The prior 2.1.99.2 used: 01165121d076dfd090b101ce2915d786fea85381 >>>>>> (which is newer and has the fix that avoids the recursive install >>>>>> of the same port indefinately) >>>>>> >>>>> >>>>> I had to downgrade to pkg 2.1.0 from 2.1.1 to get poudriere to possibly >>>>> finish building some >>>>> R-cran-* ports (fingers crossed!). >>>>> >>>>> It looks like the recursive install bug you mentioned. >>>> >>>> pkg 2.1.1 generates .pkg files with incorrect content. >>>> (That is what can later lead to the recursive >>>> addition-start sequence.) >>>> >>>> So you likely will want to regenerate any .pkg file that >>>> pkg 2.1.1 generated. >>> >>> WARNING: >>> >>> Given the above, my expectation is that any build >>> server that is not using pkg 2.1.0 or before, should >>> be prevented from (continuing) to use pkg 2.1.1 . So: >>> stop any pkg 2.1.1 based build and prevent more >>> builder runs until there is a fixed pkg with a later >>> version number, even for any between-builds machines. >>> Needing to be stopped includes (as I write this): >>> >>> beefy16's 134amd64-default >>> beefy15's 134i386-default >>> beefy22's 142amd64-default >>> beefy21's 142i386-quarterly >>> beefy20's 142amd64-quarterly beefy21's 142i386-default [correction: was listed as quarterly] [WRONG: beefy20's 142amd64-quarterly is/was using pkg 2.1.0] >>> Any .pkg files created by these should be regenerated >>> with an fixed pkg. So "poudriere bulk -c -a" (from >>> scratch) based builds would seem likely. >>> >> >> I probably should also have explicitly mentioned that pkg's >> built by pgk 2.1.1 should probably not be distributed >> to anywhere (if that can be avoided). > > pkg 2.1.2 was committed and tested out as working for > my example amd64 and aarch64 build tests that showed > the failure of pkg 2.1.1 earlier. > > So so starting pkg 2.1.2 "poudriere bulk -c -a" on > systems that did build activity with pkg 2.1.1 > looks good. > > Avoiding distribution of any .pkg files built by > pkg 2.1.1 is appropraite. > > > Because of how long the "bulk -a" builds take > when pkg 2.1.0 is involved, the builds on: > > ampere1 > ampere2 > ampere3 > beefy13 > beefy14 > beefy17 > beefy18 > beefy19 beefy20 should have been listed here. beefy19 has only 13 Remaining: May not be worth stopping. beefy20 has only 13 Remaining: May not be worth stopping. > likely should be stopped and new ones started > based on pkg 2.1.2 . These need not be from > scratch builds, however. > > The extereme example of the time to build so > far was main-arm64 on ampere2: 21 and a > fraction days, where normal is more like > 6.8 days. > > [The pkg's built look to be okay. It is just that > pkg 2.1.0 can lead to the overall build time being > over 3 times normal for a "poudriere bulk -c -a" > (from scratch or near from scratch) type of build, > for example.] === Mark Millard marklmi at yahoo.com
