Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1270910 > unrolled thread

Bug#1120385: uscan: v5: Git-Modules doesn't seem to work

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1120385: uscan: v5: Git-Modules doesn't seem to work Arnaud Rebillout <arnaudr@kali.org> - 2025-11-20 11:10 +0100
    Bug#1120385: uscan: v5: Git-Modules doesn't seem to work Arnaud Rebillout <arnaudr@kali.org> - 2025-11-21 09:40 +0100
      Bug#1120385: uscan: v5: Git-Modules doesn't seem to work Arnaud Rebillout <arnaudr@kali.org> - 2025-11-24 07:50 +0100
        Bug#1120385: uscan: v5: Git-Modules doesn't seem to work Arnaud Rebillout <arnaudr@kali.org> - 2025-11-24 12:10 +0100

#1270910 — Bug#1120385: uscan: v5: Git-Modules doesn't seem to work

[Multipart message — attachments visible in raw view] — view raw

On Mon, 17 Nov 2025 10:55:26 +0700 Arnaud Rebillout wrote:
> But then I can still reproduce it from the git repo that I work with
> usually, so I compared the logs from uscan -v, and I understand now that
> the difference is due to the presence of the upstream branch.

I meant "upstream remote" and not "upstream branch", sorry for the awful
confusion...

Arnaud

[toc] | [next] | [standalone]

#1271030

On 20/11/2025 20:08, Hugh McMaster wrote:
> No problem. I knew what you meant to say.
>
> I have a partial patch on Salsa [1] for a similar problem also using
> the git upstream mode. [2]
>
> The patch doesn't quite fix your bug, but `uscan -vv` debug output
> shows the right actions are happening.


Thanks for the pointer. I applied your patches, ran with "-vv", here's
what I found.

On
https://salsa.debian.org/arnaudr/golang-github-oschwald-maxminddb-golang-v2/
the directory "test-data" is NOT a submodule.

Background: initially this repository was created with the idea of
keeping upstream git history, so it was a git clone of upstream, however
the git submodule was NOT included. Later on I found out that the
submodule was needed for the tests. So I edited d/watch to switch to git
mode, and I imported a new upstream version. As a result, gbp/uscan
imported the content of this git submodule, however it came in under the
form of this extra commit that sits between the upstream branch and the
debian packaging branch. It's this commit:
11b4dcb8fb045b8a31f32f26b5a5e5ca8f55e2d7.

So the data is here, but it's under the form of a git commit, and not of
a git submodule. "git submodule status" shows nothing.

Now, when I run uscan, when it sees a upstream remote, it assumes the
git submodule is properly configured, and it runs this:

git submodule foreach --recursive git archive --format=tar \
  --prefix=golang-github-oschwald-maxminddb-golang-v2-2.1.0/$displaypath/ \
  --output=../$sha1.tar HEAD

But this command has no effect (it doesn't even fail, it's just no-op).

I tried to find a way out of this situation, but surprisingly it's very
hard, didn't even manage after an hour, I'm giving up for now.

I hope that sheds some light on the issue. If you have any
recommendation, I'm happy to hear it.

Arnaud

[toc] | [prev] | [next] | [standalone]

#1271392

On 23/11/2025 19:06, Hugh McMaster wrote:
> I have spent a lot of time investigating this issue and had the same
> problem, even with my own packages.
>
> The solution is to use a Git clone of the upstream repository as the
> starting point for creating Debian packaging.
>
> Otto Kekäläinen has a written a guide that works well, even with
> submodules. [1]
>
> Note that when calling `git clone`, you need to add
> `--recurse-submodules` to the command line too.
>
> I did a quick test using Otto's instructions on your repository. The
> result is at [2] and work as expected with uscan.
>
> Let me know how you go.
>
> Hugh
>
> [1] https://optimizedbyotto.com/post/debian-packaging-from-git/
>
> [2]
> https://salsa.debian.org/hmc/golang-github-oschwald-maxminddb-golang-v2 


[2] is not reachable, maybe it's private?

Ideally I wanted to be able to fix the existing git repo, rather than
restart from scratch. The repo I gave in this bug report was under my
own namespace (because edited for the purpose of this bug report), but
in fact I have two repositories that are facing this issue, and already
uploaded, so I'd prefer to avoid force-pushing.

But this morning I spend a couple of hours on that again, failed again,
I keep banging my head against a wall it feels, so at this point any
solution will do. And thanks for spending the time on this issue :)

Best,

-- 
Arnaud Rebillout / OffSec / Kali Linux Developer

[toc] | [prev] | [next] | [standalone]

#1271406

On 24/11/2025 15:45, Hugh McMaster wrote:
> On 24/11/2025 5:46 pm, Arnaud Rebillout wrote:
>> [2] is not reachable, maybe it's private?
>
> Sorry, that should be fixed now.

Thanks!

So I `git clone` your repo, then I found out that... I need to pass
--recurse-submodules, of course.

So I `git clone --recurse-submodules` and all looks good. The
`test-data` directory is populated, and I get some output with `git
submodule status`, showing that the submodule was properly initialized.

Now let's try an update this repo, we're going to update from git HEAD
since there's no new upstream release:

```
# create upstream branch
git branch upstream 8b6ffca

# edit d/watch to track git head
Mode: git
Source: https://github.com/oschwald/maxminddb-golang.git
Matching-Pattern: HEAD
Git-Modules: all
Git-Pretty: 2.1.0+git%cd.%h

# commit
git add debian
git commit -m "Update watch file"
```

Then I run `uscan`, it gets me the right tarball, including the
submodule. All good.

Now, I want to import that in my git repo, and also track upstream git
history:

```
# Add and fetch upstream remote
git remote add upstreamvcs https://github.com/oschwald/maxminddb-golang.git
git fetch upstreamvcs

# Import
gbp import-orig
../golang-github-oschwald-maxminddb-golang-v2_2.1.0+git20251120.4d0333b.orig.tar.xz
--upstream-vcs-tag=4d0333b --debian-branch=debian/latest
```

And... Alas! gbp added the test-data directory to the "New upstream
version" commit, and now the submodule is gone, `git submodule status`
returns nothing. We're back to the beginning.

Did I do something wrong?

Off-Topic: I had to be careful to add the upstream vcs only AFTER
running uscan, otherwise I hit #1120533 (uscan doesn't fetch the right
git HEAD), which doesn't seem to be fixed in devscripts 2.25.27.

Best,

Arnaud

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web