Hi, On Wed, May 15, 2024 at 06:58:22PM -0400, Daniel Kahn Gillmor wrote: [..snip..]
> background: i prefer debian packaging linked to the upstream revision > control, but also being able to tie our work to formally released > tarballs, if the upstream project ships them. I'm relying on gbp Great! This matches my preferred way too. > import-orig with an appropriately configured debian/gbp.conf to import > cryptographically signed upstream tarball releases while pointing back > to upstream's revision control tags. > > One example workflow that i would like to be able to have easily at my > disposal as a maintainer is to tell that things are in the tarball that > are *not* in the upstream revision control system (the other direction: > looking for things in upstream revision control that didn't get shipped > in the tarball, is interesting, but a separate question). > > After having verified the cryptographic signatures of the upstream > tarball, and the upstream release tag, and doing "gbp import-orig", it's > nice to be able to do (for example): > > git diff --stat gnupg-2.2.43..upstream/2.2.43 > > This helps me identify artifacts that we should probably be re-building > from source. > > By including these generated artifacts in debian/clean, i can ensure > that during the standard debian build process, they will be necessarily Wouldn't d/copyright's `Files-Excluded:` work here too? I'm using that for similar purposes as it even allows to use `gbp import-orig --uscan` and have things filtered out. `debian/clean` could parse the pattern from there. > re-generated (because we run "debian/rules clean" before building). But > if i'm including them in debian/clean, then there's no point in keeping > them in the git packaging directory either. and i would prefer to avoid > synchronizing debian/clean and debian/gbp.conf's import-orig.filter > list. What if you'd read the filter list in the `clean` target? I think what you propose is doing it the other way around: Have gbp run `debian/rules clean` to have a programatical way of filtering? Cheers, -- Guido > > --dkg > > -- System Information: > Debian Release: trixie/sid > APT prefers testing-debug > APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), > (500, 'oldstable'), (200, 'unstable-debug'), (200, 'unstable'), (1, > 'experimental-debug'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.7.12-amd64 (SMP w/4 CPU threads; PREEMPT) > Kernel taint flags: TAINT_FIRMWARE_WORKAROUND > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages git-buildpackage depends on: > ii devscripts 2.23.7 > ii git 1:2.43.0-1+b1 > ii man-db 2.12.1-1 > ii python3 3.11.8-1 > ii python3-dateutil 2.9.0-2 > ii python3-pkg-resources 68.1.2-2 > ii python3-yaml 6.0.1-2 > ii sensible-utils 0.0.22 > > Versions of packages git-buildpackage recommends: > pn cowbuilder | pbuilder | sbuild <none> > ii pristine-tar 1.50+nmu2 > ii python3-requests 2.31.0+dfsg-1 > > Versions of packages git-buildpackage suggests: > pn python3-notify2 <none> > pn sudo <none> > ii unzip 6.0-28 > > -- no debconf information
