(trimming the CC somewhat)
Theodore Tso writes ("Re: Bug#1127616: developers-reference: should document
using git-debpush to upload"):
> On Thu, Feb 12, 2026 at 05:37:26PM +0000, Ian Jackson wrote:
> > dgit-maint-gbp(7) is describing patches-unapplied, which is the usual
> > way that people use gbp (and gbp pq etc.)
>
> I don't know why you say that --- "gbp buildpackage" works just *fine*
> for me and I'm using a patches applied workflow. In fact, that's what
> I fall back to after "dgit gbp-build" fails for me.
I'm not sure which part of my statement you are questioning.
dgit-maint-gbp(7) says in terms, in paragraph 3, that it is describing
patches-unapplied.
In my experience patches-unapplied is used in majority of packaging
repositories, and in my experience many people even regard it as
officially blessed, or aren't aware that there are alternatives.
I haven't done a survey but I am pretty sure that my claim that it is
"the usual way that people use gbp" is correct.
It is true that gbp buildpackage generally does work with
patches-applied repositories, indeed. gbp is a flexible tool and even
has certain amount of dwimmery.
In summary, I think this quote from dgit-maint-gbp(7) is accurate both
as to the scope of the guidance in that manpage, and as to the most
common way that gbp is used:
Note that we assume a patches-unapplied repository: the
upstream source committed to the git repository is unpatched.
git-buildpackage(1) can work with patched-applied repositories,
but is normally used with patches-unapplied.
> > dgit build-source
>
> Sure, but that doesn't do a hermetic build.
I'm not sure what you mean. Are you concerned that the .dsc is
being built in an environment with uncontrolled other dependencies?
This is not something you need to worry about, any more than you
should worry that your kernel or filesystem aren't "hermetic". It is
quite fine to use (for example) an older version of dpkg-source to
upload. Indeed, that is quite normal.
All of my own uploaded .dscs are constructed by dgit using the
dpkg-source in my laptop's main environment, curerntly trixie.
Of course if I upload binaries I build them with sbuild, but with
sbuild the source package is built outside the chroot because it's
how the source is conveyed into the chroot for the build!
In any case, dgit checks that the source package correctly represents
what's in (your local) git, so if you had a malfunctioning dpkg-source
it would have to round-trip not to be detected.
If you really want reliable and auditable conversion from git to dsc,
you can of course use tag2upload, which has a clear definition of what
the tag means, and hermetic conversion from git to dsc. It's a system
with a fairly high level of assurance by Debian's usual standards.
> > I think you probably just need to stop passing it --gbp aka
> > --quilt=gbp, which is documented as follows:
>
> I'm not passing it --quilt=gbp. I'm just running "dgit gbp-build".
>From the documentation in dgit(1) for dgit gbp-build:
By default this uses --quilt=gbp, so HEAD should be a
git-buildpackage style branch, not a patches-applied branch.
Admittedly "git-buildpackage style branch" is rather loose phrasing
here, but "not a patches-applied branch" is quite unambiguous.
> Hmm... will something like "dgit --quilt=nofix gbp-build" do what I
> want? And if so, I can put something like
I should think so.
> [dgit "default"]
> build-products-dir = /tmp/gbp
> quilt = nofix
Yes, you can do that. You should probably put that in your
per-package git repo, rather than your global config. Otherwise dgit
might behave weirdly for you in the future when you work on other
packages with different approaches, or try to do an NMU.
(However, and I hesitate to go into this:
You shoudln't, because the /tmp/gbp is a "use of fixed filename in
/tmp" vulnerability! Like most programs, dgit is not prepared to deal
with the possibly hostile bizarrenesses that can occur in /tmp, except
for files that it itself creates in /tmp or TMPDIR or such.
I suspect that your *fingers* have a "use of fixed filename in /tmp"
vulnerability. This is OK on a machine (or VM or container) on which
all software is completely trusted, but that is rarely the situation.
So manual use of /tmp rather than (say) ~/tmp is a really bad habit.)
> in my git config file? If so, you might want to document that in
> git-maint-gbp, and not assume that everyone using gbp is using
> patch-unapplied. I certainly don't. (In fact, I don't even know how
> you can use gbp with a patch-unapplied orkflow; I didn't even know
> that was a possibility, in fact.)
What you're doing is very much a minority thing. I think the
documentation is adequately clear that these options and modes are for
use with patches-unapplied branches, unless overridden. At this
point, I'm inclined to think that adding more caveats about this would
reduce clarity for the large majority of readers.
But I'll CC Sean to see if he agrees.
Ian.
--
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.
