Hi Bertrand, I've pushed a new personal staging branch, branden-2023-04-20 to groff's Git repository. I've also pushed some documentation-only changes (meaning: changes to documentation files that affect only text, and don't require alteration of build scripts, Makefiles, etc.) to master since they are so low-risk.
I'm ready for the next tag; I don't know if you want to make another
release candidate and/or adjust the risk threshold for it given the
portability feedback from Bruno.
First the good news:
At 2023-04-15T23:05:18+0200, Bruno Haible wrote:
> On the following systems the build completes fine and all the tests pass:
>
> * Linux
> Ubuntu 22.04
> Debian 9.1
> Debian 11.1
> CentOS 8-stream
> CentOS Stream 9
> OpenSUSE Leap 15.2
> Manjaro 17
> * Hurd
> Debian GNU/Hurd
(I didn't see a report regarding macOS from Bruno, but it works for me
on gcc104.fsffrance.org, which uses macOS 12. Dave Kemper reports that
Mac OS X 10.11.6 will exhibit the pdfpic.tmac problem discussed below.)
The bad news can be summarized as follows:
* Two distinct complaints about ms(7)
1. raw .bp requests sometimes not working (Savannah #64005)
2. raw .sp requests being nilpotent sometimes
* Portability issues
3. build failure when building out of tree and the prerequisites for
running mom(7)'s test script are unavailable
4. build failure in gxditview on AIX
5. build failure with Sun C/C++ compiler due to use of GNU attribute
extension
6. build failure on MinGW due to platform not supplying <sys/wait.h>
7. test failure: gdiffmk
8. test failure: pdfpic.tmac
Here are my resolutions to the above, with their risk levels as
documented in "README.branch" on my branch.
1. fixed in 75e47ce637, risk level 5
2. addressed in documentation on master (NEWS) prior to RC4
(f9e84954174); reporter remains unhappy, but does not respond to
requests for more precise information
3. fixed in 9e07e434f2, risk level 3
4. fixed in e43becec56, risk level 3
5. fixed in 2a256b9889, risk level 6
6. fixed in a347f9c13a, risk level 3; depends on 26a92316b6, also risk
level 3
7. addressed in documentation on master (ANNOUNCE, PROBLEMS); this is
not a regression from groff 1.22.4, but exposed by (1) a defect
introduced in a recent GNU diffutils release; (2) Alpine Linux's use
of a non-GNU diff (BusyBox); and (3) FreeBSD's questionable
alteration of expr(1). I will see what I can do about these issues
for the next groff release, as Mike Bianchi has recently retired.[1]
8. addressed in documentation on master (ANNOUNCE, PROBLEMS); this is
also not a regression from groff 1.22.4, but a heretofore
undocumented dependency pdfpic.tmac has on a GNU sed (adopted by
recent versions of macOS sed as well, and therefore possibly by one
of the *BSDs as well).
Please advise which of the ones fixed on my branch you'd like me to
merge to master.
Regards,
Branden
[1] I can think of a couple of ways to work around the expr(1) problem
(both would be a risk level 4 changes). GNU diffutils has fixed
their bug but not yet done a release incorporating it. There's not
much we can do about diff(1) programs that don't implement the "-D"
option that gdiffmk(1) absolutely requires, except attempt to detect
this fact, and exit with a diagnostic and error status.
signature.asc
Description: PGP signature
