Le 5 avril 2025 06:58:12 GMT+02:00, Mark Millard <mark...@yahoo.com> a écrit : >[This is an update of earlier notes, now that I've noticed what >is different for the contexts that not seeing larger time frames >in the Mar-29/Apr-01 bulk build starts of official package builds.] > >The context here is the official bulk builds started >2025-Mar-29 (beefy 17 and beefy18) or 2025-Apr-01 . > >pkg 1.21.3 was in use on beefy 19 and beefy20. These did not get the >significantly longer time frames. > >pkg 2.1.0 was(/is) in use on: >(beefy17 and beefy18 are significantly slower hardware than beefy21 >and beefy22) > >beefy17 main-i386 168:11:08 vs. prior maximum 74:19:29 >beefy18 main-amd64 168:11:10+ (so far) vs. prior maximum 96:28:10 >(beefy18 still has 9338 Remaining and still has status parallel_build:) > >beefy21 142i386 50:40:16 vs. prior maximum 40:22:44 [141i386] >beefy22 142amd64 58:51:19 vs. prior maximum 49:37:29 [141amd64] > >Note that beefy17 took around 94 hrs longer, more than doubling the time. > >ampere2 main-arm64 is somewhat over 1/3 of the way along but also looks >to likely have a much longer overall time frame. > > >Note that beefy17 and beefy18 had/has: >(has large time changes) > >Host OSVERSION: 1500028 >Jail OSVERSION: 1500035 > >beefy19, beefy20, beefy21, and beefy22 had: >(mix of little vs. large time changes) > >Host OSVERSION: 1500035 >Jail OSVERSION: 1402000 > >ampere2's main-arm64 has: >(has large time changes) > >Host OSVERSION: 1500035 >Jail OSVERSION: 1500035 > >So: The new Host 1500035 use is not the cause. Nor is Jail 1402000 . > >=== >Mark Millard >marklmi at yahoo.com >
yes this is known and expected, because ofnthe support of provide/requires in a way the ports tree can use it (pkg add) we added some code which introduce performance penalty, we expect to be able to improve performance again by using those features in the ports tree for real (right now the work is in poudriere, then the features will be added to the ports tree) bapt
