Package Maintainer Application - Jonathan Grotelüschen
Hi everyone, I’m Jonathan, also known as tippfehlr. I am a computer science student at KIT in Karlsruhe, Germany, and I hereby apply to become a Package Maintainer. My Linux journey began with a Raspberry Pi 1B I received as a gift in 2017. After that, I hosted a few Minecraft servers on Linux Mint (though not on the 1B). A few years later, I did an internship in a company using openSUSE, but one person used Arch Linux and Neovim and impressed me a lot at the time. In 2021, I started using an old laptop for school and installed 32-bit Debian on it, but quickly switched to Arch Linux when I discovered it was a 64-bit CPU. With the experience I had from my laptop, I finally installed Arch on my PC in 2022. I had installed Manjaro before, but Arch was the first distro that replaced Windows for me. Since then, it always just worked. When I got a new laptop, Arch was simply the easiest thing to install. I started contributing to the AUR in late 2023, when I needed an INAV related package that was not yet available. Since then, I learned a lot about packaging and about the Arch community in general. A few years ago I also started self-hosting services for my family and realized that I enjoy the Sysadmin and DevOps side of software a lot. I mostly used Docker Compose until now, but I would like to learn more. So if there is need, I’d like to help there as well. Generally, I love tinkering and configuring, which probably isn’t surprising in this community. Just recently, I annoyed my brother because I ended up modding a game instead of actually playing it with him :) Outside the digital world, I love to play the Cello and like to read fantasy. I am also active in my local community: In my dorm, I lead the 3d-printing lab and volunteer in the network department, where we are currently doing a big Wi-Fi upgrade. We also maintain an Arch Linux mirror at https://files.hadiko.de/pub/dists/arch/! Since a friend in school introduced me to FPV drones, I also like to tinker with/fly my model airplane. If you want to take a look, most of my personal projects and contributions to other projects are on Codeberg [1] or on GitHub [2]. Over time, I collected a list of packages I use and would like to maintain in the official repositories: Development tools: - git-extras - dockerfile-language-server - emmet-language-server - dprint RC Flight: - betaflight-configurator - inav-configurator Games: - heroic-games-launcher - modrinth-app - osu-lazer Misc: - jellyfin-desktop (was jellyfin-media-player) - pfetch-rs I’m using Neovim without Mason and usually install language servers with pacman. I took some time to look through packages with only one maintainer and noticed a few language servers (for example arduino- and typescript-language-server) where I’d be happy to help out as a co-maintainer. My application is sponsored by Christian Heusel (gromit) and Peter Jung (ptr1337). Thanks for the nice talk and all the feedback so far! Best, Jonathan Grotelüschen [1] https://codeberg.org/tippfehlr [2] https://github.com/tippfehlr AUR: https://aur.archlinux.org/packages?O=0&SeB=M&K=tippfehlr&outdated=&SB=p&SO=d...
On 2/16/26 19:43, tippfehlr wrote:
Hi everyone,
Hi Jonathan, :)
I’m Jonathan, also known as tippfehlr. I am a computer science student at KIT in Karlsruhe, Germany, and I hereby apply to become a Package Maintainer.
My Linux journey began with a Raspberry Pi 1B I received as a gift in 2017. After that, I hosted a few Minecraft servers on Linux Mint (though not on the 1B). A few years later, I did an internship in a company using openSUSE, but one person used Arch Linux and Neovim and impressed me a lot at the time. In 2021, I started using an old laptop for school and installed 32-bit Debian on it, but quickly switched to Arch Linux when I discovered it was a 64-bit CPU. With the experience I had from my laptop, I finally installed Arch on my PC in 2022. I had installed Manjaro before, but Arch was the first distro that replaced Windows for me. Since then, it always just worked. When I got a new laptop, Arch was simply the easiest thing to install.
I started contributing to the AUR in late 2023, when I needed an INAV related package that was not yet available. Since then, I learned a lot about packaging and about the Arch community in general.
A few years ago I also started self-hosting services for my family and realized that I enjoy the Sysadmin and DevOps side of software a lot. I mostly used Docker Compose until now, but I would like to learn more. So if there is need, I’d like to help there as well.
Generally, I love tinkering and configuring, which probably isn’t surprising in this community. Just recently, I annoyed my brother because I ended up modding a game instead of actually playing it with him 🙂
Outside the digital world, I love to play the Cello and like to read fantasy. I am also active in my local community: In my dorm, I lead the 3d-printing lab and volunteer in the network department, where we are currently doing a big Wi-Fi upgrade. We also maintain an Arch Linux mirror at https://files.hadiko.de/pub/dists/arch/! Since a friend in school introduced me to FPV drones, I also like to tinker with/fly my model airplane.
If you want to take a look, most of my personal projects and contributions to other projects are on Codeberg [1] or on GitHub [2].
Over time, I collected a list of packages I use and would like to maintain in the official repositories:
Development tools: - git-extras - dockerfile-language-server - emmet-language-server - dprint
RC Flight: - betaflight-configurator - inav-configurator
Games: - heroic-games-launcher - modrinth-app - osu-lazer
Misc: - jellyfin-desktop (was jellyfin-media-player) - pfetch-rs
I’m using Neovim without Mason and usually install language servers with pacman. I took some time to look through packages with only one maintainer and noticed a few language servers (for example arduino- and typescript-language-server) where I’d be happy to help out as a co-maintainer.
My application is sponsored by Christian Heusel (gromit) and Peter Jung (ptr1337). Thanks for the nice talk and all the feedback so far!
I confirm my sponsorship and think he tippfehlr would be a great addition to archlinux packaging team! I wish you good luck with the application!
Best, Jonathan Grotelüschen
[1] https://codeberg.org/tippfehlr [2] https://github.com/tippfehlr
AUR: https://aur.archlinux.org/packages?O=0&SeB=M&K=tippfehlr&outdated=&SB=p&SO=d...
Best regards, Peter "ptr1337" Jung
On 2/17/26 21:36, Peter Jung wrote:
On 2/16/26 19:43, tippfehlr wrote:
Hi everyone,
Hi Jonathan, 🙂
I’m Jonathan, also known as tippfehlr. I am a computer science student at KIT in Karlsruhe, Germany, and I hereby apply to become a Package Maintainer.
My Linux journey began with a Raspberry Pi 1B I received as a gift in 2017. After that, I hosted a few Minecraft servers on Linux Mint (though not on the 1B). A few years later, I did an internship in a company using openSUSE, but one person used Arch Linux and Neovim and impressed me a lot at the time. In 2021, I started using an old laptop for school and installed 32-bit Debian on it, but quickly switched to Arch Linux when I discovered it was a 64-bit CPU. With the experience I had from my laptop, I finally installed Arch on my PC in 2022. I had installed Manjaro before, but Arch was the first distro that replaced Windows for me. Since then, it always just worked. When I got a new laptop, Arch was simply the easiest thing to install.
I started contributing to the AUR in late 2023, when I needed an INAV related package that was not yet available. Since then, I learned a lot about packaging and about the Arch community in general.
A few years ago I also started self-hosting services for my family and realized that I enjoy the Sysadmin and DevOps side of software a lot. I mostly used Docker Compose until now, but I would like to learn more. So if there is need, I’d like to help there as well.
Generally, I love tinkering and configuring, which probably isn’t surprising in this community. Just recently, I annoyed my brother because I ended up modding a game instead of actually playing it with him 🙂
Outside the digital world, I love to play the Cello and like to read fantasy. I am also active in my local community: In my dorm, I lead the 3d-printing lab and volunteer in the network department, where we are currently doing a big Wi-Fi upgrade. We also maintain an Arch Linux mirror at https://files.hadiko.de/pub/dists/arch/! Since a friend in school introduced me to FPV drones, I also like to tinker with/fly my model airplane.
If you want to take a look, most of my personal projects and contributions to other projects are on Codeberg [1] or on GitHub [2].
Over time, I collected a list of packages I use and would like to maintain in the official repositories:
Development tools: - git-extras - dockerfile-language-server - emmet-language-server - dprint
RC Flight: - betaflight-configurator - inav-configurator
Games: - heroic-games-launcher - modrinth-app - osu-lazer
Misc: - jellyfin-desktop (was jellyfin-media-player) - pfetch-rs
I’m using Neovim without Mason and usually install language servers with pacman. I took some time to look through packages with only one maintainer and noticed a few language servers (for example arduino- and typescript-language-server) where I’d be happy to help out as a co-maintainer.
My application is sponsored by Christian Heusel (gromit) and Peter Jung (ptr1337). Thanks for the nice talk and all the feedback so far!
I confirm my sponsorship and think he tippfehlr would be a great addition to archlinux packaging team! I wish you good luck with the application!
Best, Jonathan Grotelüschen
[1] https://codeberg.org/tippfehlr [2] https://github.com/tippfehlr
AUR: https://aur.archlinux.org/packages?O=0&SeB=M&K=tippfehlr&outdated=&SB=p&SO=d...
Best regards, Peter "ptr1337" Jung
Missed to sign the email :) Now its good
On 26/02/16 07:43PM, tippfehlr wrote:
Hi everyone,
Hey,
I’m Jonathan, also known as tippfehlr. I am a computer science student at KIT in Karlsruhe, Germany, and I hereby apply to become a Package Maintainer.
[...]
My application is sponsored by Christian Heusel (gromit) and Peter Jung (ptr1337). Thanks for the nice talk and all the feedback so far!
I hereby confirm my sponsorship of tippfehlr! This marks the start of the 2-week discussion period, which will conclude on 2026-03-03. Good luck in the process and I hope we can have a nice discussion around this application :)
Best, Jonathan Grotelüschen
Cheers, Chris
[1] https://codeberg.org/tippfehlr [2] https://github.com/tippfehlr
AUR: https://aur.archlinux.org/packages?O=0&SeB=M&K=tippfehlr&outdated=&SB=p&SO=d...
On 26/02/17 11:11PM, Christian Heusel wrote:
On 26/02/16 07:43PM, tippfehlr wrote:
Hi everyone,
Hello everyone,
I’m Jonathan, also known as tippfehlr. I am a computer science student at KIT in Karlsruhe, Germany, and I hereby apply to become a Package Maintainer.
[...]
My application is sponsored by Christian Heusel (gromit) and Peter Jung (ptr1337). Thanks for the nice talk and all the feedback so far!
I hereby confirm my sponsorship of tippfehlr! This marks the start of the 2-week discussion period, which will conclude on 2026-03-03.
thanks for everyone who had questions for tippfehlr, we have now concluded the discussion period and the vote is now live: https://aur.archlinux.org/package-maintainer/162 The voting period will run until 2026-03-12 12:11 (CET).
Good luck in the process and I hope we can have a nice discussion around this application :)
Best, Jonathan Grotelüschen
Cheers, Chris
Hello everyone, the voting period regarding the addition of tippfehlr as a Package Maintainer is now over and the results are in: - Yes: 40 - No: 2 - Abstain: 11 - Quorum 80.3 % Given the amount of votes the neccessary quorum of 66 % also has been reached and we can congratulate the candidate for being accepted and soon receiving the keys to the castle! 🎉 Cheers, Chris On 26/03/05 12:14PM, Christian Heusel wrote:
On 26/02/17 11:11PM, Christian Heusel wrote:
On 26/02/16 07:43PM, tippfehlr wrote:
Hi everyone,
Hello everyone,
I’m Jonathan, also known as tippfehlr. I am a computer science student at KIT in Karlsruhe, Germany, and I hereby apply to become a Package Maintainer.
[...]
My application is sponsored by Christian Heusel (gromit) and Peter Jung (ptr1337). Thanks for the nice talk and all the feedback so far!
I hereby confirm my sponsorship of tippfehlr! This marks the start of the 2-week discussion period, which will conclude on 2026-03-03.
thanks for everyone who had questions for tippfehlr, we have now concluded the discussion period and the vote is now live:
https://aur.archlinux.org/package-maintainer/162
The voting period will run until 2026-03-12 12:11 (CET).
Good luck in the process and I hope we can have a nice discussion around this application :)
Best, Jonathan Grotelüschen
Cheers, Chris
On February 16, 2026 1:43:27 PM EST, tippfehlr <tippfehlr@tippfehlr.dev> wrote:
Hi everyone,
I’m Jonathan, also known as tippfehlr. I am a computer science student at KIT in Karlsruhe, Germany, and I hereby apply to become a Package Maintainer.
Hi Jonathan!
My Linux journey began with a Raspberry Pi 1B I received as a gift in 2017. After that, I hosted a few Minecraft servers on Linux Mint (though not on the 1B). A few years later, I did an internship in a company using openSUSE, but one person used Arch Linux and Neovim and impressed me a lot at the time. In 2021, I started using an old laptop for school and installed 32-bit Debian on it, but quickly switched to Arch Linux when I discovered it was a 64-bit CPU. With the experience I had from my laptop, I finally installed Arch on my PC in 2022. I had installed Manjaro before, but Arch was the first distro that replaced Windows for me. Since then, it always just worked. When I got a new laptop, Arch was simply the easiest thing to install.
Archinstall or manual? (Just out of curiosity, I'm an Archinstall guy myself)
I started contributing to the AUR in late 2023, when I needed an INAV related package that was not yet available. Since then, I learned a lot about packaging and about the Arch community in general.
The AUR is the metaphorical gateway drug that leads to becoming a PM. It happened to me too.
A few years ago I also started self-hosting services for my family and realized that I enjoy the Sysadmin and DevOps side of software a lot. I mostly used Docker Compose until now, but I would like to learn more. So if there is need, I’d like to help there as well.
I'm sure gromit has already told you, but we could always use more DevOps folks ;)
Generally, I love tinkering and configuring, which probably isn’t surprising in this community. Just recently, I annoyed my brother because I ended up modding a game instead of actually playing it with him :)
Outside the digital world, I love to play the Cello and like to read fantasy. I am also active in my local community: In my dorm, I lead the 3d-printing lab and volunteer in the network department, where we are currently doing a big Wi-Fi upgrade. We also maintain an Arch Linux mirror at https://files.hadiko.de/pub/dists/arch/! Since a friend in school introduced me to FPV drones, I also like to tinker with/fly my model airplane.
Favorite fantasy novel?
If you want to take a look, most of my personal projects and contributions to other projects are on Codeberg [1] or on GitHub [2].
Half good choice in forge!
Over time, I collected a list of packages I use and would like to maintain in the official repositories:
Development tools: - git-extras - dockerfile-language-server - emmet-language-server - dprint
RC Flight: - betaflight-configurator - inav-configurator
Games: - heroic-games-launcher - modrinth-app - osu-lazer
Misc: - jellyfin-desktop (was jellyfin-media-player) - pfetch-rs
I’m using Neovim without Mason and usually install language servers with pacman. I took some time to look through packages with only one maintainer and noticed a few language servers (for example arduino- and typescript-language-server) where I’d be happy to help out as a co-maintainer.
My application is sponsored by Christian Heusel (gromit) and Peter Jung (ptr1337). Thanks for the nice talk and all the feedback so far!
Along with the duties of a package maintainer, there are other aspects of Arch that you could help out with if you're so inclined. There's DevOps, as you previously mentioned, alongside efforts like Keycloak integration, AUR moderation, Archweb improvements, architecture ports, buildbtw, signstar, et cetera. I'm not looking for a commitment because this is strictly a package maintainer application, but do any of these efforts interest you?
Best, Jonathan Grotelüschen
[1] https://codeberg.org/tippfehlr [2] https://github.com/tippfehlr
AUR: https://aur.archlinux.org/packages?O=0&SeB=M&K=tippfehlr&outdated=&SB=p&SO=d...
Solid application and I know Christian and Peter have good taste. Looking forward to hearing from you! Best, Campbell Jones (serebit)
On 2026-02-18 00:05, Campbell Jones wrote:
Hi Jonathan!
Hi Campbell!
With the experience I had from my laptop, I finally installed Arch on my PC in 2022. I had installed Manjaro before, but Arch was the first distro that replaced Windows for me. Since then, it always just worked. When I got a new laptop, Arch was simply the easiest thing to install. Archinstall or manual? (Just out of curiosity, I'm an Archinstall guy myself)
The first install was manual, but since then I’ve been using Archinstall :)
The AUR is the metaphorical gateway drug that leads to becoming a PM. It happened to me too.
The red pill, if you will. But I think it’s great that the AUR has a rather low barrier to entry for new users!
A few years ago I also started self-hosting services for my family and realized that I enjoy the Sysadmin and DevOps side of software a lot. I mostly used Docker Compose until now, but I would like to learn more. So if there is need, I’d like to help there as well. I'm sure gromit has already told you, but we could always use more DevOps folks ;)
I’m happy to help where I can!
Favorite fantasy novel?
I’d say Eragon, I’m a huge dragon fan and like its magic system. But there are a lot of good ones and I’ve been reading The Kingkiller Chronicles and Fourth Wing lately.
If you want to take a look, most of my personal projects and contributions to other projects are on Codeberg [1] or on GitHub [2]. Half good choice in forge!
An easy decision with Microsoft pushing Copilot onto GitHub. Since last summer, I’m also a member of Codeberg e.V.!
Along with the duties of a package maintainer, there are other aspects of Arch that you could help out with if you're so inclined. There's DevOps, as you previously mentioned, alongside efforts like Keycloak integration, AUR moderation, Archweb improvements, architecture ports, buildbtw, signstar, et cetera. I'm not looking for a commitment because this is strictly a package maintainer application, but do any of these efforts interest you?
I wouldn’t want to commit to everything straight away, but I plan to contribute in other areas as well. I’m rather on the Rust side of programming languages and looked a bit into buildbtw; at least the frontend stack looks very similar to a university project I’m currently working on (we’re using actix-web and askama). For aurweb, I actually have one [1] and a half [2] small open merge requests (the first one would be ready for a review :)). As I mentioned, I’d like to learn more about DevOps, and of course I’d also help with AUR moderation.
Solid application and I know Christian and Peter have good taste. Looking forward to hearing from you!
Best, Campbell Jones (serebit)
Best, Jonathan [1] https://gitlab.archlinux.org/archlinux/aurweb/-/merge_requests/870 [2] https://gitlab.archlinux.org/archlinux/aurweb/-/merge_requests/881 PS: I sent this email from my eu address because the message from dev wouldn’t reach the list. It is signed with the same PGP key.
On 2/16/26 7:43 PM, tippfehlr wrote:
> Hi everyone,
> > I’m Jonathan, also known as tippfehlr. I am a computer science student
> at KIT in Karlsruhe, Germany, and I hereby apply to become a Package
> Maintainer.
Hey Jonathan,
Thanks for applying as a Package Maintainer, good luck!
>
> My Linux journey began with a Raspberry Pi 1B I received as a gift in
> 2017. After that, I hosted a few Minecraft servers on Linux Mint (though
> not on the 1B). A few years later, I did an internship in a company
> using openSUSE, but one person used Arch Linux and Neovim and impressed
> me a lot at the time.
> In 2021, I started using an old laptop for school and installed 32-bit
> Debian on it, but quickly switched to Arch Linux when I discovered it
> was a 64-bit CPU.
> With the experience I had from my laptop, I finally installed Arch on my
> PC in 2022. I had installed Manjaro before, but Arch was the first
> distro that replaced Windows for me. Since then, it always just worked.
> When I got a new laptop, Arch was simply the easiest thing to install.
Cool journey :)
>
> I started contributing to the AUR in late 2023, when I needed an INAV
> related package that was not yet available. Since then, I learned a lot
> about packaging and about the Arch community in general.
Nice, the AUR is indeed a great resource to learn about packaging!
>
> A few years ago I also started self-hosting services for my family and
> realized that I enjoy the Sysadmin and DevOps side of software a lot. I
> mostly used Docker Compose until now, but I would like to learn more. So
> if there is need, I’d like to help there as well.
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 :)
>
> Generally, I love tinkering and configuring, which probably isn’t
> surprising in this community. Just recently, I annoyed my brother
> because I ended up modding a game instead of actually playing it with
> him :)
>
> Outside the digital world, I love to play the Cello and like to read
> fantasy. I am also active in my local community: In my dorm, I lead the
> 3d-printing lab and volunteer in the network department, where we are
> currently doing a big Wi-Fi upgrade. We also maintain an Arch Linux
> mirror at https://files.hadiko.de/pub/dists/arch/!
Very nice!
> Since a friend in school introduced me to FPV drones, I also like to
> tinker with/fly my model airplane.
>
> If you want to take a look, most of my personal projects and
> contributions to other projects are on Codeberg [1] or on GitHub [2].
>
> Over time, I collected a list of packages I use and would like to
> maintain in the official repositories:
>
> Development tools:
> - git-extras
> - dockerfile-language-server
> - emmet-language-server
> - dprint
>
> RC Flight:
> - betaflight-configurator
> - inav-configurator
>
> Games:
> - heroic-games-launcher
> - modrinth-app
> - osu-lazer
> > Misc:
> - jellyfin-desktop (was jellyfin-media-player)
> - pfetch-rs
Cool list!
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.
>
> I’m using Neovim without Mason and usually install language servers with
> pacman. I took some time to look through packages with only one
> maintainer and noticed a few language servers (for example arduino- and
> typescript-language-server) where I’d be happy to help out as a co-
> maintainer.
Thanks for looking a look at packages with an insufficient numbers of
maintainers :)
>
> My application is sponsored by Christian Heusel (gromit) and Peter Jung
> (ptr1337). Thanks for the nice talk and all the feedback so far!
>
I see the German Arch Gang keeps expanding :P
>
> Best,
> Jonathan Grotelüschen
>
>
> [1] https://codeberg.org/tippfehlr
> [2] https://github.com/tippfehlr
>
> AUR:
> https://aur.archlinux.org/packages?
> O=0&SeB=M&K=tippfehlr&outdated=&SB=p&SO=d&PP=50&submit=Go
>
Your 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].
- 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].
- 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.
Good application overall! I also had the occasion to discuss briefly
with you over IRC and the experience was pleasing!
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
--
Regards,
Robin Candau / Antiz
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=Go Your 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#n4... [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_be... [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-s... [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-l... [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#n...
On 3/2/26 2:08 PM, tippfehlr wrote:
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.
Not gonna lie, I'd be surprised too :P It was just to say that, the "gray area" of "they don't say anything about it so it's *probably* okay" might not be good enough in my opinion (though others might have a different point of view).
AUR: https://aur.archlinux.org/packages? O=0&SeB=M&K=tippfehlr&outdated=&SB=p&SO=d&PP=50&submit=Go Your 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 :)
It is yeah. Hopefully, the solution we came up with on IRC will be good / robust enough on the long run to circumvent the fact that upstream doesn't provides all licenses in their own files.
- 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?
I would personally prefer the file being sourced in the PKGBUILD and locked behind a checksum, even if it implies an extra `sed -i "s/ELECTRON_VER/$_electron/g" file` in `prepare()`. But again, I'm not sure we have proper guidelines on that front, so this is probably a matter of personal preference here.
- 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!
You're welcome!
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
-- Regards, Robin Candau / Antiz
participants (6)
-
Campbell Jones
-
Christian Heusel
-
Peter Jung
-
Robin Candau
-
tippfehlr
-
tippfehlr