groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Disposition of groff 1.23.0.rc4 feedback issues


From: G. Branden Robinson
Subject: Disposition of groff 1.23.0.rc4 feedback issues
Date: Thu, 20 Apr 2023 15:00:45 -0500

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.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]