• Re: github repo with submodules: non usable source tarball

    From =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?@21:1/5 to All on Wed Jun 25 11:20:01 2025
    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.

    Can you provide the URL so we know what specifically we are talking
    about and what the upstream publishes about the release?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Antoine Le Gonidec@21:1/5 to All on Wed Jun 25 20:30:01 2025
    It seems this Write software mostly use submodules to depend on shared dependencies, the best move here (but probably not the easiest one) would be to packages these dependencies first.

    Write itself would be packaged afterwards, and build-depend on the packages included before it in the Debian archive.

    -----BEGIN PGP SIGNATURE-----

    iHUEARYKAB0WIQSUsdxM90hewW6X7Jhja3j5HOuA2AUCaFw+BgAKCRBja3j5HOuA 2J12AQDYIldr4yiZ0AXIZdIonyiK6yMSvqtXl0VfIio5r4ExeQEA7QCH0nwy6xOz kv2fqWUYuub27hNpMMMJGGtgSnAIFA8=
    =W2kY
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Noah Meyerhans@21:1/5 to Jerome BENOIT on Wed Jul 2 16:50:01 2025
    On Wed, Jun 25, 2025 at 09:38:07AM +0200, Jerome BENOIT wrote:
    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.

    The aws-crt-python source package is similar. See debian/README.source
    for how I handled that.[1] It works well enough, though it'd probably be
    good to use uscan's native submodule support instead if that's an
    option.

    noah

    1. https://salsa.debian.org/cloud-team/aws-crt-python/-/blob/debian/sid/debian/README.source?ref_type=heads

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Xiyue Deng@1:229/2 to Jerome BENOIT on Wed Jun 25 10:20:01 2025
    From: [email protected]

    Hi Jerome,

    Jerome BENOIT <[email protected]> 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/[email protected]
    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

    --=-=-Content-Type: application/pgp-signature; name="signature.asc"

    -----BEGIN PGP SIGNATURE-----

    iQJGBAEBCgAwFiEEiKQfd6o81mjI+LWALell7WOCXJMFAmhbsLoSHG1hbnBoaXpA Z21haWwuY29tAAoJEC3pZe1jglyT8tIP/RtPoD97Dk5BtQXxGyEbPHEuxWNiLWUb c8ndAxpgWLlXm97V1yZ8Wv9dkdXJvzteT9PT/sAsifRmJLlYHWrwEIFwaVADDSMP SBkQ4vseexyxRtPDGPcYLxGpkys8lw/xa1HvG1nkJEdgFRGO/ZBu0mZm3hNZD6uS bp060PLPCJHczza2fibJ8qQTAHuYt3SUZRkUgihkHM/WY33icRFmO5hJdeZsUxf/ DFL0jUOYdw2Sr23LJlxY0Jz2Wn/fK+f9cpLlL/D3Dd+VBXHA7E7BdVCZFu2cbJKn QbwuYnXPaZYqRxJQCVsmT0ecMROarYt8gpSiIwIyAJ/MjjaifrBiExEOeO4WtUgV BWJnbUbOwN+PD2wBLOwPJPog+OtExpck7O627RgibzunL5ZdJf8kL932TfdNQoLv xPGwaQT/bjVEmRleNTsV7VgaO2Sw5i/20NZDGZLpMjovc/AQeYeyGLmvrVyDKww3 H1aXUE9y9PKWvD09JqboWW1aim8G8N+Zih1VaFS8+doXXOyl0OHz3ldQ2b4sBLTX sO6gjRIdolpIFtw+uvyvcVmBz3AR/GBHj8hsxVnSzrArZT9gy1GkRTeAhdXUv7qr Z+1b9Dv0mbvXtsRU4i8wRdxjSZcQ3pxz1JISlizjM4yS8C1T+8s7/V7FaZz64hAM
    EeQogSZ9Pc+r
    =lVvA
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: you cannot