On Jan 27, 2025, at 6:23 PM, Theo Buehler <t...@theobuehler.org> 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.
Untested because my sparc64 is currently base-clang 19. Kurt can
you spot check this on a port that’s plist changed?
Also as an attachment because my Mac’s MUA mangles diffs.
Index: infrastructure/mk/arch-defines.mk
===================================================================
RCS file: /cvs/ports/infrastructure/mk/arch-defines.mk,v
diff -u -p -r1.109 arch-defines.mk
--- infrastructure/mk/arch-defines.mk 26 Oct 2024 14:00:10 -0000 1.109
+++ infrastructure/mk/arch-defines.mk 27 Jan 2025 23:37:38 -0000
@@ -101,6 +101,12 @@ _SYSTEM_VERSION-${ARCH} ?= 0
# added to version for all clang arches
_SYSTEM_VERSION-clang = 2
+# added to version for all gcc4 arches
+_SYSTEM_VERSION-gcc4 = 1
+
+# added to version for all gcc3 arches
+_SYSTEM_VERSION-gcc1 = 1
+
# defined in go.port.mk; added to version for all go arches so that
# go-compiled packages can be updated easily for a new go compiler
.if defined(MODULES) && ${MODULES:Mlang/go}
sysver.diff
Description: Binary data
