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
