Hi Branden, G. Branden Robinson wrote on Sun, Jan 18, 2026 at 03:40:13PM -0600: > At 2026-01-18T22:24:29+0100, Ingo Schwarze wrote:
[...] >> Logical directory names would be something like >> >> groff-1.24.0 >> groff-1.24.0rc1 >> groff-1.24.0.rc1 >> >> I think calling the tarball and directory "1.24.0rc1" would make more >> sense logically than "1.24.0.rc1" because "1.24.0" is the dotted >> version number and "rc1" is a suffix to it; "rc1" is not another >> number component of the version number. > That's true, but I find it important to distinguish this "fourth > component" of the version number from that stored in the `.Y` register, > and we've had problems in this area before. I had to look up what \n[.y] even is, and now i find it weird that this register exists at all. That's not something documents should access or depend on. Whatever, we have the usual problem of feature creep here: once a useless or detrimental feature has been added, it's hard to remove again because somebody is likely to have started depending on it, however unwisely. However, i regard .Y as totally unrelated to the naming of the release tarball. Isn't the obvious right thing to do to set the file and directory name to groff-1.24.0rc1 and set .Y to 0? > I'm having trouble tracking down citations, but it back around > 2017-2018. I think a release candidate was put out and it broke weirdly > for some people because the interpolated contents of the `.Y` register > were not a simple integer. Right, obviously setting .Y to "0rc1" would be wrong because .Y is documented as the "Minor version number" and "0rc1" is not the minor version number... Duh. > Sending to the list is fine. Fine, thanks for the feedback, will do. > Maybe Dave can help convert some of them into Savannah tickets. I'm not asking him to do work on my behalf, but of course, i would not complain either if he decides to help. :-) > We can judge things on a case-by-case basis. Likely, anything that > would require a code change will merit a Savannah ticket. Case by case sounds good! So, here is the second problem report. For now, i'm lazily quoting my preliminary commit message in the WIP port: ----- 8< ----- schnipp ----- >8 ----- 8< ----- schnapp ----- >8 ----- commit 63d225ba7e1a90988645fbec0d2e599c4732bb22 Author: Ingo Schwarze <[email protected]> Date: Mon Jan 19 11:15:42 2026 +0100 disable parallel builds for now Groff builds have a long history of blowing up in parallel mode, so let's first try to build at all before worrying about broken dependency rules and trying to get parallel building to work. Right now, a parallel build dies instantly with: cp -f ./font/devpdf/SS.in font/devpdf/SS make: don't know how to make font/devpdf/symbolsl.afm (prerequisite of: font/devpdf/stamp) Stop in /usr/ports/pobj/groff-1.24.0rc1/groff-1.23.0.5077-7dcc8 I hope to investigate later and report properly, this is clearly not a very useful report. For now: as soon as i remove -j from the make flags, the instant crash goes away and the build progresses a bit further before crashing for different reasons. diff --git a/Makefile b/Makefile index c79048d..856f70a 100644 --- a/Makefile +++ b/Makefile @@ -6,7 +6,7 @@ PKGNAME = groff-${VERSION}rc1 WRKDIST = ${WRKDIR}/groff-1.23.0.5077-7dcc8 CATEGORIES = textproc -DPB_PROPERTIES = parallel +#DPB_PROPERTIES = parallel HOMEPAGE = https://www.gnu.org/software/groff/ MAINTAINER = Ingo Schwarze <[email protected]> ----- 8< ----- schnipp ----- >8 ----- 8< ----- schnapp ----- >8 ----- The reason for not investigating properly at once is that i worry that if i do everything properly, testing might end up taking weeks. For 1.23, it ended up taking two years - with my now improved testing methodology, i hope it won't get as bad as that again, but still, given the history of groff builds, it would be unwise to not try to speed up as much as possible, even at the expense of making reports feel offensively lazy. That seems the only way to maximize the number of issues found before release. Yours, Ingo
