(I'm dropping the dev-ref bug because this seems like a dgit user
support subthread now.)
Theodore Tso writes ("Bug#1127616: developers-reference: should document using
git-debpush to upload"):
> On Tue, Feb 10, 2026 at 09:32:29AM -0800, Russ Allbery wrote:
> > I have been using dgit with pristine-tar for years. It works fine with
> > pristine-tar. People have told you this repeatedly. Please listen to us
> > and stop repeating this blatantly misleading statement in every discussion
> > about dgit.
>
> I use dgit with pristine-tar, but if I need to add patches in between
> formal e2fsprogs releases, dgit is *painful*. If I need to upload to
> stable backports, dgit just did't work. Ian, I think I e-mailed you a
> request for help a few years ago, but you were apparently to busy to
> reply, so I just gave up on it for stable backports. And if I can't
> get maintenance releases doesn't work, I just fall back to the
> pre-dgit workflow.
>
> Part of this is because my workflow uses dgit plus gbp plus schroots,
> with patches applied. Which is something dgit seems to only
> incidently support, but the advantage of my setup is that if dgit does
> blow up, and I can easily fall back to a pre-dgit workflow.
I'm sorry that I apparently overlooked your earlier mail. Anyway:
We do stable backports with dgit all the time. This is supposed to e
fully supported. Indeed that's how the current dgit in trixie-bpo got
there.[1] If you're having trouble with this I'd welcome a bug report
(which would be less easy to overlook).
As for adding patches between (upstream?) e2fsprogs releases,
again, this ought to be routine and supported. But:
I'm not sure I understand your git workflow. You say you're using
patches-applied. I assume that means you're using "3.0 (quilt)".
Reading between the lines, Ithink yuu probably aren't basing your
approach on any of the workflow recommendations in dgit-maint-*(7).
That's fine, and dgit may well be able to work with your git branch,
but it does mean I don't know what's going on.
How are you keeping the upstream files in the main part of your git
tree in sync with the debian/patches/ ? Typically with
patches-applied and "3.0 (quilt)" one needs a tool to do this
(git-debrebase, git-dpm, git-debcherry).
Certainly I think cherry-picking a patch from upstream, or writing a
fresh patch on an interim basis, is a routine operation that ought to
be straightforward.
Can you point me to an example DEP-14 tag of an upload where you fell
back to dput? Examining the state in git might enlighten me.
I don't see how any of this would have anything to do with
pristine-tar.
> Maybe it's possible to make dgit work with my workflow, but I've spent
> weekends trying to make it work, and I've since timed out. I have
> higher-value work that I can do to support Linux or Debian, and trying
> to bash my head against the dgit procrustean bed isn't one of them.
Well, obviously I'm sorry you feel that way. dgit is supposed to be
quite flexible.
The only thing it insists on is that your git and your .dsc
correspond; that's the property that enables it to be a bidirectional
gateway. That's also the property that means you can look only at
your git and then be confident that "dgit push" will DTRT without
needing to examine source packages, run debdiff on dscs, etc.
Regards,
Ian.
[1] Well actually Sean did it and I think he used tag2upload, but
that's dgit-as-a-service.
--
Ian Jackson <[email protected]> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
