Package Maintainer application
Hi, my name's Martin, you can more often find me under "C0rn3j". Professionally, I work as a DevOps, and in my free time I do things I've most recently stumbled upon, which usually has to do with FOSS. I've been using Arch for about a decade, I mostly hang out in the unofficial Telegram group*, which I help moderate. I sometimes contribute to the Wiki, send patches over GitLab when relevant, or otherwise participate in discussions if I happen to see anything I can add my two cents to. I've been maintaining a random assortment of things in the AUR, a lot of the times simply because I was using a package that the previous maintainer disowned, and I figured I might pick up the torch. Which brings me to why I want to become a PM - I would like to see some of the things I currently maintain in the official repositories, such as sc-controller** or Tauon**, and to help out with the maintenance in general. I use ALARM on some of my devices too, so I'd possibly like to help out with the porting efforts to Arch in the future, when that becomes relevant. I've attached links to my accounts and also my personal site below. My sponsors are Gian (grazzolini) and Tomaz Canabrava. Special thanks goes out to Muflone for additional packaging feedback. I think that covers everything necessary, have a good day and I hope you'll consider my application! * https://t.me/archlinuxgroup ** https://github.com/Taiko2k/Tauon ** https://github.com/C0rn3j/sc-controller https://aur.archlinux.org/account/c0rn3j https://gitlab.archlinux.org/c0rn3j https://github.com/C0rn3j https://gitlab.com/C0rn3j https://rys.rs/ - GPG key used for signing is also present here
Hey Martin, awesome to see your application here (finally! :P). Good luck and fingers crossed. -- --- Sincerely, fabiscafe ☕️ - Fabian Bornschein
Hi Martin, hi list, I looked through your website and found what I think is a common misconception: Tampermonkey is not open source anymore. It’s released under a proprietary license since 2013 (v2.9). The last commit with code changes is from 2013-01-08 [1]. Common open-source alternatives are Violentmonkey, Greasemonkey and FireMonkey. If anyone knows how to analyze ~3 MiB of minified JavaScript, let me know :) @Martin: Good luck with your application! Best, tippfehlr [1] https://github.com/Tampermonkey/tampermonkey/commits/master/
Hi Martin, Regarding your application, I had a couple of notes about some of your PKGBUILDs. sc-controller: conflicts=("${pkgname}-git" 'scc') There is no necessity to add -git conflicts of package, the -git package should have conflicts/provides with base package. Unless you can use both sc-controller with sc-contoller-git and/or scc package at the same time, can it? From sc-controller-git PKGBUILD it seems they cannot get installed at the same time. svp, svp-bin: Same about provides/conflicts. jitsi-meet-desktop-bin: It has coreutils as a makedepends which is unnecessary, it's a dep of util-linux which is a dep of fakeroot which is a dep of base-devel. It also uses rm filename in package, I think it brings problem for users which alias rm to rm -i which are many. It should be rm -f IMO. chitubox-free-bin: Same thing about rm Disclaimer: I'm not a PM, developer, nor ever been, just a curious arch linux user for a couple of years, so feel free to ignore this in case it was wrong. Best Regards, Amin Vakil
Thanks for the hints, regarding the rm -i, under which circumstances would makepkg propagate the alias? I tried setting it in the current shell, and the PKGBUILD worked fine for me with makepkg. I believe the provides=svp in svp-bin is there as an alias, I can't find the original reasoning as to why I added it, though I don't believe it's necessarily wrong even though a real "svp" package cannot exist, as it is a proprietary application.
Tampermonkey is not open source anymore. It’s released under a proprietary license since 2013
That's... unfortunate, looks like I'll have to switch. I have indeed mistaken it for a FOSS application, the repo is set up in a very poor way, making it look like the code is still open :/ On 26/07/2025 11:35, Amin Vakil wrote:
Hi Martin,
Regarding your application, I had a couple of notes about some of your PKGBUILDs.
sc-controller:
conflicts=("${pkgname}-git" 'scc') There is no necessity to add -git conflicts of package, the -git package should have conflicts/provides with base package.
Unless you can use both sc-controller with sc-contoller-git and/or scc package at the same time, can it? From sc-controller-git PKGBUILD it seems they cannot get installed at the same time.
svp, svp-bin: Same about provides/conflicts.
jitsi-meet-desktop-bin: It has coreutils as a makedepends which is unnecessary, it's a dep of util-linux which is a dep of fakeroot which is a dep of base-devel.
It also uses rm filename in package, I think it brings problem for users which alias rm to rm -i which are many. It should be rm -f IMO.
chitubox-free-bin: Same thing about rm
Disclaimer: I'm not a PM, developer, nor ever been, just a curious arch linux user for a couple of years, so feel free to ignore this in case it was wrong.
Best Regards, Amin Vakil
On 7/28/25 6:31 PM, Martin Rys wrote:
Thanks for the hints, regarding the rm -i, under which circumstances would makepkg propagate the alias?
I tried setting it in the current shell, and the PKGBUILD worked fine for me with makepkg.
Honestly I don't know under which circumstances this would be possible :) I've checked /etc/profile, /etc/environment, /etc/bash.bashrc and it seems makepkg does not read alias from there, but it's better to put rm -f in all scripts whenever they have to get run noninteractive to be on the safe side IMHO.>
I believe the provides=svp in svp-bin is there as an alias, I can't find the original reasoning as to why I added it, though I don't believe it's necessarily wrong even though a real "svp" package cannot exist, as it is a proprietary application.
svp package does not exist anymore in AUR, but the reason I'd suggest adding a conflicts to svp-bin was to prevent installing svp and svp-bin concurrently. https://wiki.archlinux.org/title/PKGBUILD#provides Packages providing the same item can be installed side-by-side, unless at least one of them uses a conflicts array.
Tampermonkey is not open source anymore. It’s released under a proprietary license since 2013
That's... unfortunate, looks like I'll have to switch.
I have indeed mistaken it for a FOSS application, the repo is set up in a very poor way, making it look like the code is still open :/
On 26/07/2025 11:35, Amin Vakil wrote:
Hi Martin,
Regarding your application, I had a couple of notes about some of your PKGBUILDs.
sc-controller:
conflicts=("${pkgname}-git" 'scc') There is no necessity to add -git conflicts of package, the -git package should have conflicts/provides with base package.
Unless you can use both sc-controller with sc-contoller-git and/or scc package at the same time, can it? From sc-controller-git PKGBUILD it seems they cannot get installed at the same time.
svp, svp-bin: Same about provides/conflicts.
jitsi-meet-desktop-bin: It has coreutils as a makedepends which is unnecessary, it's a dep of util-linux which is a dep of fakeroot which is a dep of base-devel.
It also uses rm filename in package, I think it brings problem for users which alias rm to rm -i which are many. It should be rm -f IMO.
chitubox-free-bin: Same thing about rm
Disclaimer: I'm not a PM, developer, nor ever been, just a curious arch linux user for a couple of years, so feel free to ignore this in case it was wrong.
Best Regards, Amin Vakil
On July 29, 2025 5:22:17 AM EDT, Amin Vakil <info@aminvakil.com> wrote:
On 7/28/25 6:31 PM, Martin Rys wrote:
Thanks for the hints, regarding the rm -i, under which circumstances would makepkg propagate the alias?
I tried setting it in the current shell, and the PKGBUILD worked fine for me with makepkg.
Honestly I don't know under which circumstances this would be possible :)
I've checked /etc/profile, /etc/environment, /etc/bash.bashrc and it seems makepkg does not read alias from there, but it's better to put rm -f in all scripts whenever they have to get run noninteractive to be on the safe side IMHO.>
Technically avoiding `-f` would be "safer". Guarding against every unproven possibility is uneconomical.
I believe the provides=svp in svp-bin is there as an alias, I can't find the original reasoning as to why I added it, though I don't believe it's necessarily wrong even though a real "svp" package cannot exist, as it is a proprietary application.
svp package does not exist anymore in AUR, but the reason I'd suggest adding a conflicts to svp-bin was to prevent installing svp and svp-bin concurrently.
https://wiki.archlinux.org/title/PKGBUILD#provides Packages providing the same item can be installed side-by-side, unless at least one of them uses a conflicts array.
Tampermonkey is not open source anymore. It’s released under a proprietary license since 2013
That's... unfortunate, looks like I'll have to switch.
I have indeed mistaken it for a FOSS application, the repo is set up in a very poor way, making it look like the code is still open :/
On 26/07/2025 11:35, Amin Vakil wrote:
Hi Martin,
Regarding your application, I had a couple of notes about some of your PKGBUILDs.
sc-controller:
conflicts=("${pkgname}-git" 'scc') There is no necessity to add -git conflicts of package, the -git package should have conflicts/provides with base package.
Unless you can use both sc-controller with sc-contoller-git and/or scc package at the same time, can it? From sc-controller-git PKGBUILD it seems they cannot get installed at the same time.
svp, svp-bin: Same about provides/conflicts.
jitsi-meet-desktop-bin: It has coreutils as a makedepends which is unnecessary, it's a dep of util-linux which is a dep of fakeroot which is a dep of base-devel.
It also uses rm filename in package, I think it brings problem for users which alias rm to rm -i which are many. It should be rm -f IMO.
chitubox-free-bin: Same thing about rm
Disclaimer: I'm not a PM, developer, nor ever been, just a curious arch linux user for a couple of years, so feel free to ignore this in case it was wrong.
Best Regards, Amin Vakil
-- Best, Daniel <https://danielcapella.com>
On 7/30/25 5:21 PM, Daniel M. Capella wrote:
On July 29, 2025 5:22:17 AM EDT, Amin Vakil <info@aminvakil.com> wrote:
On 7/28/25 6:31 PM, Martin Rys wrote:
Thanks for the hints, regarding the rm -i, under which circumstances would makepkg propagate the alias?
I tried setting it in the current shell, and the PKGBUILD worked fine for me with makepkg.
Honestly I don't know under which circumstances this would be possible :)
I've checked /etc/profile, /etc/environment, /etc/bash.bashrc and it seems makepkg does not read alias from there, but it's better to put rm -f in all scripts whenever they have to get run noninteractive to be on the safe side IMHO.>
Technically avoiding `-f` would be "safer". Guarding against every unproven possibility is uneconomical.
Thanks! Good point! I'll keep that in mind!
I believe the provides=svp in svp-bin is there as an alias, I can't find the original reasoning as to why I added it, though I don't believe it's necessarily wrong even though a real "svp" package cannot exist, as it is a proprietary application.
svp package does not exist anymore in AUR, but the reason I'd suggest adding a conflicts to svp-bin was to prevent installing svp and svp-bin concurrently.
https://wiki.archlinux.org/title/PKGBUILD#provides Packages providing the same item can be installed side-by-side, unless at least one of them uses a conflicts array.
Tampermonkey is not open source anymore. It’s released under a proprietary license since 2013
That's... unfortunate, looks like I'll have to switch.
I have indeed mistaken it for a FOSS application, the repo is set up in a very poor way, making it look like the code is still open :/
On 26/07/2025 11:35, Amin Vakil wrote:
Hi Martin,
Regarding your application, I had a couple of notes about some of your PKGBUILDs.
sc-controller:
conflicts=("${pkgname}-git" 'scc') There is no necessity to add -git conflicts of package, the -git package should have conflicts/provides with base package.
Unless you can use both sc-controller with sc-contoller-git and/or scc package at the same time, can it? From sc-controller-git PKGBUILD it seems they cannot get installed at the same time.
svp, svp-bin: Same about provides/conflicts.
jitsi-meet-desktop-bin: It has coreutils as a makedepends which is unnecessary, it's a dep of util-linux which is a dep of fakeroot which is a dep of base-devel.
It also uses rm filename in package, I think it brings problem for users which alias rm to rm -i which are many. It should be rm -f IMO.
chitubox-free-bin: Same thing about rm
Disclaimer: I'm not a PM, developer, nor ever been, just a curious arch linux user for a couple of years, so feel free to ignore this in case it was wrong.
Best Regards, Amin Vakil
-- Best, Daniel <https://danielcapella.com>
To clarify: provides=svp is correct; you just want to also do conflicts=svp to conflict against any package that also provides svp. Note that you need to explicitly declare this because by default PKGBUILDs only provide and conflict against their pkgname. -- Cheers, Aᴀʀᴏɴ
On 7/31/25 4:48 PM, Aaron Liu wrote:
To clarify: provides=svp is correct; you just want to also do conflicts=svp to conflict against any package that also provides svp. Note that you need to explicitly declare this because by default PKGBUILDs only provide and conflict against their pkgname.
Thanks for clarification. Yes, that's what I meant as well. I was referring to missing "conflicts" in svp-bin package.
Hi everyone
my name's Martin, you can more often find me under "C0rn3j". Professionally, I work as a DevOps, and in my free time I do things I've most recently stumbled upon, which usually has to do with FOSS.
I've been using Arch for about a decade, I mostly hang out in the unofficial Telegram group*, which I help moderate.
I know Martin since a lot of years and I can confirm he's very active on Telegram, helping users daily with their questions. Since all the years, he always was a professional, respectful and polite person. On this side Martin could be a very valid addition to the team.
I've been maintaining a random assortment of things in the AUR, a lot of the times simply because I was using a package that the previous maintainer disowned, and I figured I might pick up the torch.
Which brings me to why I want to become a PM - I would like to see some of the things I currently maintain in the official repositories, such as sc-controller** or Tauon**, and to help out with the maintenance in general.
When Martin proposed himself to apply as PM I expressed him my concerns about his packages quality and lack of knowledge about the packaging guidelines. He went through his packages and some days later asked me to do further checks about his AUR packages. In such occasion I expressed him I was not yet convinced about the packaging skill and asked him to posticipate his application until he has enhanced his packaging skills and so refused to sponsor him during this application. Therefore, as long the sponsors will take care about this application, helping Martin to fix the weak points, he could be a great help on our team. However we first need to make sure the sponsor will take care about this. Best wishes and good luck, Martin -- Muflone
On Sun, Jul 27, 2025 at 12:36:45PM +0200, Muflone wrote:
my name's Martin, you can more often find me under "C0rn3j". Professionally, I work as a DevOps, and in my free time I do things I've most recently stumbled upon, which usually has to do with FOSS.
I've been using Arch for about a decade, I mostly hang out in the unofficial Telegram group*, which I help moderate.
I know Martin since a lot of years and I can confirm he's very active on Telegram, helping users daily with their questions. Since all the years, he always was a professional, respectful and polite person.
On this side Martin could be a very valid addition to the team.
Martin, thank you for the application and taking care of the Telegram users all these years! I agree that another maintainer with years long relations to Arch would be a great addition.
I've been maintaining a random assortment of things in the AUR, a lot of the times simply because I was using a package that the previous maintainer disowned, and I figured I might pick up the torch.
Which brings me to why I want to become a PM - I would like to see some of the things I currently maintain in the official repositories, such as sc-controller** or Tauon**, and to help out with the maintenance in general.
When Martin proposed himself to apply as PM I expressed him my concerns about his packages quality and lack of knowledge about the packaging guidelines.
He went through his packages and some days later asked me to do further checks about his AUR packages. In such occasion I expressed him I was not yet convinced about the packaging skill and asked him to posticipate his application until he has enhanced his packaging skills and so refused to sponsor him during this application.
It's a shame that your judgement has been ignored in this case ...
Therefore, as long the sponsors will take care about this application, helping Martin to fix the weak points, he could be a great help on our team. However we first need to make sure the sponsor will take care about this.
... and given that the sponsors haven't confirmed their sponsorship yet, 3 days after the initial message, I wonder what the motivation was to sponsor Martin without any further improvements. Giancarlo, Thomas could you elaborate on this please? Best regards, Frederik
On Sun, Jul 27, 2025 at 5:15 PM Frederik Schwan <freswa@archlinux.org> wrote:
On Sun, Jul 27, 2025 at 12:36:45PM +0200, Muflone wrote:
my name's Martin, you can more often find me under "C0rn3j". Professionally, I work as a DevOps, and in my free time I do things I've most recently stumbled upon, which usually has to do with FOSS.
I've been using Arch for about a decade, I mostly hang out in the unofficial Telegram group*, which I help moderate.
I know Martin since a lot of years and I can confirm he's very active on Telegram, helping users daily with their questions. Since all the years, he always was a professional, respectful and polite person.
On this side Martin could be a very valid addition to the team.
Martin, thank you for the application and taking care of the Telegram users all these years! I agree that another maintainer with years long relations to Arch would be a great addition.
I've been maintaining a random assortment of things in the AUR, a lot of the times simply because I was using a package that the previous maintainer disowned, and I figured I might pick up the torch.
Which brings me to why I want to become a PM - I would like to see some of the things I currently maintain in the official repositories, such as sc-controller** or Tauon**, and to help out with the maintenance in general.
When Martin proposed himself to apply as PM I expressed him my concerns about his packages quality and lack of knowledge about the packaging guidelines.
He went through his packages and some days later asked me to do further checks about his AUR packages. In such occasion I expressed him I was not yet convinced about the packaging skill and asked him to posticipate his application until he has enhanced his packaging skills and so refused to sponsor him during this application.
It's a shame that your judgement has been ignored in this case ...
Therefore, as long the sponsors will take care about this application, helping Martin to fix the weak points, he could be a great help on our team. However we first need to make sure the sponsor will take care about this.
... and given that the sponsors haven't confirmed their sponsorship yet, 3 days after the initial message, I wonder what the motivation was to sponsor Martin without any further improvements. Giancarlo, Thomas could you elaborate on this please?
Hello I was travelling with my wife and without the possibility to take the time and answer this - a matrimonial warning not worth ignoring. The "without any further improvements" is not real as Martin went through the list of issues stated by Muflone and fixed them. I have talked with Muflone to understand his point of view, and I have shared my point of view with him too. But, sincerely I believe that it's more important that someone is willing to do the work for love, even if the work is not 100% yet. The 100% part can be achieved in time, that's why we have the trial period as Junior. When I joined I didn't had a lot of experience with Packaging - I had as a C++ developer and co-maintainer of a few KDE apps such as Konsole, but packaging for a specific distro? no. Now I release KF6 and Plasma (which together are around 160-ish) packages, when Antonio Rojas asks me I also release KDE Gear (which is around 320). Of course I had some issues in the beginning but those were quickly pointed out by Antonio or Gian, and fixed. So all in all I believe that Martin will be a great developer, even if his packages needs a bit of fine tuning. Best, Tomaz
Best regards, Frederik
Hey Martin Jul 24, 2025 17:27:40 Martin Rys <spleefer90@gmail.com>:
I've been using Arch for about a decade, I mostly hang out in the unofficial Telegram group*, which I help moderate.
It's always nice to hang around in social groups. We also have internal coms, either accessible via irc or via Matrix where all our staff and all our package maintainers have access to. I believe that we're all working best together when we interact socially, not just for faster pings, but to share expertise with each other on a regular basis, and for the spirit of hanging out and being one large team. In my opinion, this is the very foundation of a truly healthy organisation. So my question: What are your thoughts, do you intend to take part equally frequently in our matrix channels, like you do in the unofficial telegram groups? Cheers, Levente
do you intend to take part equally frequently in our matrix channels, like you do in the unofficial telegram groups?
I can definitely try to be available on my desktop, but on my phone Element repeatedly eventually runs into an issue where it just hogs 100% of CPU and never loads - I've never bothered to report that bug as it just turned me off the platform, maybe the issue is not there today anymore. However, was a Telegram<>Matrix/IRC bridge ever considered? I suppose I am asking about two separate scenarios - staff-internal groups, and about the general public Arch group. It would be much easier for me to be active somewhere without having to switch between apps. Martin On Sun, Aug 10, 2025 at 10:10 AM Levente Polyak <anthraxx@archlinux.org> wrote:
Hey Martin
Jul 24, 2025 17:27:40 Martin Rys <spleefer90@gmail.com>:
I've been using Arch for about a decade, I mostly hang out in the unofficial Telegram group*, which I help moderate.
It's always nice to hang around in social groups. We also have internal coms, either accessible via irc or via Matrix where all our staff and all our package maintainers have access to. I believe that we're all working best together when we interact socially, not just for faster pings, but to share expertise with each other on a regular basis, and for the spirit of hanging out and being one large team.
In my opinion, this is the very foundation of a truly healthy organisation. So my question: What are your thoughts, do you intend to take part equally frequently in our matrix channels, like you do in the unofficial telegram groups?
Cheers, Levente
On Sun, 10 Aug 2025 at 05:39 Martin Rys <spleefer90@gmail.com> wrote:
do you intend to take part equally frequently in our matrix channels, like you do in the unofficial telegram groups?
I can definitely try to be available on my desktop, but on my phone Element repeatedly eventually runs into an issue where it just hogs 100% of CPU and never loads - I've never bothered to report that bug as it just turned me off the platform, maybe the issue is not there today anymore.
i use fluffy chat on my phone. way better than elements.
However, was a Telegram<>Matrix/IRC bridge ever considered?
it does exists
I suppose I am asking about two separate scenarios - staff-internal groups, and about the general public Arch group. It would be much easier for me to be active somewhere without having to switch between apps.
you can use bitlbee to use a single app that talks to irc for every single protocol.
Martin
On Sun, Aug 10, 2025 at 10:10 AM Levente Polyak <anthraxx@archlinux.org> wrote:
Hey Martin
Jul 24, 2025 17:27:40 Martin Rys <spleefer90@gmail.com>:
I've been using Arch for about a decade, I mostly hang out in the
unofficial Telegram group*, which I help moderate.
It's always nice to hang around in social groups. We also have internal
coms, either accessible via irc or via Matrix where all our staff and all our package maintainers have access to. I believe that we're all working best together when we interact socially, not just for faster pings, but to share expertise with each other on a regular basis, and for the spirit of hanging out and being one large team.
In my opinion, this is the very foundation of a truly healthy
organisation. So my question: What are your thoughts, do you intend to take part equally frequently in our matrix channels, like you do in the unofficial telegram groups?
Cheers, Levente
Aug 10, 2025 10:38:43 Martin Rys <spleefer90@gmail.com>:
do you intend to take part equally frequently in our matrix channels, like you do in the unofficial telegram groups?
I can definitely try to be available on my desktop, but on my phone Element repeatedly eventually runs into an issue where it just hogs 100% of CPU and never loads - I've never bothered to report that bug as it just turned me off the platform, maybe the issue is not there today anymore.
However, was a Telegram<>Matrix/IRC bridge ever considered? I suppose I am asking about two separate scenarios - staff-internal groups, and about the general public Arch group. It would be much easier for me to be active somewhere without having to switch between apps.
That’s a bit less direct than I was hoping for 😅 I get what you're saying though. I was in a similar place myself. Up until today, I only use Matrix for Arch Linux stuff and had my own mix of other platforms for everything else. I switched from irc as I found it very annoying on mobile. But honestly, being active there really changes the dynamic. It's not just another chat app, its more about feeling part of the "we" thingies, and having that constant sense of connection with the team (in both directions). That’s exactly why I made the switch myself and let go of my old IRC desktop habits. Sure, we could explore other technical options down the road, but right now, Matrix/IRC is what we have. Thank you also very much Tomaz for providing additional help which tools or apps can be used for this today, and thank you Martin for being honest. So, straight up, if it remains like this, do you think you'd be willing to take on "another app" to be more connected with the team, or would you likely avoid it because of the inconvenience? Cheers Levente
Hi Martin, On 24/07/2025 18:26, Martin Rys wrote:
I've been maintaining a random assortment of things in the AUR, a lot of the times simply because I was using a package that the previous maintainer disowned, and I figured I might pick up the torch.
Which brings me to why I want to become a PM - I would like to see some of the things I currently maintain in the official repositories, such as sc-controller** or Tauon**, and to help out with the maintenance in general.
while reviewing your application for Package Maintainer, I noticed that several of your AUR PKGBUILDs contain a personal donation message in the header, for example: sc-controller # Maintainer: Martin Rys <https://rys.rs/contact> | Toss a coin on https://rys.rs/donate sc-controller-git # Co-Maintainer: Martin Rys <https://rys.rs/contact> | Toss a coin on https://rys.rs/donate jdownloader2 # Maintainer: Martin Rys <https://rys.rs/contact> | Toss a coin on https://rys.rs/donate While I appreciate the voluntary nature of AUR contributions, this solicitation blurs the line between open community contribution and self-promotion. Arch’s volunteer-driven ethos emphasises goodwill and collaboration, in my opinion - not personal fundraising syndication within build scripts. Could you share your thoughts on this practice and whether you would be willing to remove these lines not just from official PKGBUILDs but from AUR PKGBUILDs also if you were to become a Package Maintainer? Regards, -- Leonidas Spyropoulos PGP: 244740D17C7FD0EC
On Sun, 10 Aug 2025 at 07:02 Leonidas Spyropoulos <artafinde@archlinux.org> wrote:
Hi Martin,
On 24/07/2025 18:26, Martin Rys wrote:
I've been maintaining a random assortment of things in the AUR, a lot of the times simply because I was using a package that the previous maintainer disowned, and I figured I might pick up the torch.
Which brings me to why I want to become a PM - I would like to see some of the things I currently maintain in the official repositories, such as sc-controller** or Tauon**, and to help out with the maintenance in general.
while reviewing your application for Package Maintainer, I noticed that several of your AUR PKGBUILDs contain a personal donation message in the header, for example:
sc-controller # Maintainer: Martin Rys <https://rys.rs/contact> | Toss a coin on https://rys.rs/donate
sc-controller-git # Co-Maintainer: Martin Rys <https://rys.rs/contact> | Toss a coin on https://rys.rs/donate
jdownloader2 # Maintainer: Martin Rys <https://rys.rs/contact> | Toss a coin on https://rys.rs/donate
While I appreciate the voluntary nature of AUR contributions, this solicitation blurs the line between open community contribution and self-promotion. Arch’s volunteer-driven ethos emphasises goodwill and collaboration, in my opinion - not personal fundraising syndication within build scripts.
Could you share your thoughts on this practice and whether you would be willing to remove these lines not just from official PKGBUILDs but from AUR PKGBUILDs also if you were to become a Package Maintainer?
just answering here instead of martin because this has been discussed in the past and he agreed to drop all of the toss a coin messages.
Regards,
-- Leonidas Spyropoulos PGP: 244740D17C7FD0EC
On 8/10/25 16:37, Tomaz Canabrava wrote:
On Sun, 10 Aug 2025 at 07:02 Leonidas Spyropoulos <artafinde@archlinux.org <mailto:artafinde@archlinux.org>> wrote:
Hi Martin,
On 24/07/2025 18:26, Martin Rys wrote: > I've been maintaining a random assortment of things in the AUR, a lot of > the times simply because I was using a package that the previous > maintainer disowned, and I figured I might pick up the torch. > > Which brings me to why I want to become a PM - I would like to see some > of the things I currently maintain in the official repositories, such as > sc-controller** or Tauon**, and to help out with the maintenance in > general.
while reviewing your application for Package Maintainer, I noticed that several of your AUR PKGBUILDs contain a personal donation message in the header, for example:
sc-controller # Maintainer: Martin Rys <https://rys.rs/contact <https:// rys.rs/contact>> | Toss a coin on https://rys.rs/donate <https://rys.rs/donate>
sc-controller-git # Co-Maintainer: Martin Rys <https://rys.rs/contact <https:// rys.rs/contact>> | Toss a coin on https://rys.rs/donate <https://rys.rs/donate>
jdownloader2 # Maintainer: Martin Rys <https://rys.rs/contact <https:// rys.rs/contact>> | Toss a coin on https://rys.rs/donate <https://rys.rs/donate>
While I appreciate the voluntary nature of AUR contributions, this solicitation blurs the line between open community contribution and self-promotion. Arch’s volunteer-driven ethos emphasises goodwill and collaboration, in my opinion - not personal fundraising syndication within build scripts.
Could you share your thoughts on this practice and whether you would be willing to remove these lines not just from official PKGBUILDs but from AUR PKGBUILDs also if you were to become a Package Maintainer?
just answering here instead of martin because this has been discussed in the past and he agreed to drop all of the toss a coin messages.
It would be nice to get Martin's opinion on this matter instead of through proxy.
I have provided an answer to this here, shortly after Tomaz's message - https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/me... Would you like me to elaborate on something specific, or does that suffice? Martin On Fri, Aug 15, 2025 at 11:38 AM Jelle van der Waa <jelle@vdwaa.nl> wrote:
On 8/10/25 16:37, Tomaz Canabrava wrote:
On Sun, 10 Aug 2025 at 07:02 Leonidas Spyropoulos <artafinde@archlinux.org <mailto:artafinde@archlinux.org>> wrote:
Hi Martin,
On 24/07/2025 18:26, Martin Rys wrote: > I've been maintaining a random assortment of things in the AUR, a lot of > the times simply because I was using a package that the previous > maintainer disowned, and I figured I might pick up the torch. > > Which brings me to why I want to become a PM - I would like to see some > of the things I currently maintain in the official repositories, such as > sc-controller** or Tauon**, and to help out with the maintenance in > general.
while reviewing your application for Package Maintainer, I noticed that several of your AUR PKGBUILDs contain a personal donation message in the header, for example:
sc-controller # Maintainer: Martin Rys <https://rys.rs/contact <https:// rys.rs/contact>> | Toss a coin on https://rys.rs/donate <https://rys.rs/donate>
sc-controller-git # Co-Maintainer: Martin Rys <https://rys.rs/contact <https:// rys.rs/contact>> | Toss a coin on https://rys.rs/donate <https://rys.rs/donate>
jdownloader2 # Maintainer: Martin Rys <https://rys.rs/contact <https:// rys.rs/contact>> | Toss a coin on https://rys.rs/donate <https://rys.rs/donate>
While I appreciate the voluntary nature of AUR contributions, this solicitation blurs the line between open community contribution and self-promotion. Arch’s volunteer-driven ethos emphasises goodwill and collaboration, in my opinion - not personal fundraising syndication within build scripts.
Could you share your thoughts on this practice and whether you would be willing to remove these lines not just from official PKGBUILDs but from AUR PKGBUILDs also if you were to become a Package Maintainer?
just answering here instead of martin because this has been discussed in the past and he agreed to drop all of the toss a coin messages.
It would be nice to get Martin's opinion on this matter instead of through proxy.
So, straight up, if it remains like this, do you think you'd be willing to take on "another app" to be more connected with the team, or would you likely avoid it because of the inconvenience?
Element works fine for me on the desktop where I spend most of my time, and it's convenient enough for me to use it, so absolutely, I can adapt.
Could you share your thoughts on this practice and whether you would be willing to remove these lines not just from official PKGBUILDs but from AUR PKGBUILDs also if you were to become a Package Maintainer?
I understand this is a problematic topic, and I did not intend to keep any messaging in anything that made it to the official repositories. If I do get accepted, I am removing the messages from my AUR packages. Martin On Sun, Aug 10, 2025 at 12:01 PM Leonidas Spyropoulos <artafinde@archlinux.org> wrote:
Hi Martin,
On 24/07/2025 18:26, Martin Rys wrote:
I've been maintaining a random assortment of things in the AUR, a lot of the times simply because I was using a package that the previous maintainer disowned, and I figured I might pick up the torch.
Which brings me to why I want to become a PM - I would like to see some of the things I currently maintain in the official repositories, such as sc-controller** or Tauon**, and to help out with the maintenance in general.
while reviewing your application for Package Maintainer, I noticed that several of your AUR PKGBUILDs contain a personal donation message in the header, for example:
sc-controller # Maintainer: Martin Rys <https://rys.rs/contact> | Toss a coin on https://rys.rs/donate
sc-controller-git # Co-Maintainer: Martin Rys <https://rys.rs/contact> | Toss a coin on https://rys.rs/donate
jdownloader2 # Maintainer: Martin Rys <https://rys.rs/contact> | Toss a coin on https://rys.rs/donate
While I appreciate the voluntary nature of AUR contributions, this solicitation blurs the line between open community contribution and self-promotion. Arch’s volunteer-driven ethos emphasises goodwill and collaboration, in my opinion - not personal fundraising syndication within build scripts.
Could you share your thoughts on this practice and whether you would be willing to remove these lines not just from official PKGBUILDs but from AUR PKGBUILDs also if you were to become a Package Maintainer?
Regards,
-- Leonidas Spyropoulos PGP: 244740D17C7FD0EC
participants (12)
-
Aaron Liu
-
Amin Vakil
-
Daniel M. Capella
-
Fabian Bornschein
-
Frederik Schwan
-
Jelle van der Waa
-
Leonidas Spyropoulos
-
Levente Polyak
-
Martin Rys
-
Muflone
-
tippfehlr
-
Tomaz Canabrava