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

  • Ship a git .bundle in .dsc and .deb

    From Agathe Porte@21:1/5 to All on Thu Aug 15 00:10:01 2024
    Hello everyone,

    I have recently packaged qmk¹ into debian² (see rationale³).

    However the tool still needs to git clone the qmk_firmware repository⁴
    at runtime before being able to do any work. This is what the
    autopkgtest currently does⁵, with the needs-internet restiction⁶.

    ¹ https://github.com/qmk/qmk_cli/
    ² https://tracker.debian.org/pkg/qmk
    ³ https://people.debian.org/~gagath/posts/2024/08/04/qmk-available-in-unstable/
    ⁴ https://github.com/qmk/qmk_firmware/
    ⁵ https://salsa.debian.org/python-team/packages/qmk/-/blob/debian/latest/debian/tests/clone-and-build.sh?ref_type=heads
    ⁶ https://salsa.debian.org/python-team/packages/qmk/-/blob/debian/latest/debian/tests/control?ref_type=heads

    I was thinking of packaging qmk_firware into Debian in the form of a
    native (3.0) package that would contain a git bundle of the upstream git repository, and ship in for example in /usr/src/qmk_firmware/qmk_firmware.bundle

    Pros:

    - Offline autopkgtest
    - Faster autopkgtest?
    (remote counting objects takes time, git clone is >1 minute IIRC)
    - Users can add the bundle as a remote or git clone it to get started

    Cons:

    - Big binary blob in source package?
    - Impossible to pass ftp-master even if script to recreate bundle is
    provided?

    Note that the qmk tool does require a git repository to work, so I did
    not consider shipping only the code.

    Or maybe I could tar the upstream .git folder and store everything else
    as plain files? But still a binary blob in source package. And
    extracting the tar into a .git in the filesystem in /usr/share/ may
    raise a lot of Lintian warnings?

    Cheers,

    Agathe.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Todd Zullinger@21:1/5 to Piper McCorkle on Thu Aug 15 01:20:02 2024
    Piper McCorkle wrote:
    On Wednesday, 14 August 2024 16:43:54 CDT Agathe Porte wrote:
    Or maybe I could tar the upstream .git folder and store everything else
    as plain files? But still a binary blob in source package. And
    extracting the tar into a .git in the filesystem in /usr/share/ may
    raise a lot of Lintian warnings?

    Perhaps you could include the contents of the git repo in the source package,
    then in d/rules run something like `cd usr/src/qmk_firmware && git init && cp
    files . && git add -A && git commit`. That way, you just have regular files in
    the source package, but you generate a synthetic Git repo in the build process.

    Reproducibility might be difficult, given that git uses the current date and such for creating commits. Doesn't sound insurmountable though!

    You can set GIT_AUTHOR_NAME and GIT_COMMITTER_DATE to use
    SOURCE_DATE_EPOCH and export those vars (if there isn't a
    helper which does this already in the Debian build tooling).

    --
    Todd

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

    iHUEARYIAB0WIQSvlwC4tRNlCF6x+moHOcdGE+n45gUCZr05uQAKCRAHOcdGE+n4 5h4vAQDtogNI1ZR9wpzMk6nt7T3un68G5rYAEHrSSA1TK+RP+gEAgGbDXVjGyLnK Y61TVKmm4DOzGCeIfNpPMl7wZm0t4wY=
    =22kQ
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Colin Watson@21:1/5 to Agathe Porte on Thu Aug 15 01:40:01 2024
    On Wed, Aug 14, 2024 at 11:43:54PM +0200, Agathe Porte wrote:
    Note that the qmk tool does require a git repository to work, so I did
    not consider shipping only the code.

    Is there any reason qmk couldn't be patched to accept a plain directory
    as an alternative to a git repository? It looks like it's just using it
    as a way to transport a bunch of files, rather than really needing to
    provide a locally-editable version-controlled environment.

    In fact, to me it looks as though the "setup" subcommand is pretty close
    to this already. is_qmk_firmware will be quite happy with a plain
    directory as long as it has the right files in it, and it doesn't need a
    .git subdirectory. It seems as though you'd just need to have QMK_HOME
    fall back to /usr/share/qmk-firmware (or whatever) if it isn't
    explicitly set. Am I missing something?

    --
    Colin Watson (he/him) [[email protected]]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Johannes Schauer Marin Rodrigues@21:1/5 to All on Thu Aug 15 08:30:01 2024
    Quoting Todd Zullinger (2024-08-15 01:12:01)
    Piper McCorkle wrote:
    On Wednesday, 14 August 2024 16:43:54 CDT Agathe Porte wrote:
    Or maybe I could tar the upstream .git folder and store everything else
    as plain files? But still a binary blob in source package. And
    extracting the tar into a .git in the filesystem in /usr/share/ may
    raise a lot of Lintian warnings?

    Perhaps you could include the contents of the git repo in the source package,
    then in d/rules run something like `cd usr/src/qmk_firmware && git init && cp
    files . && git add -A && git commit`. That way, you just have regular files in
    the source package, but you generate a synthetic Git repo in the build process.

    Reproducibility might be difficult, given that git uses the current date and
    such for creating commits. Doesn't sound insurmountable though!

    You can set GIT_AUTHOR_NAME and GIT_COMMITTER_DATE to use
    SOURCE_DATE_EPOCH and export those vars (if there isn't a helper which does this already in the Debian build tooling).

    If you set GIT_COMMITTER_DATE, GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL then you can create bit-by-bit reproducible git commits with --date, --author and --message set to the desired value. We do this for metasnap.debian.net. Git has no problem producing bit-by-bit identical commits, given the same input.

    Thanks!

    cheers, josch
    --==============52601412853251733=MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Description: signature
    Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

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

    iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAma9njIACgkQ8sulx4+9 g+F88hAAsRI2E/7dqe9DiU2Mg7ur6+tGTpX0H75z36i/g83h2nd4chqxlJfwmB2H otdJyOOhiKw/5dtAN49NXZFyRQqyNWzefSVEuMnAZA/DKz0VYznfG5dBE7A2uQrJ ZW2GidTRVQHtMFfEtb7yqDU0NNqcSDfq9dSQKe4ZG+RCWPeM+2z5cbHIy5QWu7oU 53BkI3c1kHtKNIB6XGCy+L6rcLu/idPo3Ysjn6hf+mcZR6lhaQH7Fb8otQxNql3v 4gu7JLqBdJzT4ho1cnaRbIV306TqqCkumAcdKntrDay/69QbaBhdnqaL8EmDpTkH 7XNMZtpaDR6PT6xKD9sUwGsyfsSGmqeIS0cNXROjEv4ca90gr0qhrxEwdB3hkIFo iIIFsDYBhB7WYAKZiMJ0GNrDLknFQMS0OeQJAOBUoHoAuvYFrSVvoCe1bfVDOzGC LiRpxhvL0KrNrYSCsGUNYIc/BuuKW0frKu4eB1zScmMbklYvROuSVrBmW/4n+kKK x1xu59SoonyK+q3/tNpU7X0Ow15K9tTCB6smQeZyG0CAN1A3LX7SUgXW9vfopxHA DLXG1ckgkMGLofIIf8Iv337dQIQgsIitARRUVpKaK+kPoJyQAI9xWuorEhN47bpc Ysj8sUUqNHFLyZI42LzlpJqlK4RcTEBh8D8HhW6w4co8PP8kOSY=
    =a+Zr
    -----END PGP SIGNATURE-----

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