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 <t...@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 <k...@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 <t...@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.
