Bug#1011666: groff 1.23.0 build dependencies will change

[G. Branden Robinson]

Package: groff
Version: 1.23.0-1
Severity: wishlist

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.

Here is the current build-dependencies declaration for Debian's groff
package.

Build-Depends: bison (>= 1:1.875b), debhelper-compat (= 12), dh-exec, dpkg-dev (>= 1.17.0~), ghostscript, netpbm, psutils, x11proto-core-dev, libx11-dev, libxmu-dev, libxt-dev, libxaw7-dev, texinfo (>= 4.8), pkg-config, libuchardet-dev, gsfonts, poppler-utils <!nocheck>

When packaging groff 1.23.0, some changes should be made. I'll quote
the 'NEWS' file for rationales.

* Drop the bison dependency.

o Building groff from its distribution archive no longer requires byacc
(or GNU Bison) to be installed.

* Drop the texinfo dependency.

o Because all generated forms of groff's Texinfo manual are now included
in the distribution archive, building from that archive no longer
depends on GNU Texinfo or a TeX installation (the latter was only
required for the "doc" target, which had to be explicitly given).

* 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.

* 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

I looked at the BuildProfileSpec page[1], and while bootstrapping is
discussed there, I couldn't find a spec that would be applicable to
groff for bootstrapping it. ("nocheck" is already used in the event
groff's test suite is not run.) But in case it's useful to know, here
are all the (non-Debian-packaging-process-related) build-dependencies
that could be dropped for such a profile. In other words, groff will
still 'configure' and 'make' without these, albeit with reduced
functionality.

ghostscript
netpbm
psutils
x11proto-core-dev
libx11-dev
libxmu-dev
libxt-dev
libxaw7-dev
pkg-config
libuchardet-dev
gsfonts

And of course the already-profiled "poppler-utils".

The aforementioned "cups-client | cups-bsd | lpr" is also not necessary
for bootstrapping. "m4" _is_ (or will be, in groff 1.23.0).

Please let me know if I can be of assistance.

Regards,
Branden

[1] https://wiki.debian.org/BuildProfileSpec

[Colin Watson]

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!

> * 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.

> * 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.

> 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. (My only
conditions are that I'd like to keep using git-dpm for patch maintenance
and dgit for uploads.)

Thanks,

--
Colin Watson (he/him) [cjwa...@debian.org]

[G. Branden Robinson]

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.

[G. Branden Robinson]

I need to amend my recommendations slightly.

pkg-config _will_ need to remain in Build-Depends due to a very recent
change in groff upstream.

> 2022-05-26 G. Branden Robinson <g.branden...@gmail.com>
>
> * bootstrap.conf: Add "pkg-config" to `buildreq`. Not having it
> causes pretty horrible macro expansion problems and diagnostics
> when 'autoreconf' is run; they're still pretty bad even if you
> use `AC_REQUIRE` and `m4_pattern_forbid`. So just demand it.

Regards,
Branden

[Colin Watson]

On Fri, May 27, 2022 at 06:27:36PM -0500, G. Branden Robinson wrote:
> At 2022-05-26T13:13:44+0100, Colin Watson wrote:
> > 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.

Quite ... I expect nowadays people probably just write the output to a
file and print it from there. ("groff -l" is an un-Unix-like
abomination anyway IMO, though you're probably now going to tell me that
it dates back to v7 or something.)

> > 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.

Great. The git repository is under the "debian" group so you should
have commit access already, but please add yourself to Uploaders with
whatever address you prefer.

> > (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.

https://alioth-lists.debian.net/pipermail/pkg-grub-devel/2014-January/013883.html
is an old email of mine that may help with the "basic level of
competence" question. (But I'm certainly happy to deal with the big
merge of 1.23.0 once that happens, since that can be rather more
complicated than day-to-day patch maintenance.)

> 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;-)

I'm afraid I'm rather of the opinion that, despite being in generally
good health, I don't expect to live long enough to see all manual page
authors fix their pages, since that didn't happen very consistently with
the more common \- issue; and I like copy and paste of commonplace shell
commands and regular expressions and such to work. As such I'm inclined
to patch {man,mdoc}.local, though I'll probably defer a final decision
on that until we merge 1.23.0.

[Colin Watson]

On Sat, Feb 25, 2023 at 11:13:29PM -0600, G. Branden Robinson wrote:
> I've sent you a couple of mails over the past few months, but I don't
> recall seeing a reply.

Sorry about that! Feel free to grab me on IRC if I'm not replying to
email.

> I am not a proficient gbp user, but I think I have done what is
> necessary.

groff doesn't use gbp - it uses git-dpm. If you try to use gbp for it
then you will probably get quite confused and so will I, so please
don't.

First, move your current branch somewhere for reference, then make a new
one. Then, my routine for pulling in new upstreams looks roughly like
this:

git-dpm import-new-upstream -p $UPSTREAMTAG^{} --rebase-patched ../foo.orig.tar.gz
# this imports the unpacked upstream tarball onto an upstream branch
# based on $UPSTREAMTAG, then drops you into a rebase session

... continue with rebase as needed, then once you're finished ...

git-dpm update-patches --amend
# the --amend is just because the import-new-upstream step will
# already have recorded the new upstream on the branch you started
# from, but the history looks clearer if you bundle the rebase with
# that in a single merge commit, which this does

Then you can cherry-pick your packaging changes on top of this, as well
as telling pristine-tar about the new upstream tarball based on the
appropriate imported branch.

If you push the results to a temporary branch on salsa then I can look
over them, which is probably a good idea since you're unfamiliar with
git-dpm.

> How do we move forward with this? I am anxious about the closing of the
> soft freeze window.

There is no way that this giant new upstream release will be suitable at
this stage in the freeze; it's too late. This should be targeted at
experimental.

[G. Branden Robinson]

[added Alex Colomar to CC]

At 2023-02-26T13:30:58+0000, Colin Watson wrote:
> Sorry about that! Feel free to grab me on IRC if I'm not replying to
> email.

Ah! I'm never on IRC anymore. I shifted to machines with power
management for everyday use; the loss of a nailed-up Internet connection
destroyed my IRC continuity. (I hear there are ways around this...)

> > I am not a proficient gbp user, but I think I have done what is
> > necessary.
>
> groff doesn't use gbp - it uses git-dpm.

Right. You told me that before and the information trickled out of my
sieve-like brain. TLA overload, so I was SOL. FML.

> If you try to use gbp for it then you will probably get quite confused
> and so will I, so please don't.

Yes, indeed, thanks.

> First, move your current branch somewhere for reference, then make a new
> one. Then, my routine for pulling in new upstreams looks roughly like
> this:
>
> git-dpm import-new-upstream -p $UPSTREAMTAG^{} --rebase-patched ../foo.orig.tar.gz
> # this imports the unpacked upstream tarball onto an upstream branch
> # based on $UPSTREAMTAG, then drops you into a rebase session
>
> ... continue with rebase as needed, then once you're finished ...
>
> git-dpm update-patches --amend
> # the --amend is just because the import-new-upstream step will
> # already have recorded the new upstream on the branch you started
> # from, but the history looks clearer if you bundle the rebase with
> # that in a single merge commit, which this does
>
> Then you can cherry-pick your packaging changes on top of this, as well
> as telling pristine-tar about the new upstream tarball based on the
> appropriate imported branch.
>
> If you push the results to a temporary branch on salsa then I can look
> over them, which is probably a good idea since you're unfamiliar with
> git-dpm.

Thanks for this. I also found
https://wiki.debian.org/PackagingWithGit/GitDpm which is helpful for my
fallback plan described below.

> > How do we move forward with this? I am anxious about the closing of the
> > soft freeze window.
>
> There is no way that this giant new upstream release will be suitable
> at this stage in the freeze; it's too late. This should be targeted
> at experimental.

Oh, man. That really sucks the wind out of my sails. :(

(Good thing I did the packaging update work already!)

The freeze policy says, "Starting 2023-02-12, only small, targeted fixes
are appropriate for bookworm. We want maintainers to focus on small,
targeted fixes. This is mainly at the maintainers discretion, there will
be no hard rule that will be enforced."[1]

I was kind of hoping for an exercise of that discretion in favor of
getting the groff release in. I hope you feel I have been attentive to
issues of implementation quality. Nevertheless I admit I have a
conflict of interest as an active upstream (for the moment, still
unoffical) co-maintainer who wants to see his 4,000 commits including
400 bug fixes get into the next Debian release.[2]

But, also, Bertrand Garrigues (GNU maintainer, who has had to step back
quite a bit for personal reasons) is going to be unavailable to tag
1.23.0 final until _next_ weekend so I think groff and Debian release
timing may simply have a curse on them.

Please find attached my much more modest proposal. Let's make sure the
groff in Debian bookworm will not throw confusing undefined register
warnings or drop text from man pages that begin to embrace groff 1.23's
new features.

Alex Colomar, the Linux man-pages maintainer, is eager to adopt the new
man(7) MR macro ASAP, so that's 2,500 man pages, many commonly used,
that will be undergoing a transition in the next few months, I expect.

Meanwhile I reckon I'll start praying to the gods of backports and point
releases.

Regards,
Branden

[1] https://release.debian.org/testing/freeze_policy.html#soft
[2] https://git.savannah.gnu.org/cgit/groff.git/tree/ANNOUNCE?id=99e5b4ae55a7c222f6bf57b355289a88d862478d
https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?id=99e5b4ae55a7c222f6bf57b355289a88d862478d

[Alejandro Colomar]

Hi Branden and Colin!

On 2/27/23 13:56, G. Branden Robinson wrote:
> [added Alex Colomar to CC]
>
> At 2023-02-26T13:30:58+0000, Colin Watson wrote:
>>> I am not a proficient gbp user, but I think I have done what is
>>> necessary.
>>
>> groff doesn't use gbp - it uses git-dpm.
>
> Right. You told me that before and the information trickled out of my
> sieve-like brain. TLA overload, so I was SOL. FML.

$ wtf is SOL
SOL: SOL (6) - a collection of card games which are easy to play with...
$ wtf is FML
Gee... I don't know what FML means...


Please send a patch to bsdgames :D

At least dict(1) could help with SOL. No luck with FML though,
I had to search it on the web. No good. Fuck my life! :D

$ dict -d foldoc SOL
1 definition found

From The Free On-line Dictionary of Computing (30 December 2018) [foldoc]:

SOL

1. <language> {Simulation Oriented Language}.

2. {Second-Order lambda-calculus}.

3. Semantic Operating Language. Language for manipulating
semantic networks for building cognitive models, particularly
for natural language understanding. "Explorations in
Cognition", D.A. Norman et al, W.H. Freeman 1974.

4. Shit Outta Luck.

$ dict FML
No definitions found for "FML", perhaps you mean:
gcide: ml Fm Fil -ful
wn: ml fl fm ful
vera: ml fl fm cfml aml bml dml eml gml iml kml mml
nml qml sml uml vml wml xml fal fbl fcl fdl frl ftl
fma fmb fmm fmo fms
jargon: fm
foldoc: ml fl fm

>
>> If you try to use gbp for it then you will probably get quite confused
>> and so will I, so please don't.
>
> Yes, indeed, thanks.
>
>> First, move your current branch somewhere for reference, then make a new
>> one. Then, my routine for pulling in new upstreams looks roughly like
>> this:
>>
>> git-dpm import-new-upstream -p $UPSTREAMTAG^{} --rebase-patched ../foo.orig.tar.gz
>> # this imports the unpacked upstream tarball onto an upstream branch
>> # based on $UPSTREAMTAG, then drops you into a rebase session
>>
>> ... continue with rebase as needed, then once you're finished ...
>>
>> git-dpm update-patches --amend
>> # the --amend is just because the import-new-upstream step will
>> # already have recorded the new upstream on the branch you started
>> # from, but the history looks clearer if you bundle the rebase with
>> # that in a single merge commit, which this does

May I ask something from you, Colin? Could you please embed that
info in the commit messages in salsa? That would help those who
want to learn Debian packaging from actual practice rather than
tutorials (I've read and watched many of those, and my confusion
only grows; I mean, just look at
<https://www.youtube.com/watch?v=O83rIRRJysA> :p).

In the Linux man pages I write the scripts or commands run to produce
a scripted or semi-scripted patch, or when some important information
needed to write a patch was gotten from some script. See for example:


commit a1eaacb1a569cd492b09c04982cd40b4b733ba3c
Author: Alejandro Colomar <a...@kernel.org>
Date: Wed Nov 9 16:36:36 2022 +0100

Many pages: Add '\" t' comment where necessary

Scripted change:

$ grep -l -x '^[.]TS$' man*/* | sort -u | xargs sed -i -e "1i'\\\\\" t"

Link: <https://lore.kernel.org/linux-man/07a7d4e7-79a6-b2c3...@gmail.com/T/#mcf36c8a387fd5ff4f800dc220e3dbdd229b556bd>
Reported-by: Jakub Wilk <jw...@jwilk.net>
Cc: Mike Frysinger <vap...@gentoo.org>
Cc: "G. Branden Robinson" <g.branden...@gmail.com>
Cc: Michael Kerrisk <mtk.ma...@gmail.com>
Cc: Stefan Puiu <stefa...@gmail.com>
Signed-off-by: Alejandro Colomar <a...@kernel.org>

commit b324e17d3208c940622ab192609b836928d5aa8d
Author: Alejandro Colomar <a...@kernel.org>
Date: Sun Dec 4 20:38:06 2022 +0100

Many pages: wfix

Refer consistently to software versions. In most cases, it is done as
<software> <version>. In the case of Linux and glibc, use the project
name, instead of other terms such as 'kernel' or 'library'.

I found the uses of inconsistent language with the following:

$ find man* -type f \
| xargs grep -i '\(since\|before\|after\|until\|to\|from\|in\|between\|version\|with\) \(kernel\|version\|2\.\|3\.\|4\.\|5\.\)' \
| sort

However, I might have missed some cases. Anyway, 99% consistency is
pretty good consistency. We'll fix the remaining cases as we see them.

Signed-off-by: Alejandro Colomar <a...@kernel.org>

>>
>> Then you can cherry-pick your packaging changes on top of this, as well
>> as telling pristine-tar about the new upstream tarball based on the
>> appropriate imported branch.
>>
>> If you push the results to a temporary branch on salsa then I can look
>> over them, which is probably a good idea since you're unfamiliar with
>> git-dpm.
>
> Thanks for this. I also found
> https://wiki.debian.org/PackagingWithGit/GitDpm which is helpful for my
> fallback plan described below.
>
>>> How do we move forward with this? I am anxious about the closing of the
>>> soft freeze window.
>>
>> There is no way that this giant new upstream release will be suitable
>> at this stage in the freeze; it's too late. This should be targeted
>> at experimental.

I think previous RC releases should have already been uploaded to
experimental, which would have helped this be smoother.

>
> Oh, man. That really sucks the wind out of my sails. :(
>
> (Good thing I did the packaging update work already!)

Please upload RC3 to experimental, even if we don't think the final
release will make it to Bookworm; at least there's something.

>
> The freeze policy says, "Starting 2023-02-12, only small, targeted fixes
> are appropriate for bookworm. We want maintainers to focus on small,
> targeted fixes. This is mainly at the maintainers discretion, there will
> be no hard rule that will be enforced."[1]
>
> I was kind of hoping for an exercise of that discretion in favor of
> getting the groff release in. I hope you feel I have been attentive to
> issues of implementation quality. Nevertheless I admit I have a
> conflict of interest as an active upstream (for the moment, still
> unoffical) co-maintainer who wants to see his 4,000 commits including
> 400 bug fixes get into the next Debian release.[2]
>
> But, also, Bertrand Garrigues (GNU maintainer, who has had to step back
> quite a bit for personal reasons) is going to be unavailable to tag
> 1.23.0 final until _next_ weekend so I think groff and Debian release
> timing may simply have a curse on them.
>
> Please find attached my much more modest proposal. Let's make sure the
> groff in Debian bookworm will not throw confusing undefined register
> warnings or drop text from man pages that begin to embrace groff 1.23's
> new features.

a370cf62 "tmac{man.local,troffrc}: Add groff 1.23 fw compat"

Acked-by: Alejandro Colomar <a...@kernel.org>

>
> Alex Colomar, the Linux man-pages maintainer, is eager to adopt the new
> man(7) MR macro ASAP, so that's 2,500 man pages, many commonly used,
> that will be undergoing a transition in the next few months, I expect.

I don't think I'll be waiting for Trixie for my changes. I guess
I'll have to be content with some package in experimental until
Bookworm, and then having it in Sid until Trixie. Other distros
like Gentoo and Arch will have 1.23.0 soon, so I think that will
be enough for me. For contributors that use Debian, I'll point
them at the RC-Buggy or Sid package.

However, your patch to add compatibility with .MR through the
.tmac file should cover most of the important stuff that worries me.

>
> Meanwhile I reckon I'll start praying to the gods of backports and point
> releases.

$deity (or deity@) save us :D

>
> Regards,
> Branden

Cheers,

Alex

>
> [1] https://release.debian.org/testing/freeze_policy.html#soft
> [2] https://git.savannah.gnu.org/cgit/groff.git/tree/ANNOUNCE?id=99e5b4ae55a7c222f6bf57b355289a88d862478d
> https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?id=99e5b4ae55a7c222f6bf57b355289a88d862478d

--
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

[Colin Watson]

On Mon, Feb 27, 2023 at 03:26:52PM +0100, Alejandro Colomar wrote:
> On 2/27/23 13:56, G. Branden Robinson wrote:
> > At 2023-02-26T13:30:58+0000, Colin Watson wrote:
> >> First, move your current branch somewhere for reference, then make a new
> >> one. Then, my routine for pulling in new upstreams looks roughly like
> >> this:
> >>
> >> git-dpm import-new-upstream -p $UPSTREAMTAG^{} --rebase-patched ../foo.orig.tar.gz
> >> # this imports the unpacked upstream tarball onto an upstream branch
> >> # based on $UPSTREAMTAG, then drops you into a rebase session
> >>
> >> ... continue with rebase as needed, then once you're finished ...
> >>
> >> git-dpm update-patches --amend
> >> # the --amend is just because the import-new-upstream step will
> >> # already have recorded the new upstream on the branch you started
> >> # from, but the history looks clearer if you bundle the rebase with
> >> # that in a single merge commit, which this does
>
> May I ask something from you, Colin? Could you please embed that
> info in the commit messages in salsa? That would help those who
> want to learn Debian packaging from actual practice rather than
> tutorials (I've read and watched many of those, and my confusion
> only grows; I mean, just look at
> <https://www.youtube.com/watch?v=O83rIRRJysA> :p).
>
> In the Linux man pages I write the scripts or commands run to produce
> a scripted or semi-scripted patch, or when some important information
> needed to write a patch was gotten from some script. See for example:

This isn't really analogous to your situation, though. git-dpm is more
like a workflow tool (such as stgit) than it is like a program you use
to generate one-off scripted patches. I don't think it would be
appropriate or reasonable to try to embed this sort of thing in every
commit generated by git-dpm, which is quite a lot of the commits that
end up in my packaging branches.

I'd be happy to write a debian/README.source file, which would be a
better place for this sort of thing. I'm not sure exactly when I'll get
round to it, but I've added it to my to-do list.

> > Please find attached my much more modest proposal. Let's make sure the
> > groff in Debian bookworm will not throw confusing undefined register
> > warnings or drop text from man pages that begin to embrace groff 1.23's
> > new features.

I'm fine with this, modulo sorting out minor commit formatting details.

[Alejandro Colomar]

Hi Colin,

On 3/3/23 19:12, Colin Watson wrote:
> This isn't really analogous to your situation, though. git-dpm is more
> like a workflow tool (such as stgit) than it is like a program you use
> to generate one-off scripted patches. I don't think it would be
> appropriate or reasonable to try to embed this sort of thing in every
> commit generated by git-dpm, which is quite a lot of the commits that
> end up in my packaging branches.

If it's recurrent, maybe doing it only once would be nice.

>
> I'd be happy to write a debian/README.source file, which would be a
> better place for this sort of thing. I'm not sure exactly when I'll get
> round to it, but I've added it to my to-do list.

Sure, that would also help!

Cheers,

Alex

[Colin Watson]

On Wed, May 25, 2022 at 07:55:10PM -0500, G. Branden Robinson wrote:
> * Drop the bison dependency.
>
> o Building groff from its distribution archive no longer requires byacc
> (or GNU Bison) to be installed.
>
> * Drop the texinfo dependency.
>
> o Because all generated forms of groff's Texinfo manual are now included
> in the distribution archive, building from that archive no longer
> depends on GNU Texinfo or a TeX installation (the latter was only
> required for the "doc" target, which had to be explicitly given).

After some thought, I'm going to keep these two build-dependencies after
all, as well as adding new build-dependencies on texlive-base and
texlive-latex-base.

Debian normally prefers to build everything from the original source if
possible, even if intermediate forms are shipped in distribution
archives. This is of course partly for ideological reasons, but there's
a significant practical motivation too: in the event that we need to
patch something in a hurry, we don't want to have to figure out the
necessary build system changes at the same time (or, worse, have changes
appear to be present in the source package but silently have no effect).
This is not a theoretical concern: my proposed patch to resolve the
SOURCE_DATE_EPOCH timezone problem changes doc/groff.texi.

It's true that this significantly bloats groff's build-dependency set
(especially texlive-base). However, I don't think this will be a
problem in practice. For bootstrapping new architectures, we often lean
on multiarch these days, and all three of the packages concerned here
are "Multi-Arch: foreign" - so it should be possible to satisfy those
build-dependencies using binaries from the host architecture when doing
a cross-build.

If it becomes an issue, we can look at putting these in a "nodoc"
profile, although that would probably also need some debian/rules
changes so I haven't bothered with it just yet.