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.
