Re: [aur-general] TU Application: Morten Linderud

2017-09-10 Thread Jelle van der Waa
On 09/05/17 at 02:12pm, Jelle van der Waa wrote:
> On 09/05/17 at 02:07pm, Morten Linderud wrote:
> > Hello Archers and Arch overlords!
> > 
> > # Introduction:
> > My name is Morten Linderud, or better known by Foxboron. I'm writing this
> > application to join the TU team. My sponsor is Jelle van der Waa.
> 
> I confirm the sponsorship of Morten!
> 
> Let the discussion period begin!

Let the voting period begin!

https://aur.archlinux.org/tu/?id=95

-- 
Jelle van der Waa


signature.asc
Description: PGP signature


Re: [aur-general] TU Application: Alad Wenter

2017-09-10 Thread Alad Wenter via aur-general
Sorry, there was a fluke with enigmail that prevented a corrected
signature. This one should however work.

Alad


Am 10/09/2017 um 15:16 schrieb Alad Wenter via aur-general:
> Hello everyone,
>
> My name is Alad Wenter, and I would like to apply for a position as Trusted 
> User. I’m a student in Germany, majoring in Mathematics with a focus on 
> Algebraic Topology. Many thanks to Johannes Löthberg who is sponsoring my TU 
> application.
>
> I’ve been using Linux since late 2013, as the EOL of Windows XP was 
> approaching. My first steps were taken via Linux Mint, gradually moving to 
> Debian in both Stable and Unstable variants.
>
> I have started using Arch in middle 2014, after being convinced that “I 
> should just install Arch” on a different forum. Since then I have become an 
> ArchWiki Bureaucrat (since May 2016) and IRC Operator (since February 2017) 
> for the #archlinux channel on freenode.
>  
> Amongst others, I helped complete the long-standing merge of the Beginners’ 
> Guide [1], vastly extended the comparison of third-party AUR scripts on the 
> “AUR Helper” article, [2] and improved coordination amongst users through a 
> new #archlinux-wiki freenode channel. [3] Other activities include the Arch 
> forums [4], Bug tracker [5], and submitting requests on the AUR.
>
> [1] 
> https://lists.archlinux.org/pipermail/arch-dev-public/2016-July/028140.html
> [2] https://wiki.archlinux.org/index.php/AUR_helpers#Comparison_table
> [3] https://wiki.archlinux.org/index.php/ArchWiki:IRC
> [4] https://bbs.archlinux.org/profile.php?id=81752
> [5] https://bugs.archlinux.org/user/18684
>
> For software development, I am familiar with the Bash and C++ languages, and 
> have published a few projects related to Arch, such as aurutils. [6] Where 
> possible, I try to coordinate with upstream authors if I encounter any issues 
> with their projects (for example, [7])
>
> [6] https://github.com/AladW/
> [7] https://github.com/i3/i3/issues/2597
>
> If I were to become a Trusted User, I would like to move the following AUR 
> packages to community:
>
> - datamash
> - dmenu-extended
> - eid-mw
> - innoextract
> - mit-scheme
> - physlock
> - polkit-explorer
> - python-i3
> - qpdfview
> - wimlib
>
> I have opened a repository with modifications from the original AUR packages 
> to better suit them as candidates for [community]. [8]
>
> [8] https://github.com/AladW/community
>
> I would further adopt the following orphans in community:
>
> - cabextract
> - gpick
> - sigil
> - sshfs
> - udevil
> - usbview
>
> Cheers,
>
> Alad
>



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Alad Wenter

2017-09-10 Thread Johannes Löthberg via aur-general
Quoting Alad Wenter via aur-general (2017-09-10 15:16:57)
> Hello everyone,
> 
> My name is Alad Wenter, and I would like to apply for a position as Trusted 
> User. I’m a student in Germany, majoring in Mathematics with a focus on 
> Algebraic Topology. Many thanks to Johannes Löthberg who is sponsoring my TU 
> application.
> 
> I’ve been using Linux since late 2013, as the EOL of Windows XP was 
> approaching. My first steps were taken via Linux Mint, gradually moving to 
> Debian in both Stable and Unstable variants.
> 
> I have started using Arch in middle 2014, after being convinced that “I 
> should just install Arch” on a different forum. Since then I have become an 
> ArchWiki Bureaucrat (since May 2016) and IRC Operator (since February 2017) 
> for the #archlinux channel on freenode.
>  
> Amongst others, I helped complete the long-standing merge of the Beginners’ 
> Guide [1], vastly extended the comparison of third-party AUR scripts on the 
> “AUR Helper” article, [2] and improved coordination amongst users through a 
> new #archlinux-wiki freenode channel. [3] Other activities include the Arch 
> forums [4], Bug tracker [5], and submitting requests on the AUR.
> 
> [1] 
> https://lists.archlinux.org/pipermail/arch-dev-public/2016-July/028140.html
> [2] https://wiki.archlinux.org/index.php/AUR_helpers#Comparison_table
> [3] https://wiki.archlinux.org/index.php/ArchWiki:IRC
> [4] https://bbs.archlinux.org/profile.php?id=81752
> [5] https://bugs.archlinux.org/user/18684
> 
> For software development, I am familiar with the Bash and C++ languages, and 
> have published a few projects related to Arch, such as aurutils. [6] Where 
> possible, I try to coordinate with upstream authors if I encounter any issues 
> with their projects (for example, [7])
> 
> [6] https://github.com/AladW/
> [7] https://github.com/i3/i3/issues/2597
> 
> If I were to become a Trusted User, I would like to move the following AUR 
> packages to community:
> 
> - datamash
> - dmenu-extended
> - eid-mw
> - innoextract
> - mit-scheme
> - physlock
> - polkit-explorer
> - python-i3
> - qpdfview
> - wimlib
> 
> I have opened a repository with modifications from the original AUR packages 
> to better suit them as candidates for [community]. [8]
> 
> [8] https://github.com/AladW/community
> 
> I would further adopt the following orphans in community:
> 
> - cabextract
> - gpick
> - sigil
> - sshfs
> - udevil
> - usbview
> 
> Cheers,
> 
> Alad
> 

I confirm my sponsorship and such.  Let the discussion period begin!

-- 
Sincerely,
  Johannes Löthberg
  PGP Key ID: 0x50FB9B273A9D0BB5
  PGP Key FP: 5134 EF9E AF65 F95B 6BB1  608E 50FB 9B27 3A9D 0BB5
  https://theos.kyriasis.com/~kyrias/


signature.asc
Description: signature


[aur-general] TU Application: Alad Wenter

2017-09-10 Thread Alad Wenter via aur-general
Hello everyone,

My name is Alad Wenter, and I would like to apply for a position as Trusted 
User. I’m a student in Germany, majoring in Mathematics with a focus on 
Algebraic Topology. Many thanks to Johannes Löthberg who is sponsoring my TU 
application.

I’ve been using Linux since late 2013, as the EOL of Windows XP was 
approaching. My first steps were taken via Linux Mint, gradually moving to 
Debian in both Stable and Unstable variants.

I have started using Arch in middle 2014, after being convinced that “I should 
just install Arch” on a different forum. Since then I have become an ArchWiki 
Bureaucrat (since May 2016) and IRC Operator (since February 2017) for the 
#archlinux channel on freenode.
 
Amongst others, I helped complete the long-standing merge of the Beginners’ 
Guide [1], vastly extended the comparison of third-party AUR scripts on the 
“AUR Helper” article, [2] and improved coordination amongst users through a new 
#archlinux-wiki freenode channel. [3] Other activities include the Arch forums 
[4], Bug tracker [5], and submitting requests on the AUR.

[1] https://lists.archlinux.org/pipermail/arch-dev-public/2016-July/028140.html
[2] https://wiki.archlinux.org/index.php/AUR_helpers#Comparison_table
[3] https://wiki.archlinux.org/index.php/ArchWiki:IRC
[4] https://bbs.archlinux.org/profile.php?id=81752
[5] https://bugs.archlinux.org/user/18684

For software development, I am familiar with the Bash and C++ languages, and 
have published a few projects related to Arch, such as aurutils. [6] Where 
possible, I try to coordinate with upstream authors if I encounter any issues 
with their projects (for example, [7])

[6] https://github.com/AladW/
[7] https://github.com/i3/i3/issues/2597

If I were to become a Trusted User, I would like to move the following AUR 
packages to community:

- datamash
- dmenu-extended
- eid-mw
- innoextract
- mit-scheme
- physlock
- polkit-explorer
- python-i3
- qpdfview
- wimlib

I have opened a repository with modifications from the original AUR packages to 
better suit them as candidates for [community]. [8]

[8] https://github.com/AladW/community

I would further adopt the following orphans in community:

- cabextract
- gpick
- sigil
- sshfs
- udevil
- usbview

Cheers,

Alad



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Morten Linderud

2017-09-08 Thread Jeremy Audet via aur-general
> > python-vagrant:
> > - test cases could be run
> > - you could distribute the LICENSE.MIT file as MIT is not a common
>
> The testing is sorta peculiar as it requires vagrant and virtualbox(!) to
run.
> Haven't gotten the cases to run after installing them so I have to work a
bit
> more on this.

Vagrant can work with a number of backends. The default one is virtualbox,
but you can also use libvirt, vmware, etc. So if you want to avoid using
virtualbox, consider something like a per-user libvirt session. I don't
know anything about python-vagrant in particular, though, so I could be off
the rails here.


Re: [aur-general] TU Application: Morten Linderud

2017-09-06 Thread Levente Polyak
On 09/06/2017 02:07 AM, Morten Linderud wrote:
>> bmusb:
>> - would me more error prone and convenient to keep pkgver in sync when
>>   using a pkgver() function for pinned commits and f.e. do:
>>   git describe --always | sed 's/^v//;s/-/./g'
>> - url variable points to a 403 page
>>
> Fixed apart from the pkgver(). Not sure about the intention of keeping the
> pkgver in sync with the commit hash. 

Well if you switch the commit you obviously need to manually also change
the pkgver -- which is annoying, more work and error prone as it can be
forgotten or "lie". If you have a pkgver() function its as easy as
changing the commit and fire up the build.
Random example in the repository:
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/baobab

If its not fully in sync with a tag, doing so will also add info like
which hash and how many commits on top of latest tag. I really recommend
doing this when using commit hashes.

> 
> Thanks again anthraxx and eschwartz for the comprehensive reviews!
> 

You are welcome :)

cheers,
Levente



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Morten Linderud

2017-09-06 Thread Morten Linderud
On Wed, Sep 06, 2017 at 10:14:34AM +0200, Florian Pritz via aur-general wrote:
> On 05.09.2017 14:07, Morten Linderud wrote:
> > signoff[2] is a tool I have written that helps testers with signing off on
> > packages they have installed from testing. It comes with neat 
> > auto-completions
> > and enough commands that it should replace the signoff page. Several 
> > testers are
> > using this to signoff packages in the testing repositories.
> 
> I've once wrote something similar[1]. I haven't used it lately, but it
> still seems to work. I could have probably done a better job at
> promoting it.
>
I believe i was made aware of your script after i started writing this, it's
pretty neat

> Looking at your script, it's mostly the same, except you send a HEAD
> request before fetching the signoff json. Since that json is probably
> generated on demand, the HEAD request creates nearly equal load to a
> normal one, minus actually sending and possibly compressing the json.
> After all, the server needs to generate the page to know how long the
> content is.
> 
> It's possible that archweb caches the generated json and my hunch is
> wrong, but it might be worth looking at that.
> 
> What can really reduce load are the ETag and/or If-Modified-Since
> headers, but I don't know if archweb supports those.
> 
The caching issue has crossed my mind a few times. I disabled compression on
the HEAD request as it was added after i wrote the machanism, and it broke the
content-length check.

I'll take a look at the ETag/If-Modified-Since headers, thanks!

> Also the get_packages function has a "tries" parameter that doesn't
> appear to be used in any way.
> 
Hurm, unsure why that was added. Thanks for the heads up.

-- 
Morten Linderud

PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature


Re: [aur-general] TU Application: Morten Linderud

2017-09-06 Thread Florian Pritz via aur-general
On 05.09.2017 14:07, Morten Linderud wrote:
> signoff[2] is a tool I have written that helps testers with signing off on
> packages they have installed from testing. It comes with neat auto-completions
> and enough commands that it should replace the signoff page. Several testers 
> are
> using this to signoff packages in the testing repositories.

I've once wrote something similar[1]. I haven't used it lately, but it
still seems to work. I could have probably done a better job at
promoting it.

Looking at your script, it's mostly the same, except you send a HEAD
request before fetching the signoff json. Since that json is probably
generated on demand, the HEAD request creates nearly equal load to a
normal one, minus actually sending and possibly compressing the json.
After all, the server needs to generate the page to know how long the
content is.

It's possible that archweb caches the generated json and my hunch is
wrong, but it might be worth looking at that.

What can really reduce load are the ETag and/or If-Modified-Since
headers, but I don't know if archweb supports those.

Also the get_packages function has a "tries" parameter that doesn't
appear to be used in any way.

[1] https://git.server-speed.net/users/flo/bin/tree/signoffs.pl

Florian



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Morten Linderud

2017-09-05 Thread Morten Linderud
On Tue, Sep 05, 2017 at 05:33:09PM +0200, Levente Polyak wrote:
> > During last years Chaos Communication Congress I got in touch with anthraxx 
> > and
> > shibumi. They introduced me to their security meet up along with jelle and
> > rgacogne. This ended up with me assisting the reviewing of security 
> > advisories,
> > and i have now added as a CVE reporter to the team.
> > 
> 
> I can confirm that this happened, and we are happy to have you around
> for security stuff.
> 
Thank you for everything!

> Now, i'm going to take a look at your AUR... Let the hunt begin *giggle*
> 
D:

> archur-git:
> - VCS package missing provides/conflicts
> 
Fixed!

> bmusb:
> - would me more error prone and convenient to keep pkgver in sync when
>   using a pkgver() function for pinned commits and f.e. do:
>   git describe --always | sed 's/^v//;s/-/./g'
> - url variable points to a 403 page
> 
Fixed apart from the pkgver(). Not sure about the intention of keeping the
pkgver in sync with the commit hash. 


> buildah-git:
> - VCS package missing provides/conflicts
> - license can be changed to 'Apache' as that is already in common
>   licences and points to version 2.0
> - clone URL could use TLS via git+https
> 
Fixed!

> cryptomator:
> - cryptomator.sh should use quotes for $PATH as it may contain spaces
> 
Fixed!

> cubemap:
> - VCS package missing provides/conflicts
> - source name must contain something unique for current tarball like
>   commit hash otherwise it collides with an existing download of a
>   previous version and just fails on checksum matching
> - fails to build: configure: error: Package requirements (libsystemd)
> were not met, seems to require it
> 
It's not a VCS package. So a little unsure what you mean with that. Rest was
fixed with eschwartz comments. Just forgot to push.

> dep-git:
> - VCS package missing provides/conflicts
> - clone URL could use TLS via git+https
> - use quotes for $PATH and $GOPATH as it could contain spaces
> 
Fixed!

> dmenu-extended:
> - VCS package not named dmenu-extended-git, either rename or
>   use a pinned commit (you promised that a year ago in the
>   comments *giggle* :P :D )
> - python packages should have a build function as its building
>   binary artifacts via setup.py and named function is needed in
>   the future to make py packages reproducible
> 
Fixed! Deletion request has been sent to the old package.

> jottalib:
> - uses static string in the source v0.5.1.tar.gz that can be replaced
>   by $pkgver
> - not an 'any' arch as it builds binary artifacts
> - seems to contain lot of test cases run by travis, maybe try to include
> 
Fixed. The test cases will have to wait a little as it refers to "python"
instead of "python2", along with being hard forked quite recently.

> molecule
> - URL pin-points to 2.0.0.rc12 (which isn't even used anymore)
> - would me more error prone and convenient to keep pkgver in sync when
>   using a pkgver() function for pinned commits and f.e. do:
>   git describe --always | sed 's/^v//;s/-/./g'
> - test cases could be run via tox
> - could build docs like txt and man via sphinx in doc folder
> - outdated since 20 hours, 2.0.4 release *giggle*
> 
Fixed, apart from the pkgver and this library needs itself installed to generate
docs. Need to figure out how this is done.

> nageru
> - 1.6.2 has been released
> 
Upstream dev forgot to update the archive on the page. Bugged him and got it 
fixed.

> protege-distribution:
> - try to build from source rather then redistribute precompiled binary
>   blobs
> 
Fixed!

> nodejs-how2:
> - could possibly be pulled via TLS https because why not :P
> - npm install package should forcefully fixup $pkgdir/usr file/dirs
>   as its a non-deterministic race condition bug that upstream still
>   fails to find and fix. It can lead to node_modules dir being world
>   writable and it contains code, f.e. line 26 :
> 
> https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/uglify-js#n26
> 
> 
All fixed!

> nerd-fonts-git:
> - VCS package missing provides/conflicts
> 
Fixed!

> python-anyconfig:
> - uses setuptools entrypoint functionality and therefor must hard depend
>   on python{,2}-setuptools instead of just makedepends
> - you could distribute the LICENSE.MIT file as MIT is not a common
>   included license
> - you could run tests via tox
> 
Fixed!

> python-gilt
> - package_python2-gilt() must depend on python2 instead of python
>   and python2-giturlparse instead of python-giturlparse
> - test cases could be run via tox, therefor all py2+3 dependencies
>   should be added to checkdepends and tox be invoked
> - could build docs like txt and man via sphinx in doc folder
> 
Fixed.
The documentation requires gilt installed to be generated. So unsure how that
should be done. I have to look closer at this.

> python-marshmallow:
> - test cases could be run via tox, therefor all py2+3 dependencies
>   should be added to checkdepends and tox be invoked
> - could bu

Re: [aur-general] TU Application: Morten Linderud

2017-09-05 Thread Eli Schwartz
On 09/05/2017 11:33 AM, Levente Polyak wrote:
> Now, i'm going to take a look at your AUR... Let the hunt begin *giggle*

[...]

Some of these were already fixed on Github but not pushed to the AUR.
And some things were already promised!

-- 
$ ztrawhcse > https://paste.xinu.at/YG9vhIHsD/



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Morten Linderud

2017-09-05 Thread Levente Polyak
On 09/05/2017 02:07 PM, Morten Linderud wrote:
> Hello Archers and Arch overlords!
> 
> # Introduction:
> My name is Morten Linderud, or better known by Foxboron. I'm writing this
> application to join the TU team. My sponsor is Jelle van der Waa.


Yay :)


> During last years Chaos Communication Congress I got in touch with anthraxx 
> and
> shibumi. They introduced me to their security meet up along with jelle and
> rgacogne. This ended up with me assisting the reviewing of security 
> advisories,
> and i have now added as a CVE reporter to the team.
> 

I can confirm that this happened, and we are happy to have you around
for security stuff.

Now, i'm going to take a look at your AUR... Let the hunt begin *giggle*


archur-git:
- VCS package missing provides/conflicts

bmusb:
- would me more error prone and convenient to keep pkgver in sync when
  using a pkgver() function for pinned commits and f.e. do:
  git describe --always | sed 's/^v//;s/-/./g'
- url variable points to a 403 page

buildah-git:
- VCS package missing provides/conflicts
- license can be changed to 'Apache' as that is already in common
  licences and points to version 2.0
- clone URL could use TLS via git+https

cryptomator:
- cryptomator.sh should use quotes for $PATH as it may contain spaces

cubemap:
- VCS package missing provides/conflicts
- source name must contain something unique for current tarball like
  commit hash otherwise it collides with an existing download of a
  previous version and just fails on checksum matching
- fails to build: configure: error: Package requirements (libsystemd)
were not met, seems to require it

dep-git:
- VCS package missing provides/conflicts
- clone URL could use TLS via git+https
- use quotes for $PATH and $GOPATH as it could contain spaces

dmenu-extended:
- VCS package not named dmenu-extended-git, either rename or
  use a pinned commit (you promised that a year ago in the
  comments *giggle* :P :D )
- python packages should have a build function as its building
  binary artifacts via setup.py and named function is needed in
  the future to make py packages reproducible

jottalib:
- uses static string in the source v0.5.1.tar.gz that can be replaced
  by $pkgver
- not an 'any' arch as it builds binary artifacts
- seems to contain lot of test cases run by travis, maybe try to include

molecule
- URL pin-points to 2.0.0.rc12 (which isn't even used anymore)
- would me more error prone and convenient to keep pkgver in sync when
  using a pkgver() function for pinned commits and f.e. do:
  git describe --always | sed 's/^v//;s/-/./g'
- test cases could be run via tox
- could build docs like txt and man via sphinx in doc folder
- outdated since 20 hours, 2.0.4 release *giggle*

nageru
- 1.6.2 has been released

protege-distribution:
- try to build from source rather then redistribute precompiled binary
  blobs

nodejs-how2:
- could possibly be pulled via TLS https because why not :P
- npm install package should forcefully fixup $pkgdir/usr file/dirs
  as its a non-deterministic race condition bug that upstream still
  fails to find and fix. It can lead to node_modules dir being world
  writable and it contains code, f.e. line 26 :

https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/uglify-js#n26


nerd-fonts-git:
- VCS package missing provides/conflicts

python-anyconfig:
- uses setuptools entrypoint functionality and therefor must hard depend
  on python{,2}-setuptools instead of just makedepends
- you could distribute the LICENSE.MIT file as MIT is not a common
  included license
- you could run tests via tox

python-gilt
- package_python2-gilt() must depend on python2 instead of python
  and python2-giturlparse instead of python-giturlparse
- test cases could be run via tox, therefor all py2+3 dependencies
  should be added to checkdepends and tox be invoked
- could build docs like txt and man via sphinx in doc folder

python-marshmallow:
- test cases could be run via tox, therefor all py2+3 dependencies
  should be added to checkdepends and tox be invoked
- could build docs like txt and man via sphinx in doc folder
- you could distribute the LICENSE.MIT file as MIT is not a common
- 2.13.6 has been released

python-vagrant:
- test cases could be run
- you could distribute the LICENSE.MIT file as MIT is not a common

python-testinfra:
- test cases could be run via pytest and included in checkdepends
- PBR_VERSION will fail if run with noextract as prepare() is skipped

python2-humanize:
- python packages should have a build function as its building
  binary artifacts via setup.py and named function is needed in
  the future to make py packages reproducible
- it depends on python while this is a python2 package
- test cases and docs can be used if github sources are fetched instead

python-rofi:
- should use prefixed source with $pkgname and $pkgver to have a unique
  file per version and package as it may conflict with a global source
  dest setup

pyt

Re: [aur-general] TU Application: Morten Linderud

2017-09-05 Thread Morten Linderud
On Tue, Sep 05, 2017 at 10:02:27AM -0400, Eli Schwartz wrote:
> On 09/05/2017 08:07 AM, Morten Linderud wrote:
> > Hello Archers and Arch overlords!
> > 
> > # Introduction:
> > My name is Morten Linderud, or better known by Foxboron. I'm writing this
> > application to join the TU team. My sponsor is Jelle van der Waa.
> 
> Of course you need to show everyone what kind of packager you are. ;)
> 
> In preparation for meeting the xarrhtna linter, we have spent much time
> fixing Foxboron's packages. Time to invent more rules I guess!
> 
> git clone https://github.com/Foxboron/PKGBUILDS
> cd PKGBUILDS
> git diff 87c1186..a948c2a
> 

Yes, i spent somewhat 4 hours on fixing PKGBUILDs after an extensive review 
from Eli.
Should have been disclosed i guess.

> Good luck, by the way! :)
> (After all the time I invested here, don't you dare even think about
> failing!)
> 

Thanks :))

-- 
Morten Linderud

PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature


Re: [aur-general] TU Application: Morten Linderud

2017-09-05 Thread Eli Schwartz
On 09/05/2017 08:07 AM, Morten Linderud wrote:
> Hello Archers and Arch overlords!
> 
> # Introduction:
> My name is Morten Linderud, or better known by Foxboron. I'm writing this
> application to join the TU team. My sponsor is Jelle van der Waa.

Of course you need to show everyone what kind of packager you are. ;)

In preparation for meeting the xarrhtna linter, we have spent much time
fixing Foxboron's packages. Time to invent more rules I guess!

git clone https://github.com/Foxboron/PKGBUILDS
cd PKGBUILDS
git diff 87c1186..a948c2a

Good luck, by the way! :)
(After all the time I invested here, don't you dare even think about
failing!)

-- 
Eli Schwartz



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Morten Linderud

2017-09-05 Thread Jelle van der Waa
On 09/05/17 at 02:07pm, Morten Linderud wrote:
> Hello Archers and Arch overlords!
> 
> # Introduction:
> My name is Morten Linderud, or better known by Foxboron. I'm writing this
> application to join the TU team. My sponsor is Jelle van der Waa.

I confirm the sponsorship of Morten!

Let the discussion period begin!

-- 
Jelle van der Waa


signature.asc
Description: PGP signature


[aur-general] TU Application: Morten Linderud

2017-09-05 Thread Morten Linderud
Hello Archers and Arch overlords!

# Introduction:
My name is Morten Linderud, or better known by Foxboron. I'm writing this
application to join the TU team. My sponsor is Jelle van der Waa.


# About me:
I'm 23 years, and currently live in Bergen, Norway. I have a bachelors degree in
Information science, and currently working towards a masters degree in the same
field. I also work part-time with infrastructure and devops at a small company 
called
Apility.

I have been active with FOSS since 2012, and have contributed to several tools
and projects. The most notable is probably Hylang[1] where I have been a core
developer since 2013.

In my spare time I enjoy playing guitar, learning photography, attending
conferences and volunteer work for LAN-parties, the local Game Jam and student
organizations "Beer and Programming", where we drink beer and discuss
programming, and Fribyte, hosting and misc IT-services for student organizations
in Bergen where i'm currently second in charge.


# Arch Linux related:
Arch Linux has been my daily driver since 2013, although I have worked with
Linux and Ubuntu for few years prior as a secondary OS. I have maintained AUR
packages since 2015, adopting orphaned packages and created new ones. 

During last years Chaos Communication Congress I got in touch with anthraxx and
shibumi. They introduced me to their security meet up along with jelle and
rgacogne. This ended up with me assisting the reviewing of security advisories,
and i have now added as a CVE reporter to the team.

I have also been added to the tester team, and done small contributions on the
Archwiki and security-tracker, along with tedious amounts of rambling on
#archlinux-offtopic.^W^W^W^W^W^W^W^W^W^W^W^W^W^W


# TU pledges:
As a TU I'll move the following packages from the AUR to community:
- protege
- ttf-font-awesome
- cryptomator
- pass-otp
- nageru

And adopt the following packages from community:
- rofi
- go-md2man
- python-xapp
- python-send2trash 
- python-pycountry
- python-autobahn

I would also love to help out with Python and Go packages.


# Other projects:
signoff[2] is a tool I have written that helps testers with signing off on
packages they have installed from testing. It comes with neat auto-completions
and enough commands that it should replace the signoff page. Several testers are
using this to signoff packages in the testing repositories.

I have also worked on other tools that may benefit the Arch Linux community in
the future. Most notable is a tool that could solve the remote GPG signing issue
that was discussed on pacman-dev in 2011[3], with no solutions back then. I
currently have a point of concept written in golang that could support this[4].
The end goal is to create an API and signing tool.

The other project is a package build system[5] that uses docker as an OS
abstraction, and builds packages proper with chroots inside. It builds on top of
buildbot[6]. It's far from feature complete, but the plan is to support
distributed package building, and dispatch rebuilds based on dependencies. I
have been using it to manage my own AUR packages.


Thanks for reading, and may the tacos be with you.


# Links:
[1]: http://docs.hylang.org/en/stable/
[2]: https://github.com/Foxboron/archweb-signoff-helper
[3]: https://lists.archlinux.org/pipermail/pacman-dev/2011-June/01.html
[4]: https://github.com/Foxboron/remote-sign
[5]: https://github.com/Foxboron/arch-auto-build
[6]: https://buildbot.net/

--
Morten Linderud

PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature


Re: [aur-general] TU Application: Dan Printzell

2017-08-08 Thread Johannes Löthberg via aur-general
Quoting Johannes Löthberg (2017-08-01 14:29:38)
> Quoting Johannes Löthberg (2017-07-27 22:58:58)
> > I confirm my sponsorship, let the discussion period begin!
> > 
> 
> The discussion period is over, and the voting period starts now!
> 
> TUs can cast their votes here: https://aur.archlinux.org/tu/?id=94
> 

The vote has been closed, and you have been accepted as a TU Wild!

Results:

* Yes: 42
* No: 2
* Abstain: 10
* Total: 39

Congrats Wild!

-- 
Sincerely,
  Johannes Löthberg
  PGP Key ID: 0x50FB9B273A9D0BB5
  PGP Key FP: 5134 EF9E AF65 F95B 6BB1  608E 50FB 9B27 3A9D 0BB5
  https://theos.kyriasis.com/~kyrias/


Re: [aur-general] TU Application: Dan Printzell

2017-08-01 Thread Johannes Löthberg via aur-general
Quoting Johannes Löthberg (2017-07-27 22:58:58)
> I confirm my sponsorship, let the discussion period begin!
> 

The discussion period is over, and the voting period starts now!

TUs can cast their votes here: https://aur.archlinux.org/tu/?id=94

-- 
Sincerely,
  Johannes Löthberg
  PGP Key ID: 0x50FB9B273A9D0BB5
  PGP Key FP: 5134 EF9E AF65 F95B 6BB1  608E 50FB 9B27 3A9D 0BB5
  https://theos.kyriasis.com/~kyrias/


Re: [aur-general] TU Application: Dan Printzell

2017-07-31 Thread Doug Newgard
On Mon, 31 Jul 2017 14:16:33 -0400
Eli Schwartz  wrote:

> On 07/31/2017 02:09 PM, Christian Rebischke wrote:
> >> Do I really need to do this? Won't the 'git submodule update' command 
> >> choose the
> >> correct commit?  
> > 
> > May somebody else correct me, but I don't think so. `git submodule
> > update` will just update to the HEAD of the sub repository. And we want
> > stable builds. Therefore it's important to pin the software at a
> > specific commit and it's dependencies, too.  
> 
> You're both right and wrong. "$srcdir/$submodulename" will be at
> origin/master, but `git submodule update` in the primary repo will
> completely ignore that clone altogether and just cares about the git
> objects which it uses in yet another clone.
> 

This is a bit confusing. You set the URL of the submodule to the location of
the local clone, so it doesn't ignore it, it just clones from the local clone.
And yes, it does use the specific commit specified in the main repo, so setting
#commit= for the submodule is useless.


Re: [aur-general] TU Application: Dan Printzell

2017-07-31 Thread Eli Schwartz
On 07/31/2017 02:09 PM, Christian Rebischke wrote:
>> Do I really need to do this? Won't the 'git submodule update' command choose 
>> the
>> correct commit?
> 
> May somebody else correct me, but I don't think so. `git submodule
> update` will just update to the HEAD of the sub repository. And we want
> stable builds. Therefore it's important to pin the software at a
> specific commit and it's dependencies, too.

You're both right and wrong. "$srcdir/$submodulename" will be at
origin/master, but `git submodule update` in the primary repo will
completely ignore that clone altogether and just cares about the git
objects which it uses in yet another clone.

-- 
Eli Schwartz



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Dan Printzell

2017-07-31 Thread Florian Bruhin
On Mon, Jul 31, 2017 at 08:09:56PM +0200, Christian Rebischke wrote:
> On Fri, Jul 28, 2017 at 02:32:07PM +, Dan Printzell wrote:
> > Do I really need to do this? Won't the 'git submodule update' command 
> > choose the
> > correct commit?
> 
> May somebody else correct me, but I don't think so. `git submodule
> update` will just update to the HEAD of the sub repository. And we want
> stable builds. Therefore it's important to pin the software at a
> specific commit and it's dependencies, too.

No, it checks out the commit pinned in the superproject. 

Florian

-- 
https://www.qutebrowser.org  | m...@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072  | https://the-compiler.org/pubkey.asc
 I love long mails!  | https://email.is-not-s.ms/


signature.asc
Description: PGP signature


Re: [aur-general] TU Application: Dan Printzell

2017-07-31 Thread Christian Rebischke
On Fri, Jul 28, 2017 at 02:32:07PM +, Dan Printzell wrote:
> I could maintain other packages as well, but I would prioritize my D packages.

Thats what I wanted to hear :)

> Do I really need to do this? Won't the 'git submodule update' command choose 
> the
> correct commit?

May somebody else correct me, but I don't think so. `git submodule
update` will just update to the HEAD of the sub repository. And we want
stable builds. Therefore it's important to pin the software at a
specific commit and it's dependencies, too.

> There is a -fPIC flag for dmd, I can enable this. I can also apply a patch to
> the other packages so they also use compile with -fPIC.

Awesome!


Best regards,

Chris


signature.asc
Description: PGP signature


Re: [aur-general] TU Application: Dan Printzell

2017-07-29 Thread Antonio Rojas
El Thu, 27 Jul 2017 20:52:10 +, Dan Printzell escribió:

> Hi Arch people.
> 
> My name is Dan Printzell, but I often go by Wild/Vild or when I use an old
> account, WildN00b. I'm writing this TU application because I want to maintain
> the dlang packages that are currently orphaned or being dropped from
> [community]. I'm being sponsored by Johannes Löthberg.

As the maintainer of the only (AFAIK) package in our repos written in D I must 
say I'm really looking forward to someone who actually cares maintaining the D 
stack, trying to keep it up to date in the latest months has been a real PITA.

You could start by investigating why dmd segfaults when building on i686 (I 
ended up dropping i686 entirely as to not block the update) 


Re: [aur-general] TU Application: Dan Printzell

2017-07-28 Thread Eli Schwartz
On 07/28/2017 05:49 AM, Bartłomiej Piotrowski wrote:
> On 2017-07-28 01:14, Christian Rebischke wrote:
>> Don't get that wrong, but I am wondering how much people this D-packages
>> really need. Do we have so much D programmers outside?
>
> Don't get me wrong, but I am wondering how much people use systemtap or
> playerctl? According to pkgstats it's not 2% and 5% and both aren't even
> listed in Stackoverflow!
>
>> Additionally some of the package that you want to move don't have so
>> much votes nor popularity.
>
> It never was a hard rule.

Yeah, even the rule itself always gave me the impression of being a
floor on what is okay for inclusion, since the repos shouldn't be filled
with packages no one actually uses other than the maintainer and like 2
other people in the world.

>> So I would like to know: Are you also interested in maintaing other
>> packages besides D specific packages? We have really a lot of orphans in
>> community.
>
> Will leave that to Dan to respond in detail but first, D toolchain is
> orphan anyway and second, it's fine to take care only of one area in
> repository.
>
>> 1. You want to surround $pkgname-$pkgver and $pkgver in your source with
>> double quotes:
>
> And I guess it has to be done because suddenly manually set variables
> will explode with whitespace?
I certainly hope that isn't a criteria for becoming a TU, given that I
see a pattern whereby repository PKGBUILDs start losing their quotes
around every variable that cannot have whitespace, as a specific style
approach of a number of Devs/TUs.

e.g. the *depends* license and arch arrays.

At least one TU even manually generates their checksums and inserts them
by hand without the single quotes `makepkg -g` creates.

...

And now the inconsistency is bothering me, because I don't think anyone
ever quotes the pkgver/pkgrel/epoch, and usually not the pkgname either,
so by rights we *shouldn't* quote the arch, make/depends, conflicts,
replaces, provides, *sums, validpgpgkeys, and some optdepends and
licenses either.

*looks at his AUR packages and shudders*

-- 
Eli Schwartz



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Dan Printzell

2017-07-28 Thread Dan Printzell

Excerpts from Dan Printzell's message of July 28, 2017 4:32 pm:

There is a -fPIC flag for dmd, I can enable this. I can also apply a patch to
the other packages so they also use compile with -fPIC.


I just saw that this flag was enabled by default for all compilations with dmd,
so no patch needed.

- Dan


pgpSMZThk7BHH.pgp
Description: PGP signature


Re: [aur-general] TU Application: Dan Printzell

2017-07-28 Thread Dan Printzell

(Sorry about the double reply Christian, I replyed to the wrong address)

Excerpts from Christian Rebischke's message of July 28, 2017 1:14 am:

Hello Dan,
Glad that you like to participate. Here are some questions + feedback to
your PKGBUILDs...

If I were to become a TU I would want to maintain all the dlang packages that
are orphaned in [community] [3]. I would also like to move these packages to
[community]:
- dcd [4]
- dfmt [5]
- dscanner [6]
- dub [7]
- workspace-d [8]


Don't get that wrong, but I am wondering how much people this D-packages
really need. Do we have so much D programmers outside? I never used that
language and according to some programming language popularity board
it's not that popular. (It's not under the big 20)[1]
Additionally some of the package that you want to move don't have so
much votes nor popularity.



dub is the default package manager for D and was dropped from [community] a
couple of days ago. So I really want to move it back to [community] again. DCD
was also dropped from [community] some time ago. DCD, dfmt and dscanner are
programs that most editors use to implement D support. So I would say that these
would really help the D community if they were in [community].

workspace-d would be nice if it were in [community] but I'll not move it unless
it gains more popularity. 


So I would like to know: Are you also interested in maintaing other
packages besides D specific packages? We have really a lot of orphans in
community.


I could maintain other packages as well, but I would prioritize my D packages.



Here is some feedback to your packages:


--- executing /usr/bin/xxarhtna 
- dcd
==



1. you want `#commit=` instead of `#tag=` in the source. Git tags are
variable so you need to pin it at a commit to make sure nobody changes
it after setting the git tag in your PKGBUILD.


Thanks, I will change that.


2. You want to also pin the commit for the other source repositories. So
for each repository pick a stable commit


Do I really need to do this? Won't the 'git submodule update' command choose the
correct commit?



- dfmt
==
3. You have a space at the end of your description (sorry for the
nut-picking)


np, I'll fix that


- dub
=

1. You want to surround $pkgname-$pkgver and $pkgver in your source with
double quotes:

source=("$pkgname-$pkgver.tar.gz::https://github.com/dlang/dub/archive/v$pkgver.tar.gz";)


Will do


2. You compile that binary with dmd.. so just out of curiosity: Does dmd
has any security features for their created binaries? Stuff like PIE?
Would be cool if you could enable that as well.


There is a -fPIC flag for dmd, I can enable this. I can also apply a patch to
the other packages so they also use compile with -fPIC.



Thats all. Thanks for your mail and sorry for the nut-picking.


Np, I appreciate all the help I can get.

- Dan

pgpnMysrkNPIP.pgp
Description: PGP signature


Re: [aur-general] TU Application: Dan Printzell

2017-07-28 Thread Jelle van der Waa
On 07/28/17 at 11:49am, Bartłomiej Piotrowski wrote:
> On 2017-07-28 01:14, Christian Rebischke wrote:
> > Don't get that wrong, but I am wondering how much people this D-packages
> > really need. Do we have so much D programmers outside?
> 
> Don't get me wrong, but I am wondering how much people use systemtap or
> playerctl? According to pkgstats it's not 2% and 5% and both aren't even
> listed in Stackoverflow!
> 
> > Additionally some of the package that you want to move don't have so
> > much votes nor popularity.
> 
> It never was a hard rule.
> 
> > So I would like to know: Are you also interested in maintaing other
> > packages besides D specific packages? We have really a lot of orphans in
> > community.
> 
> Will leave that to Dan to respond in detail but first, D toolchain is
> orphan anyway and second, it's fine to take care only of one area in
> repository.

Second that, I want D experts to maintain D packages instead of people
who don't know what they are doing :-)

-- 
Jelle van der Waa


signature.asc
Description: PGP signature


Re: [aur-general] TU Application: Dan Printzell

2017-07-28 Thread Bartłomiej Piotrowski
On 2017-07-28 01:14, Christian Rebischke wrote:
> Don't get that wrong, but I am wondering how much people this D-packages
> really need. Do we have so much D programmers outside?

Don't get me wrong, but I am wondering how much people use systemtap or
playerctl? According to pkgstats it's not 2% and 5% and both aren't even
listed in Stackoverflow!

> Additionally some of the package that you want to move don't have so
> much votes nor popularity.

It never was a hard rule.

> So I would like to know: Are you also interested in maintaing other
> packages besides D specific packages? We have really a lot of orphans in
> community.

Will leave that to Dan to respond in detail but first, D toolchain is
orphan anyway and second, it's fine to take care only of one area in
repository.

> 1. You want to surround $pkgname-$pkgver and $pkgver in your source with
> double quotes:

And I guess it has to be done because suddenly manually set variables
will explode with whitespace?

B


Re: [aur-general] TU Application: Dan Printzell

2017-07-27 Thread Christian Rebischke
Hello Dan,
Glad that you like to participate. Here are some questions + feedback to
your PKGBUILDs...
> If I were to become a TU I would want to maintain all the dlang packages that
> are orphaned in [community] [3]. I would also like to move these packages to
> [community]:
> - dcd [4]
> - dfmt [5]
> - dscanner [6]
> - dub [7]
> - workspace-d [8]

Don't get that wrong, but I am wondering how much people this D-packages
really need. Do we have so much D programmers outside? I never used that
language and according to some programming language popularity board
it's not that popular. (It's not under the big 20)[1]
Additionally some of the package that you want to move don't have so
much votes nor popularity.

So I would like to know: Are you also interested in maintaing other
packages besides D specific packages? We have really a lot of orphans in
community.

Here is some feedback to your packages:


--- executing /usr/bin/xxarhtna 
- dcd
==

1. you want `#commit=` instead of `#tag=` in the source. Git tags are
variable so you need to pin it at a commit to make sure nobody changes
it after setting the git tag in your PKGBUILD.
2. You want to also pin the commit for the other source repositories. So
for each repository pick a stable commit

- dfmt
==

1. Same for dfmt. You want to pin the commit not the tag.
2. Same for the other sources you want to pin to a stable commit.
3. You have a space at the end of your description (sorry for the
nut-picking)

- dnscanner
===

1. Same for dnscanner. You want to pin the commit not the tag.
2. Same for the other sources.

- dub
=

1. You want to surround $pkgname-$pkgver and $pkgver in your source with
double quotes:

source=("$pkgname-$pkgver.tar.gz::https://github.com/dlang/dub/archive/v$pkgver.tar.gz";)

2. You compile that binary with dmd.. so just out of curiosity: Does dmd
has any security features for their created binaries? Stuff like PIE?
Would be cool if you could enable that as well.

- workspace-d
=

1. You want to pin the commit instead of the tag.

-- end of xxarhtna output 


Thats all. Thanks for your mail and sorry for the nut-picking.

best regards,

chris


[1] https://www.tiobe.com/tiobe-index/





signature.asc
Description: PGP signature


Re: [aur-general] TU Application: Dan Printzell

2017-07-27 Thread Johannes Löthberg via aur-general
Quoting Dan Printzell (2017-07-27 22:52:10)
> Hi Arch people.
> 
> My name is Dan Printzell, but I often go by Wild/Vild or when I use an old
> account, WildN00b. I'm writing this TU application because I want to maintain
> the dlang packages that are currently orphaned or being dropped from
> [community]. I'm being sponsored by Johannes Löthberg.
> 
> A little about me. I'm 21 years old programmer from Sweden. I'm currently
> studying game programming at BTH. On my freetime I'm usually code on my
> operating system that I'm writing in D from scratch [1]. I usually stream
> this development on my twitch channel [2].
> 
> The first time I touched Linux I believe was back in '08, when I was about 12.
> I order those free CD with Ubuntu and played around with it a lot. After that
> I have been switching between Windows and Linux distroes as my main driver
> depending on if I wanted to be productive and code, or if wanted to play 
> games.
> I started to use Arch maybe 5-6 years ago, where the latest 4 years I have 
> been
> using it as my main driver for all my computers. I think I choose Arch because
> pacman made sense to me compared to apt-{get,cache,whatever}.
> 
> I created my first package about 3 years ago for my custom bar, but it is long
> gone after the AUR3 update. Around the same time I started to use dlang as my
> main language and I started to maintain a few -git packages for the different
> helper tools, and when the none -git packages got orphaned or dropped from
> [community] I took over them.
> 
> If I were to become a TU I would want to maintain all the dlang packages that
> are orphaned in [community] [3]. I would also like to move these packages to
> [community]:
> - dcd [4]
> - dfmt [5]
> - dscanner [6]
> - dub [7]
> - workspace-d [8]
> 
> 
> 
> TL;DR I use the D programming language, so I want to maintain it.
> 
> Thanks
>   Dan Printzell
>   GPG KEY: 0x22E3B67B4A86FDE7
>   https://github.com/Vild/
>   https://vild.io/
> 
> [1] https://github.com/PowerNex/PowerNex
> [2] http://twitch.tv/wildn00b/
> [3] https://www.archlinux.org/groups/x86_64/dlang/
> [4] https://aur.archlinux.org/packages/dcd/
> [5] https://aur.archlinux.org/packages/dfmt/
> [6] https://aur.archlinux.org/packages/dscanner/
> [7] https://aur.archlinux.org/packages/dub/
> [8] https://aur.archlinux.org/packages/workspace-d/
> 
> 
> 

I confirm my sponsorship, let the discussion period begin!

-- 
Sincerely,
  Johannes Löthberg
  PGP Key ID: 0x50FB9B273A9D0BB5
  PGP Key FP: 5134 EF9E AF65 F95B 6BB1  608E 50FB 9B27 3A9D 0BB5
  https://theos.kyriasis.com/~kyrias/


signature.asc
Description: signature


[aur-general] TU Application: Dan Printzell

2017-07-27 Thread Dan Printzell

Hi Arch people.

My name is Dan Printzell, but I often go by Wild/Vild or when I use an old
account, WildN00b. I'm writing this TU application because I want to maintain
the dlang packages that are currently orphaned or being dropped from
[community]. I'm being sponsored by Johannes Löthberg.

A little about me. I'm 21 years old programmer from Sweden. I'm currently
studying game programming at BTH. On my freetime I'm usually code on my
operating system that I'm writing in D from scratch [1]. I usually stream
this development on my twitch channel [2].

The first time I touched Linux I believe was back in '08, when I was about 12.
I order those free CD with Ubuntu and played around with it a lot. After that
I have been switching between Windows and Linux distroes as my main driver
depending on if I wanted to be productive and code, or if wanted to play games.
I started to use Arch maybe 5-6 years ago, where the latest 4 years I have been
using it as my main driver for all my computers. I think I choose Arch because
pacman made sense to me compared to apt-{get,cache,whatever}.

I created my first package about 3 years ago for my custom bar, but it is long
gone after the AUR3 update. Around the same time I started to use dlang as my
main language and I started to maintain a few -git packages for the different
helper tools, and when the none -git packages got orphaned or dropped from
[community] I took over them.

If I were to become a TU I would want to maintain all the dlang packages that
are orphaned in [community] [3]. I would also like to move these packages to
[community]:
- dcd [4]
- dfmt [5]
- dscanner [6]
- dub [7]
- workspace-d [8]



TL;DR I use the D programming language, so I want to maintain it.

Thanks
 Dan Printzell
 GPG KEY: 0x22E3B67B4A86FDE7
 https://github.com/Vild/
 https://vild.io/

[1] https://github.com/PowerNex/PowerNex
[2] http://twitch.tv/wildn00b/
[3] https://www.archlinux.org/groups/x86_64/dlang/
[4] https://aur.archlinux.org/packages/dcd/
[5] https://aur.archlinux.org/packages/dfmt/
[6] https://aur.archlinux.org/packages/dscanner/
[7] https://aur.archlinux.org/packages/dub/
[8] https://aur.archlinux.org/packages/workspace-d/





pgp2GlZEiKwFA.pgp
Description: PGP signature


Re: [aur-general] TU question

2017-07-24 Thread Giancarlo Razzolini

Em julho 24, 2017 12:03 Dan Printzell escreveu:


Would it count as a good bribe if I created a PKGBUILD that generates fresh 
tacos?


If it passes anthraxx's crive, why not?

pgp3WnttHw1x4.pgp
Description: PGP signature


Re: [aur-general] TU question

2017-07-24 Thread Dan Printzell

Excerpts from Xyne's message of July 24, 2017 3:54 pm:

Generously bribing existing TUs with fresh tacos can also help to swing the
vote in your favor. There's a lot of us now though so it will be expensive. The
TU system is basically a pyramid scheme. The earlier you get in, the more tacos
you net.



Would it count as a good bribe if I created a PKGBUILD that generates fresh 
tacos?


pgpbdUEkfRlKb.pgp
Description: PGP signature


Re: [aur-general] TU question

2017-07-24 Thread Xyne
On 2017-07-23 19:38 -0400
Eli Schwartz wrote:

>On 07/23/2017 07:08 PM, Dan Printzell wrote:
>> Hi, my name is Dan and I'm currently reading up on what is needed to become
>> a TU. I'm doing this because I'm interested in maintaining the dlang
>> packages, now that Dicebot left. But before I decide anything I want to know
>> what is needed from me and how the whole process works.
>> 
>> So far I've read these links:
>> https://wiki.archlinux.org/index.php/Trusted_Users
>> https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines
>> https://aur.archlinux.org/trusted-user/TUbylaws.html
>> 
>> So I was wondering if anyone had any links that I could read or any tips to
>> think about before I decide if I want to take the next step.  
>
>I believe that covers most of it. You should probably be prepared for
>anthraxx to go over your AUR packages with a fine-toothed comb looking
>for every conceivable mistake you could make though. :D
>
>Really, the main thrust of it is finding a TU to sponsor you, and making
>a good case as to what you want to accomplish as a TU and what your
>previous track record is in the Arch/FOSS community as a way to gauge
>what kind of maintainer you would be.
>
>In my experience lurking here, most people who can make a coherent
>argument for all those things tend to be accepted. Good luck! :)
>
>-- 
>Eli Schwartz
>

Generously bribing existing TUs with fresh tacos can also help to swing the
vote in your favor. There's a lot of us now though so it will be expensive. The
TU system is basically a pyramid scheme. The earlier you get in, the more tacos
you net.


Re: [aur-general] TU question

2017-07-23 Thread Eli Schwartz
On 07/23/2017 07:08 PM, Dan Printzell wrote:
> Hi, my name is Dan and I'm currently reading up on what is needed to become
> a TU. I'm doing this because I'm interested in maintaining the dlang packages,
> now that Dicebot left. But before I decide anything I want to know what is
> needed from me and how the whole process works.
> 
> So far I've read these links:
> https://wiki.archlinux.org/index.php/Trusted_Users
> https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines
> https://aur.archlinux.org/trusted-user/TUbylaws.html
> 
> So I was wondering if anyone had any links that I could read or any tips to
> think about before I decide if I want to take the next step.

I believe that covers most of it. You should probably be prepared for
anthraxx to go over your AUR packages with a fine-toothed comb looking
for every conceivable mistake you could make though. :D

Really, the main thrust of it is finding a TU to sponsor you, and making
a good case as to what you want to accomplish as a TU and what your
previous track record is in the Arch/FOSS community as a way to gauge
what kind of maintainer you would be.

In my experience lurking here, most people who can make a coherent
argument for all those things tend to be accepted. Good luck! :)

-- 
Eli Schwartz



signature.asc
Description: OpenPGP digital signature


[aur-general] TU question

2017-07-23 Thread Dan Printzell

Hi, my name is Dan and I'm currently reading up on what is needed to become
a TU. I'm doing this because I'm interested in maintaining the dlang packages,
now that Dicebot left. But before I decide anything I want to know what is
needed from me and how the whole process works.

So far I've read these links:
https://wiki.archlinux.org/index.php/Trusted_Users
https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines
https://aur.archlinux.org/trusted-user/TUbylaws.html

So I was wondering if anyone had any links that I could read or any tips to
think about before I decide if I want to take the next step.

Thanks
Dan Printzell

pgpFokZBXCGXT.pgp
Description: PGP signature


Re: [aur-general] TU Application: André Silva

2017-05-27 Thread André Silva
On 05/27/2017 11:27 AM, NicoHood wrote:
> Sorry Emulatorman, the majority of TUs did not vote for you. Maybe next
> time. Thanks for your effort on linux-libre and other projects on AUR
> and good luck for the future :)
> 
> Nico
> 

Don't worry Nico, thanks for your sponsorship and support, even all
those TUs participated and voted too. :)

Regards,
André.



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: André Silva

2017-05-27 Thread NicoHood
On 05/19/2017 04:18 PM, NicoHood wrote:
> On 05/13/2017 06:35 PM, André Silva wrote:
>> Hi all, I'm André Silva (known as Emulatorman) that was one of main
>> full-time Parabola devs between 2012-2017 [0] maintaining around 800
>> packages [1], mainly Linux-libre kernels and personal ones such as the
>> Linux-libre in combination with Knock [2], Grsecurity+Knock [3]. I will
>> happy to maintain some of my packages with the other TUs and my sponsor
>> (nicohood) in [community].
>>
>> The following packages that i would maintain are:
>>
>> * ath9k-htc-firmware
>> * linux-libre-firmware
>> * openfwwf
>> * linux-libre
>> * linux-libre-lts
>>
>> Regards,
>> André Silva
>>
>> GPG ID: C92B AA71 3B8D 53D3 CAE6  3FC9 E697 4752 F970 4456
>>
>> [0]:https://git.parabola.nu/hackers.git/tree/users/1007.yml
>> [1]:https://lists.parabola.nu/pipermail/dev/2017-April/005094.html
>> [2]:https://wiki.parabola.nu/Knock
>> [3]:https://wiki.parabola.nu/Grsecurity%2BKnock
>>
> 
> The discussion period is over, please give your vote in the aurweb
> Trusted User section:
> https://aur.archlinux.org/tu/?id=93
> 

Yes: 9
No: 27
Abstain: 6
Voted: 91.30%

Result: Rejected

Sorry Emulatorman, the majority of TUs did not vote for you. Maybe next
time. Thanks for your effort on linux-libre and other projects on AUR
and good luck for the future :)

Nico



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Thore Bödecker

2017-05-23 Thread Sébastien Luttringer
On Mon, 2017-05-22 at 14:06 +0200, Florian Pritz via aur-general wrote:
> On 15.05.2017 14:04, Florian Pritz via aur-general wrote:
> > The discussion period is now over. You can vote here:
> > 
> > https://aur.archlinux.org/tu/?id=92
> 
> Yes: 30
> No: 3
> Abstain: 9
> Voted: 91.30%
> 
> Result: Accepted
> 
> Congrats and welcome to the team!
> 
> Florian
> 

Welcome Thore.
-- 
Sébastien "Seblu" Luttringer




signature.asc
Description: This is a digitally signed message part


Re: [aur-general] TU Application: Thore Bödecker

2017-05-22 Thread Florian Pritz via aur-general
On 15.05.2017 14:04, Florian Pritz via aur-general wrote:
> The discussion period is now over. You can vote here:
> 
> https://aur.archlinux.org/tu/?id=92

Yes: 30
No: 3
Abstain: 9
Voted: 91.30%

Result: Accepted

Congrats and welcome to the team!

Florian



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: André Silva

2017-05-19 Thread NicoHood
On 05/13/2017 06:35 PM, André Silva wrote:
> Hi all, I'm André Silva (known as Emulatorman) that was one of main
> full-time Parabola devs between 2012-2017 [0] maintaining around 800
> packages [1], mainly Linux-libre kernels and personal ones such as the
> Linux-libre in combination with Knock [2], Grsecurity+Knock [3]. I will
> happy to maintain some of my packages with the other TUs and my sponsor
> (nicohood) in [community].
> 
> The following packages that i would maintain are:
> 
> * ath9k-htc-firmware
> * linux-libre-firmware
> * openfwwf
> * linux-libre
> * linux-libre-lts
> 
> Regards,
> André Silva
> 
> GPG ID: C92B AA71 3B8D 53D3 CAE6  3FC9 E697 4752 F970 4456
> 
> [0]:https://git.parabola.nu/hackers.git/tree/users/1007.yml
> [1]:https://lists.parabola.nu/pipermail/dev/2017-April/005094.html
> [2]:https://wiki.parabola.nu/Knock
> [3]:https://wiki.parabola.nu/Grsecurity%2BKnock
> 

The discussion period is over, please give your vote in the aurweb
Trusted User section:
https://aur.archlinux.org/tu/?id=93



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: André Silva

2017-05-19 Thread LoneVVolf

On 18-05-17 18:25, André Silva wrote:

Otherwise, i won't maintain more packages than linux-libre{,-lts} and
free firmware in Arch since i have another personal projects too. So i
would just help maintain my kernels in [community] as my contribution
for all users who loves use it.



Andre.

to me it looks like those goals could be achieved with AUR packages and 
an unofficial repo.


What other benefits would you becoming a TU bring for Arch Linux community ?

NOTE : i'm just an AL user


Lone_Wolf


Re: [aur-general] TU Application: André Silva

2017-05-18 Thread André Silva
On 05/18/2017 11:27 AM, Jelle van der Waa wrote:
> André, would love to see your response to the questions from Eli and
> Brtln.
> 

Hi Jelle, sorry about the delay to respond those emails, i didn't read
them until now :(

Here I go...

On 05/15/2017 11:12 AM, Bartłomiej Piotrowski wrote:
> On 2017-05-13 18:35, André Silva wrote:
>> * linux-libre
>> * linux-libre-lts
>
> The drama aside, why should we want to include a libre kernel in
> repositories, while as a whole, we don't really care about it? We
> package Flash, proprietary blobs for kernel, nvidia drivers, repackage
> projectsfrom prebuilt tarballs, pull non-free assets for games and so
> on. I really can't see this application in any other way than trying to
> annoy Parabola, even if you don't intend to be malicious.
>
> Bartłomiej
>

Hi Bartłomiej, i wouldn't try annoy Parabola and/or another distro, i
just would maintain linux-libre and linux-libre-lts plus free firmwares
in Arch for those users who loves uses it without blobs. Otherwise, it
will be helpful not only for Arch because Parabola and another distros
will benefit from it since they have a hard work making a lot of
packages [0], not just kernels, then it will save time for them to
maintain their projects too and it is a way to help to Arch and all
Arch-based distros with my contribution :)

[0]:https://git.parabola.nu/abslibre.git/tree/

On 05/15/2017 11:19 AM, Jelle van der Waa wrote:
> On 05/13/17 at 11:35pm, André Silva wrote:
>> On 05/13/2017 10:24 PM, Christian Rebischke wrote:
>>> Hello Andre,
>>> Can you tell us more about your position at parabola? Why did you quit
>>> the developer job for there and why do you want to be Arch Linux
>>> Trusted User now? This is no offense, I just want to know more about
>>> that part in your history.
>>>
>>> Best regards,
>>>
>>> Chris
>>>
>>
>> Hi Chris don't worry about your questions, it isn't a offense. :)
>
> Thanks for being so open about it, I appreciate it!
>
>> Currently, i'm dedicating my life to my family and friends than ever
>> before, however i would at least continuing maintaining some of my
>> kernels such as linux-libre and linux-libre-lts in Arch as TU in
>> [community] for the benefit of Arch the same as other Arch-based distros.
>
> Personally I have mixed feelings about yet another kernel in our
> repository's. I'm also wondering if you want to bring in more -libre
> packages? (And therfore making parabola obsolete).
>
> I'm fine with the current split between Arch and Parabola, since it
> makes it clear where Arch stands :)
>

Parabola is really more than a distro that only maintains/deblobs
kernels, you can see in their blacklist [0] and their project [1],
therefore it won't make Parabola obsolete, on the contrary, it will
benefit both (Arch and Parabola) and all Arch-based distros.

Otherwise, i won't maintain more packages than linux-libre{,-lts} and
free firmware in Arch since i have another personal projects too. So i
would just help maintain my kernels in [community] as my contribution
for all users who loves use it.

[0]:https://git.parabola.nu/blacklist.git/plain/blacklist.txt
[1]:https://wiki.parabola.nu/Parabola_Social_Contract



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: André Silva

2017-05-18 Thread Jelle van der Waa
On 05/15/17 at 11:14am, Eli Schwartz via aur-general wrote:
> On 05/15/2017 10:43 AM, NicoHood wrote:
> > Because there are people who don't use (much) proprietary software and
> > still want to benefit from Arch. We are not only a free distribution but
> > I think its a nice addition to have free kernels available. Also another
> > kernel maintainer can make the normal kernel testing faster than it is
> > now. I appreciate the work on free software and we should give users the
> > freedom of choice.
> 
> Not sure I understand this.
> 
> Anyone who chooses to use a libre kernel is presumably doing so because
> they believe in a moral argument against the use of proprietary blobs of
> any sort.
> It can be assumed that such a person doesn't want to use any of the
> other proprietary blobs we ship in the repos... however, it is not as
> though we somehow care about distinguishing between them, so anyone who
> chooses to use our repos would have to do a fair amount of work to
> *protect themselves against* the natural behavior of the Arch repos.
> 
> Parabola already perfectly fulfills this role on behalf of its users,
> and the only real benefit of shipping our own libre stuff is to give it
> the official Arch stamp of approval and thereby permit such individuals
> to receive support from the official Arch support Fora.
> 
> 
> As far as kernels go, I don't see how shipping another kernel and
> dividing our current users between 4 kernels instead of three kernels is
> supposed to make testing and signoffs of the three we have right now, go
> any faster. If anything, we will have some number less eyes on the stock
> kernel, ensuring we are less likely to catch errors with its specific
> configuration.
> One doesn't need to have push access to the package repositories in
> order to test the kernel...
> 
> ...
> 
> Obviously you all can do whatever you want, and maybe there are other
> reasons to choose to include André Silva among your number. But from
> where I am looking in from the sidelines, I simply don't see what
> non-Parabola-specific *values* he intends to bring with him to enhance
> the Arch Linux experience.
> 
> (From the Wiki)
> The minimum requirements to becoming a TU are as follows:
> ...
> a general idea of the kind of packages you want to maintain
> (basically, why do you want to become TU?)
> 
> If the answer to that question is merely "to subsume and obsolete
> Parabola", then I suddenly start being confused about the general
> direction of the Arch Linux project.
> 
> I feel sure I must be missing something, somewhere, somehow...
> 
> -- 
> Eli Schwartz
> 

André, would love to see your response to the questions from Eli and
Brtln.

-- 
Jelle van der Waa


signature.asc
Description: PGP signature


Re: [aur-general] TU Application: André Silva

2017-05-15 Thread Eli Schwartz via aur-general
On 05/15/2017 10:43 AM, NicoHood wrote:
> Because there are people who don't use (much) proprietary software and
> still want to benefit from Arch. We are not only a free distribution but
> I think its a nice addition to have free kernels available. Also another
> kernel maintainer can make the normal kernel testing faster than it is
> now. I appreciate the work on free software and we should give users the
> freedom of choice.

Not sure I understand this.

Anyone who chooses to use a libre kernel is presumably doing so because
they believe in a moral argument against the use of proprietary blobs of
any sort.
It can be assumed that such a person doesn't want to use any of the
other proprietary blobs we ship in the repos... however, it is not as
though we somehow care about distinguishing between them, so anyone who
chooses to use our repos would have to do a fair amount of work to
*protect themselves against* the natural behavior of the Arch repos.

Parabola already perfectly fulfills this role on behalf of its users,
and the only real benefit of shipping our own libre stuff is to give it
the official Arch stamp of approval and thereby permit such individuals
to receive support from the official Arch support Fora.


As far as kernels go, I don't see how shipping another kernel and
dividing our current users between 4 kernels instead of three kernels is
supposed to make testing and signoffs of the three we have right now, go
any faster. If anything, we will have some number less eyes on the stock
kernel, ensuring we are less likely to catch errors with its specific
configuration.
One doesn't need to have push access to the package repositories in
order to test the kernel...

...

Obviously you all can do whatever you want, and maybe there are other
reasons to choose to include André Silva among your number. But from
where I am looking in from the sidelines, I simply don't see what
non-Parabola-specific *values* he intends to bring with him to enhance
the Arch Linux experience.

(From the Wiki)
The minimum requirements to becoming a TU are as follows:
...
a general idea of the kind of packages you want to maintain
(basically, why do you want to become TU?)

If the answer to that question is merely "to subsume and obsolete
Parabola", then I suddenly start being confused about the general
direction of the Arch Linux project.

I feel sure I must be missing something, somewhere, somehow...

-- 
Eli Schwartz



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: André Silva

2017-05-15 Thread NicoHood
On 05/15/2017 01:12 PM, Bartłomiej Piotrowski wrote:
> On 2017-05-13 18:35, André Silva wrote:
>> * linux-libre
>> * linux-libre-lts
> 
> The drama aside, why should we want to include a libre kernel in
> repositories, while as a whole, we don't really care about it? We
> package Flash, proprietary blobs for kernel, nvidia drivers, repackage
> projectsfrom prebuilt tarballs, pull non-free assets for games and so
> on. I really can't see this application in any other way than trying to
> annoy Parabola, even if you don't intend to be malicious.
> 
> Bartłomiej
> 

Because there are people who don't use (much) proprietary software and
still want to benefit from Arch. We are not only a free distribution but
I think its a nice addition to have free kernels available. Also another
kernel maintainer can make the normal kernel testing faster than it is
now. I appreciate the work on free software and we should give users the
freedom of choice.



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Thore Bödecker

2017-05-15 Thread Florian Pritz via aur-general
On 10.05.2017 13:51, Florian Pritz via aur-general wrote:
> On 10.05.2017 13:49, Thore Boedecker via aur-general wrote:
>> My name is Thore Bödecker (a.k.a. foxxx0, or just foxxx depending on
>> nick availability) and finally I have taken the time increase my
>> involvement with Arch Linux. I'm 26 years old now and living in small
>> town called Falkensee, near Berlin in Germany.
>> 
>> First of all thanks to Florian Pritz (Bluewind) who is sponsoring my
>> TU application.
> I confirm my sponsorship. Let the discussion begin!

The discussion period is now over. You can vote here:

https://aur.archlinux.org/tu/?id=92

Florian



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: André Silva

2017-05-15 Thread Jelle van der Waa
On 05/13/17 at 11:35pm, André Silva wrote:
> On 05/13/2017 10:24 PM, Christian Rebischke wrote:
> > Hello Andre,
> > Can you tell us more about your position at parabola? Why did you quit
> > the developer job for there and why do you want to be Arch Linux
> > Trusted User now? This is no offense, I just want to know more about
> > that part in your history.
> > 
> > Best regards,
> > 
> > Chris
> > 
> 
> Hi Chris don't worry about your questions, it isn't a offense. :)

Thanks for being so open about it, I appreciate it!

> Currently, i'm dedicating my life to my family and friends than ever
> before, however i would at least continuing maintaining some of my
> kernels such as linux-libre and linux-libre-lts in Arch as TU in
> [community] for the benefit of Arch the same as other Arch-based distros.

Personally I have mixed feelings about yet another kernel in our
repository's. I'm also wondering if you want to bring in more -libre
packages? (And therfore making parabola obsolete).

I'm fine with the current split between Arch and Parabola, since it
makes it clear where Arch stands :)

-- 
Jelle van der Waa


signature.asc
Description: PGP signature


Re: [aur-general] TU Application: André Silva

2017-05-15 Thread Bartłomiej Piotrowski
On 2017-05-13 18:35, André Silva wrote:
> * linux-libre
> * linux-libre-lts

The drama aside, why should we want to include a libre kernel in
repositories, while as a whole, we don't really care about it? We
package Flash, proprietary blobs for kernel, nvidia drivers, repackage
projectsfrom prebuilt tarballs, pull non-free assets for games and so
on. I really can't see this application in any other way than trying to
annoy Parabola, even if you don't intend to be malicious.

Bartłomiej



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: André Silva

2017-05-13 Thread André Silva
On 05/13/2017 10:24 PM, Christian Rebischke wrote:
> Hello Andre,
> Can you tell us more about your position at parabola? Why did you quit
> the developer job for there and why do you want to be Arch Linux
> Trusted User now? This is no offense, I just want to know more about
> that part in your history.
> 
> Best regards,
> 
> Chris
> 

Hi Chris don't worry about your questions, it isn't a offense. :)

I was one of the full-time Parabola devs there, mainly i've been
maintaining around 90% packages in libre repo [0] and 100% in kernels
[1] and nonprism repos [2][3] for x86_64 and i686 only, except the
kernels packages that were maintained by me for all architectures
supported by Parabola (x86_64, i686 and armv7h).

However a couple days ago, i've posted an email in Parabola's dev lists
about some doubts related to Parabola'd donations [4]

For constants multiple personal attacks (ad hominem), but no substance
[5], causing an unnecessary division and this on going flamewar over
something that should have been simple, i've decided to say goodbye to
Parabola [6]

Currently, i'm dedicating my life to my family and friends than ever
before, however i would at least continuing maintaining some of my
kernels such as linux-libre and linux-libre-lts in Arch as TU in
[community] for the benefit of Arch the same as other Arch-based distros.

Regards,
André

[0]:https://wiki.parabola.nu/Repositories#libre
[1]:https://wiki.parabola.nu/Repositories#kernels
[2]:https://wiki.parabola.nu/Repositories#nonprism
[3]:https://wiki.parabola.nu/Nonprism
[4]:https://lists.parabola.nu/pipermail/dev/2017-April/004848.html
[5]:https://lists.parabola.nu/pipermail/dev/2017-April/004954.html
[6]:https://lists.parabola.nu/pipermail/dev/2017-April/005022.html



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: André Silva

2017-05-13 Thread Christian Rebischke
On Sat, May 13, 2017 at 04:35:37PM +, André Silva wrote:
> Hi all, I'm André Silva (known as Emulatorman) that was one of main
> full-time Parabola devs between 2012-2017 [0] maintaining around 800
> packages [..]

Hello Andre,
Can you tell us more about your position at parabola? Why did you quit
the developer job for there and why do you want to be Arch Linux
Trusted User now? This is no offense, I just want to know more about
that part in your history.

Best regards,

Chris


signature.asc
Description: PGP signature


Re: [aur-general] TU Application: Thore Bödecker

2017-05-13 Thread Thore Boedecker via aur-general
Hey,

just to be clear:
I did not and do not want to move any php56 related packages to the
Arch repo at any point.
It seems there was some confusion on that topic, so I have quoted the
important part from the original mail below:

On 10.05.17 - 13:49, Thore Boedecker via aur-general wrote:
> 
> The packages that I would like to move to [community], if the current
> maintainers agree, are:
>   - amavisd-new
>   - amavisd-milter
>   - perl-convert-tnef (required for amavisd-new)
>   - perl-convert-uulib (required for amavisd-new)
>   - libspf2
> 


Cheers,
Thore


signature.asc
Description: PGP signature


Re: [aur-general] TU Application: André Silva

2017-05-13 Thread NicoHood
On 05/13/2017 06:35 PM, André Silva wrote:
> Hi all, I'm André Silva (known as Emulatorman) that was one of main
> full-time Parabola devs between 2012-2017 [0] maintaining around 800
> packages [1], mainly Linux-libre kernels and personal ones such as the
> Linux-libre in combination with Knock [2], Grsecurity+Knock [3]. I will
> happy to maintain some of my packages with the other TUs and my sponsor
> (nicohood) in [community].
> 
> The following packages that i would maintain are:
> 
> * ath9k-htc-firmware
> * linux-libre-firmware
> * openfwwf
> * linux-libre
> * linux-libre-lts
> 
> Regards,
> André Silva
> 
> GPG ID: C92B AA71 3B8D 53D3 CAE6  3FC9 E697 4752 F970 4456
> 
> [0]:https://git.parabola.nu/hackers.git/tree/users/1007.yml
> [1]:https://lists.parabola.nu/pipermail/dev/2017-April/005094.html
> [2]:https://wiki.parabola.nu/Knock
> [3]:https://wiki.parabola.nu/Grsecurity%2BKnock
> 

I confirm the sponsorship of Emulatorman. Let the discussion period
begin. Good luck!



signature.asc
Description: OpenPGP digital signature


[aur-general] TU Application: André Silva

2017-05-13 Thread André Silva
Hi all, I'm André Silva (known as Emulatorman) that was one of main
full-time Parabola devs between 2012-2017 [0] maintaining around 800
packages [1], mainly Linux-libre kernels and personal ones such as the
Linux-libre in combination with Knock [2], Grsecurity+Knock [3]. I will
happy to maintain some of my packages with the other TUs and my sponsor
(nicohood) in [community].

The following packages that i would maintain are:

* ath9k-htc-firmware
* linux-libre-firmware
* openfwwf
* linux-libre
* linux-libre-lts

Regards,
André Silva

GPG ID: C92B AA71 3B8D 53D3 CAE6  3FC9 E697 4752 F970 4456

[0]:https://git.parabola.nu/hackers.git/tree/users/1007.yml
[1]:https://lists.parabola.nu/pipermail/dev/2017-April/005094.html
[2]:https://wiki.parabola.nu/Knock
[3]:https://wiki.parabola.nu/Grsecurity%2BKnock



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Thore Bödecker

2017-05-11 Thread Thore Boedecker via aur-general
On 11.05.17 - 12:13, Jeremy Audet via aur-general wrote:
> > And on my router at home.
> 
> Neat! What are you using for router hardware? I've done this as well. I
> used a desktop with ethernet and wifi expansion cards for several years,
> and then moved to a PC Engines apu2c2 .

At first it was an Intel Atom ITX board, then replaced by a Core i3
Haswell and finally I ended up with an apu2c4.
Storage is an internal 128gb mSATA SSD and WIFI is handled within 2
separate VLANs by a Unifi UAP-AC-Lite.
It is running really smooth and without any issues. At the moment I
even have two WAN uplinks and created some hooks for dhcpcd/pppd to
dynamically manage my routing tables and iptables rulesets.

> 
> It seems like you have a good set of system administration skills, as
> indicated by at least these statements:
> 
> > I ended up with Arch on my rented server as well.
> > I am also providing hosting services on that server to a small group of
> customers
> > I have been a co-maintainer of [php56] ever since and tried to push the
> security releases out as quickly as possible.
> > I am providing hosting services for customers I am also acting as an
> email service provider for my customers (and for myself too).
> > Apart from maintaining the mentioned packages I am also quite capable
> regarding server and service hosting and happy to assist in maintaining and
> improving the Arch Linux infrastructure. :)
> 
> Do you monitor PHP-related security issues? It sounds like you do, and if
> you're providing hosting services to customers, you probably should be. :-)
> Do you have any interest in sharing that knowledge by volunteering for the 
> Arch
> CVE monitoring team
> ? Nobody is
> specifically monitoring PHP issues.

Mainly I'm just subscribed to the *-announce MLs for every important
piece of software I use and oss-sec, bugtraq and fulldisclosure in
addition.

I like to keep an eye on vulnerabilities in general and make sure to
take precations if necessary.

I'll keep that idea in mind and think about it.

> 
> —Jeremy


Cheers,
Thore

-- 


signature.asc
Description: PGP signature


Re: [aur-general] TU Application: Thore Bödecker

2017-05-11 Thread Jeremy Audet via aur-general
> And on my router at home.

Neat! What are you using for router hardware? I've done this as well. I
used a desktop with ethernet and wifi expansion cards for several years,
and then moved to a PC Engines apu2c2 .

It seems like you have a good set of system administration skills, as
indicated by at least these statements:

> I ended up with Arch on my rented server as well.
> I am also providing hosting services on that server to a small group of
customers
> I have been a co-maintainer of [php56] ever since and tried to push the
security releases out as quickly as possible.
> I am providing hosting services for customers I am also acting as an
email service provider for my customers (and for myself too).
> Apart from maintaining the mentioned packages I am also quite capable
regarding server and service hosting and happy to assist in maintaining and
improving the Arch Linux infrastructure. :)

Do you monitor PHP-related security issues? It sounds like you do, and if
you're providing hosting services to customers, you probably should be. :-)
Do you have any interest in sharing that knowledge by volunteering for the Arch
CVE monitoring team
? Nobody is
specifically monitoring PHP issues.

—Jeremy


Re: [aur-general] TU Application: Thore Bödecker

2017-05-10 Thread brent s.
On 05/10/2017 07:49 AM, Thore Boedecker via aur-general wrote:
> As I am also providing hosting services on that server to a small group
> of customers, the PHP 7 release was quite cumbersome. I had to find a way
> to provide support for two different PHP versions on my server.
> Gladly I found a fellow sufferer in Mickaël Thomas (mickael9 in the AUR)
> and we started working on the php56 AUR package [1].
> It was a bit messy at first but in the end it worked out and I've been
> running php56 together with the upstream Arch Linux php packages for over
> a year now. I have been a co-maintainer of that package ever since and
> tried to push the security releases out as quickly as possible.
> 
> In order to retain as much features of php56 as possible, I created some
> additional packages for that, which could co-exist with upstream
> Arch repo packages as well:
> 
> [2] php56-apcu
> [3] php56-geoip
> [4] php56-memcache
> [5] php56-memcached
> [6] php56-xdebug
> 

Just my $0.02, but those php56 packages have saved my ass with some
php7-incompatible webapps and they were done in a clean way, so my kudos
on that.

-- 
brent saner
http://www.square-r00t.net



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Thore Bödecker

2017-05-10 Thread NicoHood
On 05/10/2017 04:01 PM, Thore Boedecker via aur-general wrote:
> 
> The php56 package already uses gpg signatures?!
> 

Sorry I think i looked at a different package then. Yeah it would be
really nice to have signatures available anywhere. Thanks for your
cooperation :)

~Nico



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Thore Bödecker

2017-05-10 Thread Thore Boedecker via aur-general
Hey,

thanks for your feedback.

On 10.05.17 - 14:26, NicoHood wrote:
> Hello Thore,
> nice to hear you want to join the ArchLinux TU Team.
> 
> I took a quick look at your PKGBUILDs and found out that you are not
> using GPG signatures for your PKGBUILDs. Please always ask upstream for
> GPG signatures and request those if not available.
> 
> See PHP:
> https://secure.php.net/downloads.php#gpg-5.6

The php56 package already uses gpg signatures?!

> 
> See Opendmarc:
> https://sourceforge.net/projects/opendmarc/files/opendmarc-1.3.2.tar.gz.asc/download

Unfortunately the key for opendmarc is not public, that is probably
the reason why it is also disabled in the repo package.

> 
> Also I suggest to use sha512sums, as they are more secure and future
> proof, even though sha256 is already considered secure at the moment.

As you mentioned sha256 should be pretty solid at the moment but I'm
happy to oblige and switched to sha512 in all (co-)maintained
packages.

> 
> Also this source can be fetched via https:
> https://www.xdebug.org/files/xdebug-2.5.3.tgz

Fixed.

> 
> I suggest to get in touch with the upstream projects and request them to
> sign their tarballs. You can also refer to GPGit with makes it easier
> for dev to get started with GPG source signing:
> https://github.com/NicoHood/gpgit

Thanks for this hint, I will contact the upstream projects and request
that. I'll add comments to the PKGBUILDs with status updates of that
progress.

> 
> Cheers
> Nico
> 
> On 05/10/2017 01:49 PM, Thore Boedecker via aur-general wrote:
> > Hey folks,
> > 
> > My name is Thore Bödecker (a.k.a. foxxx0, or just foxxx depending on
> > nick availability) and finally I have taken the time increase my
> > involvement with Arch Linux. I'm 26 years old now and living in small
> > town called Falkensee, near Berlin in Germany.
> > 
> > First of all thanks to Florian Pritz (Bluewind) who is sponsoring my
> > TU application.
> > 
> > I heard you like stories so I'm happy to tell you about my way through
> > the Linux world.
> > 
> > I have been using Linux in various flavours for a long time, if memory
> > serves correctly it all started with Ubuntu 6.10 somewhere in 2006
> > while I was still in school.
> > At first it was merely some experimentation and exploring a whole new
> > world but quickly I got really interested. Being a totally addicted
> > gamer at that time it was not a real option for daily usage but I went
> > ahead to build a small fileserver with it and continued to learn new
> > stuff while doing so.
> > 
> > After switching back and forth between Ubuntu and Debian for a couple of
> > years and a bit of Gentoo in the middle I ended up renting a server to
> > host some stuff with Debian.
> > 
> > In October 2010 my bachelor studies in some sort of technical computer
> > science started at HTW Berlin (for the German speaking people, the
> > course of studies was called "Informationstechnik/Vernetzte Systeme").
> > 
> > This surely had quite some influence and not much later Arch Linux was
> > the OS on my laptop. And oh it was good and enjoyable (even without
> > systemd back then! :P).
> > 
> > During my studies I had less and less time for gaming which eventually
> > made me install Arch on my desktop at home.
> > At that point it was already quite clear that there was no alternative
> > for me.
> > 
> > Having used Arch for some years on a daily basis made me more and
> > more annoyed with my rented server, that was still running Debian.
> > I got really upset with APT and the "Debian-way" of doing things, having
> > seen how simply and enjoyable they were on Arch Linux.
> > 
> > You can pretty much guess what happened, I ended up with Arch on my
> > rented server as well.
> > And a second one.
> > And on my router at home.
> > I even build a custom archiso for home PXE setup, doing which is really
> > pleasing too.
> > 
> > Please bear with me, I'll try to wrap things up :)
> > 
> > Since October 2013 I am studying computer science at the TU Berlin which
> > has been quite an adventure thus far and if everything works out I'm on
> > track to start my master thesis near the end of this year.
> > 
> > As I am also providing hosting services on that server to a small group
> > of customers, the PHP 7 release was quite cumbersome. I had to find a way
> > to provide support for two different PHP versions on my server.
> > Gladly I found a fellow sufferer in Mickaël Thomas (mickael9 in the AUR)
> > and we started working on the php56 AUR package [1].
> > It was a bit messy at first but in the end it worked out and I've been
> > running php56 together with the upstream Arch Linux php packages for over
> > a year now. I have been a co-maintainer of that package ever since and
> > tried to push the security releases out as quickly as possible.
> > 
> > In order to retain as much features of php56 as possible, I created some
> > additional packages for that, which could co-exist with upstream
> > Arch repo packages 

Re: [aur-general] TU Application: Thore Bödecker

2017-05-10 Thread NicoHood
Hello Thore,
nice to hear you want to join the ArchLinux TU Team.

I took a quick look at your PKGBUILDs and found out that you are not
using GPG signatures for your PKGBUILDs. Please always ask upstream for
GPG signatures and request those if not available.

See PHP:
https://secure.php.net/downloads.php#gpg-5.6

See Opendmarc:
https://sourceforge.net/projects/opendmarc/files/opendmarc-1.3.2.tar.gz.asc/download

Also I suggest to use sha512sums, as they are more secure and future
proof, even though sha256 is already considered secure at the moment.

Also this source can be fetched via https:
https://www.xdebug.org/files/xdebug-2.5.3.tgz

I suggest to get in touch with the upstream projects and request them to
sign their tarballs. You can also refer to GPGit with makes it easier
for dev to get started with GPG source signing:
https://github.com/NicoHood/gpgit

Cheers
Nico

On 05/10/2017 01:49 PM, Thore Boedecker via aur-general wrote:
> Hey folks,
> 
> My name is Thore Bödecker (a.k.a. foxxx0, or just foxxx depending on
> nick availability) and finally I have taken the time increase my
> involvement with Arch Linux. I'm 26 years old now and living in small
> town called Falkensee, near Berlin in Germany.
> 
> First of all thanks to Florian Pritz (Bluewind) who is sponsoring my
> TU application.
> 
> I heard you like stories so I'm happy to tell you about my way through
> the Linux world.
> 
> I have been using Linux in various flavours for a long time, if memory
> serves correctly it all started with Ubuntu 6.10 somewhere in 2006
> while I was still in school.
> At first it was merely some experimentation and exploring a whole new
> world but quickly I got really interested. Being a totally addicted
> gamer at that time it was not a real option for daily usage but I went
> ahead to build a small fileserver with it and continued to learn new
> stuff while doing so.
> 
> After switching back and forth between Ubuntu and Debian for a couple of
> years and a bit of Gentoo in the middle I ended up renting a server to
> host some stuff with Debian.
> 
> In October 2010 my bachelor studies in some sort of technical computer
> science started at HTW Berlin (for the German speaking people, the
> course of studies was called "Informationstechnik/Vernetzte Systeme").
> 
> This surely had quite some influence and not much later Arch Linux was
> the OS on my laptop. And oh it was good and enjoyable (even without
> systemd back then! :P).
> 
> During my studies I had less and less time for gaming which eventually
> made me install Arch on my desktop at home.
> At that point it was already quite clear that there was no alternative
> for me.
> 
> Having used Arch for some years on a daily basis made me more and
> more annoyed with my rented server, that was still running Debian.
> I got really upset with APT and the "Debian-way" of doing things, having
> seen how simply and enjoyable they were on Arch Linux.
> 
> You can pretty much guess what happened, I ended up with Arch on my
> rented server as well.
> And a second one.
> And on my router at home.
> I even build a custom archiso for home PXE setup, doing which is really
> pleasing too.
> 
> Please bear with me, I'll try to wrap things up :)
> 
> Since October 2013 I am studying computer science at the TU Berlin which
> has been quite an adventure thus far and if everything works out I'm on
> track to start my master thesis near the end of this year.
> 
> As I am also providing hosting services on that server to a small group
> of customers, the PHP 7 release was quite cumbersome. I had to find a way
> to provide support for two different PHP versions on my server.
> Gladly I found a fellow sufferer in Mickaël Thomas (mickael9 in the AUR)
> and we started working on the php56 AUR package [1].
> It was a bit messy at first but in the end it worked out and I've been
> running php56 together with the upstream Arch Linux php packages for over
> a year now. I have been a co-maintainer of that package ever since and
> tried to push the security releases out as quickly as possible.
> 
> In order to retain as much features of php56 as possible, I created some
> additional packages for that, which could co-exist with upstream
> Arch repo packages as well:
> 
> [2] php56-apcu
> [3] php56-geoip
> [4] php56-memcache
> [5] php56-memcached
> [6] php56-xdebug
> 
> 
> So why am I doing this all?
> 
> I love using Arch Linux, it has been a joyful journey most of the time
> and I'm looking forward to what might come.
> 
> But why do I want to be a TU some of you might ask.
> 
> As I am providing hosting services for customers I am also acting as
> an email service provider for my customers (and for myself too).
> Over the last few month there were some nasty spam mails glitching
> through my spamassassin setup.
> Naturally I investigated and found that I couldn't really do *anything*
> while using Arch Linux repo packages only (which I highly prefer for
> critical infrastructure).
> I ha

Re: [aur-general] TU Application: Thore Bödecker

2017-05-10 Thread Yardena Cohen via aur-general
On Wed, May 10, 2017 at 4:49 AM, Thore Boedecker via aur-general
 wrote:
> To make all these parts easily and comfortably available to all
> Arch Linux users I would like to move these few packages to [community]
> (if Yardena Cohen a.k.a. yar agrees for amavisd-new).

That's very polite of you, and once you're a TU you're welcome to take
it over, but generally you don't need to ask permission. TUs have
taken my packages before, and that's just how it is. :)


Re: [aur-general] TU Application: Thore Bödecker

2017-05-10 Thread Florian Pritz via aur-general
On 10.05.2017 13:49, Thore Boedecker via aur-general wrote:
> My name is Thore Bödecker (a.k.a. foxxx0, or just foxxx depending on
> nick availability) and finally I have taken the time increase my
> involvement with Arch Linux. I'm 26 years old now and living in small
> town called Falkensee, near Berlin in Germany.
> 
> First of all thanks to Florian Pritz (Bluewind) who is sponsoring my
> TU application.
I confirm my sponsorship. Let the discussion begin!

Florian



signature.asc
Description: OpenPGP digital signature


[aur-general] TU Application: Thore Bödecker

2017-05-10 Thread Thore Boedecker via aur-general
Hey folks,

My name is Thore Bödecker (a.k.a. foxxx0, or just foxxx depending on
nick availability) and finally I have taken the time increase my
involvement with Arch Linux. I'm 26 years old now and living in small
town called Falkensee, near Berlin in Germany.

First of all thanks to Florian Pritz (Bluewind) who is sponsoring my
TU application.

I heard you like stories so I'm happy to tell you about my way through
the Linux world.

I have been using Linux in various flavours for a long time, if memory
serves correctly it all started with Ubuntu 6.10 somewhere in 2006
while I was still in school.
At first it was merely some experimentation and exploring a whole new
world but quickly I got really interested. Being a totally addicted
gamer at that time it was not a real option for daily usage but I went
ahead to build a small fileserver with it and continued to learn new
stuff while doing so.

After switching back and forth between Ubuntu and Debian for a couple of
years and a bit of Gentoo in the middle I ended up renting a server to
host some stuff with Debian.

In October 2010 my bachelor studies in some sort of technical computer
science started at HTW Berlin (for the German speaking people, the
course of studies was called "Informationstechnik/Vernetzte Systeme").

This surely had quite some influence and not much later Arch Linux was
the OS on my laptop. And oh it was good and enjoyable (even without
systemd back then! :P).

During my studies I had less and less time for gaming which eventually
made me install Arch on my desktop at home.
At that point it was already quite clear that there was no alternative
for me.

Having used Arch for some years on a daily basis made me more and
more annoyed with my rented server, that was still running Debian.
I got really upset with APT and the "Debian-way" of doing things, having
seen how simply and enjoyable they were on Arch Linux.

You can pretty much guess what happened, I ended up with Arch on my
rented server as well.
And a second one.
And on my router at home.
I even build a custom archiso for home PXE setup, doing which is really
pleasing too.

Please bear with me, I'll try to wrap things up :)

Since October 2013 I am studying computer science at the TU Berlin which
has been quite an adventure thus far and if everything works out I'm on
track to start my master thesis near the end of this year.

As I am also providing hosting services on that server to a small group
of customers, the PHP 7 release was quite cumbersome. I had to find a way
to provide support for two different PHP versions on my server.
Gladly I found a fellow sufferer in Mickaël Thomas (mickael9 in the AUR)
and we started working on the php56 AUR package [1].
It was a bit messy at first but in the end it worked out and I've been
running php56 together with the upstream Arch Linux php packages for over
a year now. I have been a co-maintainer of that package ever since and
tried to push the security releases out as quickly as possible.

In order to retain as much features of php56 as possible, I created some
additional packages for that, which could co-exist with upstream
Arch repo packages as well:

[2] php56-apcu
[3] php56-geoip
[4] php56-memcache
[5] php56-memcached
[6] php56-xdebug


So why am I doing this all?

I love using Arch Linux, it has been a joyful journey most of the time
and I'm looking forward to what might come.

But why do I want to be a TU some of you might ask.

As I am providing hosting services for customers I am also acting as
an email service provider for my customers (and for myself too).
Over the last few month there were some nasty spam mails glitching
through my spamassassin setup.
Naturally I investigated and found that I couldn't really do *anything*
while using Arch Linux repo packages only (which I highly prefer for
critical infrastructure).
I have been in touch with Florian very, very much over the last few
years and we shared the same desire: amavisd-new.

So last week I did an experiment with a combination of opendkim +
opendmarc + amavisd-new.

When I discovered that there was no AUR package for amavisd-milter I
went ahead and created one. But somehow when I tried to push my package
to AUR it said "Permission denied". As it turned out, another fellow
Arch Linux user has done the exact same thing and pushed to the AUR a
couple of hours before me. So I got in contact with said Person, Karol
Babioch (kbabioch) and he was happy to let me take ownership of
amavisd-milter [7].

I countinued to experiment and it seemed the opendmarc internal SPF
check wasn't really working in the Arch Linux repo version.
This made me build opendmarc using libspf2 which did the trick and I've
put that together in opendmarc-libspf2 [8].

To make all these parts easily and comfortably available to all
Arch Linux users I would like to move these few packages to [community]
(if Yardena Cohen a.k.a. yar agrees for amavisd-new).

As you guys want to make sure that I am capable of writ

Re: [aur-general] TU Application: Christian Rebischke

2017-03-01 Thread Florian Pritz via aur-general
On 22.02.2017 15:53, Florian Pritz via aur-general wrote:
> You can cast your vote here: https://aur.archlinux.org/tu/?id=91

Yes: 37
No: 1
Abstain: 0
Voted: 84.44%

Result: Accepted

Congratulations Christian and welcome to the TU team :)

Florian



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Christian Rebischke

2017-02-25 Thread SanskritFritz via aur-general
On Sat, Feb 25, 2017 at 6:31 PM, Bartłomiej Piotrowski <
bpiotrow...@archlinux.org> wrote:

> On 2017-02-22 14:13, Levente Polyak wrote:
> > cheers,
> > Levente
>
> I just want to say that I'm happy I'm already a TU so I don't have to
> undergo Levente's review...
>
>
THIS. is the main reason I don't apply as TU :D


Re: [aur-general] TU Application: Christian Rebischke

2017-02-25 Thread Bartłomiej Piotrowski
On 2017-02-22 14:13, Levente Polyak wrote:
> cheers,
> Levente

I just want to say that I'm happy I'm already a TU so I don't have to
undergo Levente's review...

Bartłomiej


Re: [aur-general] TU Application: Christian Rebischke

2017-02-24 Thread Christian Rebischke
On Wed, Feb 22, 2017 at 02:13:35PM +0100, Levente Polyak wrote:
> First at all:
> I know shibumi for quite a while now (also personally in meat space) and
> what i could say in a short summary: great news!! *cheer* :D
>
> So far its bit lonely in this thread *tumbleweed*... lets get this
> rolling a bit. I'm also sure one or the other may miss my reply :P
>
> zsh> xxarhtna --pedantic --input aur/shibumi
> [+] Starting up xxarhtna
> [+] Analyzing 46 packages
> [+] Dumping 18 results...

Hi Lev,
first of all thanks for your work and checking my 46 packages.
Here is my current status.
> apk-signer:
> - upstream seems gone, googlecode redirects to a 404 github and search
>   doesn't reveal any trace of upstream existence. Bit meh it vanished
>   and there is only a binary blob left on a random dropbox >.>

WIP

> awesome-terminal-fonts:
> - you could distribute the non-common license as its available in the
>   tarball
> - fc-cache in .install is not needed anymore as thats handled by a
>   pacman hook
> - the .install creates a symlink and if the package gets uninstalled a
>   dangling symlink will remain pointing into nothing.

FIXED

> awesome-terminal-fonts-git:
> - same as awesome-terminal-fonts

FIXED

> binnavi:
> - makes sense to use ${pkgver} in source, otherwise it tends to be
>   forgotten on bump :P
> - the combination of mkdir + mv can be simplified with a single
>   install -Dm 644
> - the custom start script calls /usr/bin/java (which can by java6) but
>   it seem to require >= 8 (< please note the comment about binnavi-git
>   related to fixing this)

FIXED

> binnavi-git:
> - the combination of mkdir + mv can be simplified with a single
>   install -Dm 644
> - the custom start script calls a java-8 specific path, but the
>   dependency is specified as >= 8. If a java >= 9 will arrive, it may
>   not work if java8 is not installed, while the dependency is still
>   fulfilled. Either pin the version to java8 and use a java8 path or
>   do some dynamic sorcery to find the proper jre java executable.

FIXED

> cloud-buster:
> - makes sense to use ${pkgver} in source, otherwise it tends to be
>   forgotten on bump :P
> - requires python-dnspython as optdepends in its mxrecords.py

FIXED

> inetsim:
> - perlipq dependency does not seem to exist
> - upstream provides gpg signatures that can be used
> - grep inetsim in the install file isn't safe enough as it can match
>   anything (theoretically) use getent instead.
> - gid 16 is already reserved for stunnel

WIP

> libemu:
> - whitespace after '--prefix=/usr' :P :D

FIXED

> nyan:
> - makes sense to use ${pkgver} in source, otherwise it tends to be
>   forgotten on bump :P

FIXED

> puppetserver:
> -  upstream gpg signature are available

WIP

> python-requests-cache:
> - needs (make)depends of python-requests
> - with adding checkdepends of python{2}-pytest and python{2}-mock you
>   can add a check() call doing py.test and py.test2

FIXED except of the checks


> python-pypdns:
> - requires dependency of python{2}-requests (see source)
> - optdepends of python{2}-requests-cache.
> - license could be shipped as its available in the tarball

FIXED

> python-pymisp:
> - 2.4.65 is out :P
> - requires python{2}-requests python{2}-dateutil python{2}-jsonschema
>   as dependens
> - optionally requires a new package python{2}-pyme otherwise the
>   sign and verify functionality of this will error out
> - with python{2}-pytest and python{2}-requests-mock a check() can be
>   used running py.test and py.test2

FIXED, except of the checks


> python-piexif:
> - when adding python{2}-pytest and python{2}-pillow to checkdepends, a
>   check() can be used having set PYTHONPATH=. running py.test and
>   py.test2

FIXED

> python-pefile:
> - update available :P
> - "setup.py check" doesn't do what you think it does, it only checks
>   some metadata and stuff, the target for setup.py you are looking for
>   is "test"... but there are no tests provided by the exported tarball
>   version you choose (there are also non-exported source tarballs
>   containing them)

FIXED, except of the checks. There are missing files in the tarball

> python-virustotal-api:
> - "setup.py check" doesn't do what you think it does, it only checks
>   some metadata and stuff, the target for setup.py you are looking for
>   is "test"... if you want to run tests it provides nosetests via
>   ./tests
> - requires dependency python{2}-requests

FIXED, except of the checks.. still on it. (the tests fail, maybe missing
files)

> python-terminaltables:
> - distributing LICENSE would be neat as they are inside the tarball

FIXED

> python2-pydeep:
> - not an 'any' package as it compiles native code.
> - license can be distributed as its inside the tarball

FIXED





signature.asc
Description: PGP signature


Re: [aur-general] TU Application: Christian Rebischke

2017-02-22 Thread Giancarlo Razzolini

Em fevereiro 22, 2017 10:13 Levente Polyak escreveu:


zsh> xxarhtna --pedantic --input aur/shibumi
[+] Starting up xxarhtna
[+] Analyzing 46 packages
[+] Dumping 18 results...



Hey, you took my xxarhtna symlink to namcap idea and added some new
flags. When will we rename namcap to anthraxx?

Cheers,
Giancarlo Razzolini

pgplz_0IsNAnG.pgp
Description: PGP signature


Re: [aur-general] TU Application: Christian Rebischke

2017-02-22 Thread Florian Pritz via aur-general
On 17.02.2017 15:26, Florian Pritz via aur-general wrote:
> On 17.02.2017 15:25, Christian Rebischke wrote:
>> Hello everyone,
>> I am Christian Rebischke (in the internet mostly known as 'shibumi') and
>> I would like to increase my work in the Arch Linux Community and become
>> Arch Linux TU. Thanks to Florian Pritz (bluewind) for being my sponsor.
> 
> I confirm my sponsorship. Let the discussion begin.

The discussion period is now over. There wasn't much discussion, but
I'll take that as a good sign and assume that everyone already knows
Christian.

You can cast your vote here: https://aur.archlinux.org/tu/?id=91

Florian



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Christian Rebischke

2017-02-22 Thread Levente Polyak
On 02/17/2017 03:25 PM, Christian Rebischke wrote:
> Hello everyone,
> I am Christian Rebischke (in the internet mostly known as 'shibumi') and
> I would like to increase my work in the Arch Linux Community and become
> Arch Linux TU. Thanks to Florian Pritz (bluewind) for being my sponsor.
> 

First at all:
I know shibumi for quite a while now (also personally in meat space) and
what i could say in a short summary: great news!! *cheer* :D

So far its bit lonely in this thread *tumbleweed*... lets get this
rolling a bit. I'm also sure one or the other may miss my reply :P

zsh> xxarhtna --pedantic --input aur/shibumi
[+] Starting up xxarhtna
[+] Analyzing 46 packages
[+] Dumping 18 results...

apk-signer:
- upstream seems gone, googlecode redirects to a 404 github and search
  doesn't reveal any trace of upstream existence. Bit meh it vanished
  and there is only a binary blob left on a random dropbox >.>

awesome-terminal-fonts:
- you could distribute the non-common license as its available in the
  tarball
- fc-cache in .install is not needed anymore as thats handled by a
  pacman hook
- the .install creates a symlink and if the package gets uninstalled a
  dangling symlink will remain pointing into nothing.

awesome-terminal-fonts-git:
- same as awesome-terminal-fonts

binnavi:
- makes sense to use ${pkgver} in source, otherwise it tends to be
  forgotten on bump :P
- the combination of mkdir + mv can be simplified with a single
  install -Dm 644
- the custom start script calls /usr/bin/java (which can by java6) but
  it seem to require >= 8 (< please note the comment about binnavi-git
  related to fixing this)

binnavi-git:
- the combination of mkdir + mv can be simplified with a single
  install -Dm 644
- the custom start script calls a java-8 specific path, but the
  dependency is specified as >= 8. If a java >= 9 will arrive, it may
  not work if java8 is not installed, while the dependency is still
  fulfilled. Either pin the version to java8 and use a java8 path or
  do some dynamic sorcery to find the proper jre java executable.

cloud-buster:
- makes sense to use ${pkgver} in source, otherwise it tends to be
  forgotten on bump :P
- requires python-dnspython as optdepends in its mxrecords.py

inetsim:
- perlipq dependency does not seem to exist
- upstream provides gpg signatures that can be used
- grep inetsim in the install file isn't safe enough as it can match
  anything (theoretically) use getent instead.
- gid 16 is already reserved for stunnel

libemu:
- whitespace after '--prefix=/usr' :P :D

nyan:
- makes sense to use ${pkgver} in source, otherwise it tends to be
  forgotten on bump :P

puppetserver:
-  upstream gpg signature are available

python-requests-cache:
- needs (make)depends of python-requests
- with adding checkdepends of python{2}-pytest and python{2}-mock you
  can add a check() call doing py.test and py.test2

python-pypdns:
- requires dependency of python{2}-requests (see source)
- optdepends of python{2}-requests-cache.
- license could be shipped as its available in the tarball

python-pymisp:
- 2.4.65 is out :P
- requires python{2}-requests python{2}-dateutil python{2}-jsonschema
  as dependens
- optionally requires a new package python{2}-pyme otherwise the
  sign and verify functionality of this will error out
- with python{2}-pytest and python{2}-requests-mock a check() can be
  used running py.test and py.test2

python-piexif:
- when adding python{2}-pytest and python{2}-pillow to checkdepends, a
  check() can be used having set PYTHONPATH=. running py.test and
  py.test2

python-pefile:
- update available :P
- "setup.py check" doesn't do what you think it does, it only checks
  some metadata and stuff, the target for setup.py you are looking for
  is "test"... but there are no tests provided by the exported tarball
  version you choose (there are also non-exported source tarballs
  containing them)

python-virustotal-api:
- "setup.py check" doesn't do what you think it does, it only checks
  some metadata and stuff, the target for setup.py you are looking for
  is "test"... if you want to run tests it provides nosetests via
  ./tests
- requires dependency python{2}-requests

python-terminaltables:
- distributing LICENSE would be neat as they are inside the tarball

python2-pydeep:
- not an 'any' package as it compiles native code.
- license can be distributed as its inside the tarball



cheers,
Levente



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Christian Rebischke

2017-02-17 Thread Florian Pritz via aur-general
On 17.02.2017 15:25, Christian Rebischke wrote:
> Hello everyone,
> I am Christian Rebischke (in the internet mostly known as 'shibumi') and
> I would like to increase my work in the Arch Linux Community and become
> Arch Linux TU. Thanks to Florian Pritz (bluewind) for being my sponsor.

I confirm my sponsorship. Let the discussion begin.

Florian




signature.asc
Description: OpenPGP digital signature


[aur-general] TU Application: Christian Rebischke

2017-02-17 Thread Christian Rebischke
Hello everyone,
I am Christian Rebischke (in the internet mostly known as 'shibumi') and
I would like to increase my work in the Arch Linux Community and become
Arch Linux TU. Thanks to Florian Pritz (bluewind) for being my sponsor.

Maybe you know me already from the Arch Linux Security Team [1], but let
me introduce me first.

I was born in Goslar (Germany) in 1992 and I had first contact with Arch
Linux with around 18. This is now more than 6 years ago. Before I had a
long journey through the debian world with Ubuntu and Debian. Currently
I study computer science at TU-Clausthal and I am halftime employed as
Software Engineer at our Institute for Software Systems Engineering and
as System Administrator at our Datacenter and the Institute for
Mathematics [2]. January 2015 I started with my work in the Arch Linux
Security Team and around half a year later I became official member of
Arch Linux Security Team. If I recall correctly I pushed my first
package into the AUR in 2014. At the moment I maintain 45 packages in
the AUR [3]. Most of them are vim-plugins, python libraries or tools for
malware analysis. I am interested in malware analysis, reverse
engineering, large scale system administration, devops. I know python,
bash, C, C++, Java, x86 assembler and some Rust, but I wouldn't call my
self a professional developer. (Something that I want to change with my
job in the Institute for Software Systems Engineering). Moreover I am
quite active in the opensource community. I contributed small patches to
systemd and others. The current project that I support with pull
requests is powerlevel9k [4], a nice powerline for zsh.

Non-technical interests are asian languages like Chinese
(你们好,我会说一点点中文) and japanese (今日はみなさん), asian culture
and cooking.

If I become a TU I would want to adopt the following orphan packages in
[community]:

- ascii
- audit
- bup
- connman

Furthermore I would like to push the following packages from [AUR] to
[community] (if the maintainers agree with it):

- arch-audit
- systemtap


I also provide an Arch Linux Vagrant box and I would love to get 1-2
other people together and doing some official out of this [5]. I
currently only provide virtualbox as hypervisor. My plan are monthly
snapshots like CentOS does.

Best ways to contact me are IRC (I am on freenode, oftc and hackint as
shibumi and hangout in different #archlinux channels like #archlinux.de)
the german archlinux.de forum and mail. My PGP Key fingerprint is:
6DAF 7B80 8F9D F251 3962   D214 61E3 DFE2 060D

best regards,

Chris


[1] https://www.archlinux.org/people/support-staff/
[2] https://en.nullday.de/about/
[3] https://aur.archlinux.org/packages/?SeB=m&K=Shibumi
[4] https://github.com/bhilburn/powerlevel9k
[5] https://atlas.hashicorp.com/archlinux/boxes/archlinux/


signature.asc
Description: PGP signature


Re: [aur-general] TU Application: Bruno Pagani

2017-01-20 Thread Bruno Pagani via aur-general
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



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Bruno Pagani

2017-01-20 Thread Bartłomiej Piotrowski
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



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Bruno Pagani

2017-01-19 Thread Bartłomiej Piotrowski
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



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Bruno Pagani

2017-01-13 Thread Bartłomiej Piotrowski
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



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Bruno Pagani

2017-01-11 Thread Maxime Gauduin
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


Re: [aur-general] TU Application: Bruno Pagani

2017-01-10 Thread Bruno Pagani via aur-general
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
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Bruno Pagani

2017-01-10 Thread Bruno Pagani via aur-general
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
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Bruno Pagani

2017-01-10 Thread Bruno Pagani via aur-general
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
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Bruno Pagani

2017-01-10 Thread Johannes Löthberg via aur-general

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
Description: PGP signature


Re: [aur-general] TU Application: Bruno Pagani

2017-01-10 Thread 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.

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
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Bruno Pagani

2017-01-10 Thread Bruno Pagani via aur-general
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
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Bruno Pagani

2017-01-10 Thread Frederik “Freso” S . Olesen via aur-general
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 
AUR: https://aur.archlinux.org/account/Freso
Wiki: https://wiki.archlinux.org/index.php/User:Freso



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Bruno Pagani

2017-01-10 Thread Eli Schwartz via aur-general
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
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Bruno Pagani

2017-01-10 Thread Levente Polyak
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
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Bruno Pagani

2017-01-10 Thread Levente Polyak
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
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Bruno Pagani

2017-01-09 Thread Christian Hesse
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/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpt1aqHqkLES.pgp
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Bruno Pagani

2017-01-09 Thread Bruno Pagani via aur-general
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]). ;)

> 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
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Bruno Pagani

2017-01-09 Thread Bruno Pagani via aur-general
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
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Bruno Pagani

2017-01-08 Thread Christian Hesse
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.)

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/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpDPJoUZNQ9h.pgp
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Bruno Pagani

2017-01-08 Thread Maxime Gauduin
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" 
 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 templ

Re: [aur-general] TU Application: Bruno Pagani

2017-01-08 Thread Bruno Pagani via aur-general
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

Re: [aur-general] TU Application: Bruno Pagani

2017-01-07 Thread Bartłomiej Piotrowski
Let the games begin, good luck!

Bartłomiej



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Bruno Pagani

2017-01-07 Thread NicoHood
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
Description: OpenPGP digital signature


[aur-general] TU Application: Bruno Pagani

2017-01-07 Thread Bruno Pagani via aur-general
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/

Re: [aur-general] TU Application: Baptiste Jonglez

2016-12-06 Thread Lukas Fleischer
On Mon, 28 Nov 2016 at 07:33:16, Baptiste Jonglez wrote:
> I would like to apply to become a TU.  Lukas Fleischer has kindly accepted
> to sponsor my application.
> [...]
> Don't hesitate if you have any questions, or comments on my AUR packages!

The discussion period is over. Please cast your votes at [1].

[1] https://aur.archlinux.org/tu/?id=89


Re: [aur-general] TU Application: Baptiste Jonglez

2016-12-02 Thread Johannes Löthberg via aur-general

On 02/12, Giancarlo Razzolini wrote:

Em dezembro 2, 2016 11:18 NicoHood escreveu:


The signature itself is only a signed hash (sha256). So we do rely on
the collision resistance of sha256[1] (or whatever the GPG itself uses).
You are right, that hashes themselves are not enough to verify that the
original author provided this source. But it gives you the guarantee
that you downloaded the same source, as the maintainer(PKGBUILD writer) did.



GPG uses DSA[0]. And the signatures done using GPG are done in a way that
requires a key pair on the part of the person doing the signature. The
link you sent demonstrate precisely that. They are much more than simple
hashes.

[0] https://www.gnupg.org/gph/en/manual.html#AEN216


That's quite outdated, and RSA has been the default for quite a long 
time.


--
Sincerely,
 Johannes Löthberg
 PGP Key ID: 0x50FB9B273A9D0BB5
 https://theos.kyriasis.com/~kyrias/


signature.asc
Description: PGP signature


Re: [aur-general] TU Application: Baptiste Jonglez

2016-12-02 Thread Giancarlo Razzolini

Em dezembro 2, 2016 11:18 NicoHood escreveu:


The signature itself is only a signed hash (sha256). So we do rely on
the collision resistance of sha256[1] (or whatever the GPG itself uses).
You are right, that hashes themselves are not enough to verify that the
original author provided this source. But it gives you the guarantee
that you downloaded the same source, as the maintainer(PKGBUILD writer) did.



GPG uses DSA[0]. And the signatures done using GPG are done in a way that
requires a key pair on the part of the person doing the signature. The
link you sent demonstrate precisely that. They are much more than simple
hashes.


That is what integrity is all about, that is not only a checksum! The
weakest spot though is the initial fetching of the source on which the
maintainer relies on. However with strong hashes you can at least ensure
that you (for a rebuild) download the exact same sources, as the
maintainer did. You just cannot prove who published that source itself.
Saying sha256 is not secure enough for that purpose would also say GPG
is not safe.



I'm not saying that sha256 is not secure enough for that purpose. I'm saying
that for *maintainers* it is not enough. There's a difference, it's subtle,
but it is there nevertheless. We replace upstream trust with our own. So we
must be sure that we're packaging from the right upstream source, even if
said source can't be obtained securely, nor does it has proper hashes or not
even TLS.


Correct me if I am wrong though. I'd be also nice to discuss this in the
email I recently opened and not in the TU Application. I think this is a
highly important topic, especially for those packages where we do not
have gpg and https available and you can only rely on the hash that the
maintainer gave out (AUR).



Sure, lets discuss that. But I think we already, even if informally, agreed
that using TLS were available is better than not. I'll stop deviating from
the purpose of the TU application discussion. Baptiste, you fixed what we
suggested, and that's ok by me.

Cheers,
Giancarlo Razzolini

[0] https://www.gnupg.org/gph/en/manual.html#AEN216


pgpVZVca2vPFH.pgp
Description: PGP signature


Re: [aur-general] TU Application: Baptiste Jonglez

2016-12-02 Thread NicoHood
>>
>> Besides this issue, I already mentioned another drawback of using HTTPS:
>> untrusted certificates (either expired, self-signed, or just signed by an
>> untrusted CA) will cause build failure.  This was a real issue for
>> OpenWRT, so they switched to using --no-check-certificate in 2010 [1] to
>> avoid build failures.  Sources are already validated with a checksum.
>>
>
> Well, relying only on checksums is not good enough in my opinion. We know
> for a fact that hashing algorithms are built on top of *reasonable* chance
> that collisions won't happen. Sure, the space of a SHA256 hash is
huge, but
> we must not just shrug over it. Because if we, as maintainers do, upstream
> will think they don't need to provide signed sources, because hashes are
> probably "good enough".
>

The signature itself is only a signed hash (sha256). So we do rely on
the collision resistance of sha256[1] (or whatever the GPG itself uses).
You are right, that hashes themselves are not enough to verify that the
original author provided this source. But it gives you the guarantee
that you downloaded the same source, as the maintainer(PKGBUILD writer) did.

That is what integrity is all about, that is not only a checksum! The
weakest spot though is the initial fetching of the source on which the
maintainer relies on. However with strong hashes you can at least ensure
that you (for a rebuild) download the exact same sources, as the
maintainer did. You just cannot prove who published that source itself.
Saying sha256 is not secure enough for that purpose would also say GPG
is not safe.

Correct me if I am wrong though. I'd be also nice to discuss this in the
email I recently opened and not in the TU Application. I think this is a
highly important topic, especially for those packages where we do not
have gpg and https available and you can only rely on the hash that the
maintainer gave out (AUR).

[1]https://www.bestvpn.com/wp-content/uploads/2015/03/Digital_Signature_diagram.png

Cheers
Nico




signature.asc
Description: OpenPGP digital signature


Re: [aur-general] TU Application: Baptiste Jonglez

2016-12-02 Thread Giancarlo Razzolini

Em dezembro 1, 2016 20:37 Baptiste Jonglez escreveu:


You almost sound like I'm opposing all forms of "security" (whatever you
mean by that).  Of course we should promote the use of TLS and HTTPS on
the Internet, even though the trust model is flawed and implementations
are bloated/bugged.


I don't think Nico is saying that you oppose security. And I agree that
the CA model is practically broken. But we have alternatives to improving
the trustworthiness of that model. The recent HPKP RFC is one of those.
There are also preload lists, even though most of the software used to get
the sources do not use them.



My point is that in the context of packaging, we have different
requirements than for web browsing.  HTTPS does not provide authenticity
and integrity of the sources themselves, which is what we are interested
in.  PGP (preferably) and strong hash algorithms (as a substitute) should
be used for that.



Yes, preferably upstream must provide PGP signed sources. HTTPS only prevent
tampering in transit, which is nice, but it doesn't guarantee you didn't got
tampered software from upstream.



Besides this issue, I already mentioned another drawback of using HTTPS:
untrusted certificates (either expired, self-signed, or just signed by an
untrusted CA) will cause build failure.  This was a real issue for
OpenWRT, so they switched to using --no-check-certificate in 2010 [1] to
avoid build failures.  Sources are already validated with a checksum.



Well, relying only on checksums is not good enough in my opinion. We know
for a fact that hashing algorithms are built on top of *reasonable* chance
that collisions won't happen. Sure, the space of a SHA256 hash is huge, but
we must not just shrug over it. Because if we, as maintainers do, upstream
will think they don't need to provide signed sources, because hashes are
probably "good enough".


Anyway, some of my packages do not use HTTPS, and this is indeed mostly
because of laziness.  I consider this is a low priority task.
It does not mean that I am fundamentally opposed to the use of HTTPS,
especially for "big" providers like github which are not very likely to
have expired certs.

I had a look at the sources for my AUR packages, and here is the result:

- 5 fetched over HTTPS
- 7 fetched over git+https://

- 5 fetched over HTTP, with no HTTPS available
- 1 fetched over FTP, with no HTTPS available

- 5 fetched over HTTP while HTTPS is available (including 1 with a PGP 
signature)
- 6 fetched over git:// while git+https:// is available

So, less than half of them needed to be "fixed".  I just switched to HTTPS
for 10 out of the 11 fixable packages.  The only remaining one is
linux-mptcp, because I plan to move it away from git soon anyway.



The one thing I can take away from all this HTTPS or not discussion is
that we as maintainers are specially vulnerable. If we don't use whatever
tools at our disposal to be completely sure we didn't got the right source,
who knows how long those changes will go undetected? Heck, it's hard enough
finding bugs on *open source* software. Finding "intentional" ones on binaries
is harder.

Cheers,
Giancarlo Razzolini


pgpiffeAQb4KW.pgp
Description: PGP signature


<    2   3   4   5   6   7   8   9   10   11   >