On 2026-03-01 16:52, Robin Candau wrote:
Hey Jonathan,
Hi Robin!
I guess there's always a need for help on the DevOps side, though the technical stack doesn't include Docker (we mostly rely on our own packages / tooling, deployed with IaC tools like Terraform and Ansible). The application process is also a bit stricter (since giving keys to the infra implies a lot of accesses and responsibilities). Still, good to know you'd eventually be interested in helping on that front. That's something that can eventually be revisited later if you're accepted as a package maintainer :)
That’s also how I meant it, I don’t want to start everything at once :D I also need to learn the basics of IaC beforehand anyway.
Regarding heroic-games-launcher though: Don't quote me on that, as I'm not very familiar with the Heroic Games Launcher and the "ecosystem" around it, but I had a quick talk about it with carsme and it's apparently not very clear if Epic and Amazon are _fully_ okay with it TOS wise. At least, they don't seem to explicitly allow third party launchers, which is a bit of a "gray area" that we shouldn't take advantage of (in my opinion). As far as I understand, without explicit authorization from Epic and Amazon to use such third party launchers, officially redistributing heroic-games-launcher in our repository could theoretically expose us to a legal takedown request / enforcement from them (e.g. similar to Discord that do not authorize the usage of third party clients like vesktop, and banned users for it). But again, I'm not very familiar with Heroic Games Launcher (nor Epic / Amazon) and I didn't take a deeper look at it so this should be clarified. Still, if one is looking at promoting it to the official repository, I would personally suggest getting explicit consent from wrapped proprietary platform (Epic / Amazon) somehow, just to avoid exposing ourself to any unexpected risks.
It would surprise me a lot if Epic or Amazon would explicitly allow third party launchers, or the distribution of them ^^ But I wasn’t aware of that, thanks for letting me know. I’ll focus on other packages first and do more research in case I want to add Heroic Games Launcher to extra.
AUR: https://aur.archlinux.org/packages? O=0&SeB=M&K=tippfehlr&outdated=&SB=p&SO=d&PP=50&submit=GoYour AUR PKGBUILDs generally looks good! Here are a few small improvements / suggestions (those are mostly details though, nothing really critical): - arduino-avr-core: All non-common / custom licenses (in that case, MIT and the custom one) should be shipped with the package under /usr/share/ licenses/$pkgname [1].
That repo is a mess, but thanks for the additional feedback on IRC :)
- openbuilds-control{,-bin,-git}: I'd personally prefer to have the
wrapper "/usr/bin" script being part of the PKGBUILD source (like it's
done for the desktop file) and locked behind a checksum. This makes it
easier to detect / review changes in my opinion. Not sure if we have
actual written guidelines on that front, so that might be more of a
personal preference than anything I guess [2].
One advantage of this approach is that it can use the $_electron variable directly. The file would need a replace in prepare(), or a manual one for every electron bump. Would you prefer that?
- tail-tray: Is the "Release" CMake build type required? Otherwise, our packaging guidelines recommend the "None" build type to avoid overwriting Arch Linux default flag [3] [4]. Also, the "davfs2" optional dependency could benefit from a description I guess [5]. - servicer-bin: We very rencently split the gcc-libs package (see the related todo [6]). The gcc-libs package will therefore be deprecated & removed at some point. Might be worth to update dependencies accordingly (namcap should help here) [7]. Regarding the license, have you tried contacting upstream to see if they can ship the license file with the prebuilt bin in a tarball? That would avoid the need to fetch the LICENSE from git's HEAD, which could eventually lead to unstable source / unpredictable checksum changes accros (re)build in case the LICENSE changes in the MASTER branch (e.g. update of the copyright holder or the year). Alternatively, you could set the checksum to SKIP to mitigate the issue, but upstream shipping the license file with the binary would ultimately be the best scenario here [8]. - dockerfile-language-server: Have you tried building the package from git sources (or github auto-generated tarball) rather than from npmjs tarball? [9] We usually now tend to avoid relying on custom made or platform specific tarballs for package sources (when possible) for various reasons, for instance because of opinionated design by said platforms (see e.g. [10] for pypi) or for an improved transparency in packages sources, thanks to sources that are easier to audit (see [11] [12]). - horcrux: No reason for the package to conflict itself [13]. - cpx-bin: Should provide & conflict `cpx` [14]. - blackbox-tools-inav: No need to conflict with `blackbox-tools-git`. It's up to `blackbox-tools-git` to provide `blackbox-tools` instead (and therefore, your package conflicting with `blackbox-tools` is enough) [15]. Again, this is mostly details, nothing really critical in there.
Thanks for the detailed feedback!
Good application overall! I also had the occasion to discuss briefly with you over IRC and the experience was pleasing!
The pleasure was mine!
I think you would be a great addition to the team :)
[1] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=arduino-avr-core#n18 [2] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=openbuilds-control#n43 [3] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=tail-tray#n23 [4] https://wiki.archlinux.org/title/CMake_package_guidelines#CMake_undesired_behaviors [5] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=tail-tray#n12 [6] https://archlinux.org/todo/gcc-libs-deprecation/ [7] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=servicer-bin#n12 [8] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=servicer-bin#n14 [9] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=dockerfile-language-server#n16 [10] https://rfc.archlinux.page/0020-sources-for-python-packaging/ [11] https://rfc.archlinux.page/0046-upstream-package-sources/ [12] https://fosdem.org/2026/schedule/event/FFWA7E-transparent-sources-for-arch-linux-packages/ [13] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=horcrux#n11 [14] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=cpx-bin [15] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=blackbox-tools-inav#n14
OpenPGP_signature.asc
Description: OpenPGP digital signature
