Re: Bug#1011666: need help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[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

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Re: Bug#1011666: need help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[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+, 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
>  :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.

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

Re: Bug#1011666: need help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[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+, 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.  {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
 :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 
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: 

Reported-by: Jakub Wilk 
Cc: Mike Frysinger 
Cc: "G. Branden Robinson" 
Cc: Michael Kerrisk 
Cc: Stefan Puiu 
Signed-off-by: Alejandro Colomar 

commit b324e17d3208c940622ab192609b836928d5aa8d
Author: Alejandro Colomar 
Date:   Sun Dec 4 20:38:06 2022 +0100

Many pages: wfix

Refer consistently to software versions.  In most cases, it is done as
 .  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 


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

Re: Bug#1011666: need help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[G. Branden Robinson]

[added Alex Colomar to CC]

At 2023-02-26T13:30:58+, 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
commit 69e844df84929b8a6a440cbbafe55dcd134107b6
Author: G. Branden Robinson 
Date:   Mon Feb 27 06:27:17 2023 -0600

Rename and document patch

diff --git a/debian/changelog b/debian/changelog
index ca8a27d5..4f867aeb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,14 @@
-groff (1.22.4-10) UNRELEASED; urgency=medium
+groff (1.22.4-10) unstable; urgency=medium
 
+  [ Colin Watson ]
   * Set upstream metadata fields: Repository-Browse.
 
- -- Colin Watson   Mon, 02 Jan 2023 13:38:52 -
+  [ G. Branden Robinson ]
+  * debian/patches/add-groff-1.23-forward-compatibility.patch: Prevent
+formatter warnings and dropped man(7) document text when encountering
+documents written using new features of groff 1.23.
+
+ -- G. Branden Robinson   Mon, 27 Feb 2023 06:30:24 -0600
 
 groff (1.22.4-9) unstable; urgency=medium
 
diff --git 

Re: Bug#1011666: need help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

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

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