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/

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

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

January 10, 2017 10:31 PM, "Bruno Pagani via aur-general" 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

[0] https://github.com/beetbox/beets/issues/2382

Cheers, -- Maxime

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

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

Bruno Pagani on Mon, 2017/01/09 20:20:

Le 09/01/2017 à 08:57, Christian Hesse a écrit :

...

Bruno Pagani via aur-general 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/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

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

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