On Apr 6, 2025, at 08:39, Baptiste Daroussin <b...@freebsd.org> wrote:
> 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) Good to know. You might want to send out a HEADS UP style notice for folks that build their own packages. A lot of these folks do so in order to get security updates quicker as far as I can tell. A known large change to their build time frames could be important to their planning. It might be appropriate to suggest temporarily manually controlling the version of ports-mgmt/pkg used to be 2.0.6 (or before) for those for which time to build is the most important in the interim. It looks like ports-mgmt/poudreire* would not need to be controlled (yet?): It looks like ports-mgmt/poudreire has not been updated since 2024-08-25 . It looks like ports-mgmt/poudreire-devel has not been updated since 2025-02-09 . The notes may be of use to some others. For me, the likely implication is to stop updating my ports tree builds except on the fastest amd64 system and fastest aarch64 system and to stop building for armv7 for now. (The fastest aarch64 system does not support AArch32/armv7 and the fastest that does support such takes over 5 times as long compared to fastest aarch64 system.) Going in another direction of questions for folks that do their own bulk builds of packages: Context for the next paragraph: Already "using those features in the ports tree for real" for someone doing their own package builds: Will bulk -c builds (for example) always suffer the longer build times by not having prior information for reference (because of the -c)? What sorts of activities would destroy the information for the next build attempt if that is an issue, making the next build take the new, much-longer overall build time? For example, updating the poudriere jail's world? Context for the next paragraph: Just before "using those features in the ports tree for real" for someone doing their own package builds: How will one get to the point of "using those features in the ports tree for real"? How will a self-builder of packages get to the point of being able to test the build times in the "for real" context as well? > bapt Just for reference for official main-arm64-default bulk -c -a (from scratch) builds: p25bf3a3260c7_s680d34896c3 queued 36447 and has built 15523 and has 19479 remaining, 134:23:16 so far (will have built up to 15523+19479 == 35002 when done, if it finishes) So: 12 to 13 days (around 300 hrs) as an estimate. The prior longest main-arm64-default official build that completed: p02dd5021d6f9_s717adecbbb5 queued 36466 and had built 34853 and had 0 remaining, 163:20:35 So: 6.8 days or so. Overall: very roughly doubling the overall time when the "for real" context does not apply. === Mark Millard marklmi at yahoo.com
