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

[Baptiste Jonglez]

Hi Nicohood,

On Thu, Dec 01, 2016 at 04:23:27PM +0100, NicoHood wrote:
> you do not need to move the packages as fast as possible into
> community. I became TU month ago and arduino is still not in community
> because some issues needed to be solved first. So quality and security
> is more important here.

Agreed.

> About all this https discussion:
> I think we should all confirm with the gpg and https standards we made
> recently (and the string hashes that i suggested) and we should also try
> to increase the quality of AUR in general and especially as TU to advise
> other people to do so too.
> Packaging a secure chat program and being so lazy about https makes me
> wonder.
> 
> I think it'd be good for you to rethink the https (and gpg, hash) topic,
> because (especially) as secure chat messenger packager it'd be extremely
> important to me that you try to achieve the best security as possible.

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.

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.

To avoid repeating the same arguments, I agree with what seblu said on
arch-dev-public:

On Tue, Nov 01, 2016 at 04:03:04PM +0100, Sébastien Luttringer wrote:
> TLS is about security of the transportation of sources, not the security
> of sources themselves, that's why I asked, to know what you had in mind.
> 
> My definition of securing the sources, is a way to trust the sources at
> the build time, no matter the way they were fetched. I want to be sure
> that my sources are "correct" even if I get them by usb key, ftp, rsync
> or even if they were not corrupted locally by a btrfs bug.  And when
> possible, I want to be sure that the server (mirror or not) was not
> compromised (even at the first fetch).
> 
> Keeping that in mind, enforcing tls, doesn't improve much the source
> security.  In fact, it improves only security during the transportation
> of the sources at the cost of the caching.

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.

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.

Baptiste

[1] 
https://git.lede-project.org/?p=openwrt/source.git;a=blobdiff;f=scripts/download.pl;h=633a4f6f7d;hp=fe27df5e8f;hb=65fad8645d;hpb=5884b43b51


signature.asc
Description: PGP signature

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

[NicoHood]

On 11/29/2016 12:08 PM, Levente Polyak wrote:
> On 11/29/2016 11:33 AM, Baptiste Jonglez wrote:
>> For a package in [community], an expired certificate for the upstream
>> tarball is not a big deal, since it does not directly affect the Arch user
>> installing the package.  As a packager, you can just get the tarball by
>> some other means, or wait a few days so that somebody renews the cert.
>>
>> But for the AUR, an expired certificate would be annoying, as any user
>> trying to build the package (e.g. using an AUR helper) would encounter an
>> error.
>>
> 
> I call bullshit, especially as your cases are purely about github!
> Surly, as if they can't wait "a few days" in such an unlikely scenario.
> And what if upstream forgets to pay for their servers, it won't be
> available too.
> How often do you think that certificates stay in an expired state. Of
> cause there may be one or two cases that could be named, its still
> certainly nothing to build upon.
> 


About all this https discussion:
I think we should all confirm with the gpg and https standards we made
recently (and the string hashes that i suggested) and we should also try
to increase the quality of AUR in general and especially as TU to advise
other people to do so too. Packaging a secure chat program and being so
lazy about https makes me wonder.

Also you do not need to move the packages as fast as possible into
community. I became TU month ago and arduino is still not in community
because some issues needed to be solved first. So quality and security
is more important here.

I think it'd be good for you to rethink the https (and gpg, hash) topic,
because (especially) as secure chat messenger packager it'd be extremely
important to me that you try to achieve the best security as possible.

~Nico



signature.asc
Description: OpenPGP digital signature

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

[Christian Rebischke]

On Wed, Nov 30, 2016 at 11:38:56PM +0100, Baptiste Jonglez wrote:
> 1) Would linux-mptcp [1] have its place in [community]?  From what I read
>about linux-zen and linux-grsec [2], there does not seem to be strong
>objections, especially since most (or even all?) third-party kernel
>modules now use DKMS.

Hello Baptiste, depends on the votes. As far i can see the package 
has 9 votes. It's not that much. I would wait for more votes or discuss
this with the community if another version of the linux kernel in the
official repositories is asked for.

> 2) Some dependencies of my packages are orphaned in [community], such as
>msgpack-c [3].  As a TU, I guess it would make sense to adopt them.

Yep, this would make sense.

> 3) ring-daemon requires non-released versions of restbed [4] and asio [5].
>Is it better to wait for upstream to release a version of these libs,
>or is it acceptable to package a snapshot in [community]?
> 
> Baptiste
> 
> [1] https://aur.archlinux.org/packages/linux-mptcp/
> [2] 
> https://lists.archlinux.org/pipermail/arch-dev-public/2015-July/027311.html
> [3] https://www.archlinux.org/packages/community/x86_64/msgpack-c/
> [4] https://aur.archlinux.org/packages/restbed-latest/
> [5] https://aur.archlinux.org/packages/asio-latest/

It is definitly better to wait for a stable upstream release. Please do
not push snapshots of git branches in community when you can avoid that.


Best regards

chris


signature.asc
Description: PGP signature

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

[Baptiste Jonglez]

On Tue, Nov 29, 2016 at 08:11:39PM +0100, Lukas Fleischer wrote:
> I confirm that I sponsor Baptiste.
> 
> I have worked with him several times in the past; among other things he
> contributed several patches to calcurse back in 2012 [1]. He is
> knowledgable and I think he will be a great addition to the team!
> 
> Let the discussion period begin!

Thanks Lukas!

There are some points that I feel could be worth discussing (besides TLS…):

1) Would linux-mptcp [1] have its place in [community]?  From what I read
   about linux-zen and linux-grsec [2], there does not seem to be strong
   objections, especially since most (or even all?) third-party kernel
   modules now use DKMS.

2) Some dependencies of my packages are orphaned in [community], such as
   msgpack-c [3].  As a TU, I guess it would make sense to adopt them.

3) ring-daemon requires non-released versions of restbed [4] and asio [5].
   Is it better to wait for upstream to release a version of these libs,
   or is it acceptable to package a snapshot in [community]?


Baptiste

[1] https://aur.archlinux.org/packages/linux-mptcp/
[2] https://lists.archlinux.org/pipermail/arch-dev-public/2015-July/027311.html
[3] https://www.archlinux.org/packages/community/x86_64/msgpack-c/
[4] https://aur.archlinux.org/packages/restbed-latest/
[5] https://aur.archlinux.org/packages/asio-latest/


signature.asc
Description: PGP signature

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

[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.

I confirm that I sponsor Baptiste.

I have worked with him several times in the past; among other things he
contributed several patches to calcurse back in 2012 [1]. He is
knowledgable and I think he will be a great addition to the team!

Let the discussion period begin!

[1] http://git.calcurse.org/calcurse.git/log/?qt=author&q=Baptiste+Jonglez


signature.asc
Description: signature

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

[Doug Newgard]

On Tue, 29 Nov 2016 12:08:39 +0100
Levente Polyak  wrote:

> On 11/29/2016 11:33 AM, Baptiste Jonglez wrote:
> > For a package in [community], an expired certificate for the upstream
> > tarball is not a big deal, since it does not directly affect the Arch user
> > installing the package.  As a packager, you can just get the tarball by
> > some other means, or wait a few days so that somebody renews the cert.
> > 
> > But for the AUR, an expired certificate would be annoying, as any user
> > trying to build the package (e.g. using an AUR helper) would encounter an
> > error.
> >   
> 
> I call bullshit, especially as your cases are purely about github!
> Surly, as if they can't wait "a few days" in such an unlikely scenario.
> And what if upstream forgets to pay for their servers, it won't be
> available too.
> How often do you think that certificates stay in an expired state. Of
> cause there may be one or two cases that could be named, its still
> certainly nothing to build upon.
> 
> 
> >> I never get why people always make such a big fuzz in not pulling over TLS.
> >> The same argumentation could be used for the regular tarballs and I
> >> repeat, the outcome is simple: use https, easy as that.  
> > 
> > Well, I agree with the outcome of the discussion, which was basically "One
> > way or the other does not change much security-wise, so let's switch to
> > HTTPS if doing so does not require significant efforts".
> >   
> 
> Fine, if you were already aware of the outcome, why this useless waste
> of time to discuss it yet again. Especially a TU applicant should follow
> chosen best practices and decisions. The AUR should not be any different
> from how they should be in the binary repos, so I expect to see those
> changes in your packages as well.

Git packages were not discussed, and https wasn't really "chosen best
practices", it was more "eh, why not". Getting all emotional because someone
doesn't buy into your reteric 100% isn't helping anyone.

> >>  
>  libringclient-git
>  - a VCS package should always provide its non-VCS package variant like
>    'libringclient'
>  - If there is no strong reason to depend on a git variant, always depend
>    on the non VCS, in this case ring-daemon instead of ring-daemon-git  
> >>>
> >>> See the above comment on gnome-ring-git.  
> >>
> >> And here is the -git hell I describes, either take all -git or none...
> >> that's not how it should be. Think how it would be if every library
> >> would be like that, that would mean you need to use -git for the whole
> >> system just because you switch a single package. Don't enforce it just
> >> because... if such happens people will figure.  
> > 
> > Again, the constraints are a bit different on the AUR and on a binary
> > repository.  What I try to ensure is that somebody running e.g. "yaourt -S
> > ring-gnome-git" will not have compilation issues.  If ring-gnome-git
> > depends on libringclient, then the former will not build if the API
> > provided by libringclient has changed recently.
> >   
> 
> Again, even through there are quite obviously no -git packages in the
> binary repository, the PKGBUILDs in the AUR should not be created in a
> different way then you would write them in the binary repo. Also AUR
> packages are influenced by each other and just completely abandon all
> provides is clearly a very bad practice. As easy as that.
> 
> https://lists.archlinux.org/pipermail/aur-general/2016-October/032845.html

Reality time: The AUR is different than the binary repos. Yes, ideally the
PKGBUILD should be able to go directly to the binary repos, but reality needs
to take precedence over blind ideology. AUR packages are managed differently
than repo packages and in the vast majority of cases are built differently as
well.

I agree with you in this case, but please don't use this dubious argument.

It does make sense to depend on the -git versions in cases like this as well.
We're not talking everything, we're talking everything in a given stack
provided by a single upstream. Applying this to another example, Qt5 packages
from git should depend on other Qt5 packages from git, not on their stable
versions.

Doug


pgpSgMvvIeLnj.pgp
Description: OpenPGP digital signature

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

[Eli Schwartz via aur-general]

On 11/28/2016 06:29 PM, Baptiste Jonglez wrote:
> On the other hand, if one day the TLS certificate becomes invalid (expired
> certificate, untrusted CA, etc), the package would fail to build.  I see
> this as a significant drawback of using git+https://.

When you say drawback, are you referring to TLS performing its intended
role?
I am really confused as to what you are trying to accomplish here.

I thought the whole point of switching to git+https:// is in order that
builds should fail when suspicious things happen to the source code,
like getting served from a domain with a very suspiciously broken
certificate.

The CACERT model assumes website owners are still alive and capable of
renewing their certificate before people call their customer service (if
applicable) number to complain that they can't access the website.
On the whole, it tends to be pretty successful. (Leaving aside peoples'
questions on the premise of the model, at least when we use it we use it
according to spec.)

An untrusted CA is, well, untrusted. Why would I want to build a package
authenticated by them, if I don't trust them?

Seriously, your argument is an argument against using TLS on the World
Wide Web. "I don't wanna use TLS, because now I cannot access all these
broken websites anymore!"

-- 
Eli Schwartz

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

[georg]

Well, I actually withdraw this sentence, the discussion period is
pretty much about discussing :P


technically the discussion period has not even begun, since there was no 
confirmation of sponsorship yet.

g

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

[Levente Polyak]

On November 29, 2016 12:08:39 PM GMT+01:00, Levente Polyak 
 wrote:
>Fine, if you were already aware of the outcome, why this useless waste
>of time to discuss it yet again.

Well, I actually withdraw this sentence, the discussion period is pretty much 
about discussing :P

Cheers, 
Levente 

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

[Levente Polyak]

On 11/29/2016 11:33 AM, Baptiste Jonglez wrote:
> For a package in [community], an expired certificate for the upstream
> tarball is not a big deal, since it does not directly affect the Arch user
> installing the package.  As a packager, you can just get the tarball by
> some other means, or wait a few days so that somebody renews the cert.
> 
> But for the AUR, an expired certificate would be annoying, as any user
> trying to build the package (e.g. using an AUR helper) would encounter an
> error.
> 

I call bullshit, especially as your cases are purely about github!
Surly, as if they can't wait "a few days" in such an unlikely scenario.
And what if upstream forgets to pay for their servers, it won't be
available too.
How often do you think that certificates stay in an expired state. Of
cause there may be one or two cases that could be named, its still
certainly nothing to build upon.


>> I never get why people always make such a big fuzz in not pulling over TLS.
>> The same argumentation could be used for the regular tarballs and I
>> repeat, the outcome is simple: use https, easy as that.
> 
> Well, I agree with the outcome of the discussion, which was basically "One
> way or the other does not change much security-wise, so let's switch to
> HTTPS if doing so does not require significant efforts".
> 

Fine, if you were already aware of the outcome, why this useless waste
of time to discuss it yet again. Especially a TU applicant should follow
chosen best practices and decisions. The AUR should not be any different
from how they should be in the binary repos, so I expect to see those
changes in your packages as well.

>>
 libringclient-git
 - a VCS package should always provide its non-VCS package variant like
   'libringclient'
 - If there is no strong reason to depend on a git variant, always depend
   on the non VCS, in this case ring-daemon instead of ring-daemon-git
>>>
>>> See the above comment on gnome-ring-git.
>>
>> And here is the -git hell I describes, either take all -git or none...
>> that's not how it should be. Think how it would be if every library
>> would be like that, that would mean you need to use -git for the whole
>> system just because you switch a single package. Don't enforce it just
>> because... if such happens people will figure.
> 
> Again, the constraints are a bit different on the AUR and on a binary
> repository.  What I try to ensure is that somebody running e.g. "yaourt -S
> ring-gnome-git" will not have compilation issues.  If ring-gnome-git
> depends on libringclient, then the former will not build if the API
> provided by libringclient has changed recently.
> 

Again, even through there are quite obviously no -git packages in the
binary repository, the PKGBUILDs in the AUR should not be created in a
different way then you would write them in the binary repo. Also AUR
packages are influenced by each other and just completely abandon all
provides is clearly a very bad practice. As easy as that.

https://lists.archlinux.org/pipermail/aur-general/2016-October/032845.html

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

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

[Baptiste Jonglez]

On Tue, Nov 29, 2016 at 01:04:47AM +0100, Levente Polyak wrote:
> On 11/29/2016 12:29 AM, Baptiste Jonglez wrote:
> >> - you should use git+https:// instead of plain git:// even through the
> >>   CA world is a bit wonky it still authenticates the server and at the
> >>   very bare minimum adds confidentiality.
> > 
> > I don't like the "everything-over-HTTP(S)" approach in general, especially
> > when there is a dedicated protocol that works (yes, I know, this is basic 
> > ranting).
> > 
> > Assuming the git revision is identified by a commit hash, I see no value
> > in using HTTPS for authentication or verification.  I agree it is useful
> > however when building from a tag or a branch, as you correctly pointed out
> > for another package.
> > 
> > On the other hand, if one day the TLS certificate becomes invalid (expired
> > certificate, untrusted CA, etc), the package would fail to build.  I see
> > this as a significant drawback of using git+https://.
> 
> Well pulling over TLS was discussed over and over and over and over
> again and we ended up that we just do it for all of our packages if
> available...
> Thats why this came up in the first place:
> https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/

Yes, I saw the discussion on arch-dev-public (but obviously could not
participate).

> I quote dave: "Security is not a binary thing".
> It adds another layer of security, if you like it or not. It
> authenticates the server (yes there may be untrusted CA, so? *shrug*)
> and i repeat again: at the very bare minimum adds confidentiality. Feel
> free to re-read the arch-dev-public thread, the outcome was the
> mentioned todo list.
> 
> I heard a lot of opinions and some of them are understandable... but
> saying that its a significant drawback as the certificate could possible
> be invalid/expired is certainly nothing i would _ever_ consider as such.

For a package in [community], an expired certificate for the upstream
tarball is not a big deal, since it does not directly affect the Arch user
installing the package.  As a packager, you can just get the tarball by
some other means, or wait a few days so that somebody renews the cert.

But for the AUR, an expired certificate would be annoying, as any user
trying to build the package (e.g. using an AUR helper) would encounter an
error.

> I never get why people always make such a big fuzz in not pulling over TLS.
> The same argumentation could be used for the regular tarballs and I
> repeat, the outcome is simple: use https, easy as that.

Well, I agree with the outcome of the discussion, which was basically "One
way or the other does not change much security-wise, so let's switch to
HTTPS if doing so does not require significant efforts".

> >> ring-gnome-git
> >> - a VCS package should always provide its non-VCS package variant like
> >>   'ring-gnome'
> > 
> > Actually, the missing "provides" is intended.  The Ring components are
> > interdependent and get updated quite frequently, so at any given time
> > `ring-foo` and `ring-foo-git` are likely offer a different API/ABI.
> > 
> > More practically, when the "provides" was here, I had issues with AUR
> > users mixing -git and non-git ring packages and complaining of building
> > errors.
> > 
> 
> This could be the case for literally _any_ library f.e. and still all of
> them have their corresponding provides. If there would be anything
> depending on ring-gnome you created an unresolvable hell be just
> conflicting it because it may have API changes.
> 
> 
> >> libringclient-git
> >> - a VCS package should always provide its non-VCS package variant like
> >>   'libringclient'
> >> - If there is no strong reason to depend on a git variant, always depend
> >>   on the non VCS, in this case ring-daemon instead of ring-daemon-git
> > 
> > See the above comment on gnome-ring-git.
> 
> And here is the -git hell I describes, either take all -git or none...
> that's not how it should be. Think how it would be if every library
> would be like that, that would mean you need to use -git for the whole
> system just because you switch a single package. Don't enforce it just
> because... if such happens people will figure.

Again, the constraints are a bit different on the AUR and on a binary
repository.  What I try to ensure is that somebody running e.g. "yaourt -S
ring-gnome-git" will not have compilation issues.  If ring-gnome-git
depends on libringclient, then the former will not build if the API
provided by libringclient has changed recently.

But you're right, it's a mess.  I updated the *ring*-git packages so that
they only depend on non-git packages, and they now all provide their
non-git version.

Anyway, I was thinking of orphaning all those -git Ring packages, since I
don't use them anymore and they take time to maintain.

Baptiste


signature.asc
Description: PGP signature

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

[Levente Polyak]

On 11/29/2016 12:29 AM, Baptiste Jonglez wrote:
>> - you should use git+https:// instead of plain git:// even through the
>>   CA world is a bit wonky it still authenticates the server and at the
>>   very bare minimum adds confidentiality.
> 
> I don't like the "everything-over-HTTP(S)" approach in general, especially
> when there is a dedicated protocol that works (yes, I know, this is basic 
> ranting).
> 
> Assuming the git revision is identified by a commit hash, I see no value
> in using HTTPS for authentication or verification.  I agree it is useful
> however when building from a tag or a branch, as you correctly pointed out
> for another package.
> 
> On the other hand, if one day the TLS certificate becomes invalid (expired
> certificate, untrusted CA, etc), the package would fail to build.  I see
> this as a significant drawback of using git+https://.
> 

Well pulling over TLS was discussed over and over and over and over
again and we ended up that we just do it for all of our packages if
available...
Thats why this came up in the first place:
https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/

I quote dave: "Security is not a binary thing".
It adds another layer of security, if you like it or not. It
authenticates the server (yes there may be untrusted CA, so? *shrug*)
and i repeat again: at the very bare minimum adds confidentiality. Feel
free to re-read the arch-dev-public thread, the outcome was the
mentioned todo list.

I heard a lot of opinions and some of them are understandable... but
saying that its a significant drawback as the certificate could possible
be invalid/expired is certainly nothing i would _ever_ consider as such.
I never get why people always make such a big fuzz in not pulling over TLS.
The same argumentation could be used for the regular tarballs and I
repeat, the outcome is simple: use https, easy as that.


>> ring-gnome-git
>> - a VCS package should always provide its non-VCS package variant like
>>   'ring-gnome'
> 
> Actually, the missing "provides" is intended.  The Ring components are
> interdependent and get updated quite frequently, so at any given time
> `ring-foo` and `ring-foo-git` are likely offer a different API/ABI.
> 
> More practically, when the "provides" was here, I had issues with AUR
> users mixing -git and non-git ring packages and complaining of building
> errors.
> 

This could be the case for literally _any_ library f.e. and still all of
them have their corresponding provides. If there would be anything
depending on ring-gnome you created an unresolvable hell be just
conflicting it because it may have API changes.


>> libringclient-git
>> - a VCS package should always provide its non-VCS package variant like
>>   'libringclient'
>> - If there is no strong reason to depend on a git variant, always depend
>>   on the non VCS, in this case ring-daemon instead of ring-daemon-git
> 
> See the above comment on gnome-ring-git.

And here is the -git hell I describes, either take all -git or none...
that's not how it should be. Think how it would be if every library
would be like that, that would mean you need to use -git for the whole
system just because you switch a single package. Don't enforce it just
because... if such happens people will figure.


cheers,
Levente




signature.asc
Description: OpenPGP digital signature

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

[Baptiste Jonglez]

Hi,

On Mon, Nov 28, 2016 at 12:20:40PM +0100, Levente Polyak wrote:
> > Don't hesitate if you have any questions, or comments on my AUR packages!
> 
> Sure, I always take a look at all packages of an applicant and suggest
> changes before I decide how to vote... so here we go :P

Yes, I was expecting this :)

> pjproject
> - if you must use -j1 for every make call, you can simply add
>   !makeflags to the options instead.

Good catch, this was actually copied unchanged from the pjproject package
.

I just tested building in parallel on a 16-core machine, and it works
fine, so I removed the -j1.  The original issue must have been fixed
upstream.

> linux-mptcp
> - #tag= should never be used for git packages, instead store the commit
>   hash for the tag and always use the #tag= prefix. A named tag does not
>   mean much and you won't even notice when upstream changes such.
>   This is especially bad when using plain git:// :-)

Interesting, I had never thought about this issue.

I think I will switch to a tarball as suggested by Eli, I didn't know that
github provides tarballs for each commit.  The downside is that $pkgver
will no longer be computed automatically, I will have to update it
manually.

> - You should add an initramfs post transaction hook like in the regular
>   kernel [0] to avoid problems like described in #51818.

Thanks for the hint, will do.

> ring-daemon:
> - just a feeling but a description with 202 chars feels quite long :P

Is there a hard limit somewhere, maybe in the AUR?

Anyway, upstream has changed its description to a shorter one, so I used
that instead.  It's now "only" 130 chars.

> - you should use git+https:// instead of plain git:// even through the
>   CA world is a bit wonky it still authenticates the server and at the
>   very bare minimum adds confidentiality.

I don't like the "everything-over-HTTP(S)" approach in general, especially
when there is a dedicated protocol that works (yes, I know, this is basic 
ranting).

Assuming the git revision is identified by a commit hash, I see no value
in using HTTPS for authentication or verification.  I agree it is useful
however when building from a tag or a branch, as you correctly pointed out
for another package.

On the other hand, if one day the TLS certificate becomes invalid (expired
certificate, untrusted CA, etc), the package would fail to build.  I see
this as a significant drawback of using git+https://.

> pius
> - documentation, or hint to documentations inside .install files always
>   feels like the wrong place. If there is documentation in
>   /usr/share/doc/pius then people will find it.

I generally agree with this.  In this case, however, the suggested
configuration option is really needed on Arch when using the new Gnupg key
format, and this is not explicitely documented upstream.

I think I will send a patch upstream to fix the issue (auto-detect the
keyring format) and remove the .install file altogether with the next
release.

> ring-gnome-git
> - a VCS package should always provide its non-VCS package variant like
>   'ring-gnome'

Actually, the missing "provides" is intended.  The Ring components are
interdependent and get updated quite frequently, so at any given time
`ring-foo` and `ring-foo-git` are likely offer a different API/ABI.

More practically, when the "provides" was here, I had issues with AUR
users mixing -git and non-git ring packages and complaining of building
errors.

> libringclient-git
> - a VCS package should always provide its non-VCS package variant like
>   'libringclient'
> - If there is no strong reason to depend on a git variant, always depend
>   on the non VCS, in this case ring-daemon instead of ring-daemon-git

See the above comment on gnome-ring-git.

> - the pkgver() function doesn't sound specific enough, it just returns
>   a simple date without anything else (f.e. 20161110) which means
>   building on the same date can result in the same package version while
>   being built from quite different source states.

Good point, I can switch to the `git describe` method used by most of my
other git packages.

> udrawgraph
> - just a bit of style, but we have arch specific depends like
>   depends_x86_64 which looks better :P

Fixed.  This package long predates arch-specific depends.

> tsocks-ipv6
> - this looks like it should also provide tsocks as it just adds
>   additional v6 support

Indeed, fixed.

> coq-doc
> - the sources must be prefixed with the version as otherwise older
>   tarballs will "conflict". on top of that "stdlib.tar.gz" sounds
>   a bit too generic and may overlap with another package, conisder
>   also including the package name into the prefix to avoid such
>   situation.

Fixed.

> - sources that are not unique (like "/v$pkgver.tar.gz" from github)
>   should be prefixed with the package name (+ of cause pkgver) to
>   be unique. This is important if you configures shared SRCDEST to
>   avoid conflicts.

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

[Eli Schwartz via aur-general]

On 11/28/2016 11:26 AM, Levente Polyak wrote:
> When using a commit hash you gain basically two things out of the box:
> - get aware if wonky upstream changes something
> - get an integrity value that a potential attacker must defeat, which
>   not be the easiest task for a full commit hash (for a short partial
>   hash there are of cause some PoC's/tools available)

Hmm, that is true. git has builtin integrity checks but also ends up
almost completely lacking in any capacity for authentication. At least
as far as makepkg is concerned.

As a user, I think I would still prefer tarballs rather than unnecessary
git history... but if you must use git for non-VCS packages then commit
hashes are useful.

> In fact we already had several discussions in the IRC about this topic
> and what I mentioned above was always sufficient to justify getting rid
> of it. The only reason we don't yet have a TODO list to switch away from
> #tag= is simply lack of time (but its still on my todo list besides
> getting a TODO list for git:// sources).
> 
> If a remember correctly either heftig or JGC has created a convenience
> script to update a PKGBUILDs values, maybe they share it with us :)

That is very interesting information, thanks for mentioning it. My
curiosity is now sated. :)

>>> net-tools-mptcp
>>> - #branch= should never be used for non VCS git packages, instead store
>>>   the commit hash for the tag and always use the #tag= prefix. A named
>>>   branch does not mean much and you won't even notice when upstream
>>>   changes or adds commits to such.
>>
>> It has a pkgver() function which generates a VCS-style pkgver, and draws
>> from a #branch= so actually it is a VCS git package. The problem is that
>> it doesn't say so in the pkgname. :p
>>
> 
> Well yes... and no... though the same while looking at it but at the end
> I'm not quite sure what the intention of Baptiste is. As the branch used
> is a simple version identifier, I assumed he pretty much wanted to have
> a static versioned package.
> pkgver() itself does not tell us which one it should be, if you have a
> static version package that pulls from a git commit hash you can have a
> pkgver() function for convenience.

I have noticed that trick in repo packages, yeah. But this is pulling
from a branch... anything that has changing sources would be VCS, except
that without both #branch= and a pkgver() it is merely broken beyond repair.

Now, while some projects do use versioned branches to separate
development on apparently incompatible release branches, it could be
that this upstream only commits to that branch when releasing, and
otherwise it will never get new commits (so it is a static versioning
branch, and the tag itself wasn't used for inexplicable reasons which
justify themselves because "because"). I couldn't be bothered to read
the PKGBUILD *and* check the upstream sources, just to make random
comments about style. :p
(If so, why does the pkgver function specifically use `git describe
--long` when `git describe` would by default exclude
"r0.guselesshashpointingtoatag"` ???)

But either way, you said "you won't even notice when upstream changes or
adds commits to such" and the *current* pkgver function guarantees he
*will* notice.

-- 
Eli Schwartz

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

[Levente Polyak]

On 11/28/2016 05:05 PM, Eli Schwartz via aur-general wrote:
> On 11/28/2016 06:20 AM, Levente Polyak wrote:
>> - #tag= should never be used for git packages, instead store the commit
>>   hash for the tag and always use the #tag= prefix.
> 
> Typo?
> 

uuups, you caught me :P My bad! Of cause this should be #commit=
Thanks Eli!

>>   A named tag does not mean much and you won't even notice when upstream
>>   changes such. This is especially bad when using plain git:// :-)
> 
> Well, I should hope upstream doesn't re-release their tags... if so, you
> might have other problems.

Well I already encountered a re-release at least twice, shame on them!
When using a commit hash you gain basically two things out of the box:
- get aware if wonky upstream changes something
- get an integrity value that a potential attacker must defeat, which
  not be the easiest task for a full commit hash (for a short partial
  hash there are of cause some PoC's/tools available)

> But from the repo PKGBUILDs I have seen, it seems to me as though there
> is no policy whatsoever... some devs do like you suggest, other devs are
> more than happy to use "#tag=$pkgver".

Well i assume "more happy" just means "able to be more lazy" (without
any offense to anyone!) :P

In fact we already had several discussions in the IRC about this topic
and what I mentioned above was always sufficient to justify getting rid
of it. The only reason we don't yet have a TODO list to switch away from
#tag= is simply lack of time (but its still on my todo list besides
getting a TODO list for git:// sources).

If a remember correctly either heftig or JGC has created a convenience
script to update a PKGBUILDs values, maybe they share it with us :)

> 
>> udrawgraph
>> - just a bit of style, but we have arch specific depends like
>>   depends_x86_64 which looks better :P
> 
> That isn't "style", that is something that *must* be done, for practical
> purposes. makepkg --printsrcinfo relies on arch-dependent variables that
> are *always* there, in order to actually print truthful values. Also,
> arch-dependent sources done properly will allow updpkgsums to properly
> update, rather than merging the local *sums_$CARCH into the main
> checksums array.
> 
> All that matters a lot in the AUR, which depends on .SRCINFO, even if it
> doesn't matter so much in the repos which depend on the metadata in a
> built package.
> 

Fair enough... that's a pretty good point why it should be mandatory.
Did not really take the .SRCINFO into account for this particular case.

>> net-tools-mptcp
>> - #branch= should never be used for non VCS git packages, instead store
>>   the commit hash for the tag and always use the #tag= prefix. A named
>>   branch does not mean much and you won't even notice when upstream
>>   changes or adds commits to such.
> 
> It has a pkgver() function which generates a VCS-style pkgver, and draws
> from a #branch= so actually it is a VCS git package. The problem is that
> it doesn't say so in the pkgname. :p
> 

Well yes... and no... though the same while looking at it but at the end
I'm not quite sure what the intention of Baptiste is. As the branch used
is a simple version identifier, I assumed he pretty much wanted to have
a static versioned package.
pkgver() itself does not tell us which one it should be, if you have a
static version package that pulls from a git commit hash you can have a
pkgver() function for convenience.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

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

[Eli Schwartz via aur-general]

On 11/28/2016 06:20 AM, Levente Polyak wrote:
> linux-mptcp
> - you should use git+https:// instead of plain git:// even through the
>   CA world is a bit wonky it still authenticates the server and at the
>   very bare minimum adds confidentiality.

Now that you mention it, this does seem rather obvious... maybe I should
switch my own AUR packages to do this. It is just as fast, so there is
no real downside.

Now I'm glad I read these threads!

> - #tag= should never be used for git packages, instead store the commit
>   hash for the tag and always use the #tag= prefix.

Typo?

>   A named tag does not mean much and you won't even notice when upstream
>   changes such. This is especially bad when using plain git:// :-)

Well, I should hope upstream doesn't re-release their tags... if so, you
might have other problems.

Anyway, I would instead suggest that there is no need to pull the source
code for stable releases via git (which for long-lived projects like the
Linux kernel means a *lot* of history to download).
I can barely understand that, in the case of e.g. systemd which uses git
to backport commits. Although really, github allows you to download a
commit as a patch file...
I usually only see that in repo PKGBUILDs. I guess since the devs are
usually the only ones building the package, and the dev keeps the clone
around, it "doesn't matter" that hypothetical others would have to clone
all that history?

But from the repo PKGBUILDs I have seen, it seems to me as though there
is no policy whatsoever... some devs do like you suggest, other devs are
more than happy to use "#tag=$pkgver".

> udrawgraph
> - just a bit of style, but we have arch specific depends like
>   depends_x86_64 which looks better :P

That isn't "style", that is something that *must* be done, for practical
purposes. makepkg --printsrcinfo relies on arch-dependent variables that
are *always* there, in order to actually print truthful values. Also,
arch-dependent sources done properly will allow updpkgsums to properly
update, rather than merging the local *sums_$CARCH into the main
checksums array.

All that matters a lot in the AUR, which depends on .SRCINFO, even if it
doesn't matter so much in the repos which depend on the metadata in a
built package.

> net-tools-mptcp
> - #branch= should never be used for non VCS git packages, instead store
>   the commit hash for the tag and always use the #tag= prefix. A named
>   branch does not mean much and you won't even notice when upstream
>   changes or adds commits to such.

It has a pkgver() function which generates a VCS-style pkgver, and draws
from a #branch= so actually it is a VCS git package. The problem is that
it doesn't say so in the pkgname. :p

-- 
Eli Schwartz

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

[Levente Polyak]

Hi Bapiste,

> 
> Don't hesitate if you have any questions, or comments on my AUR packages!
> 

Sure, I always take a look at all packages of an applicant and suggest
changes before I decide how to vote... so here we go :P
Excuse me if I copy-paste some blocks, its just simpler doing so :)


ring-daemon:
- just a feeling but a description with 202 chars feels quite long :P

opendht:
- you should use git+https:// instead of plain git:// even through the
  CA world is a bit wonky it still authenticates the server and at the
  very bare minimum adds confidentiality.

sig2dot
- every reference to $pkgdir should be put inside double-quotes in case
  it contains spaces.

pjproject
- if you must use -j1 for every make call, you can simply add
  !makeflags to the options instead.

opendht-git
- you should use git+https:// instead of plain git:// even through the
  CA world is a bit wonky it still authenticates the server and at the
  very bare minimum adds confidentiality.

pius
- documentation, or hint to documentations inside .install files always
  feels like the wrong place. If there is documentation in
  /usr/share/doc/pius then people will find it.

linux-mptcp
- you should use git+https:// instead of plain git:// even through the
  CA world is a bit wonky it still authenticates the server and at the
  very bare minimum adds confidentiality.
- #tag= should never be used for git packages, instead store the commit
  hash for the tag and always use the #tag= prefix. A named tag does not
  mean much and you won't even notice when upstream changes such.
  This is especially bad when using plain git:// :-)
- You should add an initramfs post transaction hook like in the regular
  kernel [0] to avoid problems like described in #51818.

coq-doc
- the sources must be prefixed with the version as otherwise older
  tarballs will "conflict". on top of that "stdlib.tar.gz" sounds
  a bit too generic and may overlap with another package, conisder
  also including the package name into the prefix to avoid such
  situation.

asio-latest
- you should use git+https:// instead of plain git:// even through the
  CA world is a bit wonky it still authenticates the server and at the
  very bare minimum adds confidentiality.
- every reference to $pkgdir should be put inside double-quotes in case
  it contains spaces.

ring-gnome-git
- a VCS package should always provide its non-VCS package variant like
  'ring-gnome'
- the pkgver() function doesn't sound specific enough, it just returns
  a simple date without anything else (f.e. 20161110) which means
  building on the same date can result in the same package version while
  being built from quite different source states.

restbed-latest
- you should use git+https:// instead of plain git:// even through the
  CA world is a bit wonky it still authenticates the server and at the
  very bare minimum adds confidentiality.

restbed
- #tag= should never be used for git packages, instead store the commit
  hash for the tag and always use the #tag= prefix. A named tag does not
  mean much and you won't even notice when upstream changes such.

kashmir
- you should use git+https:// instead of plain git:// even through the
  CA world is a bit wonky it still authenticates the server and at the
  very bare minimum adds confidentiality.

udrawgraph
- just a bit of style, but we have arch specific depends like
  depends_x86_64 which looks better :P
- every reference to $pkgdir should be put inside double-quotes in case
  it contains spaces.
- every reference to $srcdir should be put inside double-quotes in case
  it contains spaces.

ring-daemon-git
- a VCS package should always provide/conflicts its non-VCS package
  variant like 'ring-daemon'
- just a feeling but a description with 202 chars feels quite long :P
- the pkgver() function doesn't sound specific enough, it just returns
  a simple date without anything else (f.e. 20161110) which means
  building on the same date can result in the same package version while
  being built from quite different source states.

libringclient-git
- a VCS package should always provide its non-VCS package variant like
  'libringclient'
- If there is no strong reason to depend on a git variant, always depend
  on the non VCS, in this case ring-daemon instead of ring-daemon-git
- the pkgver() function doesn't sound specific enough, it just returns
  a simple date without anything else (f.e. 20161110) which means
  building on the same date can result in the same package version while
  being built from quite different source states.

npiet
- every reference to $pkgdir should be put inside double-quotes in case
  it contains spaces.

tsocks-ipv6
- this looks like it should also provide tsocks as it just adds
  additional v6 support

iproute-mptcp
- sources that are not unique (like "/v$pkgver.tar.gz" from github)
  should be prefixed with the package name (+ of cause pkgver) to
  be unique. This is important if you configures shared SRCDEST to
  avoid conflicts.

[aur-general] TU Application: Baptiste Jonglez

[Baptiste Jonglez]

Hello,

I would like to apply to become a TU.  Lukas Fleischer has kindly accepted
to sponsor my application.

I am currently a PhD student in France, doing research on networking.  I
am also involved in several projects, in particular DIY ISPs [1], the FDN
Federation in France [2], OpenWRT/LEDE [3], etc.  The common motivation is
to work towards a more open and decentralised Internet.

I have been using Arch Linux on my personal laptops since around 2010.
I think I have never had to reinstall Arch Linux on my main laptop since
then!  In the past, I was also running Arch Linux on my servers, but I
since switched to Debian for all my servers.

By the way, I am not very active on the mailing lists, but I read most
threads on aur-general and arch-dev-public.

In the AUR, I maintain 33 packages [4], of which the most noteworthy are:

- ring: a secure and distributed voice/video/chat communication software
  (Ring is the successor of SFLphone, basically using a DHT to find
  contacts instead of relying on SIP servers, and tons of other
  improvements)

- coq: a formal proof assistant written in Ocaml

- linux-mptcp: the linux kernel with support for Multipath TCP, from
  Université Catholique de Louvain

The other packages I maintain are either dependencies of the above, or
small software tools that I packaged when I needed them.  I regularly use
about 2/3 of these packages, but I still try to maintain the other ones.

I mostly want to become a TU to push ring, coq and linux-mptcp to the
[community] binary repository.  These packages all take a fairly long time
to build, and additionally the Ring packages are a dependency nightmare.
It is often necessary for users to rebuild all dependencies simultaneously
because of API/ABI changes, and this is impractical and time-consuming
when using the AUR, especially given the number of dependencies.

Regarding linux-mptcp, it is not popular enough at the moment, and there
are few kernel packages in binary repositories.  I would wait for the
package to obtain 10 votes (and confirmation that another kernel package
is indeed welcome in the repositories) before pushing it to [community].

As a final note, I am already using the devtools to test-build my AUR
packages in clean chroots on a server.  This provides some form of
"continuous integration" of my AUR packages, although it is not completely
satisfying right now.

Don't hesitate if you have any questions, or comments on my AUR packages!

Baptiste

[1] https://diyisp.org/dokuwiki/doku.php
[2] https://www.ffdn.org/en
[3] https://lede-project.org/
[4] https://aur.archlinux.org/packages/?O=0&SeB=m&K=zorun&SB=v&SO=d


signature.asc
Description: PGP signature

Re: [aur-general] TU Application NicoHood

[Maxime Gauduin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Voting period is over, looks like your application was accepted. 
Congratulations and welcome to the team!

You will find the TODO list for new TUs on the wiki [1].

I just gave you TU status on AUR and will take care of filing a bug report to 
get your PGP key signed as soon as I can. Feel free to pîng me on IRC so I can 
give you the password to #archlinux-tu.

[1] https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines

Cheers,
- - - --
Maxime
-BEGIN PGP SIGNATURE-
Version: OpenPGP.js v2.3.2
Comment: http://openpgpjs.org

wsBcBAEBCAAQBQJX2tw2CRCv9dlQmLxv9QAAF9gIAKkeHA+E8yPi74NYM+7T
MszpT+qqr3TXQftWkXJ3QhfaADHAjYVplJQKMt2sutOLmq+OkQzctWepb4XF
LQo50IYF30X/F2iSqcb50U8/3T3DTVyPPToJMSwSksks95XsuVeqNtEdtM4R
YIIWao0sjA2dqDACeAGGdkbsSC0TfMlVmMS14CUcastoIE08QV3GCqwYzSxR
ljpk1AzM2YRWigp3HmvsV6jnrSU/G5SkB3IoWdyYJJcoqvK8xfxohAhwkmz3
/Y8v2SOEuS9WUZBOTW1c3oxDyatKLVNL7+e6PJiptXvEmw93gt6zCo+Kopq3
pw0x4N5BZcAINioqI3Y3vmw=
=sCOd
-END PGP SIGNATURE-

Re: [aur-general] TU Application NicoHood

[Maxime Gauduin]

The discussion period is now over, please cast your votes over on AUR.

Cheers,

September 3 2016 9:19 PM, "Maxime Gauduin"  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi all,
> 
> I confirm my sponsorship of this guy.
> 
> @Doug: I agree that lying about this is unacceptable, I believe Nico got the 
> message and won't
> suggest anything like this again.
> 
> That said, let the discussion period continue.
> 
> Cheers,
> - --
> Maxime
> -BEGIN PGP SIGNATURE-
> Version: OpenPGP.js v2.3.2
> Comment: http://openpgpjs.org
> 
> wsBcBAEBCAAQBQJXyyHSCRCv9dlQmLxv9QAA5QEIALR3FGEckEzK9z5b27tf
> 41mj93BMvUoOx6SxKfrBBXTtBNj88YMVa2jvzFbxgNqf6r2X9chH6z85pQQt
> 4LfgtFBJlx0/ne/MIFhOHJECLNtenhXZB7KTg0LegrnXDrio2XWSlODJQFIe
> 6fAU2Gy/GhtdXEAt3KoPJDwhcHddv0vw8e0pGaoCSV3shRhoayKLsFM+becI
> QtfiFVCV9DlKTqJV5j8NX1wLhyXBMYztKaFsHQmIGpk+VkOWG8wU+AxxakOj
> kK2rpBykaZoSVRFfl1eswNafz8U2BXWA/gK0hCUhGuYoAZyvIhd4tx8vXuXk
> 2/ZVR1Mi4P/6bU1mkBOO1ZY=
> =rdOA
> -END PGP SIGNATURE-

-- 
Maxime

Re: [aur-general] TU Application NicoHood

[Maxime Gauduin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi all,

I confirm my sponsorship of this guy.

@Doug: I agree that lying about this is unacceptable, I believe Nico got the 
message and won't suggest anything like this again.

That said, let the discussion period continue.

Cheers,
- --
Maxime
-BEGIN PGP SIGNATURE-
Version: OpenPGP.js v2.3.2
Comment: http://openpgpjs.org

wsBcBAEBCAAQBQJXyyHSCRCv9dlQmLxv9QAA5QEIALR3FGEckEzK9z5b27tf
41mj93BMvUoOx6SxKfrBBXTtBNj88YMVa2jvzFbxgNqf6r2X9chH6z85pQQt
4LfgtFBJlx0/ne/MIFhOHJECLNtenhXZB7KTg0LegrnXDrio2XWSlODJQFIe
6fAU2Gy/GhtdXEAt3KoPJDwhcHddv0vw8e0pGaoCSV3shRhoayKLsFM+becI
QtfiFVCV9DlKTqJV5j8NX1wLhyXBMYztKaFsHQmIGpk+VkOWG8wU+AxxakOj
kK2rpBykaZoSVRFfl1eswNafz8U2BXWA/gK0hCUhGuYoAZyvIhd4tx8vXuXk
2/ZVR1Mi4P/6bU1mkBOO1ZY=
=rdOA
-END PGP SIGNATURE-

Re: [aur-general] TU Application NicoHood

[Antonio Rojas]

Jelle van der Waa wrote:

>> * (spotify)
> 
> It does require an ancient libcurl and I think upstream never releases
> regularly which makes it a bit of a sad package. (And you might need a
> license to redistribute the pkg?)

Note that the ancient libcurl is already in [community]. But redistribution is 
forbidden [1], so this can't be shipped in the official repos.

[1] 
https://community.spotify.com/t5/Desktop-Linux-Windows-Web-Player/What-license-does-the-linux-spotify-client-use/td-p/173356/page/3

Re: [aur-general] TU Application NicoHood

[Doug Newgard]

On Sat, 3 Sep 2016 17:22:23 +0200
Frederik “Freso” S. Olesen  wrote:

> Den 03-09-2016 kl. 17:04 skrev Doug Newgard:
> > Anyone who advises people to lie about what distro they're running in order 
> > to
> > get support from the Arch community is suspect, IMO.  
> 
> What? I feel like I'm lacking some context, so I read the original
> application e-mail again, and I saw no suggestion of anyone lying or
> suggesting to lie about distro usage…?
> 

Yes, I should have provided logs for context. Was in a hurry when I probably
should have waited until later to post. Here you go:

https://gist.github.com/Scimmia22/dc535f19fbc7290c0665051874b53415

This policy is in place for a reason, many people have spent a lot of time
helping troubleshoot issues that turned out to be unrelated to Arch. Telling
people to disregard it is dishonest at best.


pgpDDsfqCFblW.pgp
Description: OpenPGP digital signature

Re: [aur-general] TU Application NicoHood

[Jelle van der Waa]

On 09/03/16 at 02:00pm, NicoHood wrote:
> I am maintaining the AUR arduino packages for a while now and
> think its time for it to get its place in the official community repository.

Sure, I've wanted to do this for a long time. However arduino seems to
ship and provide avr-gcc, libc, arvdude and everything else we have in
our [community] repo. I'd like to see arduino use the system binaries
for those packages if that's possible. 

Maybe the package should be split up between arduino-sdk and arduino the
ide itself. So that people can easily use ino without having to bother
with the whole arduino IDE.

> * ipod-shuffle-4g
> * (spotify)

It does require an ancient libcurl and I think upstream never releases
regularly which makes it a bit of a sad package. (And you might need a
license to redistribute the pkg?)

-- 
Jelle van der Waa


signature.asc
Description: PGP signature

Re: [aur-general] TU Application NicoHood

[Frederik “Freso” S . Olesen]

Den 03-09-2016 kl. 17:04 skrev Doug Newgard:
> Anyone who advises people to lie about what distro they're running in order to
> get support from the Arch community is suspect, IMO.

What? I feel like I'm lacking some context, so I read the original
application e-mail again, and I saw no suggestion of anyone lying or
suggesting to lie about distro usage…?

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

[Doug Newgard]

On Sat, 3 Sep 2016 14:00:21 +0200
NicoHood  wrote:

...

Anyone who advises people to lie about what distro they're running in order to
get support from the Arch community is suspect, IMO.

Scimmia


pgpLIqAdyxxrp.pgp
Description: OpenPGP digital signature

[aur-general] TU Application NicoHood

[NicoHood]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey guys,
I am maintaining the AUR arduino packages for a while now and
think its time for it to get its place in the official community repository.

If you do not know Arduino, it is a development platform for several
microcontrollers and widely used for education and also in commercial
products. This is also how I came to programming and linux.
https://www.arduino.cc/

I've been using arduino now for over 2 years now starting with version
1.0.5. Since then I've developed a lot libraries for Arduino and also an
USB Bootloader. Furthermore I've also contributed to the official
package, as you can see in the changelog. You can find those below:
https://github.com/NicoHood
http://www.nicohood.de
https://www.arduino.cc/en/Main/ReleaseNotes

Since version 1.6.9 I've joined the AUR packaging of arduino. I've
worked together with Loen (who deleted his account for some reason) as
co-maintainer. Since he disappeared I am the main maintainer now. We
have solved so far:
* General package update
* avrdude fix
* use less source files, use builtin xml and desktop file
* make depenedencies more generic
* PKGBUILD cleanup
* rebuild the system with arch's java (200mb less)
* fix java7&8 building
* fix java7&8 starting of the app
* separate packages for bin and git package
* official sha512sums from upstream for bin package
* added arduino-builder to PATH
* Fixed package permissions upstream myself
https://aur.archlinux.org/packages/arduino/

As you can see arduino is widely used and very popular on arch (over 500
votes). I think it would be a huge plug for arch if it could officially
support the arduino package. Arch also has the most up to date avr-gcc
and avrdude binaries, so all avr development would be in place.

I follow the arduino github issues and PRs, so I always know whats going
on with the project. I know the arduino team quite good, which you can
also see in the changelog. If I have an important question or request
(like the sha512sums) they will likely listen to me. That's why I was
also able to fix some of the major problems listed above.


Appart from arduino I want to maintain a few other packages also.
I thought it would be better to start with a small package number and
then increase them over the time. I didn't want to request too much, however
alucryd suggested me to list a few more packages than only arduino.

I do not own all of them, but I've modified/updated them myself. I want
to make
sure that I am able to provide high quality packages, so I chose
packages I also
use myself. I can imagine maintaining those packages in the following
preferred order.

* gtk-theme-arc
* arc-icon-theme
* hyperion
* create_ap
* python(2)-pyusb
* pyhton(2)-intelhex
* python(2)-pyqrcode
* ipod-shuffle-4g
* (spotify)

As I've explained very detailed the arduino package I want to keep it
short for
the others: I've been using them now for a very long time mostly or
developed
for those packages myself, so I know how to package them properly.

I've first contacted farseerfc who wants to sponser me, but suggested me
to also
contact a TU that is longer in the business, and though I asked alucryd
and he
also wants to sponsor me. anatolik also agreed that I should take over
the pyusb
package if my TU application gets accepted. I am very active on IRC, AUR and
github issues. If there is a question you can always ask :)

Thanks for your attention.

PS: I've signed this message with my new PGP package key and my current
email
PGP key. New key identifier: 7865312C829DF18E513A539BCC637E15FD4328D3
- -BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJXyIZ+AAoJEMxjfhX9QyjTiuMP/iUhzmvkMB843SkVGHk5a7lr
vAEvDCzmKykNtdNNxvOrwVi6IA7u5SWEAq6VTR33PzVmWG7yXeXPPG0p2f82KtTU
Yi9fyU8sPnenJHJjXKPkA1MZq6Dwx19HgVwobctjIZVf5j8Eo7uMxvnwHzuikbzw
KxPKJxkNBHzgtTgXyAiJVWfyl1bnrH9KzFfWBYGrE9y4yJn75sjNABF2KjFwfts7
hyptcbwQKYi3AhgbZYS3yZRWPkkYBL23hc6iJGeMvrpYfE7fDRbHGBBMwH1oY/r7
7VyATZ345C8yqz5868hmPSck+3BV+Jiy6R4mti+c3pOC/Qf9lATo17v1F9zYRzkD
D8AZZ1aF/9QC4JJcNwHnZEQw2TuExScHiCW6DREupIkKAjxico5go3U26Z8WiGge
j8kiFwUKJYJS6bBJ5KN9GS6EbRau9Axpzmsa2w22T82c5JT75fO8WkRXOh9XkiSp
G0un5x/8n1dQ6dF2BBlDEO7I5uk1oNS/JPPLiTi5ejSV4WWzs5Ta32oHDs5seOYs
kJNyT9OXtMCS018z0U4e1XE2ZFJoQclpDVPNPP0vWrhuDI8JQeX6IZWZQS6VuW8k
h7kL5UbBKkc9u1yoGOGnlJvqyRRT4QtWCAv5nKLamgph2vludci5gYwfaOysypyW
QYvUKycKPn7NqqicJnvT
=Q+ZQ
- -END PGP SIGNATURE-
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJXyIbOAAoJEFHa6bfBrpFhRMgP/2sQYzSDdozfTkvxFytI/RGw
O5KcLfCSMASJD73kFquPOTC50+efBAAOKHC72VPDyqgl75x4k2Jf67z2P9lAWLah
7dQa0MprMZ1cjItZIzYyk7dC4XCaHgJyAr4dDR0YIReGrtoBk0joQIPVgbyblKpY
RMQuTJzaDeDMK5/K/q5VGbj+bcHCbyGSFLzE34K4ZRWA8j2aHo9C/H6bbRcmupXD
0XHovUQnZJn5riaDK1nVVyVlzz4y/WfdyupML84TkXzvPY1t+vT5IlPHxOr9WePq
UIpQvjEQSKSZ9oQCKCtyK6yHR51tZLS/2ItNc41bkrRA3TlFB3/k9OOygd1hEJg8
sGP0pm3Ak2QMFjSdm03QXW0S/PJrJGzgE1BhuNH9t1dF0vVRr6EZ8MvAEWSilHdo
QbBvwfnR+7n/VdPvZtABspSI3OXjf+gIBM5nbV/FilpBJ2LeTGpXqA0quGIPhsa7
jzAfHI7Sh

Re: [aur-general] TU Application - Dustin Falgout

[Bartłomiej Piotrowski]

On 2016-03-23 22:59, G. Schlisio wrote:
>> Well, the 5 day period has ended to interview the applicant, so now the 7
>> day period to vote is opened.
>>
>> Good luck!
>>
>> Cheers
> 
> out of curiosity: is the voting over yet?
> 

Apparently Alexandre forgot to post the results here… To expand lakonic
Sebastien's answer:

Yes: 7
No: 16
Abstain: 8

The quorum is met as participation is 72.09%.

Dustin, according to our bylaws, you can re-apply after 3 months. I hope
you won't give up after this vote and we will see you again in that time.

Bartłomiej



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU Application - Dustin Falgout

[G. Schlisio]

Am 23.03.2016 um 23:27 schrieb Sébastien Luttringer:
> On mer., 2016-03-23 at 22:59 +0100, G. Schlisio wrote:
>>>
>>> Well, the 5 day period has ended to interview the applicant, so now the 7
>>> day period to vote is opened.
>>>
>>> Good luck!
>>>
>>> Cheers
>> out of curiosity: is the voting over yet?
>>
> 
> Yes and the motion was denied.
> 
> Cheers,

Is there a change in policy? Until now, results always have been
announced here, as far as i remember.
Maybe i remember wrong though…
thanks anyway!



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU Application - Dustin Falgout

[WebDawg]

On Wed, Mar 23, 2016 at 5:27 PM, Sébastien Luttringer  wrote:
> On mer., 2016-03-23 at 22:59 +0100, G. Schlisio wrote:
>> >
>> > Well, the 5 day period has ended to interview the applicant, so now the 7
>> > day period to vote is opened.
>> >
>> > Good luck!
>> >
>> > Cheers
>> out of curiosity: is the voting over yet?
>>
>
> Yes and the motion was denied.
>
> Cheers,
>
> --
> Sébastien "Seblu" Luttringer
> https://seblu.net | Twitter: @seblu42
> GPG: 0x2072D77A
>

What was the vote count?  Why the denial?

Re: [aur-general] TU Application - Dustin Falgout

[Sébastien Luttringer]

On mer., 2016-03-23 at 22:59 +0100, G. Schlisio wrote:
> > 
> > Well, the 5 day period has ended to interview the applicant, so now the 7
> > day period to vote is opened.
> > 
> > Good luck!
> > 
> > Cheers
> out of curiosity: is the voting over yet?
> 

Yes and the motion was denied.

Cheers,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



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

Re: [aur-general] TU Application - Dustin Falgout

[G. Schlisio]

> Well, the 5 day period has ended to interview the applicant, so now the 7
> day period to vote is opened.
> 
> Good luck!
> 
> Cheers

out of curiosity: is the voting over yet?



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU Application - Dustin Falgout

[Levente Polyak]

On 03/02/2016 11:58 PM, Dustin Falgout wrote:
>> To: aur-general@archlinux.org> From: anthr...@archlinux.org
>> Date: Wed, 2 Mar 2016 22:48:27 +0100
>> Subject: Re: [aur-general] TU Application - Dustin Falgout
>>
>> On 03/02/2016 09:19 PM, Balló György wrote:
>>> If you don't specify tag or commit hash at the end of the git source, then
>>> you should use the -git suffix. Users expect if the package has no -git
>>> suffix, then it's a working static version tested by the maintainer, and
>>> not some experimental code from git HEAD.
>>>
>>
>> Its not just a should but a guideline rule [0] that must be followed
>> upon. For official repositories it is mandatory and will also be
>> enforced because of multiple reasons: the most obvious ones are rebuilds
>> on sobumps and reproducible packages (not yet there but a topic that is
>> being worked on).
>> The only difference is that (besides that the AUR is unsupported) on the
>> AUR people may not notice it or care enough to enforce that. However, in
>> my personal opinion, a trusted user should do things above the general
>> average, that's IMHO why someone should be _trusted_.
>>
>>
>> On 03/02/2016 08:21 PM, Dustin Falgout wrote:
>>> I do have a sane reason indeed. Upstream is not following their
>>> github releases. If you look in openSUSE's package repo you will see >
>> that they are packaging the latest master as the most recently
>>> released version. Looking at the history of those packages it seems
>>> that whoever is maintaining the packages over at openSUSE does not
>>> use github releases in their release process on a regular basis.
>>
>> It applies for just one out of 3 packages, you should fully check your
>> claim before using it as an argument. Also 2/3 of those packages are not
>> something that could be considered "not released on regular basis"
>>
>> obs-service-set_version:
>> - last release: Sep 3, 2015
>> - patch commits since release: 4
>> - openSUSE version [1]: 0.5.3 release
>>
>> obs-service-tar_scm:
>> - last release: Jun 1, 2015
>> - patch commits since release: 9
>> - openSUSE version [2]: 0.5.3 0b4ce51 (2 patch commits since release)
>>
>> obs-service-recompress:
>> - last release: Nov 5, 2013
>> - patch commits since release: 7
>> - openSUSE version [3]: 7897d3f (7 patch commits since release)
>>
>> Actually, as mentioned above, its just the recompress packages that
>> really falls out of scope. The tar_scm is just a debian control file fix
>> and a missing extension parameter to service file.
>> I don't see any point why the release is not sufficient for those. Also
>> did you try to contact upstream about a recompress release?
>>
>>
>> On 03/02/2016 08:21 PM, Dustin Falgout wrote:
>>> Considering that, it doesnt make sense to tag the end of the pkgname >
>> with "-git"
>>
>> As mentioned in my very first section, this part is not something that
>> can be argued upon [0], there are just two sane possibilities:
>> 1) use a static version and have the pure package name
>> 2) use non-static VCS (like git HEAD) and add such postfix to pkgname
>>
>> cheers,
>> Levente
>>
>> [0] https://wiki.archlinux.org/index.php/VCS_package_guidelines#Guidelines
>> [1]
>> https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-set_version
>> [2]
>> https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-tar_scm
>> [3]
>> https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-recompress
> 
> 
>> It applies for just one out of 3 packages, you should fully check your
>> claim before using it as an argument

> I'm sorry, I did not realize we were having an argument. You asked me why I
> did it the way that I did and I explained. If I was planning to move those
> packages into community or if I thought there was even the remote possibility
> of my doing so, I would certainly make sure the packages were inline with the
> repo guidelines. However, that is not the case here. Those three packages are
> no longer of much use to me at this point. I didn't want to just orphan them
> considering they weren't requiring much from me in terms of maintenance so I
> kept them. In any case, I understand what you are saying. I am not now, nor 
> was
> I ever, saying you are wrong. I should have made been more clear about that,
> my apologies. 
> 
> Best Regards,Dustin 
> 

Excuse me being a

Re: [aur-general] TU Application - Dustin Falgout

[Alexandre Filgueira]

2016-02-28 16:02 GMT-05:00 Dustin Falgout :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi Everyone,
>
> My name is Dustin Falgout (aka lots0logs) and this is my application to
> join the Arch Linux project as a Trusted User.
>
> About Me:
>
> I'm 29 years old. I live on the Gulf Coast (USA). I work for a leading
> WordPress Theme Company where I do a little bit of everything: from sales,
> to development, to quality assurance, to tech support (you name it...). My
> first experience with linux was with Ubuntu in 2003. It wasn't until around
> 2008 that I began using linux exclusively on my desktops. Wanting more
> control than comes easily with Ubuntu, I first turned to openSUSE and was
> content for a while. In early 2013, I performed my first Arch linux
> installation and have been using it ever since.
>
> - From the start I loved almost everything about Arch. The one thing I
> didn't love was the attitudes towards new users that was so common in the
> forum. I certainly understand all sides of what is a complex issue and I'm
> not trying to open that can of worms here. I'm only mentioning it because
> when I first became an Arch user I found the overall tone of the forum to
> be extremely off-putting, so much so that I can pinpoint it as the sole
> reason I shied away from trying to become an active contributor back then.
> Also, it will help everyone to know where my head was at when I tell you
> the rest of my story.
>
> I stumbled upon Antergos in May 2013 and I immediately knew that I had
> found my home. The project's goals and the views of its developers aligned
> perfectly with my own. For me, Antergos was (and still is) the perfect
> solution as it has allowed me to contribute (albeit indirectly) to the
> advancement of what I truly believe to be the best linux distribution
> available. I know that's a rather broad statement, but I'm trying to keep
> this short and to the point. If anyone would like me to elaborate on
> something more specifically, I'd be happy to do so.
>
> I currently maintain six or seven PKGBUILDS in the AUR, of which three are
> notable: pycharm-eap[1], lightdm-webkit2-greeter[2], and
> lightdm-webkit-theme-antergos[3]. I've indirectly contributed to other
> packages in the AUR through comments by offering advice to users, notifying
> maintainers of new releases as well as any problems with PKGBUILDS (always
> including a proposed solution), and directing bug reports away from AUR
> comments and to their proper channel. I always take the time to properly
> request deletion of PKGBUILDS that shouldnt be in the AUR (for whatever
> reason) whenever I come across one. I've also reported (and still do
> report) bugs on http://bugs.archlinux.org when it was/is appropriate. On
> one or two occasions I've gone as far as reaching out directly to
> maintainers of official packages to provide them with important information.
>
> Its's also worth mentioning that I currently maintain many packages[4] for
> Antergos and I'm open to moving any (that are appropriate) to community.
>
> So you might be wondering: "Why become a TU now?". Well, the reason is
> pretty simple. I was asked to consider applying by Alex Filgueira, the TU
> who currently maintains the Cinnamon packages and a person with whom I've
> had the pleasure of collaborating with on Antergos for the past three
> years. Sadly, his schedule has become far too busy to continue to maintain
> the Cinnamon packages. Another TU, György Balló, has been picking up the
> slack for the past few months but, having more than a few packages of his
> own to maintain, he told Alex that it would be nice to have some help with
> Cinnamon. Considering that Cinnamon is my own personal desktop of choice,
> Alex thought I would want to consider joining forces with György to
> maintain Cinnamon. Obviously, Alex was correct and so here we are. That's
> my story :)
>
> I know that every minute of your free time is priceless, so thank you all
> in advance for taking the time review and consider my application. I look
> forward to (hopefully) "making things official" between myself and Arch
> Linux.
>
>
> [1] https://aur.archlinux.org/packages/pycharm-eap/
> [2] https://aur.archlinux.org/packages/lightdm-webkit2-greeter/
> [3] https://aur.archlinux.org/packages/lightdm-webkit-theme-antergos/
> [4] http://build.antergos.com/browse/main
>
>
> Best Regards,
>
> Dustin Falgout
> Web Developer
>
> E-mail: dus...@falgout.us
> Google/Skype: dustinfalgout
> Freenode IRC: #antergos
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJW02A1AAoJEK6lKb8SKQLlb6EH/2bE+uzlWsuU3kIouB8sEGwr
> qzGmBT3JntkZsOrsy1fYl7kNz2GAlc2/+8MCJ9LUinkv46Egiw93lW8C58G8eudQ
> LOJ1GTz7hh5suO+xOagXdmTJwJMK04VPtHksTeNg3mVONmJPNxSlDdRk77sTHZMd
> 95aAnvnPBkk1U6Zn4hr6pPUG6HvPGmMseDdmBLr62Fh5CgupsEli4Q2vmgTlZwr6
> CoJo9LEaS20djXihDgXYY/6TDEeKeyzj7I9M33IP6eppoACEzsueXxInD5aBPyvD
> HgcqvC7UNnpha8k2LBbL5xyTOUiDyhwwpf8umLHWPLCA6OmK9se3aYiY2FaUd8A=
> =8/xf
> -END 

Re: [aur-general] TU Application - Dustin Falgout

[Balló György]

2016-03-02 23:44 GMT+01:00 Dustin Falgout :

> > Date: Wed, 2 Mar 2016 21:19:08 +0100> From: ballog...@gmail.com
> > BTW, it would be nice if you could adopt some more orphan packages in the
> > community repository.
>
> Sure, I could do that. Do you have any particular packages in mind that I
> should consider first?
> Best Regards,Dustin


We have a lot of orphans, you can choose any of them:
https://www.archlinux.org/packages/?repo=Community&maintainer=orphan

--
György Balló
Trusted User

Re: [aur-general] TU Application - Dustin Falgout

[Dustin Falgout]

> To: aur-general@archlinux.org> From: anthr...@archlinux.org
> Date: Wed, 2 Mar 2016 22:48:27 +0100
> Subject: Re: [aur-general] TU Application - Dustin Falgout
> 
> On 03/02/2016 09:19 PM, Balló György wrote:
> > If you don't specify tag or commit hash at the end of the git source, then
> > you should use the -git suffix. Users expect if the package has no -git
> > suffix, then it's a working static version tested by the maintainer, and
> > not some experimental code from git HEAD.
> > 
> 
> Its not just a should but a guideline rule [0] that must be followed
> upon. For official repositories it is mandatory and will also be
> enforced because of multiple reasons: the most obvious ones are rebuilds
> on sobumps and reproducible packages (not yet there but a topic that is
> being worked on).
> The only difference is that (besides that the AUR is unsupported) on the
> AUR people may not notice it or care enough to enforce that. However, in
> my personal opinion, a trusted user should do things above the general
> average, that's IMHO why someone should be _trusted_.
> 
> 
> On 03/02/2016 08:21 PM, Dustin Falgout wrote:
> > I do have a sane reason indeed. Upstream is not following their
> > github releases. If you look in openSUSE's package repo you will see >
> that they are packaging the latest master as the most recently
> > released version. Looking at the history of those packages it seems
> > that whoever is maintaining the packages over at openSUSE does not
> > use github releases in their release process on a regular basis.
> 
> It applies for just one out of 3 packages, you should fully check your
> claim before using it as an argument. Also 2/3 of those packages are not
> something that could be considered "not released on regular basis"
> 
> obs-service-set_version:
> - last release: Sep 3, 2015
> - patch commits since release: 4
> - openSUSE version [1]: 0.5.3 release
> 
> obs-service-tar_scm:
> - last release: Jun 1, 2015
> - patch commits since release: 9
> - openSUSE version [2]: 0.5.3 0b4ce51 (2 patch commits since release)
> 
> obs-service-recompress:
> - last release: Nov 5, 2013
> - patch commits since release: 7
> - openSUSE version [3]: 7897d3f (7 patch commits since release)
> 
> Actually, as mentioned above, its just the recompress packages that
> really falls out of scope. The tar_scm is just a debian control file fix
> and a missing extension parameter to service file.
> I don't see any point why the release is not sufficient for those. Also
> did you try to contact upstream about a recompress release?
> 
> 
> On 03/02/2016 08:21 PM, Dustin Falgout wrote:
> > Considering that, it doesnt make sense to tag the end of the pkgname >
> with "-git"
> 
> As mentioned in my very first section, this part is not something that
> can be argued upon [0], there are just two sane possibilities:
> 1) use a static version and have the pure package name
> 2) use non-static VCS (like git HEAD) and add such postfix to pkgname
> 
> cheers,
> Levente
> 
> [0] https://wiki.archlinux.org/index.php/VCS_package_guidelines#Guidelines
> [1]
> https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-set_version
> [2]
> https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-tar_scm
> [3]
> https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-recompress


> It applies for just one out of 3 packages, you should fully check your
> claim before using it as an argument
I'm sorry, I did not realize we were having an argument. You asked me why I did 
it the way that I did and I explained. If I was planning to move those packages 
into community or if I thought there was even the remote possibility of my 
doing so, I would certainly make sure the packages were inline with the repo 
guidelines. However, that is not the case here. Those three packages are no 
longer of much use to me at this point. I didn't want to just orphan them 
considering they weren't requiring much from me in terms of maintenance so I 
kept them. In any case, I understand what you are saying. I am not now, nor was 
I ever, saying you are wrong. I should have made been more clear about that, my 
apologies. 

Best Regards,Dustin   

Re: [aur-general] TU Application - Dustin Falgout

[Dustin Falgout]

> Date: Wed, 2 Mar 2016 21:19:08 +0100> From: ballog...@gmail.com
> To: aur-general@archlinux.org
> Subject: Re: [aur-general] TU Application - Dustin Falgout
> 
> 2016-03-02 20:21 GMT+01:00 Dustin Falgout :
> 
> > If you are wondering why I didn't use the short version of the commit hash
> > at the end of the pkgver, well that's simply a personal preference of mine
> > (to use revision numbers instead). I hope that helps clear up any confusion
> > as to why I chose to do it the way that I did.
> >
> 
> If you don't specify tag or commit hash at the end of the git source, then
> you should use the -git suffix. Users expect if the package has no -git
> suffix, then it's a working static version tested by the maintainer, and
> not some experimental code from git HEAD.
> 
> BTW, it would be nice if you could adopt some more orphan packages in the
> community repository.
> 
> --
> György Balló
> Trusted User


Sure, I could do that. Do you have any particular packages in mind that I 
should consider first?
Best Regards,Dustin   

Re: [aur-general] TU Application - Dustin Falgout

[Levente Polyak]

On 03/02/2016 09:19 PM, Balló György wrote:
> If you don't specify tag or commit hash at the end of the git source, then
> you should use the -git suffix. Users expect if the package has no -git
> suffix, then it's a working static version tested by the maintainer, and
> not some experimental code from git HEAD.
> 

Its not just a should but a guideline rule [0] that must be followed
upon. For official repositories it is mandatory and will also be
enforced because of multiple reasons: the most obvious ones are rebuilds
on sobumps and reproducible packages (not yet there but a topic that is
being worked on).
The only difference is that (besides that the AUR is unsupported) on the
AUR people may not notice it or care enough to enforce that. However, in
my personal opinion, a trusted user should do things above the general
average, that's IMHO why someone should be _trusted_.


On 03/02/2016 08:21 PM, Dustin Falgout wrote:
> I do have a sane reason indeed. Upstream is not following their
> github releases. If you look in openSUSE's package repo you will see >
that they are packaging the latest master as the most recently
> released version. Looking at the history of those packages it seems
> that whoever is maintaining the packages over at openSUSE does not
> use github releases in their release process on a regular basis.

It applies for just one out of 3 packages, you should fully check your
claim before using it as an argument. Also 2/3 of those packages are not
something that could be considered "not released on regular basis"

obs-service-set_version:
- last release: Sep 3, 2015
- patch commits since release: 4
- openSUSE version [1]: 0.5.3 release

obs-service-tar_scm:
- last release: Jun 1, 2015
- patch commits since release: 9
- openSUSE version [2]: 0.5.3 0b4ce51 (2 patch commits since release)

obs-service-recompress:
- last release: Nov 5, 2013
- patch commits since release: 7
- openSUSE version [3]: 7897d3f (7 patch commits since release)

Actually, as mentioned above, its just the recompress packages that
really falls out of scope. The tar_scm is just a debian control file fix
and a missing extension parameter to service file.
I don't see any point why the release is not sufficient for those. Also
did you try to contact upstream about a recompress release?


On 03/02/2016 08:21 PM, Dustin Falgout wrote:
> Considering that, it doesnt make sense to tag the end of the pkgname >
with "-git"

As mentioned in my very first section, this part is not something that
can be argued upon [0], there are just two sane possibilities:
1) use a static version and have the pure package name
2) use non-static VCS (like git HEAD) and add such postfix to pkgname

cheers,
Levente

[0] https://wiki.archlinux.org/index.php/VCS_package_guidelines#Guidelines
[1]
https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-set_version
[2]
https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-tar_scm
[3]
https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-recompress

Re: [aur-general] TU Application - Dustin Falgout

[Balló György]

2016-03-02 20:21 GMT+01:00 Dustin Falgout :

> If you are wondering why I didn't use the short version of the commit hash
> at the end of the pkgver, well that's simply a personal preference of mine
> (to use revision numbers instead). I hope that helps clear up any confusion
> as to why I chose to do it the way that I did.
>

If you don't specify tag or commit hash at the end of the git source, then
you should use the -git suffix. Users expect if the package has no -git
suffix, then it's a working static version tested by the maintainer, and
not some experimental code from git HEAD.

BTW, it would be nice if you could adopt some more orphan packages in the
community repository.

--
György Balló
Trusted User

Re: [aur-general] TU Application - Dustin Falgout

[Dustin Falgout]

> To: aur-general@archlinux.org> From: anthr...@archlinux.org
> Date: Wed, 2 Mar 2016 12:28:58 +0100
> Subject: Re: [aur-general] TU Application - Dustin Falgout
> 
> On 03/02/2016 11:56 AM, Jan Alexander Steffens wrote:
> > On Wed, Mar 2, 2016 at 11:40 AM, Levente Polyak  
> > wrote:
> >> That was fast, but I think you accidentally forgot to implement the most
> >> important part of my feedback: It is not allowed to have no pkgname VCS
> >> postfix (like -git) but pull from a git HEAD.
> >> You either have to rename those packages or pull a static source like
> >> github or upstream tarballs. In case of github tarballs remember to use
> >> the source filename prefix to make them unique (like
> >> lightdm-webkit-theme-userdock).
> > 
> > The simplest way to make these "static" if you want to import them
> > into [community] is to pin the git source using #commit=1234567.
> > 
> 
> Also in that case, only if you have a sane reason to not stick to the
> upstream released versions. If there is no real reason one should follow
> the upstream released version so the commit hash should not be arbitrary
> but the one of the release.
> In general we want to follow upstream releases.
> 
> cheers,
> Levente

Hi Levente,
I do have a sane reason indeed. Upstream is not following their github 
releases. If you look in openSUSE's package repo you will see that they are 
packaging the latest master as the most recently released version. Looking at 
the history of those packages it seems that whoever is maintaining the packages 
over at openSUSE does not use github releases in their release process on a 
regular basis. Considering that, it doesnt make sense to tag the end of the 
pkgname with "-git". If you are wondering why I didn't use the short version of 
the commit hash at the end of the pkgver, well that's simply a personal 
preference of mine (to use revision numbers instead). I hope that helps clear 
up any confusion as to why I chose to do it the way that I did. 
Cheers!Dustin 

Re: [aur-general] TU Application - Dustin Falgout

[Levente Polyak]

On 03/02/2016 11:56 AM, Jan Alexander Steffens wrote:
> On Wed, Mar 2, 2016 at 11:40 AM, Levente Polyak  
> wrote:
>> That was fast, but I think you accidentally forgot to implement the most
>> important part of my feedback: It is not allowed to have no pkgname VCS
>> postfix (like -git) but pull from a git HEAD.
>> You either have to rename those packages or pull a static source like
>> github or upstream tarballs. In case of github tarballs remember to use
>> the source filename prefix to make them unique (like
>> lightdm-webkit-theme-userdock).
> 
> The simplest way to make these "static" if you want to import them
> into [community] is to pin the git source using #commit=1234567.
> 

Also in that case, only if you have a sane reason to not stick to the
upstream released versions. If there is no real reason one should follow
the upstream released version so the commit hash should not be arbitrary
but the one of the release.
In general we want to follow upstream releases.

cheers,
Levente

Re: [aur-general] TU Application - Dustin Falgout

[Jan Alexander Steffens]

On Wed, Mar 2, 2016 at 11:40 AM, Levente Polyak  wrote:
> That was fast, but I think you accidentally forgot to implement the most
> important part of my feedback: It is not allowed to have no pkgname VCS
> postfix (like -git) but pull from a git HEAD.
> You either have to rename those packages or pull a static source like
> github or upstream tarballs. In case of github tarballs remember to use
> the source filename prefix to make them unique (like
> lightdm-webkit-theme-userdock).

The simplest way to make these "static" if you want to import them
into [community] is to pin the git source using #commit=1234567.

Re: [aur-general] TU Application - Dustin Falgout

[Levente Polyak]

On 03/02/2016 04:16 AM, Dustin Falgout wrote:
>> To: aur-general@archlinux.org> From: anthr...@archlinux.org
>> Date: Tue, 1 Mar 2016 17:12:04 +0100
>> Subject: Re: [aur-general] TU Application - Dustin Falgout
>>
>> On 02/28/2016 10:02 PM, Dustin Falgout wrote:
>>> I currently maintain six or seven PKGBUILDS in the AUR, of which three are 
>>> notable: pycharm-eap[1], lightdm-webkit2-greeter[2], and 
>>> lightdm-webkit-theme-antergos[3]. I've indirectly contributed to other 
>>> packages in the AUR through comments by offering advice to users, notifying 
>>> maintainers of new releases as well as any problems with PKGBUILDS (always 
>>> including a proposed solution), and directing bug reports away from AUR 
>>> comments and to their proper channel. I always take the time to properly 
>>> request deletion of PKGBUILDS that shouldnt be in the AUR (for whatever 
>>> reason) whenever I come across one. I've also reported (and still do 
>>> report) bugs on http://bugs.archlinux.org when it was/is appropriate. On 
>>> one or two occasions I've gone as far as reaching out directly to 
>>> maintainers of official packages to provide them with important information.
>>
>> Hi Dustin
>>
>> I went through your packages and had a rough look at the PKGBUILDS...
>> don't be scared but i wanted to dump my feedback and some personal
>> opinions about those:
>>
>>
>> lightdm-webkit-theme-antergos:
>> - just my 2 cents but post_install() should not sed around in your
>>   lightdm.conf as you can also install multiple theme packages
>>
>> lightdm-webkit-theme-userdock:
>> - just my 2 cents but post_install() should not be used for explaining
>>   documentation/setup
>>
>> lightdm-webkit2-greeter:
>> - you can use #tag=2.0.0 instead of doing a checkout in build()
>> - reference to $pkgdir should always be quoted (make call)
>> - should not sed the lightdm.conf in post_install() as you can possibly
>>   install multiple greeters
>>
>> obs-service-recompress:
>> - this package actually pulls the git HEAD and should either be renamed
>>   to obs-service-recompress-git or pull the 0.3.1 tarball and have the
>>   pkgver() removed.
>> - reference to $pkgdir should always be quoted (make call)
>>
>> obs-service-set_version:
>> - same as obs-service-recompress, pulls git HEAD with pkgver() function
>>   instead of 0.5.3 tarball
>> - reference to $pkgdir should always be quoted (make call)
>>
>> obs-service-tar_scm:
>> - same as obs-service-recompress, pulls git HEAD with pkgver() function
>>   instead of 0.5.3 tarball
>> - reference to $pkgdir should always be quoted (make call)
>>
>> pycharm-eap:
>> - not sure what the _eap="True" variable and the if does there as its
>>   the -eap package, guess it can just be dropped (including the else)
>> - just my 2 cents but using groups with "development" "IDE" "editor"
>>   and "jetbrains" feels a bit too much, groups should logically group
>>   together similarities like "vim-plugins" and not used like generic
>>   keywords
>>
>>
>>
>> cheers,
>> Levente
>>
>> PS: instead of inline PGP you may want to have a look at PGP/MIME...
>> besides weird text in clients that don't support PGP it can also result
>> in breakage in various scenarios where the text gets altered by MTA/MUA
>>
> 
> 
> Hi Levente,
> I've implemented your feedback where it was appropriate. Thanks :) I'm not 
> familiar with PGP/MIME. I've heard of it, but I have no clue how to go about 
> using it. I'll definitely look into it so thanks for the tip!
> Best Regards,Dustin 
> 

Hey Dustin,

That was fast, but I think you accidentally forgot to implement the most
important part of my feedback: It is not allowed to have no pkgname VCS
postfix (like -git) but pull from a git HEAD.
You either have to rename those packages or pull a static source like
github or upstream tarballs. In case of github tarballs remember to use
the source filename prefix to make them unique (like
lightdm-webkit-theme-userdock).

cheers,
Levente

Re: [aur-general] TU Application - Dustin Falgout

[Dustin Falgout]

> To: aur-general@archlinux.org> From: anthr...@archlinux.org
> Date: Tue, 1 Mar 2016 17:12:04 +0100
> Subject: Re: [aur-general] TU Application - Dustin Falgout
> 
> On 02/28/2016 10:02 PM, Dustin Falgout wrote:
> > I currently maintain six or seven PKGBUILDS in the AUR, of which three are 
> > notable: pycharm-eap[1], lightdm-webkit2-greeter[2], and 
> > lightdm-webkit-theme-antergos[3]. I've indirectly contributed to other 
> > packages in the AUR through comments by offering advice to users, notifying 
> > maintainers of new releases as well as any problems with PKGBUILDS (always 
> > including a proposed solution), and directing bug reports away from AUR 
> > comments and to their proper channel. I always take the time to properly 
> > request deletion of PKGBUILDS that shouldnt be in the AUR (for whatever 
> > reason) whenever I come across one. I've also reported (and still do 
> > report) bugs on http://bugs.archlinux.org when it was/is appropriate. On 
> > one or two occasions I've gone as far as reaching out directly to 
> > maintainers of official packages to provide them with important information.
> 
> Hi Dustin
> 
> I went through your packages and had a rough look at the PKGBUILDS...
> don't be scared but i wanted to dump my feedback and some personal
> opinions about those:
> 
> 
> lightdm-webkit-theme-antergos:
> - just my 2 cents but post_install() should not sed around in your
>   lightdm.conf as you can also install multiple theme packages
> 
> lightdm-webkit-theme-userdock:
> - just my 2 cents but post_install() should not be used for explaining
>   documentation/setup
> 
> lightdm-webkit2-greeter:
> - you can use #tag=2.0.0 instead of doing a checkout in build()
> - reference to $pkgdir should always be quoted (make call)
> - should not sed the lightdm.conf in post_install() as you can possibly
>   install multiple greeters
> 
> obs-service-recompress:
> - this package actually pulls the git HEAD and should either be renamed
>   to obs-service-recompress-git or pull the 0.3.1 tarball and have the
>   pkgver() removed.
> - reference to $pkgdir should always be quoted (make call)
> 
> obs-service-set_version:
> - same as obs-service-recompress, pulls git HEAD with pkgver() function
>   instead of 0.5.3 tarball
> - reference to $pkgdir should always be quoted (make call)
> 
> obs-service-tar_scm:
> - same as obs-service-recompress, pulls git HEAD with pkgver() function
>   instead of 0.5.3 tarball
> - reference to $pkgdir should always be quoted (make call)
> 
> pycharm-eap:
> - not sure what the _eap="True" variable and the if does there as its
>   the -eap package, guess it can just be dropped (including the else)
> - just my 2 cents but using groups with "development" "IDE" "editor"
>   and "jetbrains" feels a bit too much, groups should logically group
>   together similarities like "vim-plugins" and not used like generic
>   keywords
> 
> 
> 
> cheers,
> Levente
> 
> PS: instead of inline PGP you may want to have a look at PGP/MIME...
> besides weird text in clients that don't support PGP it can also result
> in breakage in various scenarios where the text gets altered by MTA/MUA
> 


Hi Levente,
I've implemented your feedback where it was appropriate. Thanks :) I'm not 
familiar with PGP/MIME. I've heard of it, but I have no clue how to go about 
using it. I'll definitely look into it so thanks for the tip!
Best Regards,Dustin   

Re: [aur-general] TU Application - Dustin Falgout

[Eli Schwartz]

On 03/01/2016 02:23 PM, Johannes Löthberg wrote:
> Not just similarities, things that you might want to actually install 
> the whole group of, like base and base-devel & co. Not to mention the 
> fact that groups are pretty useless in the AUR either way.

Groups aren't entirely useless in the AUR. Once they are installed, you
can remove the whole group at once too.

Or make a custom repository out of them.

-- 
Eli Schwartz

Re: [aur-general] TU Application - Dustin Falgout

[Luchesar V. ILIEV]

On 01/03/16 21:23, Johannes Löthberg wrote:
> (...snip...) Not to mention the
> fact that groups are pretty useless in the AUR either way.

Well, they can be useful if you maintain a binary repo as well. I don't
argue however with the other point that was made (and not quoted here).

Cheers,
Luchesar
-- 
https://aur.archlinux.org/account/kerberizer

Re: [aur-general] TU Application - Dustin Falgout

[Johannes Löthberg]

On 01/03, Levente Polyak wrote:

pycharm-eap:

...

- just my 2 cents but using groups with "development" "IDE" "editor"
 and "jetbrains" feels a bit too much, groups should logically group
 together similarities like "vim-plugins" and not used like generic
 keywords



Not just similarities, things that you might want to actually install 
the whole group of, like base and base-devel & co. Not to mention the 
fact that groups are pretty useless in the AUR either way.



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


signature.asc
Description: PGP signature

Re: [aur-general] TU Application - Dustin Falgout

[Levente Polyak]

On 02/28/2016 10:02 PM, Dustin Falgout wrote:
> I currently maintain six or seven PKGBUILDS in the AUR, of which three are 
> notable: pycharm-eap[1], lightdm-webkit2-greeter[2], and 
> lightdm-webkit-theme-antergos[3]. I've indirectly contributed to other 
> packages in the AUR through comments by offering advice to users, notifying 
> maintainers of new releases as well as any problems with PKGBUILDS (always 
> including a proposed solution), and directing bug reports away from AUR 
> comments and to their proper channel. I always take the time to properly 
> request deletion of PKGBUILDS that shouldnt be in the AUR (for whatever 
> reason) whenever I come across one. I've also reported (and still do report) 
> bugs on http://bugs.archlinux.org when it was/is appropriate. On one or two 
> occasions I've gone as far as reaching out directly to maintainers of 
> official packages to provide them with important information.

Hi Dustin

I went through your packages and had a rough look at the PKGBUILDS...
don't be scared but i wanted to dump my feedback and some personal
opinions about those:


lightdm-webkit-theme-antergos:
- just my 2 cents but post_install() should not sed around in your
  lightdm.conf as you can also install multiple theme packages

lightdm-webkit-theme-userdock:
- just my 2 cents but post_install() should not be used for explaining
  documentation/setup

lightdm-webkit2-greeter:
- you can use #tag=2.0.0 instead of doing a checkout in build()
- reference to $pkgdir should always be quoted (make call)
- should not sed the lightdm.conf in post_install() as you can possibly
  install multiple greeters

obs-service-recompress:
- this package actually pulls the git HEAD and should either be renamed
  to obs-service-recompress-git or pull the 0.3.1 tarball and have the
  pkgver() removed.
- reference to $pkgdir should always be quoted (make call)

obs-service-set_version:
- same as obs-service-recompress, pulls git HEAD with pkgver() function
  instead of 0.5.3 tarball
- reference to $pkgdir should always be quoted (make call)

obs-service-tar_scm:
- same as obs-service-recompress, pulls git HEAD with pkgver() function
  instead of 0.5.3 tarball
- reference to $pkgdir should always be quoted (make call)

pycharm-eap:
- not sure what the _eap="True" variable and the if does there as its
  the -eap package, guess it can just be dropped (including the else)
- just my 2 cents but using groups with "development" "IDE" "editor"
  and "jetbrains" feels a bit too much, groups should logically group
  together similarities like "vim-plugins" and not used like generic
  keywords



cheers,
Levente

PS: instead of inline PGP you may want to have a look at PGP/MIME...
besides weird text in clients that don't support PGP it can also result
in breakage in various scenarios where the text gets altered by MTA/MUA



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU Application - Dustin Falgout

[Dustin Falgout]

> To: aur-general@archlinux.org> From: bpiotrow...@archlinux.org
> Date: Tue, 1 Mar 2016 14:33:18 +0100
> Subject: Re: [aur-general] TU Application - Dustin Falgout
> 
> On 2016-02-28 22:02, Dustin Falgout wrote:
> > Hi Everyone,
> > 
> > My name is Dustin Falgout (aka lots0logs) and this is my application to 
> > join the Arch Linux project as a Trusted User.
> > 
> > About Me:
> > 
> > I'm 29 years old. I live on the Gulf Coast (USA). I work for a leading 
> > WordPress Theme Company where I do a little bit of everything: from sales, 
> > to development, to quality assurance, to tech support (you name it...). My 
> > first experience with linux was with Ubuntu in 2003. It wasn't until around 
> > 2008 that I began using linux exclusively on my desktops. Wanting more 
> > control than comes easily with Ubuntu, I first turned to openSUSE and was 
> > content for a while. In early 2013, I performed my first Arch linux 
> > installation and have been using it ever since.
> > 
> > - From the start I loved almost everything about Arch. The one thing I 
> > didn't love was the attitudes towards new users that was so common in the 
> > forum. I certainly understand all sides of what is a complex issue and I'm 
> > not trying to open that can of worms here. I'm only mentioning it because 
> > when I first became an Arch user I found the overall tone of the forum to 
> > be extremely off-putting, so much so that I can pinpoint it as the sole 
> > reason I shied away from trying to become an active contributor back then. 
> > Also, it will help everyone to know where my head was at when I tell you 
> > the rest of my story.
> > 
> > I stumbled upon Antergos in May 2013 and I immediately knew that I had 
> > found my home. The project's goals and the views of its developers aligned 
> > perfectly with my own. For me, Antergos was (and still is) the perfect 
> > solution as it has allowed me to contribute (albeit indirectly) to the 
> > advancement of what I truly believe to be the best linux distribution 
> > available. I know that's a rather broad statement, but I'm trying to keep 
> > this short and to the point. If anyone would like me to elaborate on 
> > something more specifically, I'd be happy to do so.
> > 
> > I currently maintain six or seven PKGBUILDS in the AUR, of which three are 
> > notable: pycharm-eap[1], lightdm-webkit2-greeter[2], and 
> > lightdm-webkit-theme-antergos[3]. I've indirectly contributed to other 
> > packages in the AUR through comments by offering advice to users, notifying 
> > maintainers of new releases as well as any problems with PKGBUILDS (always 
> > including a proposed solution), and directing bug reports away from AUR 
> > comments and to their proper channel. I always take the time to properly 
> > request deletion of PKGBUILDS that shouldnt be in the AUR (for whatever 
> > reason) whenever I come across one. I've also reported (and still do 
> > report) bugs on http://bugs.archlinux.org when it was/is appropriate. On 
> > one or two occasions I've gone as far as reaching out directly to 
> > maintainers of official packages to provide them with important information.
> > 
> > Its's also worth mentioning that I currently maintain many packages[4] for 
> > Antergos and I'm open to moving any (that are appropriate) to community.
> > 
> > So you might be wondering: "Why become a TU now?". Well, the reason is 
> > pretty simple. I was asked to consider applying by Alex Filgueira, the TU 
> > who currently maintains the Cinnamon packages and a person with whom I've 
> > had the pleasure of collaborating with on Antergos for the past three 
> > years. Sadly, his schedule has become far too busy to continue to maintain 
> > the Cinnamon packages. Another TU, György Balló, has been picking up the 
> > slack for the past few months but, having more than a few packages of his 
> > own to maintain, he told Alex that it would be nice to have some help with 
> > Cinnamon. Considering that Cinnamon is my own personal desktop of choice, 
> > Alex thought I would want to consider joining forces with György to 
> > maintain Cinnamon. Obviously, Alex was correct and so here we are. That's 
> > my story :)
> > 
> > I know that every minute of your free time is priceless, so thank you all 
> > in advance for taking the time review and consider my application. I look 
> > forward to (hopefully) "making things official" between myself and Arch 
> > Linux.
> > 
> >

Re: [aur-general] TU Application - Dustin Falgout

[Alexandre Filgueira]

2016-02-28 16:02 GMT-05:00 Dustin Falgout :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi Everyone,
>
> My name is Dustin Falgout (aka lots0logs) and this is my application to
> join the Arch Linux project as a Trusted User.
>
> About Me:
>
> I'm 29 years old. I live on the Gulf Coast (USA). I work for a leading
> WordPress Theme Company where I do a little bit of everything: from sales,
> to development, to quality assurance, to tech support (you name it...). My
> first experience with linux was with Ubuntu in 2003. It wasn't until around
> 2008 that I began using linux exclusively on my desktops. Wanting more
> control than comes easily with Ubuntu, I first turned to openSUSE and was
> content for a while. In early 2013, I performed my first Arch linux
> installation and have been using it ever since.
>
> - From the start I loved almost everything about Arch. The one thing I
> didn't love was the attitudes towards new users that was so common in the
> forum. I certainly understand all sides of what is a complex issue and I'm
> not trying to open that can of worms here. I'm only mentioning it because
> when I first became an Arch user I found the overall tone of the forum to
> be extremely off-putting, so much so that I can pinpoint it as the sole
> reason I shied away from trying to become an active contributor back then.
> Also, it will help everyone to know where my head was at when I tell you
> the rest of my story.
>
> I stumbled upon Antergos in May 2013 and I immediately knew that I had
> found my home. The project's goals and the views of its developers aligned
> perfectly with my own. For me, Antergos was (and still is) the perfect
> solution as it has allowed me to contribute (albeit indirectly) to the
> advancement of what I truly believe to be the best linux distribution
> available. I know that's a rather broad statement, but I'm trying to keep
> this short and to the point. If anyone would like me to elaborate on
> something more specifically, I'd be happy to do so.
>
> I currently maintain six or seven PKGBUILDS in the AUR, of which three are
> notable: pycharm-eap[1], lightdm-webkit2-greeter[2], and
> lightdm-webkit-theme-antergos[3]. I've indirectly contributed to other
> packages in the AUR through comments by offering advice to users, notifying
> maintainers of new releases as well as any problems with PKGBUILDS (always
> including a proposed solution), and directing bug reports away from AUR
> comments and to their proper channel. I always take the time to properly
> request deletion of PKGBUILDS that shouldnt be in the AUR (for whatever
> reason) whenever I come across one. I've also reported (and still do
> report) bugs on http://bugs.archlinux.org when it was/is appropriate. On
> one or two occasions I've gone as far as reaching out directly to
> maintainers of official packages to provide them with important information.
>
> Its's also worth mentioning that I currently maintain many packages[4] for
> Antergos and I'm open to moving any (that are appropriate) to community.
>
> So you might be wondering: "Why become a TU now?". Well, the reason is
> pretty simple. I was asked to consider applying by Alex Filgueira, the TU
> who currently maintains the Cinnamon packages and a person with whom I've
> had the pleasure of collaborating with on Antergos for the past three
> years. Sadly, his schedule has become far too busy to continue to maintain
> the Cinnamon packages. Another TU, György Balló, has been picking up the
> slack for the past few months but, having more than a few packages of his
> own to maintain, he told Alex that it would be nice to have some help with
> Cinnamon. Considering that Cinnamon is my own personal desktop of choice,
> Alex thought I would want to consider joining forces with György to
> maintain Cinnamon. Obviously, Alex was correct and so here we are. That's
> my story :)
>
> I know that every minute of your free time is priceless, so thank you all
> in advance for taking the time review and consider my application. I look
> forward to (hopefully) "making things official" between myself and Arch
> Linux.
>
>
> [1] https://aur.archlinux.org/packages/pycharm-eap/
> [2] https://aur.archlinux.org/packages/lightdm-webkit2-greeter/
> [3] https://aur.archlinux.org/packages/lightdm-webkit-theme-antergos/
> [4] http://build.antergos.com/browse/main
>
>
> Best Regards,
>
> Dustin Falgout
> Web Developer
>
> E-mail: dus...@falgout.us
> Google/Skype: dustinfalgout
> Freenode IRC: #antergos
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJW02A1AAoJEK6lKb8SKQLlb6EH/2bE+uzlWsuU3kIouB8sEGwr
> qzGmBT3JntkZsOrsy1fYl7kNz2GAlc2/+8MCJ9LUinkv46Egiw93lW8C58G8eudQ
> LOJ1GTz7hh5suO+xOagXdmTJwJMK04VPtHksTeNg3mVONmJPNxSlDdRk77sTHZMd
> 95aAnvnPBkk1U6Zn4hr6pPUG6HvPGmMseDdmBLr62Fh5CgupsEli4Q2vmgTlZwr6
> CoJo9LEaS20djXihDgXYY/6TDEeKeyzj7I9M33IP6eppoACEzsueXxInD5aBPyvD
> HgcqvC7UNnpha8k2LBbL5xyTOUiDyhwwpf8umLHWPLCA6OmK9se3aYiY2FaUd8A=
> =8/xf
> -END 

Re: [aur-general] TU Application - Dustin Falgout

[Jan Alexander Steffens]

On Tue, Mar 1, 2016 at 2:33 PM, Bartłomiej Piotrowski
 wrote:
> How exactly are you going to contribute to Arch, except maintaining
> Cinnamon? Packages from AUR you mentioned aren't really notable (and in
> fact, one just repackages proprietary tarball) and these in Antergos
> repositories also seem rather unpopular. Looks like some of them can't
> be even distributed at all unless JetBrains license allows that; as far
> as I know, distribution of ZFS binaries is a GPL violation.

FWIW, the zfs package in Antergos is a source distribution using DKMS
to build. Also, (antergos-)gnome-defaults-list, assuming it's solid,
is something the Arch GNOME distribution is in need of. Would be
interesting to get in contact with whoever made that.

More on topic, if Cinnamon desperately needs maintainers, I'd welcome Dustin.

Re: [aur-general] TU Application - Dustin Falgout

[Bartłomiej Piotrowski]

On 2016-02-28 22:02, Dustin Falgout wrote:
> Hi Everyone,
> 
> My name is Dustin Falgout (aka lots0logs) and this is my application to join 
> the Arch Linux project as a Trusted User.
> 
> About Me:
> 
> I'm 29 years old. I live on the Gulf Coast (USA). I work for a leading 
> WordPress Theme Company where I do a little bit of everything: from sales, to 
> development, to quality assurance, to tech support (you name it...). My first 
> experience with linux was with Ubuntu in 2003. It wasn't until around 2008 
> that I began using linux exclusively on my desktops. Wanting more control 
> than comes easily with Ubuntu, I first turned to openSUSE and was content for 
> a while. In early 2013, I performed my first Arch linux installation and have 
> been using it ever since.
> 
> - From the start I loved almost everything about Arch. The one thing I didn't 
> love was the attitudes towards new users that was so common in the forum. I 
> certainly understand all sides of what is a complex issue and I'm not trying 
> to open that can of worms here. I'm only mentioning it because when I first 
> became an Arch user I found the overall tone of the forum to be extremely 
> off-putting, so much so that I can pinpoint it as the sole reason I shied 
> away from trying to become an active contributor back then. Also, it will 
> help everyone to know where my head was at when I tell you the rest of my 
> story.
> 
> I stumbled upon Antergos in May 2013 and I immediately knew that I had found 
> my home. The project's goals and the views of its developers aligned 
> perfectly with my own. For me, Antergos was (and still is) the perfect 
> solution as it has allowed me to contribute (albeit indirectly) to the 
> advancement of what I truly believe to be the best linux distribution 
> available. I know that's a rather broad statement, but I'm trying to keep 
> this short and to the point. If anyone would like me to elaborate on 
> something more specifically, I'd be happy to do so.
> 
> I currently maintain six or seven PKGBUILDS in the AUR, of which three are 
> notable: pycharm-eap[1], lightdm-webkit2-greeter[2], and 
> lightdm-webkit-theme-antergos[3]. I've indirectly contributed to other 
> packages in the AUR through comments by offering advice to users, notifying 
> maintainers of new releases as well as any problems with PKGBUILDS (always 
> including a proposed solution), and directing bug reports away from AUR 
> comments and to their proper channel. I always take the time to properly 
> request deletion of PKGBUILDS that shouldnt be in the AUR (for whatever 
> reason) whenever I come across one. I've also reported (and still do report) 
> bugs on http://bugs.archlinux.org when it was/is appropriate. On one or two 
> occasions I've gone as far as reaching out directly to maintainers of 
> official packages to provide them with important information.
> 
> Its's also worth mentioning that I currently maintain many packages[4] for 
> Antergos and I'm open to moving any (that are appropriate) to community.
> 
> So you might be wondering: "Why become a TU now?". Well, the reason is pretty 
> simple. I was asked to consider applying by Alex Filgueira, the TU who 
> currently maintains the Cinnamon packages and a person with whom I've had the 
> pleasure of collaborating with on Antergos for the past three years. Sadly, 
> his schedule has become far too busy to continue to maintain the Cinnamon 
> packages. Another TU, György Balló, has been picking up the slack for the 
> past few months but, having more than a few packages of his own to maintain, 
> he told Alex that it would be nice to have some help with Cinnamon. 
> Considering that Cinnamon is my own personal desktop of choice, Alex thought 
> I would want to consider joining forces with György to maintain Cinnamon. 
> Obviously, Alex was correct and so here we are. That's my story :)
> 
> I know that every minute of your free time is priceless, so thank you all in 
> advance for taking the time review and consider my application. I look 
> forward to (hopefully) "making things official" between myself and Arch Linux.
> 
> 
> [1] https://aur.archlinux.org/packages/pycharm-eap/
> [2] https://aur.archlinux.org/packages/lightdm-webkit2-greeter/
> [3] https://aur.archlinux.org/packages/lightdm-webkit-theme-antergos/
> [4] http://build.antergos.com/browse/main
> 
> 
> Best Regards,
> 
> Dustin Falgout
> Web Developer
> 
> E-mail: dus...@falgout.us
> Google/Skype: dustinfalgout
> Freenode IRC: #antergos
> 

Hi Dustin,

To begin with, could Alex reply to your application to confirm it?

How exactly are you going to contribute to Arch, except maintaining
Cinnamon? Packages from AUR you mentioned aren't really notable (and in
fact, one just repackages proprietary tarball) and these in Antergos
repositories also seem rather unpopular. Looks like some of them can't
be even distributed at all unless JetBrains license allows that; as far
as I know, distribution of ZFS binari

[aur-general] TU Application - Dustin Falgout

[Dustin Falgout]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Everyone,

My name is Dustin Falgout (aka lots0logs) and this is my application to join 
the Arch Linux project as a Trusted User.

About Me:

I'm 29 years old. I live on the Gulf Coast (USA). I work for a leading 
WordPress Theme Company where I do a little bit of everything: from sales, to 
development, to quality assurance, to tech support (you name it...). My first 
experience with linux was with Ubuntu in 2003. It wasn't until around 2008 that 
I began using linux exclusively on my desktops. Wanting more control than comes 
easily with Ubuntu, I first turned to openSUSE and was content for a while. In 
early 2013, I performed my first Arch linux installation and have been using it 
ever since.

- From the start I loved almost everything about Arch. The one thing I didn't 
love was the attitudes towards new users that was so common in the forum. I 
certainly understand all sides of what is a complex issue and I'm not trying to 
open that can of worms here. I'm only mentioning it because when I first became 
an Arch user I found the overall tone of the forum to be extremely off-putting, 
so much so that I can pinpoint it as the sole reason I shied away from trying 
to become an active contributor back then. Also, it will help everyone to know 
where my head was at when I tell you the rest of my story.

I stumbled upon Antergos in May 2013 and I immediately knew that I had found my 
home. The project's goals and the views of its developers aligned perfectly 
with my own. For me, Antergos was (and still is) the perfect solution as it has 
allowed me to contribute (albeit indirectly) to the advancement of what I truly 
believe to be the best linux distribution available. I know that's a rather 
broad statement, but I'm trying to keep this short and to the point. If anyone 
would like me to elaborate on something more specifically, I'd be happy to do 
so.

I currently maintain six or seven PKGBUILDS in the AUR, of which three are 
notable: pycharm-eap[1], lightdm-webkit2-greeter[2], and 
lightdm-webkit-theme-antergos[3]. I've indirectly contributed to other packages 
in the AUR through comments by offering advice to users, notifying maintainers 
of new releases as well as any problems with PKGBUILDS (always including a 
proposed solution), and directing bug reports away from AUR comments and to 
their proper channel. I always take the time to properly request deletion of 
PKGBUILDS that shouldnt be in the AUR (for whatever reason) whenever I come 
across one. I've also reported (and still do report) bugs on 
http://bugs.archlinux.org when it was/is appropriate. On one or two occasions 
I've gone as far as reaching out directly to maintainers of official packages 
to provide them with important information.

Its's also worth mentioning that I currently maintain many packages[4] for 
Antergos and I'm open to moving any (that are appropriate) to community.

So you might be wondering: "Why become a TU now?". Well, the reason is pretty 
simple. I was asked to consider applying by Alex Filgueira, the TU who 
currently maintains the Cinnamon packages and a person with whom I've had the 
pleasure of collaborating with on Antergos for the past three years. Sadly, his 
schedule has become far too busy to continue to maintain the Cinnamon packages. 
Another TU, György Balló, has been picking up the slack for the past few months 
but, having more than a few packages of his own to maintain, he told Alex that 
it would be nice to have some help with Cinnamon. Considering that Cinnamon is 
my own personal desktop of choice, Alex thought I would want to consider 
joining forces with György to maintain Cinnamon. Obviously, Alex was correct 
and so here we are. That's my story :)

I know that every minute of your free time is priceless, so thank you all in 
advance for taking the time review and consider my application. I look forward 
to (hopefully) "making things official" between myself and Arch Linux.


[1] https://aur.archlinux.org/packages/pycharm-eap/
[2] https://aur.archlinux.org/packages/lightdm-webkit2-greeter/
[3] https://aur.archlinux.org/packages/lightdm-webkit-theme-antergos/
[4] http://build.antergos.com/browse/main


Best Regards,

Dustin Falgout
Web Developer

E-mail: dus...@falgout.us
Google/Skype: dustinfalgout
Freenode IRC: #antergos
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJW02A1AAoJEK6lKb8SKQLlb6EH/2bE+uzlWsuU3kIouB8sEGwr
qzGmBT3JntkZsOrsy1fYl7kNz2GAlc2/+8MCJ9LUinkv46Egiw93lW8C58G8eudQ
LOJ1GTz7hh5suO+xOagXdmTJwJMK04VPtHksTeNg3mVONmJPNxSlDdRk77sTHZMd
95aAnvnPBkk1U6Zn4hr6pPUG6HvPGmMseDdmBLr62Fh5CgupsEli4Q2vmgTlZwr6
CoJo9LEaS20djXihDgXYY/6TDEeKeyzj7I9M33IP6eppoACEzsueXxInD5aBPyvD
HgcqvC7UNnpha8k2LBbL5xyTOUiDyhwwpf8umLHWPLCA6OmK9se3aYiY2FaUd8A=
=8/xf
-END PGP SIGNATURE-   

Re: [aur-general] TU Application: Jiachen Yang (farseerfc)

[Jiachen Yang]

On 11/18/2015 12:55 AM, Felix Yan wrote:
> The vote is over and the results are:
> 
> Yes: 25
> No: 4
> Abstain: 5
> Participation: 80.95%
> 
> Congratulations and welcome to our latest TU, Jiachen Yang!
> 
> Here is a list of stuff for you to do now:
> 
> https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#TODO_list_for_new_Trusted_Users
> 

Thank you all!

And it's time to start working~

--
Jiachen Yang 楊嘉晨
Graduate School of Information Science and Technology, Osaka University
Blog: https://farseerfc.me/
Gmail: farsee...@gmail.com



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU Application: Jiachen Yang (farseerfc)

[Felix Yan]

The vote is over and the results are:

Yes: 25
No: 4
Abstain: 5
Participation: 80.95%

Congratulations and welcome to our latest TU, Jiachen Yang!

Here is a list of stuff for you to do now:

https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#TODO_list_for_new_Trusted_Users

-- 
Regards,
Felix Yan



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU Application: Jiachen Yang (farseerfc)

[Jiachen Yang]

On 11/10/2015 11:48 PM, Levente Polyak wrote:
> On 11/10/2015 03:39 PM, Felix Yan wrote:
>> On 11/05/2015 06:16 PM, Jiachen Yang wrote:
>>> Hi everyone,
>>>
>>> I (nickname farseerfc) would like to apply as a Trusted User.
>>> Felix Yan (felixonmars) will be my sponsor.
>>> [...]
>>
>> Discussion period has ended. You can now cast your votes [1]. The voting
>> period ends on 2015-11-17.
>>
>> https://aur.archlinux.org/tu/?id=84
>>
> 
> Hi Jiachen,
> 
> great to hear that Felix has found someone that he has searched for a
> very long time :-)
> 
> The following list seems long, but its just very minor nitpicking...
> don't be scared please! :)
> 
> Sorry that I post some minor nitpicking after the discussion period has
> ended... I forgot my mail in my drafts folder.
> I will do my vote either way, but just wanted to provide my collected
> information to you so its not worthless :-)
> 
> 1) some packages should include a unique source file prefix if they
>were pulled from f.e. github and only contain the $pkgver as tarball:
> - cutegram
> - libqtelegram-ae
> - telegramqml
> - powder-toy
> - wecase
> 
> 2) VCS packages (like git) should add provides and conflicts of the
>providing name (that does not include the VCS postfix)
> - cutegram-git
> - notify-desktop-git
> 
> 3) external references variables should be used only inside of
>quotation-marks
> - ipad_charge
> 
> 4) You could use the new fancy VCS style for jfbpdf, it also should
>either have a -git suffix or be pinned to a static commit
> - jfbpdf
> 
> 5) there is no need anymore for ' || return 1' in normal commands
> - cdate
> 
> 6) a concrete (old) version package should always provide and conflict
>the one it overrides:
> - awesome34
> 
> cheers,
> Levente
> 

Hi, Thank you!

It's my pleasure to receive so many great suggestions for my packages.
I will try my best to update these packages based on these suggestions
as soon as possible.

Thank you again for your precious time and attention.

cheers,
farseerfc



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU Application: Jiachen Yang (farseerfc)

[Levente Polyak]

On 11/10/2015 03:39 PM, Felix Yan wrote:
> On 11/05/2015 06:16 PM, Jiachen Yang wrote:
>> Hi everyone,
>>
>> I (nickname farseerfc) would like to apply as a Trusted User.
>> Felix Yan (felixonmars) will be my sponsor.
>> [...]
> 
> Discussion period has ended. You can now cast your votes [1]. The voting
> period ends on 2015-11-17.
> 
> https://aur.archlinux.org/tu/?id=84
> 

Hi Jiachen,

great to hear that Felix has found someone that he has searched for a
very long time :-)

The following list seems long, but its just very minor nitpicking...
don't be scared please! :)

Sorry that I post some minor nitpicking after the discussion period has
ended... I forgot my mail in my drafts folder.
I will do my vote either way, but just wanted to provide my collected
information to you so its not worthless :-)

1) some packages should include a unique source file prefix if they
   were pulled from f.e. github and only contain the $pkgver as tarball:
- cutegram
- libqtelegram-ae
- telegramqml
- powder-toy
- wecase

2) VCS packages (like git) should add provides and conflicts of the
   providing name (that does not include the VCS postfix)
- cutegram-git
- notify-desktop-git

3) external references variables should be used only inside of
   quotation-marks
- ipad_charge

4) You could use the new fancy VCS style for jfbpdf, it also should
   either have a -git suffix or be pinned to a static commit
- jfbpdf

5) there is no need anymore for ' || return 1' in normal commands
- cdate

6) a concrete (old) version package should always provide and conflict
   the one it overrides:
- awesome34

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU Application: Jiachen Yang (farseerfc)

[Felix Yan]

On 11/05/2015 06:16 PM, Jiachen Yang wrote:
> Hi everyone,
> 
> I (nickname farseerfc) would like to apply as a Trusted User.
> Felix Yan (felixonmars) will be my sponsor.
> [...]

Discussion period has ended. You can now cast your votes [1]. The voting
period ends on 2015-11-17.

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

-- 
Regards,
Felix Yan



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU Application: Jiachen Yang (farseerfc)

[Jiachen Yang]

On 11/06/2015 04:38 AM, Pierre Neidhardt wrote:
> Just out of curiousity: why are you maintaining awesome34?
> Is there something that got lost on the way to 3.5?
> 

Short answer: Yes, the upstream of awesome 3.5 dropped the support for
multiple screens (in X protocol term, not the general meaning of
"screen" in English). There is a bug report to track this in their old
issue tracking system [1], which is the only remaining issue that marked
"critical" and remains unsolved.

Long answer:

I have a relatively rare X multihead setup [2] on my workstation. It has
two identical graphic boards (ATI FirePro V3700), each connected to two
monitors, without a crossfire cable in between. Awesome 3.4 is the only
WM that can drive this setup sanely in my knowledge.

Awesome 3.5 removed support for this setup intentionally, as I quote
from the issue comment [3]:

> This was not by accident. This was me removing something which I can't
> test, which was buggy and which complicated the code a lot (now there
> is just a single pixel at coordinates 0x0 instead of one per screen).

I tried to use Xinerama/Xrandr for some time.

Xinerama itself is painfully slow and buggy to be use, because of the
software rendering. I cannot get OpenGL on Xinerama, and even typing
code in Eclipse is a pain in Xinerama. Further, Xinerama don't seem to
understand monitor rotation and will enter a strange pining mode, so
that I have to patch the Xorg to disable that mode in order to use Xinerama.

Xrandr can use GPU and renders much faster, but xrandr can only utilize
a single GPU. Xrandr 1.3 and previous cannot use 2 graphic boards at
all. Xrandr 1.4 add the ability to render in one card and use another
card as the output sink. I was excited at the time that xrandr 1.4
arrived in Arch Linux and tried it as soon as possible. I was able to
use 3 monitors, 2 connected to the rendering card and 1 connected to the
sink card. But as soon as I added the 4th monitor, Xorg dumped core. I
assume that the buffer size of the entire desktop may beyond the GL
surface that my card can handle.

So since then, I have no choice but to stick on the awesome 3.4 version.
I won't blame the upstream for making the decision, because all other
WMs have either already dropped the support for multiple screens or not
implemented it from the beginning. I have used this setup for years and
I don't want to drop my monitors either.

During these years I have met other problems because of the setup. One
particular case is the GTK3 dropped the support for this setup from
3.10.4 [4] and make the X clipboard unusable for years [5] until
recently. I reported these bug to corresponding upstreams and adopt
workarounds myself during these days. Luckily the clipboard issue is
acknowledged by the upstream and its fix has arrived in Arch Linux since
gtk3.18 . There are other small issues that remains or won't fix.

Talk back to awesome 3.4, I maintain this package mainly for my own use,
with the hope that this might help some other people in the same
situation as I am. It can also helps to debug some old devices with
awesome3.4 installed, for example my kindle paperwhite is running Xorg
and awesome3.4 on it, with highly customized lua configuration from amazon.

I hope this can explain my complex feeling about this package.

[1] https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1069
[2] https://wiki.archlinux.org/index.php/Multihead
[3]
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1069#comment3289
[4] https://bugzilla.gnome.org/show_bug.cgi?id=709716
[5] https://bugzilla.gnome.org/show_bug.cgi?id=719314

--
Jiachen Yang 楊嘉晨
Graduate School of Information Science and Technology, Osaka University
Blog: https://farseerfc.me/
Gmail: farsee...@gmail.com



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU Application: Jiachen Yang (farseerfc)

[Pierre Neidhardt]

Just out of curiousity: why are you maintaining awesome34?
Is there something that got lost on the way to 3.5?

-- 
Pierre Neidhardt

Re: [aur-general] TU Application: Jiachen Yang (farseerfc)

[Felix Yan]

On 11/05/2015 06:16 PM, Jiachen Yang wrote:
> Hi everyone,
> 
> I (nickname farseerfc) would like to apply as a Trusted User.
> Felix Yan (felixonmars) will be my sponsor.
> 
> Some basic information about myself,
> My name is Jiachen Yang (楊嘉晨). I am 27 years old.
> I grown up in Shanghai, China, and I am living in Osaka, Japan.
> I am a PhD student major in Software Engineering in Osaka University.
> I mainly do programming in Python, Java and C++, while I am always
> interested in learning new languages.
> I am a native speaker of Chinese and near-native speaker of Japanese.
> 
> About my involvement in Arch Linux, I have 33 packages on AUR [1].
> I also maintains 89 packages in the unofficial [archlinuxcn] repo [2]
> (most of which PKGBUILD comes from AUR though).
> I do translations of archlinux news for the archlinuxcn.org [3].
> I also contribute occasionally on arch wiki and other places.
> 
> About the packages I want to maintain in [community] , I am considering
> bringing cutegram [4] and its dependencies, several small tools for
> Chinese users such as ccal [5] and cdate [6], some python tools I use
> like pystopwatch [7] and pelican [8].
> I will also take over some packages from Felix Yan, to balance his
> burden. Among all his packages (there is too many) I am interested in
> maintaining Japanese related packages such as fcitx-mozc and some
> packages I am actively using such as pdfpc.
> 
> Thank you for your attention!
> 
> [1] https://aur.archlinux.org/packages/?SeB=m&K=farseerfc
> [2] https://github.com/archlinuxcn/repo/graphs/contributors
> [3] https://www.archlinuxcn.org/feed/
> [4] https://aur.archlinux.org/packages/cutegram/
> [5] https://aur.archlinux.org/packages/ccal/
> [6] https://aur.archlinux.org/packages/cdate/
> [7] https://aur.archlinux.org/packages/pystopwatch/
> [8] https://aur.archlinux.org/packages/pelican/
> 
> 
> --
> Jiachen Yang 楊嘉晨
> Graduate School of Information Science and Technology, Osaka University
> Blog: https://farseerfc.me/
> Gmail: farsee...@gmail.com

I'm glad to confirm my sponsorship. I'm sure he will be great
addition to our team.

So, let the discussion begin!

-- 
Regards,
Felix Yan



signature.asc
Description: OpenPGP digital signature

[aur-general] TU Application: Jiachen Yang (farseerfc)

[Jiachen Yang]

Hi everyone,

I (nickname farseerfc) would like to apply as a Trusted User.
Felix Yan (felixonmars) will be my sponsor.

Some basic information about myself,
My name is Jiachen Yang (楊嘉晨). I am 27 years old.
I grown up in Shanghai, China, and I am living in Osaka, Japan.
I am a PhD student major in Software Engineering in Osaka University.
I mainly do programming in Python, Java and C++, while I am always
interested in learning new languages.
I am a native speaker of Chinese and near-native speaker of Japanese.

About my involvement in Arch Linux, I have 33 packages on AUR [1].
I also maintains 89 packages in the unofficial [archlinuxcn] repo [2]
(most of which PKGBUILD comes from AUR though).
I do translations of archlinux news for the archlinuxcn.org [3].
I also contribute occasionally on arch wiki and other places.

About the packages I want to maintain in [community] , I am considering
bringing cutegram [4] and its dependencies, several small tools for
Chinese users such as ccal [5] and cdate [6], some python tools I use
like pystopwatch [7] and pelican [8].
I will also take over some packages from Felix Yan, to balance his
burden. Among all his packages (there is too many) I am interested in
maintaining Japanese related packages such as fcitx-mozc and some
packages I am actively using such as pdfpc.

Thank you for your attention!

[1] https://aur.archlinux.org/packages/?SeB=m&K=farseerfc
[2] https://github.com/archlinuxcn/repo/graphs/contributors
[3] https://www.archlinuxcn.org/feed/
[4] https://aur.archlinux.org/packages/cutegram/
[5] https://aur.archlinux.org/packages/ccal/
[6] https://aur.archlinux.org/packages/cdate/
[7] https://aur.archlinux.org/packages/pystopwatch/
[8] https://aur.archlinux.org/packages/pelican/


--
Jiachen Yang 楊嘉晨
Graduate School of Information Science and Technology, Osaka University
Blog: https://farseerfc.me/
Gmail: farsee...@gmail.com



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application: Pierre Neidhardt

[Sébastien Luttringer]

On Tue, 2015-10-13 at 10:59 +0200, Pierre Neidhardt wrote:
> Great, I'm very happy to read this!
> Thank you very much and see you around! :)
> 
> On 15-10-12 17:58:43, Alexander F Rødseth wrote:
> > The vote is over and the results are:
> > 
> > Yes: 24
> > No: 4
> > Abstain: 4
> > 
> > Congratulations and welcome to our latest TU, Pierre Neidhardt!
> > 
> > -- 
> > Sincerely,
> > Alexander F Rødseth / xyproto
> 

Welcome!

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

Re: [aur-general] TU application: Pierre Neidhardt

[Anatol Pomozov]

Hi Pierre

On Tue, Oct 13, 2015 at 1:59 AM, Pierre Neidhardt  wrote:
> Great, I'm very happy to read this!
> Thank you very much and see you around! :)

Welcome to the club. Herding Arch packages is a fun and interesting activity.

Re: [aur-general] TU application: Pierre Neidhardt

[Laurent Carlier]

Le Tuesday 13 October 2015, 10:59:38 Pierre Neidhardt a écrit :
> Great, I'm very happy to read this!
> Thank you very much and see you around! :)
> 

Welcome Pierre!
-- 
Laurent Carlier
http://www.archlinux.org

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

Re: [aur-general] TU application: Pierre Neidhardt

[Sven-Hendrik Haase]

On 13.10.2015 10:59, Pierre Neidhardt wrote:

Great, I'm very happy to read this!
Thank you very much and see you around! :)

On 15-10-12 17:58:43, Alexander F Rødseth wrote:

The vote is over and the results are:

Yes: 24
No: 4
Abstain: 4

Congratulations and welcome to our latest TU, Pierre Neidhardt!

--
Sincerely,
 Alexander F Rødseth / xyproto


Awesome, welcome aboard!

Re: [aur-general] TU application: Pierre Neidhardt

[Pierre Neidhardt]

Great, I'm very happy to read this!
Thank you very much and see you around! :)

On 15-10-12 17:58:43, Alexander F Rødseth wrote:
> The vote is over and the results are:
> 
> Yes: 24
> No: 4
> Abstain: 4
> 
> Congratulations and welcome to our latest TU, Pierre Neidhardt!
> 
> -- 
> Sincerely,
> Alexander F Rødseth / xyproto

-- 
Pierre Neidhardt

Booker's Law:
An ounce of application is worth a ton of abstraction.


signature.asc
Description: PGP signature

Re: [aur-general] TU application: Pierre Neidhardt

[Alexander F Rødseth]

The vote is over and the results are:

Yes: 24
No: 4
Abstain: 4

Congratulations and welcome to our latest TU, Pierre Neidhardt!

-- 
Sincerely,
Alexander F Rødseth / xyproto

Re: [aur-general] TU application: Pierre Neidhardt

[Bartłomiej Piotrowski]

On Sun, 11 Oct 2015 14:10:42 +0200
Stefan Husmann  wrote:
> Am 04.10.2015 um 21:01 schrieb Alexander F Rødseth:
> > The discussion period is over. Let the voting begin!
> > https://aur.archlinux.org/tu/?id=83
> > 
> > ---
> > Sincerely,
> > Alexander F Rødseth / xyproto
> >   
> Any results?


Not yet, vote will end in 2 hours.

BP


pgpEtmVACvDZw.pgp
Description: OpenPGP digital signature

Re: [aur-general] TU application: Pierre Neidhardt

[Stefan Husmann]

Am 04.10.2015 um 21:01 schrieb Alexander F Rødseth:
> The discussion period is over. Let the voting begin!
> https://aur.archlinux.org/tu/?id=83
> 
> ---
> Sincerely,
> Alexander F Rødseth / xyproto
> 
Any results?

Re: [aur-general] TU application: Pierre Neidhardt

[Alexander F Rødseth]

The discussion period is over. Let the voting begin!
https://aur.archlinux.org/tu/?id=83

---
Sincerely,
Alexander F Rødseth / xyproto

Re: [aur-general] TU application: Pierre Neidhardt

[Jerome Leclanche]

On 28 September 2015 at 12:34, Alexander F Rødseth
 wrote:
> I confirm that I sponsor the TU application of Pierre Neidhardt.
>
> While not having that many packages on AUR, his packages are pretty clean
> and he was very helpful in fixing up the latest Go PKGBUILD (upstream had
> made several changes that required the build process to change, and it was
> a pretty long and cumbersome PKGBUILD in the first place). See FS#46219 (
> https://bugs.archlinux.org/task/46219) for more information.
>
> The applicant also has several other open source contributions under his
> belt, and communicates clearly.
>
> I think he would make a great addition to the team.
>
> --
> Best regards,
> Alexander F Rødseth / xyproto

I think Pierre would make an excellent TU.

Best of luck!

J. Leclanche

Re: [aur-general] TU application: Pierre Neidhardt

[Pierre Neidhardt]

Thanks!

Sure, I can talk a bit more about myself: I'm 26, I've been living in various
countries around Europe, lastly in Sweden. In a few weeks time I'll find myself
flying to Australia. I will probably spend some time over there surfing the
kangaroos.

I speak English, French, German, some rusty Swedish and random bits of
European languages. (Yep, I like learning about languages :p) Other hobbies
include skiing, camping in the wild, visiting cities and their pubs, and
watching the latest Korean movie.

Hope that will do for an express biography! :D

Cheers!

Pierre

On 15-09-29 03:19:55, Sven-Hendrik Haase wrote:
> Hi, nice application!
> 
> I'd like to get to know you a bit. How old are you? Where do you currently
> reside?
> 
> I like your goals.
> 
> Sven

-- 
Pierre Neidhardt

You may be recognized soon.  Hide.


signature.asc
Description: PGP signature

Re: [aur-general] TU application: Pierre Neidhardt

[Sven-Hendrik Haase]

Hi, nice application!

I'd like to get to know you a bit. How old are you? Where do you currently
reside?

I like your goals.

Sven

On Mon, Sep 28, 2015 at 12:34 PM, Alexander F Rødseth  wrote:

> I confirm that I sponsor the TU application of Pierre Neidhardt.
>
> While not having that many packages on AUR, his packages are pretty clean
> and he was very helpful in fixing up the latest Go PKGBUILD (upstream had
> made several changes that required the build process to change, and it was
> a pretty long and cumbersome PKGBUILD in the first place). See FS#46219 (
> https://bugs.archlinux.org/task/46219) for more information.
>
> The applicant also has several other open source contributions under his
> belt, and communicates clearly.
>
> I think he would make a great addition to the team.
>
> --
> Best regards,
> Alexander F Rødseth / xyproto
>

Re: [aur-general] TU application: Pierre Neidhardt

[Alexander F Rødseth]

I confirm that I sponsor the TU application of Pierre Neidhardt.

While not having that many packages on AUR, his packages are pretty clean
and he was very helpful in fixing up the latest Go PKGBUILD (upstream had
made several changes that required the build process to change, and it was
a pretty long and cumbersome PKGBUILD in the first place). See FS#46219 (
https://bugs.archlinux.org/task/46219) for more information.

The applicant also has several other open source contributions under his
belt, and communicates clearly.

I think he would make a great addition to the team.

-- 
Best regards,
Alexander F Rødseth / xyproto

[aur-general] TU application: Pierre Neidhardt

[Pierre Neidhardt]

Hi!

My name is Pierre Neidhardt. I am sending my TU application under the
sponsor of Alexander F Rødseth (xyproto). (Thanks again, Alexander.)

Before going on with the geekiness, a few things about me: my hobbies include
cinema, reading & watching stuff on psychology and education, as well as
quitting my job + moving out + travelling to another country every two years. I
am a computer scientist. I am deeply interested in algorithms, languages and
operating systems, but my main field remains computer graphics. I have worked in
research and briefly for the video game industry. I am working / planning on
getting games and engines running on Unices. I am also a little active in the
Wine project and on AppDB.

I have been dealing with many different flavours of Unices for several years
now. My preference goes to KISS / fundamental Unices, such as Gentoo, FreeBSD,
or, surprisingly, Arch :D I love the robustness and the scientific approach of
these distributions and their philosophy. (I have deep respect for the dreadful
. :p)

I am fond of programming languages created with a technically simple and elegant
design in mind. I am thinking of C, Lua and the younger Go. I've contributed to
numerous open-source projects (dwb, Emacs, Mutt, ranger...), since I strongly
endorse the opinion that upstream should be fixed first ;) I have created and
maintained a few programs. One of them is demlo[1], a (very) dynamic and
extensible music organizer. (Currently broken with Lua 5.3 because of an
unported dependency... Will fix soon!)

I also used to be a TeX and LaTeX guru and I contributed to a major part of the
LaTeX Wikibook[2]. (Beside new content, I helped for a massive re-organization,
structure and progression clarification, duplicates removal and pointer use.)


Regarding Arch, I have maintained a few dozen AUR packages[3] in the last few
years. (Some of which I have disowned out of a lack of interest.) Other
contributions include numerous Wiki edits[4] (Cups, Emacs, Mutt, wifi), a few
bug reports (everybody knows Arch has no bugs :p), some forum strolling and some
documentation / patches around makepkg & co[5][6].

I have recently been working with Alexander on overhauling the Go package[7]:
correct dependencies, strip binaries, update cleanup, set up cross-compilation
tool-chain properly and remove unneeded binaries. This gave me even more
motivation than before to become a TU. I have subsequently asked Alexander to
endorse my TU application.

My focus is on Go packages, other CLI applications, Lua libraries and video
games. I might consider packaging Go programs such as gur, camlistore, gotsync,
oh, fnd, tabby, to name a few. The `go` compiler enforces static building
(rationale: [8]), which often results in packages with no dependencies at all.
(The `go` package itself has none!) This makes packaging even more relevant, as
the requirements for building the package are much higher than for installing
the result.

AUR packages that I would like to maintain in community include clyrics,
docx2txt, tespeed, textadept, uncrustify, translate, trash-cli.

Thank you and happy voting!

Cheers!

-- 
Pierre Neidhardt

https://ambrevar.bitbucket.org

[1]: https://ambrevar.bitbucket.org/demlo/
[2]: http://en.wikibooks.org/wiki/User:Ambrevar
[3]: https://aur.archlinux.org/packages/?SeB=m&K=Ambrevar
[4]: https://wiki.archlinux.org/index.php/User:Ambrevar
[5]: https://lists.archlinux.org/pipermail/pacman-dev/2014-February/018807.html
[6]: https://lists.archlinux.org/pipermail/pacman-dev/2014-March/018851.html
[7]: 
https://projects.archlinux.org/svntogit/community.git/commit/trunk?h=packages/go&id=005cb503bf18d040e2ac756bffee5123c826d92b
[8]: http://port70.net/~nsz/32_dynlink.html


signature.asc
Description: PGP signature

[aur-general] TU vacation

[Alexander F Rødseth]

Hi,

Feel free to update my packages while I'm on vacation. I'm back at the end
of July.

--
Best regards,
  Alexander Rødseth
  xyproto / TU


-- 
Best regards,
Alexander F Rødseth / xyproto

Re: [aur-general] TU Application: Johannes Löthberg

[Sam Stuewe]

On Tue, Apr 21, 2015 at 09:52:58AM +0200, Jelle van der Waa wrote:
> Which means that the TU Application has been accepted!

Congratulations! I look forward to seeing all that you bring to the
community (I have no doubt it will be great)!

All the best,

-Sam

Re: [aur-general] TU Application: Johannes Löthberg

[Jelle van der Waa]

On 04/09/15 at 11:27am, Johannes Löthberg wrote:
> Hello,
> 
> This is my official application to become a Trusted User, as Jelle decided
> to sponsor me
> 
> So, a little info about me. My name is Johannes Löthberg, I’m currently 19
> years old, at the end of the last year of my Gymnasium education, and I live
> in Stockholm, Sweden. I sometimes do some light programming, in either C or
> Python[1][2], I like to do server and network administration.
> 
> Currently I am an Arch Linux IRC operator, occasionally take a stroll through
> the Arch bug-tracker, and have sent in small number of patches to
> makpkg/pacman[3][4], and maintain a couple of packages in the AUR.
> 
> Some packages I would like to maintain in [community] are, among others,
> np1-mps[5], mps-youtube[6], spambayes[7], irker[8], and rhash[#]. Some of
> the orphans in [community] I’d like to adopt are ncmpcpp, nss-pam-ldapd, and
> python{,2}-msgpack, and possibly Apache Directory Studio if I can get it
> packaged sanely. Additionally, I’d also like to help maintain some of the
> Haskell packages.
> 
> -- 
> Sincerely,
>  Johannes Löthberg
>  PGP Key ID: 0x50FB9B273A9D0BB5
>  https://theos.kyriasis.com/~kyrias/

Vote ended, here are the results!

Yes: 23
No:  4
Abstain: 4

Which means that the TU Application has been accepted!

Johannes, please look at the TODO list for new Trusted Users. [1]

[1] https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines

-- 
Jelle van der Waa


pgpB4FLFo41ER.pgp
Description: PGP signature

Re: [aur-general] TU Application: Johannes Löthberg

[Jelle van der Waa]

On 04/09/15 at 11:42am, Jelle van der Waa wrote:
> On 04/09/15 at 11:27am, Johannes Löthberg wrote:
> > Hello,
> > 
> > This is my official application to become a Trusted User, as Jelle decided
> > to sponsor me
> > 
> > So, a little info about me. My name is Johannes Löthberg, I’m currently 19
> > years old, at the end of the last year of my Gymnasium education, and I live
> > in Stockholm, Sweden. I sometimes do some light programming, in either C or
> > Python[1][2], I like to do server and network administration.
> > 
> > Currently I am an Arch Linux IRC operator, occasionally take a stroll 
> > through
> > the Arch bug-tracker, and have sent in small number of patches to
> > makpkg/pacman[3][4], and maintain a couple of packages in the AUR.
> > 
> > Some packages I would like to maintain in [community] are, among others,
> > np1-mps[5], mps-youtube[6], spambayes[7], irker[8], and rhash[#]. Some of
> > the orphans in [community] I’d like to adopt are ncmpcpp, nss-pam-ldapd, and
> > python{,2}-msgpack, and possibly Apache Directory Studio if I can get it
> > packaged sanely. Additionally, I’d also like to help maintain some of the
> > Haskell packages.
> 
> I confirm that I sponsor Johannes, also known as 'demize' on irc :). I
> think he will be great additition to the team.
> 
> -- 
> Jelle van der Waa

You can cast your votes!

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

-- 
Jelle van der Waa


pgpYVLh4xMi5M.pgp
Description: PGP signature

Re: [aur-general] TU Application: Johannes Löthberg

[Sam Stuewe]

On Thu, Apr 09, 2015 at 02:32:53PM +0200, Johannes Löthberg wrote:
> On 09/04, Sam Stuewe wrote:
> ❤
❤ indeed.

> Two related groups of packages I’m interested in are LDAP and Kerberos
> packages. I couldn’t adopt krb5 and openldap since they are in [core], but
> I’d like to maintain related packages like nss-pam-ldapd, pam-krb5, and
> possibly things like mod_auth_kerb, which is an Apache module for Kerberos
> authentication, and apachedirectorystudio if I can get it packages more
> nicely as an eclipse plugin instead of just dumping their binaries in /opt.
Having little experience with either group, I cannot offer much on the
topic, but it sounds like you have some clear idea of what you'd like to
offer :)

> I’m also interested in some media packages, like np1-mps and mps-youtube
> which are music streaming clients, cmusfm and mpdscribble which are last.fm
> scrobblers for cmus and mpd respectively,
>
> Other than that, I don’t use much Haskell things, but the language does
> interest me, and I also know that it’s something of a pain to maintain the
> packages, so I thought that more help with that could be nice.
Great! Thanks for the responses and I wish you the best of luck!

All the best,

Sam Stuewe

Re: [aur-general] TU Application: Johannes Löthberg

[Johannes Löthberg]

On 09/04, Sam Stuewe wrote:
As an extra side note about Johannes's experience, he diligently 
maintains his own custom repo with several quality packages. So, he is 
already familiar with much of the repo maintenance schtick.




❤

I'd be interested to hear whether or not there are some groups of 
packages (not the packages themselves, but rather, a theme or type of 
package) that you are interested in maintaining. Put more plainly, what 
kind of packages interest you (you mentioned Haskell packages, for 
example, is that because Haskell interests you, or are there particular 
Haskell packages that you'd like to see in [community])?




Two related groups of packages I’m interested in are LDAP and Kerberos 
packages. I couldn’t adopt krb5 and openldap since they are in [core], 
but I’d like to maintain related packages like nss-pam-ldapd, pam-krb5, 
and possibly things like mod_auth_kerb, which is an Apache module for 
Kerberos authentication, and apachedirectorystudio if I can get it 
packages more nicely as an eclipse plugin instead of just dumping their 
binaries in /opt.


I’m also interested in some media packages, like np1-mps and mps-youtube 
which are music streaming clients, cmusfm and mpdscribble which are 
last.fm scrobblers for cmus and mpd respectively, 

Other than that, I don’t use much Haskell things, but the language does 
interest me, and I also know that it’s something of a pain to maintain 
the packages, so I thought that more help with that could be nice.


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


signature.asc
Description: PGP signature

Re: [aur-general] TU Application: Johannes Löthberg

[Sam Stuewe]

Dear TUs,

As an extra side note about Johannes's experience, he diligently maintains his 
own custom repo with several quality packages. So, he is already familiar with 
much of the repo maintenance schtick.

Johannes, I am clearly not a TU, but as an interested member of the AL peanut 
gallery, I'd be interested to hear whether or not there are some groups of 
packages (not the packages themselves, but rather, a theme or type of package) 
that you are interested in maintaining. Put more plainly, what kind of packages 
interest you (you mentioned Haskell packages, for example, is that because 
Haskell interests you, or are there particular Haskell packages that you'd like 
to see in [community])?

Full disclosure: though not a TU myself, I would wholeheartedly support 
Johannes's joining the team and he would have my vote if I had one to give.

All the best,

---
Sam Stuewe

Re: [aur-general] TU Application: Johannes Löthberg

[Jelle van der Waa]

On 04/09/15 at 11:27am, Johannes Löthberg wrote:
> Hello,
> 
> This is my official application to become a Trusted User, as Jelle decided
> to sponsor me
> 
> So, a little info about me. My name is Johannes Löthberg, I’m currently 19
> years old, at the end of the last year of my Gymnasium education, and I live
> in Stockholm, Sweden. I sometimes do some light programming, in either C or
> Python[1][2], I like to do server and network administration.
> 
> Currently I am an Arch Linux IRC operator, occasionally take a stroll through
> the Arch bug-tracker, and have sent in small number of patches to
> makpkg/pacman[3][4], and maintain a couple of packages in the AUR.
> 
> Some packages I would like to maintain in [community] are, among others,
> np1-mps[5], mps-youtube[6], spambayes[7], irker[8], and rhash[#]. Some of
> the orphans in [community] I’d like to adopt are ncmpcpp, nss-pam-ldapd, and
> python{,2}-msgpack, and possibly Apache Directory Studio if I can get it
> packaged sanely. Additionally, I’d also like to help maintain some of the
> Haskell packages.
> 
> [1]: https://github.com/kyrias/
> [2]: https://github.com/yabok
> [3]: https://lists.archlinux.org/pipermail/pacman-dev/2014-July/019185.html
> [4]: 
> https://lists.archlinux.org/pipermail/pacman-dev/2014-December/019673.html
> [5]: https://aur.archlinux.org/packages/np1-mps/
> [6]: https://aur.archlinux.org/packages/mps-youtube
> [7]: https://aur.archlinux.org/packages/spambayes
> [8]: https://aur.archlinux.org/packages/irker
> [9]: https://aur.archlinux.org/packages/rhash
> 
> -- 
> Sincerely,
>  Johannes Löthberg
>  PGP Key ID: 0x50FB9B273A9D0BB5
>  https://theos.kyriasis.com/~kyrias/


I confirm that I sponsor Johannes, also known as 'demize' on irc :). I
think he will be great additition to the team.

-- 
Jelle van der Waa


pgp90qXagNxlw.pgp
Description: PGP signature

[aur-general] TU Application: Johannes Löthberg

[Johannes Löthberg]

Hello,

This is my official application to become a Trusted User, as Jelle 
decided to sponsor me


So, a little info about me. My name is Johannes Löthberg, I’m currently 
19 years old, at the end of the last year of my Gymnasium education, and 
I live in Stockholm, Sweden. I sometimes do some light programming, in 
either C or Python[1][2], I like to do server and network 
administration.


Currently I am an Arch Linux IRC operator, occasionally take a stroll through
the Arch bug-tracker, and have sent in small number of patches to
makpkg/pacman[3][4], and maintain a couple of packages in the AUR.

Some packages I would like to maintain in [community] are, among others, 
np1-mps[5], mps-youtube[6], spambayes[7], irker[8], and rhash[#]. Some 
of the orphans in [community] I’d like to adopt are ncmpcpp, 
nss-pam-ldapd, and python{,2}-msgpack, and possibly Apache Directory 
Studio if I can get it packaged sanely. Additionally, I’d also like to 
help maintain some of the Haskell packages.


[1]: https://github.com/kyrias/
[2]: https://github.com/yabok
[3]: https://lists.archlinux.org/pipermail/pacman-dev/2014-July/019185.html
[4]: https://lists.archlinux.org/pipermail/pacman-dev/2014-December/019673.html
[5]: https://aur.archlinux.org/packages/np1-mps/
[6]: https://aur.archlinux.org/packages/mps-youtube
[7]: https://aur.archlinux.org/packages/spambayes
[8]: https://aur.archlinux.org/packages/irker
[9]: https://aur.archlinux.org/packages/rhash

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


signature.asc
Description: PGP signature

Re: [aur-general] TU application

[Andrea Scarpino]

On Fri 07, November 10:34:13 Florian Pritz wrote:
> The vote is over:
> 
> Yes: 24
> No: 2
> Abstain: 1

Great result!

Congrats Antonio!!!

-- 
Andrea
Arch Linux Developer

Re: [aur-general] TU application

[Sébastien Luttringer]

On 07/11/2014 10:34, Florian Pritz wrote:
> On 31.10.2014 08:44, Andrea Scarpino wrote:
>> On Thu, Oct 23, 2014 at 9:24 AM, Antonio Rojas  wrote:
>>> Hello Arch Linux community,
>>>
>>>  This is my application to become an Arch trusted user. My name is Antonio
>>> Rojas, I'm a mathematician and professor from Spain. Andrea Scarpino has
>>> kindly encouraged me to apply and agreed to sponsor my application.
>>
>> The discussion period is over, TUs let's vote!
>>
>> https://aur.archlinux.org/tu/?id=78
>>
> 
> The vote is over:
> 
> Yes: 24
> No: 2
> Abstain: 1
> 
> Welcome to the TU team Antonio!
> 
Welcome aboard.

-- 
Sébastien "Seblu" Luttringer
Archlinux Developer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

Re: [aur-general] TU application

[Muflone]

> Welcome to the TU team Antonio!


Welcome, Antonio :D


-- 
Fabio Castelli aka Muflone

Re: [aur-general] TU application

[Jerome Leclanche]

Hi Antonio

Sorry I caught this late. I'm an lxqt developer and I maintain the lxqt git
packages on the AUR. Please email me if you would like help packaging them
for arch, I would like to assist.
On Nov 7, 2014 3:27 PM, "Antonio Rojas"  wrote:

> El Viernes, 7 de noviembre de 2014 a las 10:34 Florian Pritz escribió:
> > The vote is over:
> >
> > Yes: 24
> > No: 2
> > Abstain: 1
> >
> > Welcome to the TU team Antonio!
>
> Great, thanks! Going through the to-do list now.

Re: [aur-general] TU application

[Antonio Rojas]

El Viernes, 7 de noviembre de 2014 a las 10:34 Florian Pritz escribió: 
> The vote is over:
> 
> Yes: 24
> No: 2
> Abstain: 1
> 
> Welcome to the TU team Antonio!

Great, thanks! Going through the to-do list now. 

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

Re: [aur-general] TU application

[Florian Pritz]

On 31.10.2014 08:44, Andrea Scarpino wrote:
> On Thu, Oct 23, 2014 at 9:24 AM, Antonio Rojas  wrote:
>> Hello Arch Linux community,
>>
>>  This is my application to become an Arch trusted user. My name is Antonio
>> Rojas, I'm a mathematician and professor from Spain. Andrea Scarpino has
>> kindly encouraged me to apply and agreed to sponsor my application.
> 
> The discussion period is over, TUs let's vote!
> 
> https://aur.archlinux.org/tu/?id=78
> 

The vote is over:

Yes: 24
No: 2
Abstain: 1

Welcome to the TU team Antonio!



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application

[Andrea Scarpino]

On Thu, Oct 23, 2014 at 9:24 AM, Antonio Rojas  wrote:
> Hello Arch Linux community,
>
>  This is my application to become an Arch trusted user. My name is Antonio
> Rojas, I'm a mathematician and professor from Spain. Andrea Scarpino has
> kindly encouraged me to apply and agreed to sponsor my application.

The discussion period is over, TUs let's vote!

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

-- 
Andrea

Re: [aur-general] TU application

[Ike Devolder]

Op donderdag 23 oktober 2014 09:33:57 schreef Andrea Scarpino:
> On Thu, Oct 23, 2014 at 9:31 AM, Andrea Scarpino  
wrote:
> > As I said time ago Antonio has been fundamental for Plasma 5 packages,
> > but he also helped me a lot handling the conflicts with KDE4.
> 
> Oh, about his packaging skills you can see I changed very few and
> minor things (you can take a look to our SVN history: I pushed his
> version first, and then I applied some change where needed).

Great to have another KDE enthousiast applying here :)

-- 
Ike

Re: [aur-general] TU application

[Andrea Scarpino]

On Thu, Oct 23, 2014 at 9:31 AM, Andrea Scarpino  wrote:
> As I said time ago Antonio has been fundamental for Plasma 5 packages,
> but he also helped me a lot handling the conflicts with KDE4.

Oh, about his packaging skills you can see I changed very few and
minor things (you can take a look to our SVN history: I pushed his
version first, and then I applied some change where needed).

-- 
Andrea

Re: [aur-general] TU application

[Andrea Scarpino]

On Thu, Oct 23, 2014 at 9:24 AM, Antonio Rojas  wrote:
>  This is my application to become an Arch trusted user. My name is Antonio
> Rojas, I'm a mathematician and professor from Spain. Andrea Scarpino has
> kindly encouraged me to apply and agreed to sponsor my application.

...and I'm very happy you did accept!

As I said time ago Antonio has been fundamental for Plasma 5 packages,
but he also helped me a lot handling the conflicts with KDE4.

Also, since some TU resigned I guess we lack a "KDE figure" in our
team at the moment.

Let the discussion period begin! Good luck Antonio!

-- 
Andrea

[aur-general] TU application

[Antonio Rojas]

Hello Arch Linux community,

 This is my application to become an Arch trusted user. My name is Antonio 
Rojas, I'm a mathematician and professor from Spain. Andrea Scarpino has 
kindly encouraged me to apply and agreed to sponsor my application. 

 I started using Linux in grad school in 1999 (Red Hat). I 
quickly got to like it, but since it was preinstalled I was missing all the 
fun of installing and configuring it. Around 2004 I finally decided to install 
it in my own computers, first in virtual machines and then as the main OS. 
After trying a few distros I settled with Mandriva, and kept using it until 
the company started going downhill. Then I moved briefly to Fedora, until I 
discovered Arch around 2008 and I haven't left since then. It requires the 
perfect ammount of fiddling to make it work (for my taste) and I love always 
having the latest software available. 

 In the last few years I've been an active user in the forum [1] (mostly 
helping people with KDE issues) and bug tracker [2], both in Arch and in 
upstream KDE. Despite not being a programmer, I've occasionally sent small 
patches to fix some issues. 

 I've been maintaining packages in AUR for a few years, some of them have been 
moved to the repos. Currently I maintain close to 200 packages [3], most of 
them KDE related. I maintain the git versions of KDE Frameworks and Plasma, 
and created and maintained the first version of the Plasma 5 packages that 
were moved to [extra] last week. I think the next few months are going to be 
very exciting in the KDE world, with apps being ported to Frameworks and new 
apps popping up that could be moved to [community] when they become popular.

Among the KDE apps that I would like to maintain in community are some that 
were dropped in the past but are still maintained upstream, like 
partitionmanager or kmplayer, some addons for Plasma 5 like sddm-kcm or kde-
gtk-config (they are very recent so don't have many votes yet, but their KDE4 
version is quite popular), and other ones like bangarang or zanshin which were 
unmaintained upstream for a while but have seen very active development in the 
last few weeks. I could also maintain some orphan KDE/Qt packages in 
community: rekonq, kcm-touchpad, texmaker.

Besides KDE, my other interest is mathematical and scientific applications in 
general. Those tend to be quite specialized, so not many of them satisfy the 
requirements to be moved to [community]. What I would like to do however (if 
arcanis agrees, of course) is try to package sage-mathematics "properly". That 
is, instead of shipping the monolithic monster that upstream provides, with 
private copies of many system libraries (which sometimes cause conflicts with 
system libs, like it happened with the last major bash upgrade), package all 
missing dependencies and 
build the Sage library against them. This is a big task, since Sage has a huge 
number of dependencies, but Fedora and Mandriva (before it died) already do it 
this way since a few years ago, so it could be used as a model. Besides the 
obvious advantages in terms of disk space and runtime memory savings, this 
would also provide the individual components by themselves in the repos, so 
those interested could use them without having to install a 2.5 GB package. I 
looked into it when I was maintaining Sage in AUR, but I decided it wouldn't 
be practical to make people compile lots of different packages, now that it's 
in the repos it's a different story.

Some other packages that I would like to move to the repos: clipgrab, 
speedcrunch, some libreoffice-latex extensions (writer2latex and texmaths), 
opensc (dropped recently for lack of TUs interest). I would also consider 
moving the LXQt desktop, the port of lxde to Qt5 and KF5, which has seen its 
first stable release recently. 

Thank you all for considering my application.
Regards,
 Antonio

[1] https://bbs.archlinux.org/profile.php?id=53078
[2] https://bugs.archlinux.org/user/5403
[3] https://aur.archlinux.org/packages/?SeB=m&K=arojas

 

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

Re: [aur-general] TU resignation.

[Sébastien Luttringer]

On 04/08/2014 18:41, Peter Lewis wrote:
> ...
> 

Thanks for you early support. Good road buddy!


-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU resignation.

[Ike Devolder]

On Mon, Aug 04, 2014 at 05:41:42PM +0100, Peter Lewis wrote:
> Hi all,
> 
> I had hoped it wouldn't come to this, but based on mounting evidence,
> I've come to the conclusion that I should resign as a TU. Most of you
> probably already forgot I was here, and I'm sorry that I just haven't
> been able to keep on top of things and participate lately.
> 
> A lot has happened with me over the last year: became a father, got a
> new job, moved house... and I'm realising that my life has changed such
> that I haven't found time to keep up with Arch / TU duties.
> 
> I'm still a day-to-day Archer at work and home, and don't see that
> changing any time. And it's great to have been part of such a talented
> and welcoming team. Thanks to all of you for the effort you put in to
> keeping Arch the great distribution it is.
> 
> Cheers,
> 
> Pete.

First of all: congratulations on becoming a father, enjoy all the time
you can get with your kid(s).

Thanks for your contributions to this great distribution.

Enjoy life and Arch :)

-- 
Ike


pgpbVSXHQwVLC.pgp
Description: PGP signature

Re: [aur-general] TU resignation.

[Xyne]

Congrats on what sounds like several bits of good news! 

On 2014-08-04 17:41 +0100
Peter Lewis wrote:

>Hi all,
>
>I had hoped it wouldn't come to this, but based on mounting evidence,
>I've come to the conclusion that I should resign as a TU. Most of you
>probably already forgot I was here, and I'm sorry that I just haven't
>been able to keep on top of things and participate lately.
>
>A lot has happened with me over the last year: became a father, got a
>new job, moved house... and I'm realising that my life has changed such
>that I haven't found time to keep up with Arch / TU duties.
>
>I'm still a day-to-day Archer at work and home, and don't see that
>changing any time. And it's great to have been part of such a talented
>and welcoming team. Thanks to all of you for the effort you put in to
>keeping Arch the great distribution it is.
>
>Cheers,
>
>Pete.

Re: [aur-general] TU resignation.

[Stefan Husmann]

Am 04.08.2014 um 18:41 schrieb Peter Lewis:

Hi all,

I had hoped it wouldn't come to this, but based on mounting evidence,
I've come to the conclusion that I should resign as a TU. Most of you
probably already forgot I was here, and I'm sorry that I just haven't
been able to keep on top of things and participate lately.

A lot has happened with me over the last year: became a father, got a
new job, moved house... and I'm realising that my life has changed such
that I haven't found time to keep up with Arch / TU duties.

I'm still a day-to-day Archer at work and home, and don't see that
changing any time. And it's great to have been part of such a talented
and welcoming team. Thanks to all of you for the effort you put in to
keeping Arch the great distribution it is.

Cheers,

Pete.


Hello,

very good reasons indeed. All the best to you and your family.

And when time has come, come back and sponsor your son/daughter :)

Best wishes

Stefan