Hi git-buildpackage users, I noticed several maintainers recently stopped using 'gbp import-orig --uscan' and switched to 'gbp import-ref' instead, and potentially inadvertently broke the software provenance chain of their package, or no longer have consistent automated repackaging happening.
Please use 'gbp import-orig --uscan' to import new upstream packages to ensure that what you download is exactly the same thing as uscan downloads based on the debian/watch file (or debian/upstream/metadata). Uscan has all kinds of automation built-in, such as checking upstream signatures and also repacking upstream sources on the fly based on debian/copyright:Files-Excluded. If you manually 'git pull' or run 'gbp import-ref' for a package with debian/copyright:Files-Excluded they will stop working. Ideally also just run plain 'gbp import-orig --uscan' without any extra parameters. If your upstream uses git and has release tags, put upstream-vcs-tag in debian/gbp.conf, along with anything else you previously passed on the command-line so that if anyone else wants to contribute to your git-buildpackage maintained package, they can trust that 'gbp import-orig --uscan' yields the same result as previous imports. On Fri, 9 Jan 2026 at 04:40, Otto Kekäläinen <[email protected]> wrote: > > Hi! > > On Thu, 8 Jan 2026 at 08:15, Ian Jackson > <[email protected]> wrote: > > Simon Josefsson writes ("Re: Include git commit id and git tree id in > > *.changes files when uploading?"): > > > Right. I use 'gbp import-orig --uscan' to import new upstreams. > > > > You should perhaps consider switching to gbp import-ref. Thanks to > > Gioele Barabucci for the tip. AIUI golang packages are primarily in > > git almost by definition. > > I think Gioele wanted to point out that git-buildpackage has this > feature. It should not be construed as a suggestion to import new > upstream versions with it. Let me explain. > > If a package is using git-buildpackage in the first place, the best > and really only sensible command to import new upstream versions is > `gbp import-orig --uscan` as Simon is already doing, and without any > additional parameters. > > This is important for two reasons: > > 1) Debian uses uscan and upstreams needs to be fetchable with debian/watch > info > > The whole Debian infrastructure (currently) expects all non-native > packages to have a debian/watch file, and that uscan will download the > upstream source package accordingly. Tools like vcswatch and the new > debaudit run uscan to fetch new and old versions. The package > maintainer should also be using this and not bypassing getting new > upstream versions with some other manual way. With this also anyone > auditing a potential backdoor can reproduce the import and (directly) > see it came from upstream and not from the maintainer in Debian. > > 2) Git-buildpackage settings should be in debian/gbp.conf for consistency > > While I suggest everyone to do upstream imports using `gbp import-orig > --uscan`, it does not mean all packages need to have the same settings > or git layout and so forth. I just consider it a major source of > problems if each maintainer runs the command and passes their own > extra parameters to it, as whoever later works on the package has no > way of knowing what those extra parameters were. By always using the > same generic command to do the import AND by having the settings > specific for that package in debian/gbp.conf we can ensure that > imports are consistent (and also anyone auditing what happened can > reproduce the import). > > Why does `gbp import-ref` exist then? That command is used when the > upstream import has already been done once into the git repository and > you want to import the same version to another branch. For example > when there is a new MariaDB version I run in branch `debian/latest` > the command `gbp import-orig --uscan` and eventually upload to > unstable. Later when I backport to Trixie I run in the branch > `debian/13-trixie` the command `gbp import-ref > --upstream-version=11.8.5` and git-buildpackage will automatically use > the upstream sources and tarball already in the git repository. > > Does this seem complicated? Yes, there are a lot of moving parts and > most Debian maintainers who want to focus on just packaging and not > learn all possible workflows and git layouts surely feel overwhelmed, > and we need to simplify this going forward. > > But for now most maintainers (meaning the subset who use > git-buildpackage) will get things correct by asking for each new > package these 3 questions: > > 1. Does upstream release tarballs? If so, enforce pristine-tar = True. > 2. Does upstream sign the tarballs? If so, configure explicit > signature checking with upstream-signatures = on. > 3. Does upstream have a Git repository, and does it have release Git > tags? If so, configure the release Git tag format, e.g. > upstream-vcs-tag = %(version%~%.)s. > > The above is a quote from > https://optimizedbyotto.com/post/debian-packaging-from-git/ for those > who want to read a longer explanation with "screenshots" and diagrams. > > The above post is using the Entr package in Debian as a real example, > and as you can see on the new debaudit pages it passes all green: > > https://debaudit.debian.net/orig-check/result/262f24ff0aa2ef9da6d40118294c404074c93753998db692b852b978dddf6a98 > https://debaudit.debian.net/git2dsc/result/262f24ff0aa2ef9da6d40118294c404074c93753998db692b852b978dddf6a98 > > > Simon: In your Go packages the vast majority should have > `upstream-vcs-tag = %v(version%~%.)s` (note the 'v' which is very > common for Go upstreams) and you should continue to always run `gbp > import-orig --uscan` as you do. The dh-make-golang will have this in > new gbp.conf files as soon as the PR that updates the template gets > merged. > > We should not stop using uscan. Maybe in the future if there are > better end-to-end workflows that everyone is happy with, but > prematurely abandoning relevant parts of the traditional workflow will > create a hard to manage mess, and potentially even large gaps in > software provenance and auditability. > > Hope this helps and clarifies things, > > Otto
