1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL.MENTOR

  • Packaging git submodule as multi upstream tarballs?

    From Daniel =?utf-8?Q?Gr=C3=B6ber?=@21:1/5 to All on Tue Jun 13 17:50:01 2023
    Hi Mentors,

    I'm working on packaging prjtrellis[1] which has a git submodule that is required for building. My plan is to use dpkg-source's multi upstream
    tarball support to do this.

    [1]: https://github.com/YosysHQ/prjtrellis

    I'm wondering if a) this is a good idea and 2) how to get uscan to download
    the precise commit referenced in the main package instead of the "latest" version. Is this even possible?

    I have a similar situation in my yosys package already (it has a
    berkeley-abc submodule) but since berkeley-abc is just a seperate package I just package the latest berkeley-abc commit and pray it doesn't diverge
    from what upstream's release uses too much. This is less than ideal
    obviously.

    Any input would be appreciated,
    --Daniel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Wise@21:1/5 to All on Wed Jun 14 10:10:01 2023
    On Tue, 2023-06-13 at 16:48 +0200, Daniel Gröber wrote:

    I'm working on packaging prjtrellis[1] which has a git submodule that is required for building. My plan is to use dpkg-source's multi upstream
    tarball support to do this.

    This appears to be the repo of the submodule:

    https://github.com/YosysHQ/prjtrellis-db

    I note Arch Linux uses a separate database package:

       $ grep database .github/archlinux/PKGBUILD
         # The database is provided in a separate package
         rmdir "$pkgdir"/usr/share/$_prj/database

    [1]: https://github.com/YosysHQ/prjtrellis

    This repo contains embedded code copies, please follow this advice:

    https://wiki.debian.org/EmbeddedCopies

    --
    bye,
    pabs

    https://wiki.debian.org/PaulWise

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

    iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmSJc/AACgkQMRa6Xp/6 aaOWnRAAjdN2vlJooyzsJeohlynVwSV/MkZaBXLv8CkQ+oJDfk27Z1UWx47FEsik p4489rZfyEmvqVjEaBesFB2MlnzQBDHz1MT5RvMapVy7HF9EajoY062W3vt4rpsO Ia6RRAnyhHZTBVhhhY8yktb8Ul7pD+sxye3JCBX6N73yP3v/LAOd/5QVekCzs46H icB8351WBVSUuMOxYDjuzbEnNrbj0xRU8YPpX6Yy+87o66B84f2mzvgbClNfG+it EnExmmFtfO3a6eloXAzWBClTqLeAtFrKrOQWjyB4rmulK+EszO5fDVVNMh8AxJFQ jwMwyhTzkNk9iMd1Zqn+GNWK9qRChWvhBdBprvfjk8mQQOinB8yfM410k5pigAWN eL4R2BYewb6BYBs8/9lbZ7jQbALr/JQwWib36gup1GlXB3QdfmAiCnfoceUZL57O 36+VVqBuf75ZDt5eMDuvX43pY0dkdyj7X1Grl/YERXr6WD5L3GfUHUEXJc0xfCN0 70OxwxNX2SQi16cHsyci3bwp857LUzTIcfSN8lXz/cUzU8FNyvZWBwtVpfCSQ77r wO/maSNSMhY16mrjyCWdTIZ5FGVYX3eDS/Dub02Og/7NjuSCCplKHUEFl4L32wpN Tqiph66G14Bqn9/a5R6Jo/dPk1zIHHJYbDcVLDBEc8qKnNdVavo=
    =BeJE
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ryan Pavlik@21:1/5 to [email protected] on Wed Jun 21 22:10:01 2023
    I'm not sure if uscan can do it, but for meshlab, as they don't tag the submodule when they release the main project, I have a script that updates
    the submodule commit using the github API. It's more clunky than I'd like,
    but I am not sure exactly how to fix this. It parses the version out of debian/changelog to find the main repo revision. https://salsa.debian.org/science-team/meshlab/-/blob/master/debian/get-orig-source.sh

    Ryan

    On Tue, Jun 13, 2023 at 10:45 AM Daniel Gröber <[email protected]> wrote:

    Hi Mentors,

    I'm working on packaging prjtrellis[1] which has a git submodule that is required for building. My plan is to use dpkg-source's multi upstream
    tarball support to do this.

    [1]: https://github.com/YosysHQ/prjtrellis

    I'm wondering if a) this is a good idea and 2) how to get uscan to download the precise commit referenced in the main package instead of the "latest" version. Is this even possible?

    I have a similar situation in my yosys package already (it has a
    berkeley-abc submodule) but since berkeley-abc is just a seperate package I just package the latest berkeley-abc commit and pray it doesn't diverge
    from what upstream's release uses too much. This is less than ideal obviously.

    Any input would be appreciated,
    --Daniel



    <div dir="ltr"><div>I&#39;m not sure if uscan can do it, but for meshlab, as they don&#39;t tag the submodule when they release the main project, I have a script that updates the submodule commit using the github API. It&#39;s more clunky than I&#39;d
    like, but I am not sure exactly how to fix this. It parses the version out of debian/changelog to find the main repo revision. <a href="https://salsa.debian.org/science-team/meshlab/-/blob/master/debian/get-orig-source.sh">https://salsa.debian.org/
    science-team/meshlab/-/blob/master/debian/get-orig-source.sh</a></div><div><br></div><div>Ryan<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 13, 2023 at 10:45 AM Daniel Gröber &lt;<a href="mailto:dxld@
    darkboxed.org">[email protected]</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Mentors,<br>

    I&#39;m working on packaging prjtrellis[1] which has a git submodule that is<br>
    required for building. My plan is to use dpkg-source&#39;s multi upstream<br> tarball support to do this.<br>

    [1]: <a href="https://github.com/YosysHQ/prjtrellis" rel="noreferrer" target="_blank">https://github.com/YosysHQ/prjtrellis</a><br>

    I&#39;m wondering if a) this is a good idea and 2) how to get uscan to download<br>
    the precise commit referenced in the main package instead of the &quot;latest&quot;<br>
    version. Is this even possible?<br>

    I have a similar situation in my yosys package already (it has a<br> berkeley-abc submodule) but since berkeley-abc is just a seperate package I<br> just package the latest berkeley-abc commit and pray it doesn&#39;t diverge<br> from what upstream&#39;s release uses too much. This is less than ideal<br> obviously.<br>

    Any input would be appreciated,<br>
    --Daniel<br>

    </blockquote></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Daniel =?utf-8?Q?Gr=C3=B6ber?=@21:1/5 to Ryan Pavlik on Wed Jun 21 23:30:01 2023
    Hi Ryan,

    On Wed, Jun 21, 2023 at 03:07:24PM -0500, Ryan Pavlik wrote:
    I'm not sure if uscan can do it,

    I did get it working but it's exceedingly cludgy. I have to use mode=git
    for the second component since uscan can't just download master.tar.gz
    AFACT (it's at a static location not linked from a page). I also have to
    set the version to "ignore" instead of "same" as the generated git commit
    based version is obviously not going to match the main project tag.

    Further I have to disable the uupdate hook since 1) it would have to be attached to the second component to work properly but 2) it gets passed the generated git version which again doesn't match the main tarball so it
    barfs as it can't find the orig.tar.

    What a mess.

    So I have this now:

    version=4
    opts=filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%@PACKAGE@-$1.tar.gz%,\
    https://github.com/YosysHQ/prjtrellis/tags \
    (?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian

    opts=mode=git,\
    component=database \
    https://github.com/YosysHQ/prjtrellis-db.git \
    HEAD ignore


    but for meshlab, as they don't tag the submodule when they release the
    main project, I have a script that updates the submodule commit using the github API. It's more clunky than I'd like, but I am not sure exactly how
    to fix this. It parses the version out of debian/changelog to find the
    main repo revision. https://salsa.debian.org/science-team/meshlab/-/blob/master/debian/get-orig-source.sh

    I was looking for an API endpoint to get the submodule commit actually,
    this way at least I don't have to do a temp clone just to get it. This is
    super useful, thanks!

    --Daniel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)