Re: Bug#1011666: need help with groff 1.23.0 (1.23.0~rc3-1 package prepared)
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.
--
Colin Watson (he/him) [cjwatson@debian.org]
Reply to: