On Fri, Feb 13, 2026 at 12:14:08AM +0000, Ian Jackson wrote:
>
> 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.
Well, you _can_ use "gbp pq", which basicaly gives you quilt-sytle
interface. But it only makes sense if you are working with external
patches and you aren't particularly comfortable with git. Personally,
I think it's a terrible and not particularly useful interface,
especially if the patches that you want are already in the upstream
git repo, and all you want to do is to cherry-pick them into the
debian/master or debian/backport branch. In any case, it is a purely
optional module in gbp, and it is mostly certainly not mandatory to
use it if you want to take advantage of the other benefits of gbp.
In other words, I didn't have to do anything special to use gbp with a
patch-applied debian/master. It's not like I had to take advantage of
any configuration flexibility in gbp.
Are you really certain everyone who uses gbp also uses "gbp pq"? [Citation
needed.]
> > > 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?
No, I want to make sure that I am building the package in a hermetic
build environment. Which is to say, I want to build using sbuild so I
can make sure it builds correctly in the latest unstable environment
and using the minimal set of patches so I can make sure the
Build-Depends line in debian/control is correct, *before* I do an upload.
Put another way, my primary development environment is Debian/testing,
with a lot of convenience packages included. (I'm not brave enough to
use Debian unstable, after too many cases where my primary environment
was broken by broken unstable upload.) My normal development
environment is where I do my upstream Kernel and e2fsprogs
development. So I've already run my normal set of regression testing
using a non-hermetic environment, and before I do a release, I've
already used github's CI infrastructure to make sure e2fsprogs builds
on Windows and MacOS, and I've run non-hermetic "./configure ; make ;
make check" runs on PowerPC and S390 developer machines, as well as on
a FreeBSD VM.
One of my last QA checks is to do a hermetic build using sbuild. So I
create the upstream tarball, sign it, deposit into my git repository
using pristine-tar. Then I run "git checkout debian/master ; git
merge master ; gbp buildpackage". (where gbp is configured to use a
builder of "sbuild -A -s -v")
If that works, only *then* do I do a "dit gbp-build ; dgit push".
So there are an awful lot of consistency checks that I do; it's not
just about making sure .dsc == git. In fact, I don't think that's
*ever* been the issue in terms of quality control checks where I've
caught issues before I do an upstream release or do a dupload.
> > 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.
I just tried it, and it doesn't work. Apparently that only sets
--quilt=nofix as the default for "dgit build" or "dgit sbuild". It
does *not* override the default for "dgit gbp-build". I can't seem to
find a way override the default --quilt setting for dgit gbp-build.
Is there a way to do that?
> 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.
This is on my (single user) development system that I use for upstream
development. It's where I sign kernel tags before doing send git
request-pulls to Linus, and from where I upload packages to Debian.
If it is compromised, attacks involving /tmp/gbp would be the *least*
of my worries.
> So manual use of /tmp rather than (say) ~/tmp is a really bad habit.)
I use /tmp instead of ~/tmp because I'm trying to avoid SSD write
wearout. (/tmp is a tmpfs file system)
- Ted
