Agreed, the setup of the upstream sources is tedious, and at least on my laptop that runs Trisquel aramo (based on Ubuntu 22.04) gbp does not understand the --add-upstreamvcs parameter, so I add the git remote manually based on debian/upstream/metadata. I think this can be resolved by documenting in the Go policy something like: Clone the package using 'gbp clone vcs-git:golang-github-foo-bar --add-upstreamvcs' to set up upstream git tracking, or manually set up and fetch from a git remote based on debian/upstream/metadata: git remote add up $(grep ^Repository: debian/upstream/metadata |sed -e 's/.*: //') git fetch up After that, 'gbp import-orig --uscan' will work work. The second aspect is that 'gbp import-orig --uscan' fails with a unhelpful error message if the tag doesn't exist -- but maybe this has been improved in newer gbp? It could suggest a command to run to setup upstream git tracking. /Simon Reinhard Tartler <siretart@gmail.com> writes: > Hi Simon, > > I would definitely love to see upstream-vcs-tag used more often. > > The primary challenge with this is that it currently requires manual setup > of the upstream remote. Failing to perform this manual setup results in an > error, which is useful because otherwise the packaging repository won't > have the upstream Git history. I personally find the upstream Git history > very valuable, though I understand that some developers will disagree due > to different packaging style preferences. > > For the team, I understand that we did settle on DEP-14, which does seem to > mandate including the upstream history. > > The unfortunate aspect is the error behavior when one misses setting up the > proper upstream remote. I wonder whether we can improve the tooling to make > missing this step less surprising, particularly to less experienced > packagers? > > Best regards, > > Reinhard > > > On Fri, Nov 21, 2025 at 9:23 AM Simon Josefsson <simon@josefsson.org> wrote: > >> I made the change to golang-golang-x-text too, and uploaded it. >> >> This is systematic across most Go packages. >> >> Is there anyone who think that debian/gbp.conf should NOT contain the >> relevant 'upstream-vcs-tag' label? >> >> I'm wondering if we should use it for all Go packages. Right now I >> think it is only used in a smaller minority of packages, at least I >> rarely seems to notice it in existing packages. >> >> It is possible to make reasonable arguments against (e.g., it move >> things further away from a tarball-centric upstream view), but I'm not >> sure if anyone feels strongly about it. Otto has posted good argument >> for using it. >> >> If we make a decision, it would be nice to improve tooling somehow to >> notice lack of it. Right now none of the QA tools I use even suggests >> anything about this. >> >> I don't care either way, although if I was forced to chose I would use >> it, but I do care for consistency since eventually common idioms and >> patterns save everyone time. So I would be happier if we use it for all >> packages, or for no packages. Maybe this should be implicit through >> DEP14. It may be that we are essentially stuck on reaching any form of >> agreement, though, and things continue to be per-package tradition. >> >> /Simon >>
Attachment:
signature.asc
Description: PGP signature