[aur-general] TU application; freswa
Hi everyone, my name is Frederik aka freswa and I'm applying to become a Trusted User with svenstaro's and grazzolini's sponsorship. I started using Linux around 2004 with some live images of Ubuntu. In 2010, Debian became my main OS. Only a year later I switched to Arch after I screwed up Debian/sid while hunting for the latest kernel. I'm interested in DevOps topics, mail server, C, Rust, Go and newer JVM languages such as Kotlin. Thanks to svenstaro I've been a bug wrangler since February. You mostly hear from me when I assign bugs to the wrong people from time to time :P OS contributions: - working on the dovecot-xaps code, providing native Mail.app Apple Push for iOS devices - maintaining and writing PKGBUILDs for the AUR - bug reporting and fixing for several projects My AUR packages got reviewed recently by eschwartz, svenstaro and alad - thanks :) If I become a TU, I'd like to focus on the bug tracker until we have a better solution. I'd also like to help out bug fixing when maintainers are busy, away or on vacation. Packages which I would like to move to [Community], some of which are not mine: docker-credential-pass i3status-rust intel-undervolt ispin mysqltuner pdfposter pinentry-rofi protobuf-go sha3sum spin talosctl thermald unifi woeusb I'm aware though that some of these packages do not meet the criteria of 10 votes yet. I'll reevaluate whether they meet this criteria from time to time. I'd also like to go on helping Eli with maintenance of zfs-dkms and zfs-utils in the AUR. In case JetBrains is okay with us packaging their IDE's, I'd also maintain them. But so far all requests I found resulted in a negative response from JB. I am looking forward to working with you! Frederik
On Wed, May 06, 2020 at 11:19:04PM +0200, Frederik Schwan via aur-general wrote:
Hi everyone, my name is Frederik aka freswa and I'm applying to become a Trusted User with svenstaro's and grazzolini's sponsorship.
Hi Freswa!
I started using Linux around 2004 with some live images of Ubuntu. In 2010, Debian became my main OS. Only a year later I switched to Arch after I screwed up Debian/sid while hunting for the latest kernel. I'm interested in DevOps topics, mail server, C, Rust, Go and newer JVM languages such as Kotlin.
Thanks to svenstaro I've been a bug wrangler since February. You mostly hear from me when I assign bugs to the wrong people from time to time :P
OS contributions: - working on the dovecot-xaps code, providing native Mail.app Apple Push for iOS devices - maintaining and writing PKGBUILDs for the AUR - bug reporting and fixing for several projects
My AUR packages got reviewed recently by eschwartz, svenstaro and alad - thanks :)
If I become a TU, I'd like to focus on the bug tracker until we have a better solution. I'd also like to help out bug fixing when maintainers are busy, away or on vacation.
Packages which I would like to move to [Community], some of which are not mine:
I'll do a review of your PKGBUILDS for these, but I'm curious to know if you also had any orphans on community that you were considering/interested on adopting[1]. To add to this, any other packages on community that you'd be interested in co-maintaining? :) Cheers! -Santiago [1] https://www.archlinux.org/packages/?repo=Community&maintainer=orphan
On 06/05/2020 23.21, Santiago Torres-Arias wrote:
If I become a TU, I'd like to focus on the bug tracker until we have a better solution. I'd also like to help out bug fixing when maintainers are busy, away or on vacation.
Packages which I would like to move to [Community], some of which are not mine: I'll do a review of your PKGBUILDS for these, but I'm curious to know if you also had any orphans on community that you were considering/interested on adopting[1]. To add to this, any other packages on community that you'd be interested in co-maintaining? :)
Hi Santiago, I don't use any of the orphaned packages in [community], so I'd rather spend my time on the bugtracker than maintaining packages I don't really know. But I could co-maintain anything where help is needed. I'd prefer go, rust and docker stuff, but I'm open for anything :) I'll also offer my help depending on bugs that will come in. Cheers, freswa
On 5/6/20 11:19 PM, Frederik Schwan via aur-general wrote:
Hi everyone, my name is Frederik aka freswa and I'm applying to become a Trusted User with svenstaro's and grazzolini's sponsorship.
I started using Linux around 2004 with some live images of Ubuntu. In 2010, Debian became my main OS. Only a year later I switched to Arch after I screwed up Debian/sid while hunting for the latest kernel. I'm interested in DevOps topics, mail server, C, Rust, Go and newer JVM languages such as Kotlin.
Thanks to svenstaro I've been a bug wrangler since February. You mostly hear from me when I assign bugs to the wrong people from time to time :P
That rings a bell, thanks for helping out with our bugtracker - even if that means some things get accidentally assigned wrong :p
OS contributions: - working on the dovecot-xaps code, providing native Mail.app Apple Push for iOS devices - maintaining and writing PKGBUILDs for the AUR - bug reporting and fixing for several projects
My AUR packages got reviewed recently by eschwartz, svenstaro and alad - thanks :)
Hey, i just submitted all AUR PKGBUILDs that you are a (co-)maintainer for to my PKGBUILD checker and there are a couple of things you should review most importantly: - all references to $srcdir & co should be quoted as those might contain spaces, leading to undesireable word-splitting - foo should never conflict/provide foo-git, those relations should work the other way around - http URLs should be upgraded to https when the remote supports it At the bottom of this mail you'll find the raw checker output, please review and adjust as needed :)
If I become a TU, I'd like to focus on the bug tracker until we have a better solution. I'd also like to help out bug fixing when maintainers are busy, away or on vacation.
Packages which I would like to move to [Community], some of which are not mine: docker-credential-pass i3status-rust intel-undervolt ispin mysqltuner pdfposter pinentry-rofi protobuf-go sha3sum spin talosctl thermald unifi woeusb
I'm aware though that some of these packages do not meet the criteria of 10 votes yet. I'll reevaluate whether they meet this criteria from time to time. I'd also like to go on helping Eli with maintenance of zfs-dkms and zfs-utils in the AUR.
AUR package maintenance is orthogonal to TU duties ^^ - you should talk to Eli directly about this
In case JetBrains is okay with us packaging their IDE's, I'd also maintain them. But so far all requests I found resulted in a negative response from JB.
As far as i know, JetBrains is quite adamant on people using their "Toolbox" for managing JetBrains software, good luck though.
I am looking forward to working with you! Frederik
Good luck with the rest of your application! Checker output mentioned above: adobe-icc: Warning: Potentially unintentional HTTP URL on line 10 Offending line: url='http://www.adobe.com/support/downloads/iccprofiles/iccprofiles_mac.html' Warning: Potentially unintentional HTTP URL on line 13 Offending line: source=('http://download.adobe.com/pub/adobe/iccprofiles/mac/AdobeICCProfilesCS4Mac_e...' brother-hl4150cdn: Warning: Potentially unintentional HTTP URL on line 9 Offending line: url='http://support.brother.com/g/b/downloadlist.aspx?c=de&lang=de&prod=hl4150cdn_all&os=127&flang=English' Warning: Potentially unintentional HTTP URL on line 17 Offending line: "http://download.brother.com/welcome/dlf005939/hl4150cdnlpr-${pkgver}-${pkgrel}.i386.rpm" Warning: Potentially unintentional HTTP URL on line 18 Offending line: "http://download.brother.com/welcome/dlf005941/hl4150cdncupswrapper-${pkgver}-${pkgrel}.i386.rpm") datagrip: Warning: Potentially unintentional HTTP URL on line 9 Offending line: url='http://www.jetbrains.com/datagrip/' dovecot-xaps-daemon: Style: 'conflicts' on line 10 should not contain other variant(s) of 'dovecot-xaps-daemon' Offending line: conflicts=('dovecot-xaps-daemon-git') dovecot-xaps-plugin: Style: 'conflicts' on line 11 should not contain other variant(s) of 'dovecot-xaps-plugin' Offending line: conflicts=('dovecot-xaps-plugin-git') exfat-utils-nofuse: Error: Potentially unquoted variable may contain spaces and should be quoted on line 22 Offending line: patch -p0 < ${srcdir}/nofuse.patch flexbox-udev: Error: Potentially unquoted variable may contain spaces and should be quoted on line 14 Offending line: install -Dm644 ${srcdir}/99-tprogrammer.rules ${pkgdir}/usr/lib/udev/rules.d/99-tprogrammer.rules gtkhotkey: Warning: Potentially unintentional HTTP URL on line 17 Offending line: source=("http://launchpad.net/$pkgname/0.2/$pkgver/+download/$pkgname-$pkgver.tar.gz" hipchat: Warning: Potentially unintentional HTTP URL on line 6 Offending line: # Contributor: Tom Vincent <http://tlvince.com/contact> imapsync: Warning: Potentially unintentional HTTP URL on line 8 Offending line: url='http://www.linux-france.org/prj/' ispin: Warning: Potentially unintentional HTTP URL on line 9 Offending line: url='http://spinroot.com/' jetbrains-toolbox: Warning: Potentially unintentional HTTP URL on line 8 Offending line: url='http://www.jetbrains.com/toolbox/' jtool-bin: Warning: Potentially unintentional HTTP URL on line 8 Offending line: url='http://www.newosxbook.com/tools/jtool.html' Warning: Potentially unintentional HTTP URL on line 10 Offending line: source=('http://www.newosxbook.com/tools/jtool.tar') libpurple-lurch: Style: 'provides' on line 12 should not contain other variant(s) of 'libpurple-lurch' Offending line: provides=('libpurple-lurch-git') makemkv-cli: Warning: Potentially unintentional HTTP URL on line 9 Offending line: url='http://www.makemkv.com' minetime-bin: Style: 'pkgdesc' on line 5 should not end on punctuation Offending line: pkgdesc='MineTime is a modern, intuitive and smart calendar application.' namebench: Warning: Potentially unintentional HTTP URL on line 10 Offending line: url='http://code.google.com/p/namebench/' nameinator: Error: Potentially unquoted variable may contain spaces and should be quoted on line 32 Offending line: install -Dm755 ${srcdir}/gopath/bin/${pkgname} "${pkgdir}"/usr/bin/${pkgname} onivim2: Style: 'conflicts' on line 14 should not contain other variant(s) of 'onivim2' Offending line: conflicts=('onivim2-git') or-tools-java: Style: 'pkgdesc' on line 5 should not end on punctuation Offending line: pkgdesc='Google`s Operations Research tools. With Java bindings.' Error: Potentially unquoted variable may contain spaces and should be quoted on line 46 Offending line: for i in ${pkgdir}/usr/lib/${pkgname}/*.so.*; do ln -rs ${i} ${i%so.*}so; done parcimonie-sh-git: Style: 'validpgpkeys' on line 14 is empty and should be removed Offending line: validpgpkeys=( perl-http-dav: Warning: Potentially unintentional HTTP URL on line 10 Offending line: url='http://search.cpan.org/dist/HTTP-DAV' Warning: Potentially unintentional HTTP URL on line 11 Offending line: source=("http://search.cpan.org/CPAN/authors/id/C/CO/COSIMO/HTTP-DAV-${pkgver}.tar.gz") perl-json-webtoken: Warning: Potentially unintentional HTTP URL on line 8 Offending line: url="http://search.cpan.org/~xaicron/JSON-WebToken/" Warning: Potentially unintentional HTTP URL on line 13 Offending line: source=("http://search.cpan.org/CPAN/authors/id/X/XA/XAICRON/JSON-WebToken-${pkgver}.tar.gz") perl-ntlm: Warning: Potentially unintentional HTTP URL on line 9 Offending line: url='http://search.cpan.org/~nbebout/NTLM/' Warning: Potentially unintentional HTTP URL on line 12 Offending line: source=("http://search.cpan.org/CPAN/authors/id/N/NB/NBEBOUT/NTLM-${pkgver}.tar.gz") pxz: Warning: Potentially unintentional HTTP URL on line 11 Offending line: url='http://jnovy.fedorapeople.org/pxz/' sendip: Style: 'pkgdesc' on line 7 should not end on punctuation Offending line: pkgdesc='A commandline tool to allow sending arbitrary IP packets.' thunderbird-nightly: Warning: Potentially unintentional HTTP URL on line 12 Offending line: url="http://www.mozilla.org/thunderbird" tomighty: Warning: Potentially unintentional HTTP URL on line 9 Offending line: url='http://www.tomighty.org/' ttf-freebanglafont: Warning: Potentially unintentional HTTP URL on line 10 Offending line: url='http://www.ekushey.org/' ttf-ubraille: Warning: Potentially unintentional HTTP URL on line 10 Offending line: url='http://yudit.org/download/fonts/UBraille/' Warning: Potentially unintentional HTTP URL on line 14 Offending line: source=('http://yudit.org/download/fonts/UBraille/UBraille.ttf') webstorm: Style: 'pkgdesc' on line 8 should not end on punctuation Offending line: pkgdesc='JavaScript IDE and HTML editor.' xfce-polkit: Style: 'conflicts' on line 11 should not contain other variant(s) of 'xfce-polkit' Offending line: conflicts=('xfce-polkit-git' 'polkit-gnome') youtrack: Warning: Potentially unintentional HTTP URL on line 8 Offending line: url='http://www.jetbrains.com/youtrack/' -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On 06/05/2020 23.48, Robin Broda via aur-general wrote:
On 5/6/20 11:19 PM, Frederik Schwan via aur-general wrote:
[...]
My AUR packages got reviewed recently by eschwartz, svenstaro and alad - thanks :)
Hey, i just submitted all AUR PKGBUILDs that you are a (co-)maintainer for to my PKGBUILD checker and there are a couple of things you should review
most importantly:
- all references to $srcdir & co should be quoted as those might contain spaces, leading to undesireable word-splitting
- foo should never conflict/provide foo-git, those relations should work the other way around
- http URLs should be upgraded to https when the remote supports it
At the bottom of this mail you'll find the raw checker output, please review and adjust as needed :)
fixed and pushed to https://github.com/freswa/aur
[...] I'd also like to go on helping Eli with maintenance of zfs-dkms and zfs-utils in the AUR.
AUR package maintenance is orthogonal to TU duties ^^ - you should talk to Eli directly about this
In the past he was happy to get a PR for compatibility patches for the latest kernel. I'd really like to see zfs-dkms in [community], but that sadly won't happen :/
I am looking forward to working with you!
Frederik
Good luck with the rest of your application!
Thank you :) freswa
Em maio 6, 2020 18:19 Frederik Schwan via aur-general escreveu:
Hi everyone, my name is Frederik aka freswa and I'm applying to become a Trusted User with svenstaro's and grazzolini's sponsorship.
I started using Linux around 2004 with some live images of Ubuntu. In 2010, Debian became my main OS. Only a year later I switched to Arch after I screwed up Debian/sid while hunting for the latest kernel. I'm interested in DevOps topics, mail server, C, Rust, Go and newer JVM languages such as Kotlin.
Thanks to svenstaro I've been a bug wrangler since February. You mostly hear from me when I assign bugs to the wrong people from time to time :P
OS contributions: - working on the dovecot-xaps code, providing native Mail.app Apple Push for iOS devices - maintaining and writing PKGBUILDs for the AUR - bug reporting and fixing for several projects
My AUR packages got reviewed recently by eschwartz, svenstaro and alad - thanks :)
If I become a TU, I'd like to focus on the bug tracker until we have a better solution. I'd also like to help out bug fixing when maintainers are busy, away or on vacation.
Packages which I would like to move to [Community], some of which are not mine: docker-credential-pass i3status-rust intel-undervolt ispin mysqltuner pdfposter pinentry-rofi protobuf-go sha3sum spin talosctl thermald unifi woeusb
I'm aware though that some of these packages do not meet the criteria of 10 votes yet. I'll reevaluate whether they meet this criteria from time to time. I'd also like to go on helping Eli with maintenance of zfs-dkms and zfs-utils in the AUR.
In case JetBrains is okay with us packaging their IDE's, I'd also maintain them. But so far all requests I found resulted in a negative response from JB.
I am looking forward to working with you! Frederik
I confirm the sponsorship of Frederik. I see the discussion already started though but, I'd suggest you guys wait until Sven also confirms. Regards, Giancarlo Razzolini
On 06.05.20 23:19, Frederik Schwan via aur-general wrote:
Hi everyone, my name is Frederik aka freswa and I'm applying to become a Trusted User with svenstaro's and grazzolini's sponsorship.
I started using Linux around 2004 with some live images of Ubuntu. In 2010, Debian became my main OS. Only a year later I switched to Arch after I screwed up Debian/sid while hunting for the latest kernel. I'm interested in DevOps topics, mail server, C, Rust, Go and newer JVM languages such as Kotlin.
Thanks to svenstaro I've been a bug wrangler since February. You mostly hear from me when I assign bugs to the wrong people from time to time :P
OS contributions: - working on the dovecot-xaps code, providing native Mail.app Apple Push for iOS devices - maintaining and writing PKGBUILDs for the AUR - bug reporting and fixing for several projects
My AUR packages got reviewed recently by eschwartz, svenstaro and alad - thanks :)
If I become a TU, I'd like to focus on the bug tracker until we have a better solution. I'd also like to help out bug fixing when maintainers are busy, away or on vacation.
Packages which I would like to move to [Community], some of which are not mine: docker-credential-pass i3status-rust intel-undervolt ispin mysqltuner pdfposter pinentry-rofi protobuf-go sha3sum spin talosctl thermald unifi woeusb
I'm aware though that some of these packages do not meet the criteria of 10 votes yet. I'll reevaluate whether they meet this criteria from time to time. I'd also like to go on helping Eli with maintenance of zfs-dkms and zfs-utils in the AUR.
In case JetBrains is okay with us packaging their IDE's, I'd also maintain them. But so far all requests I found resulted in a negative response from JB.
I am looking forward to working with you! Frederik
I'm confirming my sponsorship! Let the discussions begin. Well, continue, I suppose, since it already kinda started while I slept. Discussion period shall last until 2020-05-12. Sven
Em maio 7, 2020 2:50 Sven-Hendrik Haase via aur-general escreveu:
Discussion period shall last until 2020-05-12.
This is just a reminder that today is the last day for discussion on this application. Tomorrow I'll create a vote on the AUR. Regards, Giancarlo Razzolini
Em maio 12, 2020 12:06 Giancarlo Razzolini via aur-general escreveu:
Em maio 7, 2020 2:50 Sven-Hendrik Haase via aur-general escreveu:
Discussion period shall last until 2020-05-12.
This is just a reminder that today is the last day for discussion on this application. Tomorrow I'll create a vote on the AUR.
Correction: Both me and Sven were wrong on the time for discussion period. It will end on 2020-05-20, as the addition of a new TU requires a 14 day period discussion. Carry on. Regards, Giancarlo Razzolini
On Wed, May 06, 2020 at 11:19:04PM +0200, Discussion about the Arch User Repository (AUR) wrote:
Hi everyone, my name is Frederik aka freswa and I'm applying to become a Trusted User with svenstaro's and grazzolini's sponsorship.
I started using Linux around 2004 with some live images of Ubuntu. In 2010, Debian became my main OS. Only a year later I switched to Arch after I screwed up Debian/sid while hunting for the latest kernel. I'm interested in DevOps topics, mail server, C, Rust, Go and newer JVM languages such as Kotlin.
Thanks to svenstaro I've been a bug wrangler since February. You mostly hear from me when I assign bugs to the wrong people from time to time :P
OS contributions: - working on the dovecot-xaps code, providing native Mail.app Apple Push for iOS devices - maintaining and writing PKGBUILDs for the AUR - bug reporting and fixing for several projects
My AUR packages got reviewed recently by eschwartz, svenstaro and alad - thanks :)
If I become a TU, I'd like to focus on the bug tracker until we have a better solution. I'd also like to help out bug fixing when maintainers are busy, away or on vacation.
Packages which I would like to move to [Community], some of which are not mine: docker-credential-pass i3status-rust intel-undervolt ispin mysqltuner pdfposter pinentry-rofi protobuf-go sha3sum spin talosctl thermald unifi woeusb
I'm aware though that some of these packages do not meet the criteria of 10 votes yet. I'll reevaluate whether they meet this criteria from time to time. I'd also like to go on helping Eli with maintenance of zfs-dkms and zfs-utils in the AUR.
In case JetBrains is okay with us packaging their IDE's, I'd also maintain them. But so far all requests I found resulted in a negative response from JB.
I am looking forward to working with you! Frederik
Hi freswa, I would like to ask you the following questions: 1. How do you monitor new software releases? Do you use a specific tool for this like urlwatch? 2. How do you want to participate in the Arch Linux community? I see that you are very active in the IRC and on the bugtracker. Are there other areas, where you are active? 3. Do you use any tools for enforcing a specific PKGBUILD format? For example shfmt? 4. Are you testing your packages? If so, how? Do you spawn a VM via vagrant? Or do you use systemd-nspawn or docker images? Or do you just test it locally on your machine? Thanks chris
Hi Chris, On 08/05/2020 02.43, Christian Rebischke via aur-general wrote:
1. How do you monitor new software releases? Do you use a specific tool for this like urlwatch?
I'm using nvchecker which is automatically triggered on tty login.
2. How do you want to participate in the Arch Linux community? I see that you are very active in the IRC and on the bugtracker. Are there other areas, where you are active?
I'm also helping out in the DevOps team. E.g. I participated in the latest Rollout of Keycloak and Gitlab. I'll probably also help out when we will migrate our bugs at some point in the future. Looking forward to increase my engagement at DevOps in the future.
3. Do you use any tools for enforcing a specific PKGBUILD format? For example shfmt?
Not yet, but I'll have a look at shfmt. Honestly I haven't had the idea to use a formatting tool yet. But I'm using aurpublish to ensure .SRCINFO and checksum consistency.
4. Are you testing your packages? If so, how? Do you spawn a VM via vagrant? Or do you use systemd-nspawn or docker images? Or do you just test it locally on your machine?
I'm using most of the packages myself, so I test them locally. The builds are tested with our devtools package in systemd-nspawn (for missing deps etc.). Docker seems to be a nice idea to improve this in the future :) Cheers, freswa
On 5/6/20 5:19 PM, Frederik Schwan via aur-general wrote:
Hi everyone, my name is Frederik aka freswa and I'm applying to become a Trusted User with svenstaro's and grazzolini's sponsorship.
I started using Linux around 2004 with some live images of Ubuntu. In 2010, Debian became my main OS. Only a year later I switched to Arch after I screwed up Debian/sid while hunting for the latest kernel.
I'm interested in DevOps topics, mail server, C, Rust, Go and newer JVM languages such as Kotlin.
Thanks to svenstaro I've been a bug wrangler since February. You mostly hear from me when I assign bugs to the wrong people from time to time :P
OS contributions: - working on the dovecot-xaps code, providing native Mail.app Apple Push for iOS devices - maintaining and writing PKGBUILDs for the AUR - bug reporting and fixing for several projects
My AUR packages got reviewed recently by eschwartz, svenstaro and alad - thanks :)
Just for the record -- I did not review your AUR packages, you may have intended to ask me to do so but this never happened. Perhaps you drafted this email and forgot to remove my name before sending it? You did provide a very useful kernel backports patch for my zfs-dkms package, which was much appreciated.
If I become a TU, I'd like to focus on the bug tracker until we have a better solution. I'd also like to help out bug fixing when maintainers are busy, away or on vacation.
I don't know what this means... once there is a "better solution for our bugtracker" you intend to not focus on it? :p Becoming a TU might give more opportunities to commit fixes to packages, but it's unrelated to triage and analysis, at least, which I'd say are the things which need the most love. So there's plenty to do there either way. :D (Speaking from personal experience, being a TU has made me less productive on the bugtracker.)
I'm aware though that some of these packages do not meet the criteria of 10 votes yet. I'll reevaluate whether they meet this criteria from time to time.
I'd also like to go on helping Eli with maintenance of zfs-dkms and zfs-utils in the AUR.
Patches and suggestions are definitely welcome. :D Though I doubt zfs is suitable in any way for inclusion in community, despite indeed having enough votes.
In case JetBrains is okay with us packaging their IDE's, I'd also maintain them. But so far all requests I found resulted in a negative response from JB.
I'm given to understand packaging our current packages for pycharm/intellij community edition gives their current maintainers enough agonizing headaches. It seems like the kind of thing one would want to avoid getting involved in. :D I don't think we should be packaging their custom JRE, anyway, as that should remain an AUR kind of thing (and we don't optdepends on AUR packages either). This probably makes it more complicated to support their stuff, especially for things which aren't open source? tl;dr do you believe this is practical to focus on? Do you think they are likely to provide a way for us to package it which fits our packaging guidelines? -- Eli Schwartz Bug Wrangler and Trusted User
On 12/05/2020 19.02, Eli Schwartz via aur-general wrote:
My AUR packages got reviewed recently by eschwartz, svenstaro and alad - thanks :) Just for the record -- I did not review your AUR packages, you may have intended to ask me to do so but this never happened. Perhaps you drafted
On 5/6/20 5:19 PM, Frederik Schwan via aur-general wrote: this email and forgot to remove my name before sending it?
I just looked at my git log. No we did not. Sorry, that was not intentional :( I thought we did a review when we talked about my bugwrangler application. But apparently we didn't.
You did provide a very useful kernel backports patch for my zfs-dkms package, which was much appreciated.
Thank you :)
If I become a TU, I'd like to focus on the bug tracker until we have a better solution. I'd also like to help out bug fixing when maintainers are busy, away or on vacation. I don't know what this means... once there is a "better solution for our bugtracker" you intend to not focus on it? :p
Becoming a TU might give more opportunities to commit fixes to packages, but it's unrelated to triage and analysis, at least, which I'd say are the things which need the most love.
So there's plenty to do there either way. :D (Speaking from personal experience, being a TU has made me less productive on the bugtracker.)
I am missing any experience of a TU's life, so any judgement from me would be arrogant imo. Though, I have experienced the rogue environment of the AUR and I think I'm well prepared to handle some of the packages in [community], where at least no one comments "PKGBUILD broken, `One or more PGP signatures could not be verified!`" :P I intend to keep the bugtracker as my first priority though :)
I'm aware though that some of these packages do not meet the criteria of 10 votes yet. I'll reevaluate whether they meet this criteria from time to time.
I'd also like to go on helping Eli with maintenance of zfs-dkms and zfs-utils in the AUR. Patches and suggestions are definitely welcome. :D
Though I doubt zfs is suitable in any way for inclusion in community, despite indeed having enough votes.
I don't think it's suitable for community either. I'd like to continue working with you in the AUR on it if you don't mind?
In case JetBrains is okay with us packaging their IDE's, I'd also maintain them. But so far all requests I found resulted in a negative response from JB. I'm given to understand packaging our current packages for pycharm/intellij community edition gives their current maintainers enough agonizing headaches. It seems like the kind of thing one would want to avoid getting involved in. :D
I don't think we should be packaging their custom JRE, anyway, as that should remain an AUR kind of thing (and we don't optdepends on AUR packages either). This probably makes it more complicated to support their stuff, especially for things which aren't open source?
tl;dr do you believe this is practical to focus on? Do you think they are likely to provide a way for us to package it which fits our packaging guidelines?
I don't intend to focus on this. I've been the maintainer of 5 JB packages for some time now and JB is a pretty prominent IDE creator. If there is some time I'd like to ask them how they think about repackaging their stuff. But before I'll help out on updating pycharm-community and intellij-idea-community to feel the pain first. :P Frederik
On 5/6/20 11:19 PM, Frederik Schwan via aur-general wrote:
I am looking forward to working with you! Frederik
Hi Frederik, I'm happy to _already_ work with you as you are doing a great job on the bugtracker. I hope we won't loose your power wrangling that beast :D I managed to cut some free time to review all your packages, so here comes the feedback, cheers, Levente $ xxarhtna --user freswa adobe-icc: - could use TLS in url and source, because why not :} - would be a good idea to reuse $pkgver in source=() chisel: - doesn't use a unique source as v$pkgver.tar.gz may exist multiple times. could use githubs full filename endpoint: $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz dovecot-xaps-daemon: - should not have the conflicts, its always the special variants that conflict on the regular variant, not the other way around - doesn't use a unique source as v$pkgver.tar.gz may exist multiple times. could use githubs full filename endpoint: $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz - could use the new set of go binary hardening flags so sources are fortified, pie, etc: CGO_{L,C,CXX,CPP}FLAGS - License is a non common one but the distribution of anything indicating the license is missing. dovecot-xaps-daemon-git: - normally its a bit better to have a pkgver that actually has any meaning in what kind of version the installed pkg matches, like 0.7.r21.b098747 instead of 94.b098747 git describe --tags | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g' - could use the new set of go binary hardening flags so sources are fortified, pie, etc: CGO_{L,C,CXX,CPP}FLAGS - License is a non common one but the distribution of anything indicating the license is missing. dovecot-xaps-plugin: - build function doesn't build anything, the package functions "make install" will do the real compilation. - Should not makedepend on git as its not using git - should not have the conflicts, its always the special variants that conflict on the regular variant, not the other way around - doesn't use a unique source as v$pkgver.tar.gz may exist multiple times. could use githubs full filename endpoint: $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz - License is a non common one but the distribution of anything indicating the license is missing. - cmake has a convenient "-B build" to that doesn't require mkdir dovecot-xaps-plugin-git: - build function doesn't build anything, the package functions "make install" will do the real compilation. - missing provides and conflicts on the regular non -git variant - normally its a bit better to have a pkgver that actually has any meaning in what kind of version the installed pkg matches, like 0.7.r21.b098747 instead of 94.b098747 git describe --tags | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g' - License is a non common one but the distribution of anything indicating the license is missing. - cmake has a convenient "-B build" to that doesn't require mkdir duperemove-git: - should not pull over plaintext git:// but git+https to provide endpoint verification and encryption during transit - missing conflicts on duperemove - normally its a bit better to have a pkgver that actually has any meaning in what kind of version the installed pkg matches, like 0.7.r21.b098747 instead of 94.b098747 git describe --tags | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g' exfat-dkms-git: - shouldn't this also provide something like exfat and exfat-dkms - this shouldn't confict on other special git variant exfat-git - shouldn't this package be named exfat-nofuse-dkms-git ? its not just exfat-dkms, this is in fact exfat-nofuse exfat-utils-nofuse: - non quoted usage of ${srcdir} which may fail if it contains spaces - autoreconf could be executed during prepare step flexbox-udev: - non quoted usage of ${srcdir} and ${pkgdir } which may fail if it contains spaces gimp-plugin-separate+: - modifying or patching files should be done during prepare gtkhotkey: - modifying or patching files should be done during prepare heif: - doesn't use a unique source as v$pkgver.tar.gz may exist multiple times. could use githubs full filename endpoint: $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz jtool-bin: - doesn't use a unique source and should prefix it with $pkgver - package is outdated as v2 exists latex-tuda-ci: - doesn't use a unique source as v$pkgver.tar.gz may exist multiple times. could use githubs full filename endpoint: $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz libpurple-lurch: - should not on every single build side load the whole submodules repos, instead they should be declared in source=() and the paths updated accordingly -- for an exaple look at the mono package - static version must not provides=() its -git counterpart nameinator: - doesn't use a unique source as v$pkgver.tar.gz may exist multiple times. could use githubs full filename endpoint: $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz - could use the new set of go binary hardening flags so sources are fortified, pie, etc: CGO_{L,C,CXX,CPP}FLAGS - must not use 'go get' on a repo as thats not reproducible onivim2: - should not have the conflicts, its always the special variants that conflict on the regular variant, not the other way around onivim2-git: - missing provides and conflicts on the regular non -git variant open-ecard-git: - should not pull over plaintext git:// but git+https to provide endpoint verification and encryption during transit - missing provides and conflicts on the regular non -git variant - it this hard depending on the JRE 8 for a reason, can't this be run on newer JRE? If so, it would need the startup script to hardcode the java jvm path to that specific variant OpenBoardView: - cmake has a convenient "-B build" to that doesn't require mkdir or-tools-java: - doesn't use a unique source as v$pkgver.tar.gz may exist multiple times. could use githubs full filename endpoint: $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz - does this really makedepend on git? It it checking out more stuff? If so it should be revisited to add those repos to the source=() array and popule them otherwise they get downloaded on each run - could use some indention in package() parcimonie-sh-git - pkgdesc looks a bit overly long, should be cut a bit pass-sshaskpass: - should not pull over plaintext git:// but git+https to provide endpoint verification and encryption during transit - pkgname is wrong as this is in fact a -git package, but the name makes it a static version one pdfposter: - repo seems to contain unit tests, would be worth running in a check() function - uses setuptools entrypoing wrapper, therefor python-setuptools is not just a makedepends but a hard requirement perl-ntlm: - seems to lack depends on perl, i hardly doubt a perl module works without a single dependency :) - could use TLS in url and source, because why not :} pinentry-rofi: - missing depends on rofi - doesn't use a unique source as v$pkgver.tar.gz may exist multiple times. could use githubs full filename endpoint: $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz - License is a non common one but the distribution of anything indicating the license is missing. python-requests-gpgauthlib: - doesn't use a unique source as v$pkgver.tar.gz may exist multiple times. could use githubs full filename endpoint: $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz - missing requires on python-gnupg and python-requests - repo seems to contain unit tests, would be worth running in a check() function talosctl: - doesn't use a unique source as v$pkgver.tar.gz may exist multiple times. could use githubs full filename endpoint: $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz - could use the new set of go binary hardening flags so sources are fortified, pie, etc: CGO_{L,C,CXX,CPP}FLAGS - Go packages are not 'any' arch, they are architecture dependent tbt: - cmake has a convenient "-B build" to that doesn't require mkdir - doesn't use a unique source as v$pkgver.tar.gz may exist multiple times. could use githubs full filename endpoint: $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz - any reason why its deleting the documentation in /usr/share/doc? thunderbird-nightly: - this is not a source build and hence must be postfixed with -bin tomighty: - is a static version 0.7.2 but doesn't use a static source, the branch for 0.7 could change at any point. must depend on a non changing state - convert operations should be done during build tpacpi-bat-git: - should not pull over plaintext git:// but git+https to provide endpoint verification and encryption during transit - normally its a bit better to have a pkgver that actually has any meaning in what kind of version the installed pkg matches, like 0.7.r21.b098747 instead of 94.b098747 git describe --tags | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g' - pkgdesc looks a bit overly long, should be cut a bit wrench: - doesn't use a unique source as v$pkgver.tar.gz may exist multiple times. could use githubs full filename endpoint: $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz - missing depends on python-requests and python-click - uses setuptools entrypoing wrapper, therefor python-setuptools is not just a makedepends but a hard requirement - repo seems to contain unit tests, would be worth running in a check() function xfce-polkit: - autotools stuff should be run during prepare() - should not have the conflicts on -git, its always the special variants that conflict on the regular variant, not the other way around xfce-polkit-git: - autotools stuff should be run during prepare() - normally its a bit better to have a pkgver that actually has any meaning in what kind of version the installed pkg matches, like 0.7.r21.b098747 instead of 94.b098747 git describe --tags | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g' EOF
Am 16.05.20 um 21:01 schrieb Levente Polyak via aur-general:
- shouldn't this package be named exfat-nofuse-dkms-git ? its not
Why would a fuse-filesystem use dkms? The whole purpose of fuse is to run in user space. And renaming packages is an annoyance. Just my 2¢, as a user of this package. BR
On 5/16/20 10:48 PM, Markus Schaaf wrote:
Am 16.05.20 um 21:01 schrieb Levente Polyak via aur-general:
- shouldn't this package be named exfat-nofuse-dkms-git ? its not
Why would a fuse-filesystem use dkms? The whole purpose of fuse is to run in user space. And renaming packages is an annoyance.
Just my 2¢, as a user of this package.
BR
What exactly do you mean? I'm talking about the exfat-dkms-git packages, which in fact already uses dkms. I'm pretty sure you confuse something here. And the name is in fact wrong, as its exfat-nofuse git package using dkms, hence its name should be exfat-nofuse-dkms-git. In general it doesn't matter much if renaming is annoyance, what matter is if the name is correct or wrong. cheers, Levente
On 16/05/2020 21.01, Levente Polyak via aur-general wrote:
I'm happy to _already_ work with you as you are doing a great job on the bugtracker. I hope we won't loose your power wrangling that beast :D
Thank you. I'll stick to bug wrangling :)
I managed to cut some free time to review all your packages, so here comes the feedback,
Some comments below.
$ xxarhtna --user freswa
adobe-icc: - could use TLS in url and source, because why not :} - would be a good idea to reuse $pkgver in source=()
I explicitly decided against using the ${pkgver} in the source, as the version never changes. Adobe CS4 has long been superseded and there is and probably never will be an update for this. I don't see the improvement in this case. Please enlighten me :P
chisel: dovecot-xaps-daemon: dovecot-xaps-daemon-git: dovecot-xaps-plugin: dovecot-xaps-plugin-git: duperemove-git:
fixed
exfat-dkms-git: - shouldn't this package be named exfat-nofuse-dkms-git ? its not just exfat-dkms, this is in fact exfat-nofuse
renamed to exfat-nofuse-dkms-git - merge request submitted
exfat-utils-nofuse: flexbox-udev: gimp-plugin-separate+: gtkhotkey: heif: jtool-bin: latex-tuda-ci: libpurple-lurch:
fixed
nameinator: - must not use 'go get' on a repo as thats not reproducible
Sadly upstream does not provide vendoring or go modules. I filled a request to use go modules and will fix this when it lands in a release.
onivim2: onivim2-git: open-ecard-git: OpenBoardView: or-tools-java: parcimonie-sh-git pass-sshaskpass:
renamed to pass-sshaskpass-git - merge request submitted
- pkgname is wrong as this is in fact a -git package, but the name makes it a static version one
pdfposter: perl-ntlm: pinentry-rofi: python-requests-gpgauthlib: - repo seems to contain unit tests, would be worth running in a check() function
Tests fail atm. I filled an upstream bugreport and I will add the tests once things are sorted out.
talosctl: tbt: thunderbird-nightly: - this is not a source build and hence must be postfixed with -bin
renamed to thunderbird-nightly-bin - merge request submitted
tomighty:> tpacpi-bat-git: wrench: xfce-polkit: xfce-polkit-git:
Fixed. Changes can be found here: https://github.com/freswa/aur/commit/c3778f6bda345f0165289f3a57d36047e6ba593... Thank you for doing the review :) Cheers Frederik
On 5/17/20 5:06 AM, Frederik Schwan via aur-general wrote:
Changes can be found here: https://github.com/freswa/aur/commit/c3778f6bda345f0165289f3a57d36047e6ba593...
Thank you for doing the review :)
Time for the next round: Package: datagrip datagrip-jre 'commercial' on line 9 is not a valid license[1], in case of a custom license prefix with 'custom:' Offending line: license=('commercial') Package: or-tools-java Variable ${srcdir} on line 44 should be quoted as it may contain spaces Offending line: sed -i "s#${src#git+}#${srcdir}/${srcfolder}#" ${srcdir}/${pkgname%-java}-${pkgver}/makefiles/Makefile.third_party.unix.mk ---------------------------------------------------^^^^^^^^^ Package: pass-sshaskpass 'GPLv2' on line 8 is not a valid license[1], in case of a custom license prefix with 'custom:' Offending line: license=('GPLv2') Package: pass-sshaskpass-git 'GPLv2' on line 8 is not a valid license[1], in case of a custom license prefix with 'custom:' Offending line: license=('GPLv2') Package: tomighty Variable ${srcdir} on line 32 should be quoted as it may contain spaces Offending line: convert ${srcdir}/tomato.ico ${srcdir}/tomato.png Package: tpacpi-bat-git Error: 'GPLv3' on line 9 is not a valid license[1], in case of a custom license prefix with 'custom:' Offending line: license=('GPLv3') Package: unifi-beta Potentionally unintentional HTTP URL http://www.ubnt.com/ on line 10 should be https Offending line: url='http://www.ubnt.com/' Package: youtrack 'commercial:jetbrains' on line 8 is not a valid license[1], in case of a custom license prefix with 'custom:' Offending line: license=('commercial:jetbrains')
Cheers Frederik
:P [1] (Currently) valid non-custom licenses are: AGPL3, Apache, Artistic2.0, Boost, CCPL, CDDL, CPL, EPL, FDL1.2, FDL1.3, GPL2, GPL3, LGPL2.1, LGPL3, LPPL, MPL, MPL2, PHP, PSF, PerlArtistic, RUBY, W3C, ZPL, AGPL, APACHE, FDL, GPL, LGPL, Unlicense, BSD, ISC, MIT, OFL, Python, ZLIB -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On 17/05/2020 05.28, Robin Broda via aur-general wrote:
On 5/17/20 5:06 AM, Frederik Schwan via aur-general wrote:
Changes can be found here: https://github.com/freswa/aur/commit/c3778f6bda345f0165289f3a57d36047e6ba593...
Thank you for doing the review :) Time for the next round:
Package: datagrip datagrip-jre Package: or-tools-java Package: pass-sshaskpass Package: pass-sshaskpass-git Package: tomighty Package: tpacpi-bat-git Package: unifi-beta Package: youtrack
Fixed. https://github.com/freswa/aur/commit/6a1f6efae06f137b6d93f7f66973a6272766fe1... Thank you Frederik
Em maio 17, 2020 11:40 Frederik Schwan via aur-general escreveu:
On 17/05/2020 05.28, Robin Broda via aur-general wrote:
On 5/17/20 5:06 AM, Frederik Schwan via aur-general wrote:
Changes can be found here: https://github.com/freswa/aur/commit/c3778f6bda345f0165289f3a57d36047e6ba593...
Thank you for doing the review :) Time for the next round:
Package: datagrip datagrip-jre Package: or-tools-java Package: pass-sshaskpass Package: pass-sshaskpass-git Package: tomighty Package: tpacpi-bat-git Package: unifi-beta Package: youtrack
Fixed. https://github.com/freswa/aur/commit/6a1f6efae06f137b6d93f7f66973a6272766fe1...
Thank you Frederik
The discussion period is over. Let's vote! https://aur.archlinux.org/tu/?id=121 Regards, Giancarlo Razzolini
Em maio 21, 2020 8:29 Giancarlo Razzolini via aur-general escreveu:
The discussion period is over. Let's vote!
The voting period is over and we have a result: Yes: 39 No: 3 Abstain: 9 Participation: 92.73% So, I guess it's official, welcome to the team! Regards, Giancarlo Razzolini
On Thu, 2020-05-28 at 08:42 -0300, Giancarlo Razzolini via aur-general wrote:
Em maio 21, 2020 8:29 Giancarlo Razzolini via aur-general escreveu:
The discussion period is over. Let's vote!
The voting period is over and we have a result:
Yes: 39 No: 3 Abstain: 9 Participation: 92.73%
So, I guess it's official, welcome to the team!
Yes, welcome aboard ! Cheers, -- Seblu
participants (10)
-
Christian Rebischke
-
Eli Schwartz
-
Frederik Schwan
-
Giancarlo Razzolini
-
Levente Polyak
-
Markus Schaaf
-
Robin Broda
-
Santiago Torres-Arias
-
Sven-Hendrik Haase
-
Sébastien Luttringer