Re: Problem with the package builds

On Tue, Jul 11, 2023 at 9:15 PM Mark Millard <marklmi@yahoo.com> wrote:

> On Jul 11, 2023, at 21:05, Kevin Oberman <rkoberman@gmail.com> wrote:
>
> > On Tue, Jul 11, 2023 at 1:10 PM Mark Millard <marklmi@yahoo.com> wrote:
> > On Jul 11, 2023, at 12:57, Kevin Oberman <rkoberman@gmail.com> wrote:
> >
> > > On Mon, Jul 10, 2023 at 9:42 PM Mark Millard <marklmi@yahoo.com>
> wrote:
> > > On Jul 10, 2023, at 21:27, Rainer Hurling <rhurlin@gwdg.de> wrote:
> > >
> > > > As I understand it, the ports-mgmt/pkg of the system running
> Poudriere must be updated beforehand?
> > > >
> > > > At least on my side, this seems to work as expected :)
> > > >
> > >
> > > poudriere builds pkg updates first (if needed) and then uses the pkg it
> > > built for building the later ports into packages.
> > >
> > > But, after the restarts of main-* builds, the FreeBSD build servers are
> > > still showing examples were, after an 1hr, some builds are still in
> > > build-depends. Also there was an example I saw were after 1.5 hr it was
> > > still in run-depends.
> > >
> > > It may be that things are improved but not fully fixed relative to
> > > some performance issues.
> > >
> > > ===
> > > Mark Millard
> > > marklmi at yahoo.com
> > >  A new build started this morning at 1:06 UTC and, with pkg-1.20.2,
> it's better, but not much. It's running at 21 packages/hour, a 100%
> improvement on the last attempt which appears to have been killed last
> night. The logs indicate the installation of dependencies, but I don't see
> any sign of caching. It's a re-install every time. (I may not understand
> how poudriere does things, but I am pretty sure that caching is done.)
> >
> > Just about "caching" relative to "poudriere bulk" builds . . .
> >
> > Nope. At the end of a builder run of a port build the context is
> destroyed.
> > At the start of the builder building its next port the context is
> recreated
> > from scratch. The only ports installed are exactly the declared
> dependencies,
> > no more, no less, for the new port to be built.
> >
> > Caching installed state would imply access to ports from prior build
> > activity that do not apply: It would make the build environment polluted
> with
> > irrelevant history. poudriere's purpose is to have a "clean-room"
> context for
> > each port build. Thus its construction of such a context for each port
> build.
> >
> > Caching vs. not is not the source of the large increase in how long
> things
> > take to build.
> >
> > ===
> > Mark Millard
> > marklmi at yahoo.com
> > OK. I knew it started in a clean jail. I just thought that it might use
> some caching technique to speed repeated installs of a single port... not
> that I have any idea of how this might be done.
> >
> > I think I'll monitor the speed of installs. I iish build logs included
> timestamps
>
> FYI: Freshports now shows a pkg 1.20.3 described with:
>
> pkg*: new regression fixes release
>
> Changes:
> - speed up pkg add again, and greatly reduce its memory footprint
> - more compatibility with libfetch (SSL_* variables)
> - fixed FETCH_TIMEOUT adaptation to libcurl
>
> Looks to have been committed about 16 hr ago.
>
> Last I looked the official package builders had not been stopped
> and restarted with a newer ports tree yet.
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
> As I expected, each package install takes a very long time. It appears
that the average time to install a package with 1.20.2 was running about
45-50 seconds. Hopefully this latest update will fix that.
No rush to stop the current build, I guess. The next build won't start
until 1:00 UTC tomorrow. It might be that Bapt wants some time to work with
it before. killing the current build or just entered a request to the
builds manager in some timezone who sees no rush.
-- 
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkoberman@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683