[aur-general] TU Application: Bruno Pagani
Hi everyone, My name is Bruno Pagani (a.k.a. ArchangeGabriel, or just archange sometimes), long time Linux user and Arch user since January 2014. I have since fallen in love with pacman/PKGBUILDs, the community and the distribution in its whole more generally. I took maintainership of my first AUR package quite rapidly, and then gradually of more of them. I was recently thinking of becoming a TU in order to bring some of those packages to [community]; Bartłomiej Piotrowski encouraged me to do so and kindly accepted to sponsor my application. Regarding my implication in Arch, even if I’m not participating much in MLs, I’ve been them reading a lot and always try to follow best practices like using devtools to build (including in painful cases like very long AUR dependencies chain — thanks zorun for becoming a TU and bringing ring in [community] soon!). I’m also going to setup a Matrix[0] with IRC bridges on my server to participate in IRC (whether I’m accepted as a TU or not), something I’ve postponed for too long. Among the packages I maintain in AUR[1], most of them are -light/-minimal (meaning less dependencies/features) versions of repo’s one and thus not suitable for leaving AUR, but there are a few noteworthy others that I want to bring to [community]: – beignet[2]: Intel OSS OpenCL implementation for their iGPU, currently only supporting OpenCL 1.2 but work for OpenCL 2.0 is ongoing. – bs1770gain[3]: Loudness scanner/replaygain calculator, and — to my opinion at least — a good alternative as a beets[4] optdep for those who want to avoid pulling gst-* and their dependencies for this sole purpose. − ring-kde[5]: The KDE client for Ring. Leftover by Baptiste Jonglez (zorun) since he does not use it. Being a KDE user, I’m using this one rather than it’s Gnome counterpart. − thermald[6]: Thermal Daemon for Intel processors, doing thermal management using advanced processor states. – whipper[7]: secure CD ripper, successor of the defunct morituri. It has been very recently pushed to AUR by Freso, but he is OK with me maintaining it in [community] (and in fact would also like to become a TU at some point and help co-maintaining whipper). This would also require moving accuraterip-checksum[8] for which I am not the current maintainer either, but Shardz (the current one) agreed to transfer it to any TU wanting to maintain whipper. Outside of those, they are other packages I might want to maintain in the future but I felt those above would make a good start. I might just add uchardet[9], because it’s now needed for mpv[10], and I’m OK to maintain it if Christian Hesse (eworm) doesn’t want to. Just in case this could be of some interest for any of you, other packages interesting me in AUR are either KDE thumbnailers, ColorHug related software and HDF5/NetCDF stuff (+mpich). Which leads me to currently orphaned packages in [community] I can maintain: – python{,2}-mpi4py[11]: Not currently out-of-date, but since I rely on those packages for my work I would definitively take care of them if needed. And that brings me to add some more words about me: I’m a 24 years old french PhD student in astrophysics, doing mostly numerical simulations of supernovæ explosions on supercomputers (hence the interest in HDF5/NetCDF/MPI stuff). When it comes to Linux, it has been the first OS present at home, in the form of Mandrake in 1999 (the sysadmin was my father at this point in time). I’ve then handled the switch to Mandrake’s successor Mandriva myself, and later on moved to Ubuntu when I got my first personal computer. Then my second one was in the very first generation of Optimus[12] laptops, and in order to make use of my GPU this made me join The Bumblebee Project[13] (as “project manager” one could say, and yes we definitively need to update this thing). At this point I gained a lot of knowledge in Linux environments, and a lot of factors (including people here that might recognize themselves) pushed me to try ArchLinux, which I did… and I loved it. Today, my server is proudly running Arch Linux, my home media server too (Cubieboard, so that’s Arch Linux ARM), and I’ve recently converted my girlfriend and younger brothers to Arch. So thanks to all of you for your hard work in this distro! Finally, concerning my involvement in FLOSS projects outside of Arch and the aforementioned Bumblebee, I’m mostly opening bugs for ideas/feature requests (or actual bugs sometimes) in various BugZillas and the likes as well as around GitHub since I don’t know how to code in any useful language outside of Python (I use Fortran at work and have no time to learn other ones currently even if I would like to, like C and perhaps Rust too), but I love music and recently discovered beets[14], and will try to contribute code to this Python project soon. Do not hesitate if you have any questions on anything or any comments regarding my AUR packages. ;) Thanks for reading and considering my application, Bruno [0] https://matrix.org/ [1] https://aur.archlinux.org/packages/?K=ArchangeGabriel&SeB=m [2] https://aur.archlinux.org/packages/beignet [3] https://aur.archlinux.org/packages/bs1770gain [4] https://www.archlinux.org/packages/community/any/beets [5] https://aur.archlinux.org/packages/ring-kde [6] https://aur.archlinux.org/packages/thermald [7] https://aur.archlinux.org/packages/whipper [8] https://aur.archlinux.org/packages/accuraterip-checksum [9] https://aur.archlinux.org/packages/uchardet [10] https://bugs.archlinux.org/task/52269 [11] https://www.archlinux.org/packages/community/x86_64/python-mpi4py [12] https://wiki.archlinux.org/index.php/NVIDIA_Optimus [13] http://bumblebee-project.org [14] http://beets.io
On 01/07/2017 03:32 PM, Bruno Pagani via aur-general wrote:
Hi everyone,
My name is Bruno Pagani (a.k.a. ArchangeGabriel, or just archange [...]
Hey Bruno, nice to hear that you want to join the great ArchLinux project as TU. I am aware the discussion period has not started yet, but I think its fine if I already give some feedback. I've checked your PKGBUILDs and I've noted a few thinks (which I also did wrong or sometimes forget). Those are mostly only concerning security aspects which I find important. If you followed the recent discussion you might have noticed that some people differ from this opinion. Please take it as a kind notice for you, use it if you wish :) * For github download .tar.gz is preferred over .zip in general if i am not wrong. * Prefix your source download with: ${pkgname}-${pkgver}.tar.xz:: if you have a common SRCDIR. I also recently change to a common src dir, as too many packages blow my directories. * You can use https for sourceforge downloads soon/now[1] (bs1770gain) * Thanks for using sha256sums. You may want to use the even stronger sha512sums, as it does not hurt to use stronger hashes *duck* * certbot-user: the gpg keys should have a comment with the owner of the trusted keys (as you did with exfalso, but with email) * mpd-{sserver,}minimal uses a sha1sum. If its an upstream hash please contact them to use stronger hashes and include a stronger one as well. You can use multiple hashes in the PKGBUILD (as in weboob-headless). * powerdevil/spectacle-light uses http downloads. Even though gpg signatures are used, it would be nice to have https available anyways. It seems kde missconfigured their download subdomain for https, so you might want to contact them about that? * What I also do is to put my own GPG ID inside my PKGBUILDs, so people can simpler verify/find my key. Just as an idea. * For those projects who dont use GPG signatures yet, you might want to kindly contact them. I've written a script + instructions for using gpg along with a template to contact upstreams[2]. You might want to check it out. * If you want to move whipper, please consider to take part in the discussion about gpg[3]. Please dont take it personally, some people found them personally offended, while this was not the intention. You have the chance to also speak up for stronger security. I do not want to end this in an offtopic discussion, maybe you can help too ;) Cheers ~Nico [1] https://github.com/arduino/Arduino/pull/5772#issuecomment-269715945 [2] https://github.com/NicoHood/gpgit#a-template-for-contacting-upstreams [3] https://github.com/JoeLametta/whipper/issues/77
Le 07/01/2017 à 16:05, NicoHood a écrit :
Hey Bruno, nice to hear that you want to join the great ArchLinux project as TU. I am aware the discussion period has not started yet, but I think its fine if I already give some feedback.
Hi Nico, You’ve been very fast indeed, but the discussion period started right after anyway. ;)
I've checked your PKGBUILDs and I've noted a few thinks (which I also did wrong or sometimes forget). Those are mostly only concerning security aspects which I find important. If you followed the recent discussion you might have noticed that some people differ from this opinion. Please take it as a kind notice for you, use it if you wish :)
* For github download .tar.gz is preferred over .zip in general if i am not wrong.
Assuming you refer to audiothumbs-frameworks and ring-kde, I wasn’t aware GitHub was providing .tar.gz downloads for snapshots tarballs (they are not provided in the UI), but I admit not having tried a simple substitution of file extension, which indeed works. Strange lack of curiosity from my part. I’ve fixed both of them, thanks!
* Prefix your source download with: ${pkgname}-${pkgver}.tar.xz:: if you have a common SRCDIR. I also recently change to a common src dir, as too many packages blow my directories.
Can you please specify which package(s) you have in mind here? I’ve just checked again and didn’t found any package where I don’t do this and upstream tarball doesn’t follow this either.
* You can use https for sourceforge downloads soon/now[1] (bs1770gain)
Yes, and that is already what I do. Maybe you’ve overlooked or are talking of “Upstream URL” (in which case this doesn’t work).
* Thanks for using sha256sums. You may want to use the even stronger sha512sums, as it does not hurt to use stronger hashes *duck*
Stronger is relative (they’re mathematically the sames, breaking one in an applicable way probably means breaking both). Does not hurt too. Everything has been said around this in this list some months ago, I’ll not start that debate again. I’ll only provide sha512 if this is what upstream provides or a new policy going that way is adopted by ArchLinux, which currently isn’t the case AFAIK.
* certbot-user: the gpg keys should have a comment with the owner of the trusted keys (as you did with exfalso, but with email)
Sure, fixed. :) I’ve also fixed it in scribus-devel where it has apparently escaped your review. ;)
* mpd-{sserver,}minimal uses a sha1sum. If its an upstream hash please contact them to use stronger hashes and include a stronger one as well. You can use multiple hashes in the PKGBUILD (as in weboob-headless).
Like most of my -light or -minimal packages, hashes are from the repo package. When they are upstream ones too (KDE packages notably), I verify them, but here it’s not the case AFAIK. Those packages also use a PGP key, so I could remove the sum altogether as the wiki proposes. But actually this is one almost valid use case where I agree on switching to stronger checksum: packages being on AUR, and AUR being full of people that don’t understand PGP and its support in makepkg, the use of --skippgpcheck is probably frequent. Then, even if this is not a behaviour to be encouraged, having a strong verified checksum here is probably better for those users. I’ve thus switched them to sha256sums. That way, people relying on PGP still get the full verification, while people skipping it get a checksum that I’ve computed after PGP verification of the same tarball.
* powerdevil/spectacle-light uses http downloads. Even though gpg signatures are used, it would be nice to have https available anyways. It seems kde missconfigured their download subdomain for https, so you might want to contact them about that?
Yes, KDE doesn’t provides https at the moment. I’ve reported a bug upstream[0] (failed to find any open or close one relating to this).
* What I also do is to put my own GPG ID inside my PKGBUILDs, so people can simpler verify/find my key. Just as an idea.
What purpose does that serve (outside of cluttering the PKGBUILD)? My fingerprint is already in my AUR account profile[1] for that matter.
* For those projects who dont use GPG signatures yet, you might want to kindly contact them. I've written a script + instructions for using gpg along with a template to contact upstreams[2]. You might want to check it out.
And I don’t like it. Because (good) PGP is not easy, and PGP signatures for the sake of PGP signatures are not a good idea. If you want to be able to trust a sig, you need to trust the key and the behaviour of his owner regarding PGP. And I won’t trust a sig issued by someone that only did it to satisfy you, rather than deeply thought about it and its implications. Also, automated is rarely a good idea when it comes to PGP.
* If you want to move whipper, please consider to take part in the discussion about gpg[3]. Please dont take it personally, some people found them personally offended, while this was not the intention. You have the chance to also speak up for stronger security. I do not want to end this in an offtopic discussion, maybe you can help too ;)
Done. But as you might have expected since last paragraph, didn’t went your way. Regards, Bruno [0] https://bugs.kde.org/show_bug.cgi?id=374741 [1] https://aur.archlinux.org/account/ArchangeGabriel/
Hi Bruno, Nice to see a fellow beets lover apply! Your PKGBUILDs look nice and tidy, you'll most likely fit right in :) You piqued my interest with bs1770gain, any idea how it fares speed-wise against the default gstreamer backend? I kept using wine + foobar2000 to compute my replaygain values even after transitioning to beets because it's infinitely faster than using gstreamer. Cheers, -- Maxime January 8, 2017 4:42 PM, "Bruno Pagani via aur-general" <aur-general@archlinux.org> wrote:
Le 07/01/2017 à 16:05, NicoHood a écrit :
Hey Bruno, nice to hear that you want to join the great ArchLinux project as TU. I am aware the discussion period has not started yet, but I think its fine if I already give some feedback.
Hi Nico,
You’ve been very fast indeed, but the discussion period started right after anyway. ;)
I've checked your PKGBUILDs and I've noted a few thinks (which I also did wrong or sometimes forget). Those are mostly only concerning security aspects which I find important. If you followed the recent discussion you might have noticed that some people differ from this opinion. Please take it as a kind notice for you, use it if you wish :)
* For github download .tar.gz is preferred over .zip in general if i am not wrong.
Assuming you refer to audiothumbs-frameworks and ring-kde, I wasn’t aware GitHub was providing .tar.gz downloads for snapshots tarballs (they are not provided in the UI), but I admit not having tried a simple substitution of file extension, which indeed works. Strange lack of curiosity from my part. I’ve fixed both of them, thanks!
* Prefix your source download with: ${pkgname}-${pkgver}.tar.xz:: if you have a common SRCDIR. I also recently change to a common src dir, as too many packages blow my directories.
Can you please specify which package(s) you have in mind here? I’ve just checked again and didn’t found any package where I don’t do this and upstream tarball doesn’t follow this either.
* You can use https for sourceforge downloads soon/now[1] (bs1770gain)
Yes, and that is already what I do. Maybe you’ve overlooked or are talking of “Upstream URL” (in which case this doesn’t work).
* Thanks for using sha256sums. You may want to use the even stronger sha512sums, as it does not hurt to use stronger hashes *duck*
Stronger is relative (they’re mathematically the sames, breaking one in an applicable way probably means breaking both). Does not hurt too. Everything has been said around this in this list some months ago, I’ll not start that debate again. I’ll only provide sha512 if this is what upstream provides or a new policy going that way is adopted by ArchLinux, which currently isn’t the case AFAIK.
* certbot-user: the gpg keys should have a comment with the owner of the trusted keys (as you did with exfalso, but with email)
Sure, fixed. :) I’ve also fixed it in scribus-devel where it has apparently escaped your review. ;)
* mpd-{sserver,}minimal uses a sha1sum. If its an upstream hash please contact them to use stronger hashes and include a stronger one as well. You can use multiple hashes in the PKGBUILD (as in weboob-headless).
Like most of my -light or -minimal packages, hashes are from the repo package. When they are upstream ones too (KDE packages notably), I verify them, but here it’s not the case AFAIK. Those packages also use a PGP key, so I could remove the sum altogether as the wiki proposes. But actually this is one almost valid use case where I agree on switching to stronger checksum: packages being on AUR, and AUR being full of people that don’t understand PGP and its support in makepkg, the use of --skippgpcheck is probably frequent. Then, even if this is not a behaviour to be encouraged, having a strong verified checksum here is probably better for those users. I’ve thus switched them to sha256sums. That way, people relying on PGP still get the full verification, while people skipping it get a checksum that I’ve computed after PGP verification of the same tarball.
* powerdevil/spectacle-light uses http downloads. Even though gpg signatures are used, it would be nice to have https available anyways. It seems kde missconfigured their download subdomain for https, so you might want to contact them about that?
Yes, KDE doesn’t provides https at the moment. I’ve reported a bug upstream[0] (failed to find any open or close one relating to this).
* What I also do is to put my own GPG ID inside my PKGBUILDs, so people can simpler verify/find my key. Just as an idea.
What purpose does that serve (outside of cluttering the PKGBUILD)? My fingerprint is already in my AUR account profile[1] for that matter.
* For those projects who dont use GPG signatures yet, you might want to kindly contact them. I've written a script + instructions for using gpg along with a template to contact upstreams[2]. You might want to check it out.
And I don’t like it. Because (good) PGP is not easy, and PGP signatures for the sake of PGP signatures are not a good idea. If you want to be able to trust a sig, you need to trust the key and the behaviour of his owner regarding PGP. And I won’t trust a sig issued by someone that only did it to satisfy you, rather than deeply thought about it and its implications. Also, automated is rarely a good idea when it comes to PGP.
* If you want to move whipper, please consider to take part in the discussion about gpg[3]. Please dont take it personally, some people found them personally offended, while this was not the intention. You have the chance to also speak up for stronger security. I do not want to end this in an offtopic discussion, maybe you can help too ;)
Done. But as you might have expected since last paragraph, didn’t went your way.
Regards, Bruno
[0] https://bugs.kde.org/show_bug.cgi?id=374741 [1] https://aur.archlinux.org/account/ArchangeGabriel
-- Maxime
Le 08/01/2017 à 19:19, Maxime Gauduin a écrit :
Hi Bruno,
Hi Maxime,
Nice to see a fellow beets lover apply! Your PKGBUILDs look nice and tidy, you'll most likely fit right in :)
Thanks! :)
You piqued my interest with bs1770gain, any idea how it fares speed-wise against the default gstreamer backend? I kept using wine + foobar2000 to compute my replaygain values even after transitioning to beets because it's infinitely faster than using gstreamer.
I admit having never looked at it from a performance POV, I was mostly interested on avoiding the gstreamer dependency tree. I’ll test that tonight if I have time to do so or tomorrow if not, by removing values from my whole collection and adding them again through beets. However, quoting the beets doc[0], you should probably not expect miracles: “This can be a slow process”. But keep tuned. ;) And if that is the sole reason you have wine and thus multilib on your system, I’ll be more than happy if I can make it possible for you to get ride of them. :) Regards, Bruno [0] https://beets.readthedocs.io/en/latest/plugins/replaygain.html
Den 09-01-2017 kl. 20:15 skrev Bruno Pagani via aur-general:
Le 08/01/2017 à 19:19, Maxime Gauduin a écrit :
You piqued my interest with bs1770gain, any idea how it fares speed-wise against the default gstreamer backend? I kept using wine + foobar2000 to compute my replaygain values even after transitioning to beets because it's infinitely faster than using gstreamer.
I admit having never looked at it from a performance POV, I was mostly interested on avoiding the gstreamer dependency tree. I’ll test that tonight if I have time to do so or tomorrow if not, by removing values from my whole collection and adding them again through beets. However, quoting the beets doc[0], you should probably not expect miracles: “This can be a slow process”. But keep tuned. ;)
Veering slightly off-topic for a second, beets might actually be moving somewhat away from bs1770gain at some point in the future: https://botbot.me/freenode/beets/msg/79152052/ https://chatlogs.metabrainz.org/brainzbot/musicbrainz/msg/3784688/ -- Namasté, Frederik “Freso” S. Olesen <https://freso.dk/> AUR: https://aur.archlinux.org/account/Freso Wiki: https://wiki.archlinux.org/index.php/User:Freso
Le 10/01/2017 à 20:48, Frederik “Freso” S. Olesen via aur-general a écrit :
Den 09-01-2017 kl. 20:15 skrev Bruno Pagani via aur-general:
Le 08/01/2017 à 19:19, Maxime Gauduin a écrit :
You piqued my interest with bs1770gain, any idea how it fares speed-wise against the default gstreamer backend? I kept using wine + foobar2000 to compute my replaygain values even after transitioning to beets because it's infinitely faster than using gstreamer. I admit having never looked at it from a performance POV, I was mostly interested on avoiding the gstreamer dependency tree. I’ll test that tonight if I have time to do so or tomorrow if not, by removing values from my whole collection and adding them again through beets. However, quoting the beets doc[0], you should probably not expect miracles: “This can be a slow process”. But keep tuned. ;) Veering slightly off-topic for a second, beets might actually be moving somewhat away from bs1770gain at some point in the future: https://botbot.me/freenode/beets/msg/79152052/ https://chatlogs.metabrainz.org/brainzbot/musicbrainz/msg/3784688/
Good to know. :) I agree that Peter Balkner (bs1770gain dev) is someone to avoid regarding his political opinion (I had already seen the “Trump” line, but the new one from today is also interesting…), and I especially reject the use of bs1770gain page/changelog to promote them, but if we start to reject every piece of software based on who wrote it, we’re gonna have some troubles I think… Anyway, while this gets implemented in beets, I’ll stick with bs1770gain, but I wont hesitate to make the switch to this new tool (and package it) if it performs at least similarly for my usage. I’ll still continue to maintain bs1770gain for a while even if that happens, because for now regainer[0] seems not to support ATSC A/85 for instance and more generally has way less features, among which some might be of interest to specific Arch users. Anyway, thanks for mentioning it, and I’ve added two IRC channels to my “places to be” list. ;) Regards, Bruno [0] https://github.com/kepstin/regainer
Le 08/01/2017 à 19:19, Maxime Gauduin a écrit :
You piqued my interest with bs1770gain, any idea how it fares speed-wise against the default gstreamer backend? I kept using wine + foobar2000 to compute my replaygain values even after transitioning to beets because it's infinitely faster than using gstreamer.
Hi again, So, after a little bug fix[0], I ran `time beet replaygain -a` (so Album mode, which I expected to be your use case) command on my newly imported (with `-A`and into a new library for this test purpose) incoming folder, which has the following stats: Tracks: 2556 Total time: 1.1 weeks Approximate total size: 102.0 GiB Artists: 150 Albums: 176 Album artists: 56 And here is the output of the `time` command: beet replaygain -a 2775,24s user 32,68s system 80% cpu 58:00,41 total Note this is on a HDD, which I heard spinning a lot during all the process. So results on a SSD might differ, I could test that this WE if you want, but here we can say roughly 1s per track. How does it compare to your workflow? Cheers, Bruno [0] https://github.com/beetbox/beets/issues/2382
January 10, 2017 10:31 PM, "Bruno Pagani via aur-general" <aur-general@archlinux.org> wrote:
Le 08/01/2017 à 19:19, Maxime Gauduin a écrit :
You piqued my interest with bs1770gain, any idea how it fares speed-wise against the default gstreamer backend? I kept using wine + foobar2000 to compute my replaygain values even after transitioning to beets because it's infinitely faster than using gstreamer.
Hi again,
So, after a little bug fix[0], I ran `time beet replaygain -a` (so Album mode, which I expected to be your use case) command on my newly imported (with `-A`and into a new library for this test purpose) incoming folder, which has the following stats: Tracks: 2556 Total time: 1.1 weeks Approximate total size: 102.0 GiB Artists: 150 Albums: 176 Album artists: 56
And here is the output of the `time` command: beet replaygain -a 2775,24s user 32,68s system 80% cpu 58:00,41 total
Note this is on a HDD, which I heard spinning a lot during all the process. So results on a SSD might differ, I could test that this WE if you want, but here we can say roughly 1s per track.
How does it compare to your workflow?
Thanks for doing the testing, I too did some tests on my server over a sample of 373 representative files (flac, m4a, mp3). HDD as well but I only had 15MB/s of disk I/O so it's definitely CPU bound. Here are the results: gstreamer -> roughly 4s per track bs1770gain -> roughly 3s per track bs1770gain is definitely faster, but right now I'm using fb2k over the network where it takes 0.4s per track. Mind you, my desktop has a much more powerful CPU, and fb2k actually uses several threads which afaict beets does not. I'm quite sure I can divide the time it takes on my server by 4 using threads as well which would make beets a viable alternative, I'll look into it when I'm more familiar with ayncio. Also found out about the volumedetect filter of ffmpeg, but I'd need to document myself more about replaygain and its variants to make good use of the output.
Cheers, Bruno
Cheers, -- Maxime
Let the games begin, good luck! Bartłomiej
On 2017-01-07 16:18, Bartłomiej Piotrowski wrote:
Let the games begin, good luck!
Bartłomiej
Unless I'm a victim of some time-space distortions, 5 days of discussion period has passed. Link to the voting for the lazy: https://aur.archlinux.org/tu/?id=90 Bartłomiej
On 2017-01-13 09:54, Bartłomiej Piotrowski wrote:
On 2017-01-07 16:18, Bartłomiej Piotrowski wrote:
Let the games begin, good luck!
Bartłomiej
Unless I'm a victim of some time-space distortions, 5 days of discussion period has passed.
Link to the voting for the lazy: https://aur.archlinux.org/tu/?id=90
Bartłomiej
A shy reminder that less than 24 hours are left to vote. Be a part of voting history and help to beat participation percentage since it's actually tracked! The 100th customer gets a ponyduck. Bartłomiej
On 2017-01-13 09:54, Bartłomiej Piotrowski wrote:
On 2017-01-07 16:18, Bartłomiej Piotrowski wrote:
Let the games begin, good luck!
Bartłomiej
Unless I'm a victim of some time-space distortions, 5 days of discussion period has passed.
Link to the voting for the lazy: https://aur.archlinux.org/tu/?id=90
Bartłomiej
The vote has ended. Yes: 33 No: 3 Abstain: 7 Participation: 93.33% (awesome!) Congratulations Bruno! Please follow steps described on the Trusted User page[1]. [1] https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines
Le 20/01/2017 à 11:11, Bartłomiej Piotrowski a écrit :
On 2017-01-13 09:54, Bartłomiej Piotrowski wrote:
On 2017-01-07 16:18, Bartłomiej Piotrowski wrote:
Let the games begin, good luck!
Bartłomiej
Unless I'm a victim of some time-space distortions, 5 days of discussion period has passed.
Link to the voting for the lazy: https://aur.archlinux.org/tu/?id=90
Bartłomiej
The vote has ended.
Yes: 33 No: 3 Abstain: 7 Participation: 93.33% (awesome!)
Congratulations Bruno! Please follow steps described on the Trusted User page[1].
[1] https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines
Thanks everyone for this warm welcoming! :) I’m going through the TODO. Cheers, Bruno
Bruno Pagani via aur-general <aur-general@archlinux.org> on Sat, 2017/01/07 15:32:
Outside of those, they are other packages I might want to maintain in the future but I felt those above would make a good start. I might just add uchardet[9], because it’s now needed for mpv[10], and I’m OK to maintain it if Christian Hesse (eworm) doesn’t want to.
We have package uchardet in [extra] already [0], maintained by Felix Yan. (The uchardet package in AUR confused me as well... Deleted it.) I updated mpv with support for uchardet on Saturday evening [1] (and remove dependency to enca later on). [0] https://www.archlinux.org/packages/?name=uchardet [1] https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/mpv&id=8c1e195e31193d57c887c62ec052488b4f0f34b5 -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
Le 09/01/2017 à 08:57, Christian Hesse a écrit :
Bruno Pagani via aur-general <aur-general@archlinux.org> on Sat, 2017/01/07 15:32:
Outside of those, they are other packages I might want to maintain in the future but I felt those above would make a good start. I might just add uchardet[9], because it’s now needed for mpv[10], and I’m OK to maintain it if Christian Hesse (eworm) doesn’t want to. We have package uchardet in [extra] already [0], maintained by Felix Yan. (The uchardet package in AUR confused me as well... Deleted it.)
To be fair, uchardet is only in extra since friday, so this wasn’t the case when I wrote (most of) my application, and I admit that I didn’t checked between that point and when I posted yesterday, especially since the related issue had seen no comment and I didn’t received any notification related to uchardet package in AUR prior to that (so expected it to still not be in [community]). ;)
I updated mpv with support for uchardet on Saturday evening [1] (and remove dependency to enca later on).
Seen that from the notifications about uchardet and the issue. ;) Thanks, that’s also one less thing I must think about when building mpv-light using devtools. :) Regards, Bruno
Bruno Pagani <bruno.n.pagani@gmail.com> on Mon, 2017/01/09 20:20:
Le 09/01/2017 à 08:57, Christian Hesse a écrit :
Bruno Pagani via aur-general <aur-general@archlinux.org> on Sat, 2017/01/07 15:32:
Outside of those, they are other packages I might want to maintain in the future but I felt those above would make a good start. I might just add uchardet[9], because it’s now needed for mpv[10], and I’m OK to maintain it if Christian Hesse (eworm) doesn’t want to. We have package uchardet in [extra] already [0], maintained by Felix Yan. (The uchardet package in AUR confused me as well... Deleted it.)
To be fair, uchardet is only in extra since friday, so this wasn’t the case when I wrote (most of) my application, and I admit that I didn’t checked between that point and when I posted yesterday, especially since the related issue had seen no comment and I didn’t received any notification related to uchardet package in AUR prior to that (so expected it to still not be in [community]). ;)
Ah, Felix and me worked on this in parallel... :-p I do not want to blame you for anything, he fooled me as well. ;) -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
On 01/07/2017 03:32 PM, Bruno Pagani via aur-general wrote:
Hi everyone,
Hi Bruno o/
Do not hesitate if you have any questions on anything or any comments regarding my AUR packages. ;)
sure, I'm dumping some random thoughts... but its mostly just minor foo :) audiothumbs-frameworks: - a pkgver() function could be handy when using commit hashes, that helps avoiding to manually keep pkgver parts in sync (like r5 part before the partial hash) certbot-user: - I have no clue, but is it really that strictly tied to python2-acme? - I think it may change at some point, but right now like every python package i know does -O1 on install - you could also do a --skip-build when building separately in the build() function exfalso: - I think it may change at some point, but right now like every python package i know does -O1 on install - you could also do a --skip-build when building separately in the build() function mpd-server-minimal: - maybe sed-ing the mpd.service.in in a prepare() would be nicer then after processing/install in the package() function ring-kde: - a pkgver() function could be handy when using commit hashes, that helps avoiding to manually keep pkgver parts in sync (like 2.3.0.r287 part before the partial hash) weboob-headless: - I think it may change at some point, but right now like every python package i know does -O1 on install cheers, Levente
On 01/10/2017 04:11 PM, Levente Polyak wrote:
audiothumbs-frameworks: - a pkgver() function could be handy when using commit hashes, that helps avoiding to manually keep pkgver parts in sync (like r5 part before the partial hash)
[...]
ring-kde: - a pkgver() function could be handy when using commit hashes, that helps avoiding to manually keep pkgver parts in sync (like 2.3.0.r287 part before the partial hash)
Oh, just after sending the mail i realized that you pull those commits via tarball... well guess that won't work that easily except if you use git checkouts for it :D cheers, Levente
Le 10/01/2017 à 16:15, Levente Polyak a écrit :
On 01/10/2017 04:11 PM, Levente Polyak wrote:
audiothumbs-frameworks: - a pkgver() function could be handy when using commit hashes, that helps avoiding to manually keep pkgver parts in sync (like r5 part before the partial hash)
[...]
ring-kde: - a pkgver() function could be handy when using commit hashes, that helps avoiding to manually keep pkgver parts in sync (like 2.3.0.r287 part before the partial hash) Oh, just after sending the mail i realized that you pull those commits via tarball... well guess that won't work that easily except if you use git checkouts for it :D
Yes, the whole point here is was to avoid cloning the repo and having git in makedepends. So, no pkgver function here, and it will stay my job to update this var correctly. ;) That being said, audiothumbs-frameworks is not likely to see another commit any time soon and ring-kde should switch to versionned released again at some (not too far) point, so this is no big deal. :) Regards, Bruno
On 01/10/2017 10:11 AM, Levente Polyak wrote:
certbot-user: - I think it may change at some point, but right now like every python package i know does -O1 on install
Details on that changing? I haven't seen any discussion anywhere. Arch doesn't seem to have an explicit policy listed anywhere, why I am not sure, but the Python Packaging Policies for other distros that I have seen all seem to agree that pyc and pyo files are both mandatory. e.g. : - RPM -- should be created with `python -m compileall ...; python -O -m compileall ...` when necessary, or rather an arcane macro provided by the packaging tool. - DEB -- is a linting error, should be created/updated by post-install hooks and when the system python is updated, and removed by pre-remove hooks.
- you could also do a --skip-build when building separately in the build() function
I do this myself, although I have seen a lot of packages that don't -- I think I first saw it in python-setuptools. Bikesheddably useful :o on the grounds that package() should never have to do the work of build(). You'll notice that this makes the installation step no longer report an empty attempt to run build, build_py before install, install_py.
mpd-server-minimal: - maybe sed-ing the mpd.service.in in a prepare() would be nicer then after processing/install in the package() function
That, plus learning to use the "-e" flag to pass multiple sed patterns rather than using multiple sed invocations on a single file. -- Eli Schwartz
On 10/01, Eli Schwartz via aur-general wrote:
On 01/10/2017 10:11 AM, Levente Polyak wrote:
certbot-user: - I think it may change at some point, but right now like every python package i know does -O1 on install
Details on that changing? I haven't seen any discussion anywhere.
Arch doesn't seem to have an explicit policy listed anywhere, why I am not sure, but the Python Packaging Policies for other distros that I have seen all seem to agree that pyc and pyo files are both mandatory. e.g. : - RPM -- should be created with `python -m compileall ...; python -O -m compileall ...` when necessary, or rather an arcane macro provided by the packaging tool. - DEB -- is a linting error, should be created/updated by post-install hooks and when the system python is updated, and removed by pre-remove hooks.
https://wiki.archlinux.org/index.php/Python_package_guidelines is the closest we have to official policy. -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/
Le 10/01/2017 à 18:38, Eli Schwartz via aur-general a écrit :
On 01/10/2017 10:11 AM, Levente Polyak wrote:
mpd-server-minimal: - maybe sed-ing the mpd.service.in in a prepare() would be nicer then after processing/install in the package() function That, plus learning to use the "-e" flag to pass multiple sed patterns rather than using multiple sed invocations on a single file.
Thanks, I’ve learned something more today. ;) Bruno
Le 10/01/2017 à 16:11, Levente Polyak a écrit :
On 01/07/2017 03:32 PM, Bruno Pagani via aur-general wrote:
Hi everyone, Hi Bruno o/
Hi Levente,
Do not hesitate if you have any questions on anything or any comments regarding my AUR packages. ;) sure, I'm dumping some random thoughts... but its mostly just minor foo :)
I had started wondering whether I’d be deprived of it. ;)
audiothumbs-frameworks: - a pkgver() function could be handy when using commit hashes, that helps avoiding to manually keep pkgver parts in sync (like r5 part before the partial hash)
Answering that to your other email.
certbot-user: - I have no clue, but is it really that strictly tied to python2-acme?
AFAIK, currently yes, cerbot and python-acme being developed together and thus tightly connected. You can see that at the bottom of the PyPi page[0]. This might change at some point when things will have stabilized a lot, but that’s not for today (even if it breaks AUR helpers).
- I think it may change at some point, but right now like every python package i know does -O1 on install
Not certbot[1]. ;p But sure, added.
- you could also do a --skip-build when building separately in the build() function
Sure, done. :)
exfalso: - I think it may change at some point, but right now like every python package i know does -O1 on install - you could also do a --skip-build when building separately in the build() function
Both done (and updated to 3.8 btw).
mpd-server-minimal: - maybe sed-ing the mpd.service.in in a prepare() would be nicer then after processing/install in the package() function
Changed, including Eli suggestion.
ring-kde: - a pkgver() function could be handy when using commit hashes, that helps avoiding to manually keep pkgver parts in sync (like 2.3.0.r287 part before the partial hash)
Same as audiothumbs-frameworks. ;)
weboob-headless: - I think it may change at some point, but right now like every python package i know does -O1 on install
Done (+ updated to 1.2). Thanks for this thorough review. ;) Regards, Bruno [0] https://pypi.python.org/pypi/certbot
participants (9)
-
Bartłomiej Piotrowski
-
Bruno Pagani
-
Christian Hesse
-
Eli Schwartz
-
Frederik “Freso” S. Olesen
-
Johannes Löthberg
-
Levente Polyak
-
Maxime Gauduin
-
NicoHood