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

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: