On 2/16/26 7:43 PM, tippfehlr wrote:
Hi everyone, > I’m Jonathan, also known as tippfehlr. I am a computer science studentat 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
OpenPGP_0xFDC3040B92ACA748.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
