@Ed/Andrew, can one of you assign yourselves to this issue please Also worth noting whether/that these dependent port fixes should be MFH'd
While looking at an arm64 objdump issue (PR 212308) I took a look at the top 50 or so failing ports by # of downstream skipped packages. While looking at that, I noticed that the following ports that failed due to no sbrk: devel/libgtop devel/rvm graphics/graphviz lang/gauche sysutils/bacula-client sysutils/bacula5-client sysutils/bareos-client
See https://wiki.freebsd.org/arm64/ports#Missing_sbrk for the ports that have been marked BROKEN due to missing sbrk. Note that graphics/graphviz has been fixed for missing sbrk; see https://svnweb.freebsd.org/ports/head/graphics/graphviz/files/patch-lib-vmalloc-vmhdr.h?view=markup&pathrev=426075 .
Does the project plan to acquire another ports/ building box? thunderx1 is oversubscribed: -CURRENT builds are often weeks/months out of date and unnecessarily delay /latest updates for -RELEASE; full builds often crash. This makes QAing port fixes, finding regressions and figuring out remaining bustage harder. When pkg-fallout@ mail will be enabled by default? Increasing buy-in from maintainers maybe necessary before promoting to Tier1 e.g., https://lists.freebsd.org/pipermail/freebsd-ports/2017-July/109503.html linimion@ does a tremendous job of classifying bustage via BROKEN lines but there're many mistakes, spoiling the effort and adding to the burnout. And I no longer have time to analyze/fix bustage in ports that don't matter to me (only ~100 ports are on my radar). Contributors with actual aarch64 hardware are still rare, so few notice how much bustage is left.
Probably not needed any longer.