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" <[email protected]> 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
