TU Application: Bruno Pagani

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

TU Application: Bruno Pagani

tur-users mailing list
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



signature.asc (531 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application: Bruno Pagani

NicoHood-3
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


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application: Bruno Pagani

Bartłomiej Piotrowski-3
In reply to this post by tur-users mailing list
Let the games begin, good luck!

Bartłomiej


signature.asc (537 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application: Bruno Pagani

tur-users mailing list
In reply to this post by NicoHood-3
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/


signature.asc (531 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application: Bruno Pagani

Maxime Gauduin-2
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" <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: TU Application: Bruno Pagani

Christian Hesse
In reply to this post by tur-users mailing list
Bruno Pagani via aur-general <[hidden email]> 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);}

attachment0 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application: Bruno Pagani

tur-users mailing list
In reply to this post by Maxime Gauduin-2
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


signature.asc (531 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application: Bruno Pagani

tur-users mailing list
In reply to this post by Christian Hesse
Le 09/01/2017 à 08:57, Christian Hesse a écrit :

> Bruno Pagani via aur-general <[hidden email]> 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


signature.asc (531 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application: Bruno Pagani

Christian Hesse
Bruno Pagani <[hidden email]> on Mon, 2017/01/09 20:20:

> Le 09/01/2017 à 08:57, Christian Hesse a écrit :
>
> > Bruno Pagani via aur-general <[hidden email]> 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);}

attachment0 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application: Bruno Pagani

Levente Polyak-3
In reply to this post by tur-users mailing list
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


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application: Bruno Pagani

Levente Polyak-3
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


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application: Bruno Pagani

tur-users mailing list
In reply to this post by Levente Polyak-3
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


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application: Bruno Pagani

tur-users mailing list
In reply to this post by tur-users mailing list
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


signature.asc (879 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application: Bruno Pagani

tur-users mailing list
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


signature.asc (531 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application: Bruno Pagani

tur-users mailing list
In reply to this post by Maxime Gauduin-2
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


signature.asc (531 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application: Bruno Pagani

tur-users mailing list
In reply to this post by tur-users mailing list
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/

signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application: Bruno Pagani

tur-users mailing list
In reply to this post by Levente Polyak-3
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


signature.asc (531 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application: Bruno Pagani

tur-users mailing list
In reply to this post by Levente Polyak-3
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


signature.asc (531 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application: Bruno Pagani

tur-users mailing list
In reply to this post by tur-users mailing list
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


signature.asc (531 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application: Bruno Pagani

Maxime Gauduin-2
In reply to this post by tur-users mailing list
January 10, 2017 10:31 PM, "Bruno Pagani via aur-general" <[hidden email]> 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
12