On Sun 06 Apr 13:27, Mark Millard wrote: > [I thought of another question.] > > On Apr 6, 2025, at 10:53, Mark Millard <mark...@yahoo.com> wrote: > > > 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. > > Additional question . . . > > Which of the following are the stage(s) that take the extra > time for an active builder? : > > check-sanity > pkg-depends > fetch-depends > fetch > checksum > extract-depends > extract > patch-depends > patch > build-depends > lib-depends > configure > build > run-depends > stage > package >
All the -depends. Best regards, Bapt
