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

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

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

     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 <alx@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-6892-1e39a0679f27@gmail.com/T/#mcf36c8a387fd5ff4f800dc220e3dbdd229b556bd>
    Reported-by: Jakub Wilk <jwilk@jwilk.net>
    Cc: Mike Frysinger <vapier@gentoo.org>
    Cc: "G. Branden Robinson" <g.branden.robinson@gmail.com>
    Cc: Michael Kerrisk <mtk.manpages@gmail.com>
    Cc: Stefan Puiu <stefan.puiu@gmail.com>
    Signed-off-by: Alejandro Colomar <alx@kernel.org>

commit b324e17d3208c940622ab192609b836928d5aa8d
Author: Alejandro Colomar <alx@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 <alx@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 <alx@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



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

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply to: