[aur-general] TU application - artafinde
Hello, I'm Leonidas Spyropoulos and I'd like to apply to become a Trusted User. I'm particularly instersted in packaging dependencies which are required for the ongoing python porting of Aurweb and anything related performance. I'm sponsored from Jelle van der Waa <jelle> and Sven-Hendrik Haase<sventaro>. I'm a 39 years old Software Developer living in London originally from Greece. I've been an Linux user for almost 20 years and an Arch Linux for more than 15. Previous distributions include Suse and Debian but I find Arch Linux suits me more. I've been a big supported of FOSS philosophy and projects and try to contribute where possible (check my github). I'm a developer in my day-to-day job working mostly with JVM languages and DevOps. For the minimum requirements: - I know my way around shell scripting, mostly bash but I've done some ksh due to my work maintaining old server. These days almost all scripting is in bash and POSIX compliant. My daily shell is ZSH. - I've been maintaining some packages in AUR [1] and some have moved to community (i.e. neomutt, dvdstyler). I believe some of the current ones are good enough PKGBUILDs to be moved to community repository. - I've suscribed to most mailing lists and replied a few times, but I'm easier to be contacted in IRC. My forum activity is low since I find IRC more responsive. - I can Google around - For packages I want to maintain see list below My contributions so far in Arch Linux are mostly: - AUR packaging [1] - AUR development (aurweb) with code reviews, testing and development in python porting (and some php) [2] - DevOps keycloak theme packaging [3] - DevOps patches for various issues [4] - Actively involved in DevOps IRC for pitching in solutions to current issues/discussions AUR packages (I maintain) interested in moving to Community - Any package which will be a requirement for python ported Aurweb version - aarchup - python-prometheus-fastapi-instrumentator - freeplane - intellij-idea-{ce,ue}-eap (Provided their license is allowing that) - gdu AUR packages interested in moving to Community - abook - bfg - clean-chroot-manager - goland - jdtls - jetbrains-toolbox - tectonic I'd also be interesting in maintaining some Community packages which are orphan or co-maintain some: orphans: - elasticsearch packages I use and interested in {co-}maintaining: - ansible - aurpublish - aws-cli - ccache - cpupower - docker - docker-compose - go - gradle - kotlin - kubectl - lrzip - neomutt (used to be co-maintainer in aur) - notmuch - profile-sync-daemon - alot - android-file-transder - android-tools - android-udev - beets - bpytop - dvdbackup (used to maintain in aur) - cuda - fstrim - gcc10 (required for cuda) - handbrake - kitty - ncmpcpp - ninja - nextcloud-client - nlohmann-json - packer - pacman-contrib - pandoc - profile-cleaner - python-* (packages required for Aurweb see list from INSTALL) - screenfetch - spellcheck - signal-desktop - wxsvg (required from dvdbackup) - zsh-completions Github: https://github.com/inglor AUR: https://aur.archlinux.org/account/artafinde Forums: https://bbs.archlinux.org/profile.php?id=17838 Bugs: https://bugs.archlinux.org/user/10369 IRC: artafinde | inglor [1]: https://aur.archlinux.org/packages/?O=0&SeB=M&K=artafinde&outdated=&SB=n&SO=a&PP=50&do_Search=Go [2]: https://gitlab.archlinux.org/archlinux/aurweb/-/merge_requests?scope=all&state=all&author_username=artafinde [3]: https://gitlab.archlinux.org/artafinde/keycloak-archlinux-theme/-/tree/multi... [4]: https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests?scope=all&state=all&author_username=artafinde I'm looking forward to contributing more to Arch Linux. It's a great community and I've thoroughly enjoyed my time so far. Kind Regards, Leonidas -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On 31.10.21 19:24, Leonidas Spyropoulos via aur-general wrote:
Hello,
I'm Leonidas Spyropoulos and I'd like to apply to become a Trusted User. I'm particularly instersted in packaging dependencies which are required for the ongoing python porting of Aurweb and anything related performance. I'm sponsored from Jelle van der Waa <jelle> and Sven-Hendrik Haase<sventaro>. 'Tis true!
On 31/10/2021 19:24, Leonidas Spyropoulos via aur-general wrote:
Hello,
I'm Leonidas Spyropoulos and I'd like to apply to become a Trusted User. I'm particularly instersted in packaging dependencies which are required for the ongoing python porting of Aurweb and anything related performance. I'm sponsored from Jelle van der Waa <jelle> and Sven-Hendrik Haase<sventaro>.
I confirm my sponsorship. Greetings, Jelle van der Waa
On Sun, Oct 31, 2021 at 06:24:51PM +0000, Leonidas Spyropoulos via aur-general wrote:
Hello,
Yo! Good luck with your application :) Some preliminary thoughts.
I'd also be interesting in maintaining some Community packages which are orphan or co-maintain some: orphans: - elasticsearch
This isn't as much of an orphan as there is a question what to do with the elasticsearch ecosystem in Arch. With the relicensing and subsequent release of opensearch what are you plans for this package? This also applies to the beat packages and auxiliary packages to the ELK stack.
packages I use and interested in {co-}maintaining: - ansible - aurpublish - aws-cli - ccache - cpupower - docker - docker-compose - go
I'd rather not have a co-maintainer for go unless they want to take some responsibility for the ecosystem and packaging standards as well. It's quite a bit of work and just updating Go is the simple part of it. So what are you thoughts here?
- gradle - kotlin - kubectl - lrzip - neomutt (used to be co-maintainer in aur) - notmuch - profile-sync-daemon - alot - android-file-transder - android-tools - android-udev - beets - bpytop - dvdbackup (used to maintain in aur) - cuda - fstrim - gcc10 (required for cuda) - handbrake - kitty - ncmpcpp - ninja - nextcloud-client - nlohmann-json - packer - pacman-contrib - pandoc - profile-cleaner - python-* (packages required for Aurweb see list from INSTALL) - screenfetch - spellcheck - signal-desktop - wxsvg (required from dvdbackup) - zsh-completions
There are a few packages in this list that has anywhere between 2 and 3 maintainers already. One maintainer is bad, two is good, but having 3+ maintainers is just painful to communicate if they are not all on the same page. This applies mostly to docker and docker-compose on my end, but I suspect there are more? When we started doing this list it was mostly to highlight packages that need more maintainers where we just had one, but I don't think it's super useful listing up every one package you want to maintain which doesn't strictly need more maintainers? To me this seems like listing up packages for the sake of listing up packages. -- Morten Linderud PGP: 9C02FF419FECBE16
Hello, On 01/11/21, Morten Linderud wrote:
On Sun, Oct 31, 2021 at 06:24:51PM +0000, Leonidas Spyropoulos via aur-general wrote: Good luck with your application :) Some preliminary thoughts.
Thank you
This isn't as much of an orphan as there is a question what to do with the elasticsearch ecosystem in Arch. With the relicensing and subsequent release of opensearch what are you plans for this package? This also applies to the beat packages and auxiliary packages to the ELK stack.
I think the best thing to do for Arch Linux is to wait to see how this will evolve. If opensearch gets traction and support from the community it might be the answer and eventually elasticsearch will not be important to keep in repos. I must say though I had to educate myself to the latest in elasticsearch licensing.
I'd rather not have a co-maintainer for go unless they want to take some responsibility for the ecosystem and packaging standards as well. It's quite a bit of work and just updating Go is the simple part of it. So what are you thoughts here?
There are a few packages in this list that has anywhere between 2 and 3 maintainers already. One maintainer is bad, two is good, but having 3+ maintainers is just painful to communicate if they are not all on the same page. This applies mostly to docker and docker-compose on my end, but I suspect there are more?
When we started doing this list it was mostly to highlight packages that need more maintainers where we just had one, but I don't think it's super useful listing up every one package you want to maintain which doesn't strictly need more maintainers? To me this seems like listing up packages for the sake of listing up packages.
Coming up as a newbie in the TU I would have contacted the current maintainer(s) to ask if they need assistance on packaging and if it's a good idea to become a co-maintainer. As you mention here this would probably be an issue for docker and docker-compose packages. As for packages which are part of a bigger ecosystem then I would be willing to get involved into that if it's required. -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On Mon, Nov 01, 2021 at 11:29:51AM +0000, Leonidas Spyropoulos via aur-general wrote:
Hello,
On 01/11/21, Morten Linderud wrote:
On Sun, Oct 31, 2021 at 06:24:51PM +0000, Leonidas Spyropoulos via aur-general wrote: Good luck with your application :) Some preliminary thoughts.
Thank you
This isn't as much of an orphan as there is a question what to do with the elasticsearch ecosystem in Arch. With the relicensing and subsequent release of opensearch what are you plans for this package? This also applies to the beat packages and auxiliary packages to the ELK stack.
I think the best thing to do for Arch Linux is to wait to see how this will evolve. If opensearch gets traction and support from the community it might be the answer and eventually elasticsearch will not be important to keep in repos. I must say though I had to educate myself to the latest in elasticsearch licensing.
Please do read the previou discussion regarding SSPL and mongodb. I don't know if there are recent development but it's still not an OSI license. https://lists.archlinux.org/pipermail/arch-dev-public/2019-January/029430.ht... I do think there is a possible debate still about how we should approach these licenses, but in general people favour dropping them instead of pretending to be a lawyer. This is also why elasticsearch has been updated until the version before the license change and then orphaned. -- Morten Linderud PGP: 9C02FF419FECBE16
On Mon, 1 Nov 2021 11:29:51 +0000 Leonidas Spyropoulos via aur-general <aur-general@lists.archlinux.org> wrote:
If opensearch gets traction and support from the community it might be the answer and eventually elasticsearch will not be important to keep in repos.
Since I'm more or less the current elasticsearch maintainer: As I've written in a past mail [0] I would hold the ELK stack <7.11.0 until we have opensearch in the repos. I wouldn't drop elasticsearch entirely though. The mentioned issues seem to have been resolved, I should take another look at this. [0] https://lists.archlinux.org/pipermail/arch-dev-public/2021-August/030496.htm... -- hashworks Web https://hashworks.net Public Key 0x4FE7F4FEAC8EBE67
On Sun, Oct 31, 2021 at 06:24:51PM +0000, Leonidas Spyropoulos via aur-general wrote:
Hello,
I'm Leonidas Spyropoulos and I'd like to apply to become a Trusted User. I'm particularly instersted in packaging dependencies which are required for the ongoing python porting of Aurweb and anything related performance. I'm sponsored from Jelle van der Waa <jelle> and Sven-Hendrik Haase<sventaro>.
hello Leonidas. first of all, I wish you luck with your application. I have reviewed your pkgbuilds and would like to share some notes: # aarchup provides=("${pkgname}") this is the default behavior, so this line is unnecessary. install -Dm644 LICENSE.md "$pkgdir/usr/share/licenses/$pkgname/LICENSE" GPL3 is in licenses package so no need to install it. # auracle-git _pkgname=auracle you can use "${pkgname%-git}" instead. # caatinga-git cd "${srcdir}/${pkgname%-git}" all makepkg's functions start in ${srcdir}. python2 setup.py install --root="${pkgdir}/" --optimize=1 no python2-setuptools in makedepends. I take this opportunity to recommend building aur packages in a clean chroot. it helps to identify just such errors. # corefreq-git no git in makedepends. # freeplane mkdir -p I recommend to use install for that. Moreover. below install will create these folders on its own thanks to the D flag. # gnome-shell-extension-cpufreq _pkgname=cpufreq you can use ${pkgname#gnome-shell-extension-} instead. mkdir -p "${pkgdir}/usr/share/gnome-shell/extensions/" I recommend to use install for that. # ntellij-idea-ce-eap, intellij-idea-ue-eap mkdir -p I recommend to use install for that. cat <<EOF a nicer looking solution is to put this file in git and modify it with sed in prepare function. mkdir -p "${pkgdir}/usr/bin/" mkdir -p "${pkgdir}/usr/share/applications/" mkdir -p "${pkgdir}/usr/share/licenses/${pkgname}/" all of this is unnecessary since install will create these folders. ln -sf "${srcdir}/${_pkgname}-${_buildver}/license/$i" "${pkgdir}/usr/share/licenses/${pkgname}/$i" I do not quite understand why this is needed, but it does not look correct. and it seems to me that namcap will agree with me. # python-sklearn-pandas mkdir -p "${pkgdir}/usr/share/licenses/${pkgname}/" install will do this for you. -- Sincerely, Alexander | Trusted User
On 01/11/21, Alexander Epaneshnikov wrote:
hello Leonidas. first of all, I wish you luck with your application.
I have reviewed your pkgbuilds and would like to share some notes:
Thanks for taking the time to check these
# aarchup provides=("${pkgname}") this is the default behavior, so this line is unnecessary. install -Dm644 LICENSE.md "$pkgdir/usr/share/licenses/$pkgname/LICENSE" GPL3 is in licenses package so no need to install it.
Resolved.
# auracle-git _pkgname=auracle you can use "${pkgname%-git}" instead.
Resolved.
# caatinga-git cd "${srcdir}/${pkgname%-git}" all makepkg's functions start in ${srcdir}. python2 setup.py install --root="${pkgdir}/" --optimize=1 no python2-setuptools in makedepends. I take this opportunity to recommend building aur packages in a clean chroot. it helps to identify just such errors.
Resolved.
# corefreq-git no git in makedepends.
Resolved.
# freeplane mkdir -p I recommend to use install for that. Moreover. below install will create these folders on its own thanks to the D flag.
Resolved.
# gnome-shell-extension-cpufreq _pkgname=cpufreq you can use ${pkgname#gnome-shell-extension-} instead. mkdir -p "${pkgdir}/usr/share/gnome-shell/extensions/" I recommend to use install for that.
Resolved.
# ntellij-idea-ce-eap, intellij-idea-ue-eap mkdir -p I recommend to use install for that. cat <<EOF a nicer looking solution is to put this file in git and modify it with sed in prepare function. mkdir -p "${pkgdir}/usr/bin/" mkdir -p "${pkgdir}/usr/share/applications/" mkdir -p "${pkgdir}/usr/share/licenses/${pkgname}/" all of this is unnecessary since install will create these folders. ln -sf "${srcdir}/${_pkgname}-${_buildver}/license/$i" "${pkgdir}/usr/share/licenses/${pkgname}/$i" I do not quite understand why this is needed, but it does not look correct. and it seems to me that namcap will agree with me.
This seems wrong indeed - I will take a closer look.
# python-sklearn-pandas mkdir -p "${pkgdir}/usr/share/licenses/${pkgname}/" install will do this for you.
Resolved.
-- Sincerely, Alexander | Trusted User
-- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Hey Leonidas, I wish you good like as well. May the force be with you :D For now I just have a tiny bit after reading through your mail: On 10/31/21 19:24, Leonidas Spyropoulos via aur-general wrote:
AUR packages (I maintain) interested in moving to Community ... - intellij-idea-{ce,ue}-eap (Provided their license is allowing that)
Those are early access programs. We should not by default endorse a bleeding edge set in the official repos that are deemed purely for testing and feedback purpose rather than production usage. JetBrains also marks them with a specific warning: # This is an early access version of the product # You expressly acknowledge that this version of the product may not be # reliable, may not work as intended and may contain errors. Any use of # the EAP product is at your own risk. I'm not really fond of the idea to put them into our repos, the AUR is a quite good fit for it. Both are also just re-packaging the JetBrains dists so build time isn't really something to be concerned about. On top I see problems doing that with the JetBrains license issued for those two dists. cheers, Levente
On 01/11/21, Levente Polyak via aur-general wrote:
Hey Leonidas,
I wish you good like as well. May the force be with you :D
Thank you
For now I just have a tiny bit after reading through your mail:
On 10/31/21 19:24, Leonidas Spyropoulos via aur-general wrote:
AUR packages (I maintain) interested in moving to Community ... - intellij-idea-{ce,ue}-eap (Provided their license is allowing that)
Those are early access programs. We should not by default endorse a bleeding edge set in the official repos that are deemed purely for testing and feedback purpose rather than production usage.
JetBrains also marks them with a specific warning: # This is an early access version of the product # You expressly acknowledge that this version of the product may not be # reliable, may not work as intended and may contain errors. Any use of # the EAP product is at your own risk.
I'm not really fond of the idea to put them into our repos, the AUR is a quite good fit for it. Both are also just re-packaging the JetBrains dists so build time isn't really something to be concerned about. On top I see problems doing that with the JetBrains license issued for those two dists.
Fail point - keeping them in AUR is it. -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Hi On 31/10/2021 19:24, Leonidas Spyropoulos via aur-general wrote:
Hello,
I'm Leonidas Spyropoulos and I'd like to apply to become a Trusted User. I'm particularly instersted in packaging dependencies which are required for the ongoing python porting of Aurweb and anything related performance. I'm sponsored from Jelle van der Waa <jelle> and Sven-Hendrik Haase<sventaro>. <snip>
Discussion period is over! Please vote https://aur.archlinux.org/tu/?id=133
On 15.11.21 15:35, Jelle van der Waa via aur-general wrote:
Hi
On 31/10/2021 19:24, Leonidas Spyropoulos via aur-general wrote:
Hello,
I'm Leonidas Spyropoulos and I'd like to apply to become a Trusted User. I'm particularly instersted in packaging dependencies which are required for the ongoing python porting of Aurweb and anything related performance. I'm sponsored from Jelle van der Waa <jelle> and Sven-Hendrik Haase<sventaro>. <snip>
Discussion period is over! Please vote https://aur.archlinux.org/tu/?id=133
The voting period is over and with 41 yes votes Leonidas is now our most recent member. Congratulations! I'm going to create an issue for onboarding you on our issue tracker. Cheers, Sven
On Wed, Nov 24, 2021 at 04:30:16PM +0100, Sven-Hendrik Haase via aur-general wrote:
On 15.11.21 15:35, Jelle van der Waa via aur-general wrote:
Hi
On 31/10/2021 19:24, Leonidas Spyropoulos via aur-general wrote:
Hello,
I'm Leonidas Spyropoulos and I'd like to apply to become a Trusted User. I'm particularly instersted in packaging dependencies which are required for the ongoing python porting of Aurweb and anything related performance. I'm sponsored from Jelle van der Waa <jelle> and Sven-Hendrik Haase<sventaro>. <snip>
Discussion period is over! Please vote https://aur.archlinux.org/tu/?id=133
The voting period is over and with 41 yes votes Leonidas is now our most recent member. Congratulations!
I'm going to create an issue for onboarding you on our issue tracker.
This is the complete results if anyone where curious :) Yes No Abstain Total Voted Participation 41 1 9 51 Yes 86.44% -- Morten Linderud PGP: 9C02FF419FECBE16
participants (7)
-
Alexander Epaneshnikov
-
Jelle van der Waa
-
Justin Kromlinger
-
Leonidas Spyropoulos
-
Levente Polyak
-
Morten Linderud
-
Sven-Hendrik Haase