At 2022-05-26T13:13:44+0100, Colin Watson wrote: > On Wed, May 25, 2022 at 07:55:10PM -0500, G. Branden Robinson wrote: > > I apologize for filing this bug report a bit prematurely, but I've > > been working on building groff in a bullseye chroot lately to > > prepare for groff 1.23.0.rc2, and I wanted to document some findings > > while they were fresh in my mind. > > Thanks for this research!
My pleasure! > > * Add a dependency on m4. > > > > o m4 is now required to build. Any m4 that implements the > > features documented in the Version 7 Unix m4(1) man page, and the > > `-D` option, should suffice. > > It'll be there anyway due to debhelper → dh-autoreconf → autoconf → > m4, but I generally approve of directly specifying direct > (build-)dependencies. Agreed. To do otherwise discards important advantages of modularity and a dependency resolution system that copes with transitive relationships. > > * Add a dependency on "cups-client | cups-bsd | lpr". > > > > This is not due to new development. I confess to being puzzled > > why this build dependency isn't already present. groff's > > configure script has for years looked for an installed "lpr" > > command, then fallen back to "lp". Only "groff -l" uses the > > detected spooler command, however, and maybe people just don't do > > that very often. I think it is possible that for chroot-built > > groff packages in Debian--for those done by the buildds, for > > instance--the compiled groff command is silently ignoring the > > flag. > > > > https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/groff/groff.cpp#n408 > > Isn't this handled by passing PSPRINT=lpr to configure, as we do in > debian/rules? I generally prefer this approach over > build-dependencies in cases where the build-dependency would just be > for path detection and isn't actually used during the build. > > The fact that /usr/share/groff/1.22.4/font/devps/DESC ends with "print > lpr" suggests that this is working. You are quite right. I withdraw that suggestion. I guess if someone doesn't want a BSD-style print spooler installed but does have an lp(1) command and still wants to use 'groff -l', they'll have to edit the DESC files for the output devices...which aren't conffiles. Yuck. Maybe grops(1), grodvi(1), grolbp(1), and grolj4(1) (and gropdf(1)?) should grow an option to override the "print" directive in their DESC files. This is probably not urgent. The lack of bug reports from people satisfying the demographic sector I characterized above suggests that their numbers are few. > > Please let me know if I can be of assistance. > > Would you like to co-maintain the package? You're already much more > active upstream than I am and you've been doing lots of bug > maintenance; I'd be happy for you to do that with a maintainer hat. Thank you for this gracious invitation! I've been looking for a way back into measurable Debian development activity. I accept. > (My only conditions are that I'd like to keep using git-dpm for patch > maintenance and dgit for uploads.) Certainly. I have no revolutionary aspirations there. Nor, I'm ashamed to admit, a basic level of competence with git-gpm. I seem to remember using dgit and git-buildpackage the last time I uploaded a package, which was quite some time ago thanks to my upstream slowing WAY down. I would ask that you to take the decision about the man/mdoc/UTF-8 glyph contretemps[1] (which boils down to: patch {man,mdoc}.local or not?); as the upstream instigator of the controversial change, I'm afraid I'm conflicted out on the issue. Unless you agree with me but would prefer I wore the blame for it. 3;-) Thank you again. It will be strange to have responsibility for a package in main again. I might feel duty-bound to cast DPL election ballots... Regards, Branden [1] https://lists.gnu.org/archive/html/groff/2022-05/msg00050.html et seq.
signature.asc
Description: PGP signature
