Hello Hugh, On 26/11/2025 18:17, Hugh McMaster wrote: > Hi Arnaud, > > Sorry for my delayed reply. > > On 25/11/2025 2:42 am, Arnaud Rebillout wrote: >> This time, `gbp import-orig --uscan` does its job, it imports versions >> v2.1.0, however... It replaces the submodule with a git commit. >> >> Please tell me if I'm stubbornly missing something. > > I believe this is a bug in gbp import-orig. When it imports the > tarball, it clobbers the submodule somehow.
I have the same guess, but didn't check gbp's code. > I believe I've found the solution, and it looks to me like we have > been over-thinking this. > > Like you, I started a new repository based on the v2.0.0 tag. > > git clone --recurse-submodules > https://salsa.debian.org/hmc/maxminddb-golang.git > git switch upstream/latest > git remote add upstreamvcs > https://github.com/oschwald/maxminddb-golang.git > git fetch --recurse-submodules upstreamvcs > git merge v2.1.0 > git switch debian/latest > uscan -v At this point, the debian packaging branch is still at 2.0.0. The step to update to 2.1.0 is missing? On my side, I have found two solutions. 1) If the goal is to have submodules and track upstream git history, then I can use a "pure git" workflow. No uscan, no gbp, just two remotes (salsa and upstream). When I want to update my repo, I git fetch and git merge. That's roughly what's described at https://go-team.pages.debian.net/workflow-changes.html#wf-2017-11-upstream-branch, section "Packaging new upstream release". However this workflow never really took off in the Go packaging team. 2) If the goal is to use uscan and gbp, then I can just NOT track upstream git history. So not upstream remote, then uscan will use "git ls-remote" and get the submodule just fine. gbp imports it in a commit when it changes. It seems to work well. I decided to go for solution 2, because the 2 packages maxminddb-golang and mmdbinspect are maintained within the Go team, and teammates will basically do "gbp import-orig --uscan" to update those repositories. So I need this command to work out of the box. I don't care too much about git history (it's nice to have and it's standard practice in the team, but in this particular case we'll do without). One last thought on that: I really don't know what's the best way to approach packaging when upstream uses git submodules. You surely put more thoughts than me on that topic. But if you think that the right approach is to also have the submodules proper on salsa.debian.org, then that kind of clashes with tools like debcheckout / gbp-clone that don't setup submodules by default (TBH I didn't check, maybe this kind of things is being discussed and adjusted). It means that co-worker that want to work on my submodule-enabled packaging repo won't get their local git repo properly setup when they clone it, and good luck figuring out about the submodules. On that note, well, thanks a lot for spending so much time on that. I let you decide what to do with this bug report. Thanks again, -- Arnaud Rebillout / OffSec / Kali Linux Developer
