On 2025/01/28 00:23, Theo Buehler wrote:
> On Mon, Jan 27, 2025 at 11:19:18PM +0000, Kurt Miller wrote:
> > On Jan 27, 2025, at 6:06 PM, Theo Buehler <tb@theobuehler.org> wrote:
> > >
> > > On Mon, Jan 27, 2025 at 11:00:03PM +0000, Kurt Miller wrote:
> > >> On Jan 27, 2025, at 4:50 PM, Kurt Mosiejczuk <kurt@cranky.work> wrote:
> > >>>
> > >>> On Thu, Jan 23, 2025 at 03:16:57PM +0000, Kurt Miller wrote:
> > >>>> On Jan 23, 2025, at 3:49 AM, Theo Buehler <tb@theobuehler.org> wrote:
> > >>>
> > >>>>>> Thoughts? If looks good, testing with a bulk build on amd64 and sparc64 would be
> > >>>>>> helpful to ensure I didn't miss a port that needs a REVISION bump.
> > >>>
> > >>>>> This went through an amd64 bulk with no fallout. I think you should land
> > >>>>> this and if there's sparc64 fallout, we can deal with it in tree.
> > >>>
> > >>>> Ok. Thanks for the bulk build and review. I have committed it and will
> > >>>> review the sparc64 bulk build logs for any missing REVISION bumps needed.
> > >>>
> > >>> Lots of fallout. I have domething that keeps the logs from sending out before
> > >>> my review if we have less than 9000 packages. This run has only produced 6998
> > >>> packages. I'll let these logs through, but we're probably looking at multiple
> > >>> runs of whackamole doing it this way.
> > >>
> > >> Can you tar up the logs so I can search them and see what's going on quicker?
> > >
> > > Look at
> > >
> > > https://cranky.work/sparc64/2025-01-26/summary.log
> > >
> > > Two obvious things with a huge chain of dependencies are
> > >
> > > nghttp3 -> curl -> ...
> > > glib2,bootstrap -> ...
> > >
> > > I bumped them. But if such crucial things are missed, this is indeed
> > > going to take a while.
> >
> > niobe$ grep -l "Error: change in plist" *.log | wc -l
> > 35
> >
> > Ugh this is a class of ports I didn't focus on… those that use
> > COMPILER = base-clang ports-gcc
> > for a c only port. While there are only 35 ports in this list, as you
> > point out they block other ports and this will become an iterative
> > process. Perhaps its better to bump arch-defines.mk SYSTEM_VERSION
> > for non-base clang arches?
>
> I was wondering the same. I'm not sure whether the plist db takes the
> system version into account though.
I don't _think_ it does. It definitely didn't in April 2019, but
something may have changed later.
To identify missed bumps I would take sqlports from the current snap,
grab output from "select fullpkgpath,wantlib order by fullpkgpath" and
diff against same from sqlports built from the current ports tree.
No comments:
Post a Comment