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 <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
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
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature