Hi Jerome, Jerome BENOIT <calculus@rezozer.net> writes: > Hi, > > I am considering to package a software stored at GitHub. > It is under active development and it builds well in Sid. > However it appears that its source tarball at GitHub does not > contain all the necessary material: its submodules are not included. > This issue seems to be an old GitHub issue. Whatever. > I am wondering how we can grab its source tarball with uscan(1). > The best solution I come with is to write a script that would git-clone > with the option `--recurse-submodule` the git repo and then build a > source ball from this. However this approach sounds heavy to me. > Is there any better way ? Any example of a package with such an issue > is welcome. > > Cheers, > Jerome > > > > -- > Jerome BENOIT | calculus+at-rezozer^dot*net > https://qa.debian.org/developer.php?login=calculus@rezozer.net > AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B > I have recently encountered the similar issue with gptel, which makes its tests in a submodule. I think gbp support submodules, but it's not really compatible with uscan, so the tarball created by uscan is still missing the submodules. I have proposed a few solutions. The one upstream accepted is to let the submodule have the same release schedule as the main repo (basically same tag versions). Then in Debian I use uscan with the multiple upstream tarball (MUT) settings. uscan(1) manpage has examples (search for MUT). Of course, it would be better to persuade upstream to merge the repo, which would make their CI setup easier, though they may well reject it (with good reasons). -- Regards, Xiyue Deng
Attachment:
signature.asc
Description: PGP signature