[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 === Mark Millard marklmi at yahoo.com
