Re: [aur-general] SGE

[Loui Chang]

On Wed 14 Oct 2020 21:13 +0200, alad via aur-general wrote:
> On 14/10/2020 21:09, t...@tswartz.net wrote:
> > On Wed, Oct 14, 2020 at 09:03:26PM +0200, alad via aur-general wrote:
> > > On 14/10/2020 17:16, Manhong Dai via aur-general wrote:
> > > > Hi Bruno,
> > > Top-posting, do you know what it means?
> > >
> > > Do not do this: https://en.wikipedia.org/wiki/Posting_style#Top-posting
> > >
> > > But do this: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
> > > or https://en.wikipedia.org/wiki/Posting_style#Bottom-posting
> > >
> > > Again https://wiki.archlinux.org/index.php/Code_of_conduct#Top_posting
> > >
> > > Don't expect anyone to take you seriously if you keep doing this even 
> > > after
> > > being asked not to, repeatedly.
> > >
> > > Alad
> > >
> > > > Thanks a lot for confirming that I didn't receive Orphaning
> > > > email!
> > > >
> > > > I did receive the comment. I actually checked the pull request
> > > > a little, but decided not to reply because I didn't want to be
> > > > negative. I totally believe the current maintainer has a better format
> > > > of PKGBUILD (well, except his pkgver mistake). Now let me comment a few
> > > > things on SGE.
> > > >
> > > > In the SGE package comment.
> > > >
> > > > 1, The current maintainer blamed me "连pkgver都填错这个真的是有点不可容忍了". Google
> > > > translation: "It’s really intolerable that even pkgver was filled in
> > > > wrong."
> > > >
> > > > Now it turned out that the current maintainer made the mistake.
> > > >
> > > > 2, He also said "通过.install在post install阶段装了一大堆包管理器没有接管的文件", Google
> > > > translation "A lot of files that the package manager did not take over
> > > > were installed in the post install stage through .install".
> > > >
> > > > This could be a disaster if somebody want to upgrade SGE by 
> > > > uninstall
> > > > and re-install. SGE has been a very special software because it needs
> > > > some post installation to let user specify a lot of host/jobs/queue
> > > > configuration. Thus all files are put under /opt/sge for the legacy
> > > > reason.
> > > >
> > > >
> > > > Best,
> > > > Manhong
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, 2020-10-14 at 18:58 +0400, Archange wrote:
> > > > > Hi,
> > > > >
> > > > > Le 14/10/2020 à 18:47, Manhong Dai via aur-general a écrit :
> > > > > > 2, Force an AUR package maintainer to join AUR-general, or send
> > > > > > every
> > > > > > notification to the package maintainer, as I never received any
> > > > > > email
> > > > > > notification about orphaning SGE.
> > > > > I’m not commenting on everything else here, but regarding this point:
> > > > > subscription to aur-general is not required, and every notifications
> > > > > are
> > > > > sent to the package maintainer… or at least should be, because a bug
> > > > > introduced some months ago broke that (see
> > > > > https://gitlab.archlinux.org/archlinux/aurweb/-/merge_requests/6).
> > > > >
> > > > > So indeed you did not receive the Orphaning requests notifications.
> > > > > But
> > > > > you did receive comments on the AUR page, and you did receive the
> > > > > emails
> > > > > to which you responded and that told you to *stop top-posting*.
> > > > >
> > > > > Regards,
> > > > > Bruno/Archange
> > Excellent use of top posting yourself, Alad.
>
> Except it's not (interleaved, right below "Hi Bruno"). Nice try, though.
>
> Alad
>
> >
> > Cheers,
> >

Don't forget to trim quoted text.

Re: [aur-general] Deletion of sxiv-cdown-git

[Loui Chang]

On Sun 13 Sep 2020 19:03 -0400, Eli Schwartz via aur-general wrote:
> Perhaps there should be a general discussion about how to handle the
> proliferation of suckless.org software forks, and what constitutes
> uniqueness.

My wild idea is that maybe each package could enable their own mini-aur which
would contain all available configurations.

Re: [aur-general] Proposal: Mark packages that require significant computational power to build

[Loui Chang]

On Fri 03 Apr 2020 23:24 +0400, Nick Shvelidze wrote:
> Hello everyone, as you know, some packages on AUR take many minutes to
> build on all but very powerful machines. I think it would be helpful to
> have an optional bit of metadata that will mark these packages, or possibly
> even a general thing that will describe approximately how intensive the
> package is to build.

Neat idea but too arbitrary unless you can figure out a way to quantify or
measure an 'intensity score' in a scientific manner.

An 'intensive' package for raspi will be very different for notebook,
workstation, server, etc.

Would also be neat to have runtime requirements in package metadata.

Could lead to something similar to "Windows Experience Index"

Re: [aur-general] aur client

[Loui Chang]

Replying on the most relevant mailing list.

On Tue 29 Oct 2019 02:49 +0100, Alberto Salvia Novella wrote:
> Since publishing to the AUR is something that all packagers do quite
> frequently, I have developed a software that reduces the related operations
> to the bare minimum, making publishing to the AUR instant.

Dude you can't just spam all lists with your projects.
Please consider mailing list etiquette.

> The software is called "aur "

Please rename your project to avoid confusion. I'm surprised that the name
wasn't already blacklisted. I would hope some TU does add 'aur' to the blacklist
of package names.

Good luck.

[aur-general] Separating PKGBUILDs for architectures

[Loui Chang]

On Fri 01 Jun 2012 20:28 +, Xyne wrote:
 Loui Chang wrote:
   It may be a bit of chicken-and-egg, though.  The ppc/arm userbase might
   grow if arch is seen stable enough and seems to have sufficient
   packages, possibly making it worth being supported, but the lack of
   infrastructure won't make that so possible.
  
  Yes, I also see it as a way of welcoming the ppc/arm/etc userbase into
  the main Arch collective, and adding their technological distinctiveness
  to our own.

 At first I thought to propose a naming scheme for architecture-specific
 packages similar to VCS or programming language module packages, but that 
 would
 be messy. The real problem is that each architecture has a different
 namespace for packages. It just so happens that i686 and x86_64 packages
 often require no changes, so we can use the same PGKBUILD for both.

 I doubt that there is any impetus for it, but the ideal solution would be to
 separate the namespaces in ABS and AUR. Most PKGBUILDs would remain the same.
 Packages for multiple architectures would be copied into each namespace (e.g.
 arch=(i686 x86_64) would be copied to i686 and x86_64). This is what happens
 with built packages already, but the PKGBUILDs are still jumbled together in
 ABS and AUR for convenience|laziness|tradition|tacos.

Yeah this is not a bad idea. It would reduce need for complexity in
PKGBUILDs

 The real change would be that instead of having PKGBUILDs with complicated
 if-then-else blocks to handle architecture, we would have  PKGBUILDs for
 each architecture *in those cases*, i.e. when changes are required for a
 particular architecture. Or maybe we could just use the current split PKGBUILD
 framework for doing something similar, with architecture-specific packages 
 named
 foo-arch in the PKGBUILD.

The problem is with the PKGBUILD design. It wasn't really designed for
multi-architectures, or even for fully supporting source builds. I don't
really like the idea of building hacks upon hacks upon a format
ill-suited for current needs.

 Meh, I'm mostly thinking out loud here. The point was simply that there would
 be a way to have a namespace for unsupported architectures living side-by-side
 with the supported ones.

 Ultimately I still think that it's unfortunate that all of the metadata is
 locked up in Bash. It difficilitates the creation of many practical
 metapackaging tools.

Yep. In terms of metadata I guess a good first step would be to use some
simple clean format that is meant for data, not execution. Maybe
pkginfo, (pacman db), yaml or something.

Re: [aur-general] AUR and unsuported architectures

[Loui Chang]

On Thu 31 May 2012 09:56 -0300, Hugo Osvaldo Barrera wrote:
 On 2012-05-31 08:10, Phillip Smith wrote:
  On 31 May 2012 17:38, Jelle van der Waa je...@vdwaa.nl wrote:
  When I first though about it, I wanted to say why not, it doesn't hurt
  the functioning of the normal i686,x86_64 packages.
  
  I thought the same, but after thinking more... While AUR is
  unsupported, the project/site is still an official item.
  
  In my mind, it doesn't make sense to include unofficial platforms in
  official infrastructure, supported or not.
  
  We don't encourage documentation of other platforms in our wiki (do we?)
 
 While I'd wish this weren't true, your argument does make perfect sense,
 so I guess it's best to keep AUR clear of these architectures.

I'm not a TU, but I actually think allowing other architectures in the
PKGBUILDs is a Good Thing. The AUR is supposed be be a place of
less-restricted user contribution - where packages (and/or
architectures?) that developers are not interested in can be submitted.

 It may be a bit of chicken-and-egg, though.  The ppc/arm userbase might
 grow if arch is seen stable enough and seems to have sufficient
 packages, possibly making it worth being supported, but the lack of
 infrastructure won't make that so possible.

Yes, I also see it as a way of welcoming the ppc/arm/etc userbase into
the main Arch collective, and adding their technological distinctiveness
to our own.

Re: [aur-general] Lost AUR username linked to this email account

[Loui Chang]

On Thu 19 Apr 2012 20:55 +0300, Ionut Biru wrote:
 On 04/19/2012 08:10 PM, Filipe Pinheiro wrote:
  *How can I get it back?*
  *The email is : filipe.cantare...@gmail.com*
 
 user is LipeCantarelli

Hmm. Maybe this should be a feature in the AUR?

[aur-general] Misconceptions about the AUR?

[Loui Chang]

On Fri 02 Mar 2012 00:49 +0100, Heiko Baums wrote:
 Am Fri, 02 Mar 2012 09:21:33 +1000
 schrieb Allan McRae al...@archlinux.org:
 
  You do realize who first came up with the workaround for adding split
  packages to the AUR...   Because from memory it was figured out in the
  TU IRC channel.
 
 I don't know, because I'm not in the IRC channels. But if I recall
 correctly this workaround was also discussed in the forums and/or the
 mailing lists. This was at a time when it was still discussed if AUR
 shall support split packages or not.
 
 The package splittest which was meant to test this workaround and to
 give a sample PKGBUILD was uploaded to AUR by Harvie, a normal user.
 And if I recall correctly it was him who first came up with it. But I
 can be wrong.
 
 The problem is if you add a subpackage of a split package into a
 depends array as György did it just can't be installed, because AUR
 don't know anything about those subpackages, because it doesn't support
 split packages. And thus the AUR wrappers can't find them. So it's
 not possible to install those packages.

First of all I'll deplore you for hijacking György's TU Application
thread to rant about your own qualms. You should be ashamed. You should
apologise. You are wrong.

Secondly. If a PKGBUILD can be built with makepkg then it IS a valid
PKGBUILD. No matter what you say. If an AUR helper cannot process it,
then there is a problem with the AUR helper, not the AUR and not the
PKGBUILD.

Third. The AUR is not meant to help you build source packages. It hosts
them, and parses the tarballs only for convenience. You are supposed to
install it by your own means. If your means are buggy, that's your
problem.

Finally, yes, there are problems with Arch source packages but you're
missing the solution by lightyears. These things have been discussed on
the list, the forums, and the bugtracker. You would be keen to do a
little research and perhaps propose solutions (patches?) rather than
wasting precious oxygen.

Cheers.

Re: [aur-general] GPG Key Signing

[Loui Chang]

On Fri 02 Dec 2011 14:02 +1000, Allan McRae wrote:
 On 02/12/11 12:37, Loui Chang wrote:
  Let Ionut be the first to provide
  enough personal information to satisfy naysayers. I've never met him, so
  I have my doubts. :P
 
 Such as

Is that supposed to be a question?

  gpg --list-sigs Ionut
 pub   2048R/615137BC 2011-04-19
 uid  Ionut Biru ib...@archlinux.org
 sig P65D0FD58 2011-04-19  CA Cert Signing Authority (Root CA)
 g...@cacert.org

This doesn't mean anything to me. I've never met CA Cert either and I
doubt whether CA Cert has met Ionut Biru to confirm his identity.
Also meeting does not guarantee positive identity. Drivers licenses and
passports can be forged.

Anyways... in case you missed it:

:P

Re: [aur-general] GPG Key Signing

[Loui Chang]

On Fri 02 Dec 2011 01:23 +0100, Xyne wrote:
 Ionut Biru wrote:

  why are you so sure that I'll sign it?

 I no longer am, but until you replied I never had any reason to doubt it.

 As for the discussion about my name:

 I could easily claim a fake name to make you happy and you would never
 know the difference. The name means absolutely nothing.

You ought to just for fun. ;)

 As I said to keenerd in a private email, if this is really an issue
 for some of you then start a discussion and call a vote to remove me
 as a TU. Even if the vote passes I may resign if I see many that would
 like me gone, so you win.

Such a vote should never pass, otherwise every Trusted User would have
to positively identified be fair. Let Ionut be the first to provide
enough personal information to satisfy naysayers. I've never met him, so
I have my doubts. :P

[aur-general] TU Resignation

[Loui Chang]

Hello everyone!

I haven't been very involved with the AUR for a long while, and I don't
really see that changing much. Since I only have a few packages I think
it's time for me to resign as a TU. I may still throw a few patches
around if I find the time. I've asked Lukas Fleischer to assume my duty
of adding new TUs.

It was a pleasure to work with you folks. See you around!

My former packages which I've recently disowned:
esmtp
libesmtp (dependency of balsa, collectd, and esmtp)
mhwaveedit
oldstand-font
tig

Cheers.

Re: [aur-general] Securing the AUR website

[Loui Chang]

On Sat 06 Aug 2011 13:25 +0200, Florian Pritz wrote:
 On 06.08.2011 13:13, Lukas Fleischer wrote:
  On Sat, Aug 06, 2011 at 01:02:03PM +0200, Thomas Bächler wrote:
  Am 05.08.2011 23:54, schrieb Lukas Fleischer:
   [1] http://projects.archlinux.org/aur.git/commit/?id=1e7b9d57
   [2] http://projects.archlinux.org/aur.git/commit/?id=5ea9fc19
   [3] http://projects.archlinux.org/aur.git/commit/?id=973e4f85
   [4] http://projects.archlinux.org/aur.git/commit/?id=89721137
  
  Those commits are nothing but a charade. The very least you must do is 
  this:
  
  1) ALWAYS force a redirect to https on the AUR login page, never allow
  the login to be submitted unencrypted.
  
  Thought about that. The problem is that there currently isn't a separate
  login page. Maybe removing the overall login form and creating a
  separate page for that will make things easier.
  
  2) Ensure that the cookie is never sent over http, only over https.
  
  We discussed that before, see the other replies. This will be
  implemented.
 
 Securing the login page itself is quite good and prevents eavesdropping,
 but it doesn't take care of MITM attacks.
 
 If Alice is on http://aur.archlinux.org and clicks on a login link that
 points to http://aur.archlinux.mallory.com/login.php the browser won't
 complain about anything and Mallory can easily get access to her password.

This is why the redirects are also a charade.
If Bob requests http://aur.archlinux.org but is redirected to
http://aur.archlinux.frank.org rather than https://aur.archlinux.org
he is probably expecting http anyways and may not bat an eye.

Re: [aur-general] Securing the AUR website

[Loui Chang]

On Sat 06 Aug 2011 11:21 +0200, Pierre Schmitz wrote:
 On Fri, 5 Aug 2011 19:22:21 -0400, Loui Chang wrote:
  If I recall correctly some time after that debate/argument there was a
  problem with certificates and wget

 Wget was broken, yes. But this is fixed by now.

  - a problem that was supposedly
  impossible. Anyways, the redirect is Really God Damned Annoying. If I
  ask for HTTP please give me HTTP. If I ask for ssl on top give me that.
  Please don't employ hacky rules in the web server config.

 That is a strange argument. First of all why would you explicitly
 decide against encryption? And more important: Most users don't decide
 using to HTTP. This decision is made by links theyy click or their
 browser when typing in the URL directly.

Right. Let me make that decision myself. Thanks.
I would decide against encryption if I have problems with ssl so that I
can just go ahead and retrieve the PKGBUILDs that I need to do my job.
I manually review their authenticity anyhow.

  That redirect is subject to a MITM attack just as well. A user might not
  even notice that they've been redirected to another site. If you really
  want to promote security don't even respond to requests on port 80.

 This argument is hard to follow. So you say using no encryption will
 lower the chance of mtm attacks? Not responding on port 80 is a bad idea
 as browser will try this port first and there are a lot of old links
 around.

Users may get a false sense of security with the redirect. I'm saying
that having that redirect doesn't change the chance of mitm attacks. An
attacker will impersonate the Arch server from the http onward and all
your ssl is for nothing. If you're worried about old links then you can
serve a page saying that http is no longer supported, so people can
figure out what's going on. Increased security usually involves
some discomfort.

  I agree that encryption should be recommended, but not forced.

 Maybe forcing is a bad word here. Its more about ensuring security. ATM
 http is recommend and I bet most users use the AUR unencrypted atm.

Yeah the links just need to be updated to recommend ssl.

Re: [aur-general] Securing the AUR website

[Loui Chang]

On Sat 06 Aug 2011 13:39 +0200, Thomas Bächler wrote:
 Alternatively: Do not display a login form on http, instead display a
 link If you want to login, switch to a secure connection first.. This
 way, the user verifies the certificate and URL first (by looking at the
 URL bar), then enters his password.

I agree with this. As long as the rest of the site is functional via
http.

Re: [aur-general] Securing the AUR website

[Loui Chang]

On Sat 06 Aug 2011 02:18 +0200, Lukas Fleischer wrote:
 On Sat, Aug 06, 2011 at 01:16:45AM +0300, Ionut Biru wrote:
  On 08/06/2011 12:54 AM, Lukas Fleischer wrote:
  
  
  To prevent session hijacking, mtm attacks or whatnot I'd recommend the
  following:
  * Redirect all http traffic to https by default
  
  We won't do that. HTTPs will be the default but we won't force users to
  use HTTPs. If you decide to use HTTP intentionally, we won't prevent you
  from doing so. HTTPs implies an unnecessary overhead and there's no
  point in forcing everybody to use HTTPs even if one doesn't even have an
  AUR account.
  
  That reason is a bit childish. We had this discussion 1 year ago and
  only you and Loui were against.
  
  Seriously now, why you are against https? Do you use some aur helper
  that is broken and uses http and cannot handle redirect well?
 
 Dude, please stick to the facts. Iirc, I didn't even interfere in the
 last HTTPs discussion and I nowhere mentioned being against HTTPs. I am
 totally for making HTTPs the default, I'm just against enforcing it. As
 you can see, I even committed a few patches replacing all links the AUR
 ever spits out by HTTPs ones. Everything else is only a matter of server
 configuration and I am against disabling plain HTTP here.
 
 Is there any *real* reason to do that? Even archweb doesn't do that and
 I don't understand the concerns here. Every half-attentive should be
 perfectly fine with how we do it in current master. And in case you're
 really, really paranoid, just setup a proxy that blocks HTTP connections
 to the AUR.

If I recall correctly some time after that debate/argument there was a
problem with certificates and wget - a problem that was supposedly
impossible. Anyways, the redirect is Really God Damned Annoying. If I
ask for HTTP please give me HTTP. If I ask for ssl on top give me that.
Please don't employ hacky rules in the web server config.

That redirect is subject to a MITM attack just as well. A user might not
even notice that they've been redirected to another site. If you really
want to promote security don't even respond to requests on port 80.

I agree that encryption should be recommended, but not forced.

Re: [aur-general] Aurphan in community

[Loui Chang]

On Sat 30 Apr 2011 09:39 +0300, Grigorios Bouzakis wrote:
 Loui Chang wrote:
  On Fri 29 Apr 2011 21:49 -0400, keenerd wrote:
  I would like to move Aurphan into community.  I've added a number of
  features to it lately, and it has become an automated means of
  answering what can I do to help Arch, parsing and summarizing the
  todo list, the bugtracker and the orphans.  The one random dev I've
  asked seems cool with it, however he thought a wider consensus should
  be found.  It has enough votes but
 
  Aurphan could be considered an AUR helper.  By default it searches the
  AUR for AUR packages you already have installed.  It does not download
  anything.
 
  I will change it so the default behavior does not search the AUR.
  (New default would display the --help)  I won't change the name, on
  account of it being cute.
 
  aur page: http://aur.archlinux.org/packages.php?ID=43726
  project page: http://kmkeen.com/aurphan/
 
  This script seems like a really nice idea, but if it deals with
  unsupported packages it should remain in that domain. Maybe move the
  functionality that deals with unsupported into an add-on that you can
  install separately?
 
 Didn't the extremely popular powerpill also have support for the AUR?
 Although i had never used it, i seem to recall it did, and it was in
 community.

Powerpill was always a pacman wrapper that had no interface to the AUR.
You could however install an add-on called bauerbill which would give
you functionality with the AUR.

Though aurbuild did briefly make its appearance into [community] many
years ago, it was quickly removed for obvious reasons. The only official
client for the AUR that remained for any time was called aurtools and it
was part of the system that TUs used for submitting binary packages to
[community] only.

 Also from your reply on [0] and particularly the Functionality needs to
 be moved to the clients for the better future of the AUR. part, i got
 the impression that the TU's might actually be considering creating or
 baptising an AUR client official pretty soon.

I did kind of think that it might be a good idea to have a minimal
official client, but that's no longer the case. Arch has no official
client for you to utilize its web service, nor its email service. I'll
maintain there should be no official client for the AUR either. Maybe a
minimal reference client could be useful for testing purposes though.

 The AUR isn't usable 100% from the web interface like it was before
 and users are pratically forced to use one of the many

The web interface seems to work perfectly fine for me.

Re: [aur-general] Aurphan in community

[Loui Chang]

On Sat 30 Apr 2011 16:12 +1000, Allan McRae wrote:
 On 30/04/11 12:25, Loui Chang wrote:
 On Fri 29 Apr 2011 21:49 -0400, keenerd wrote:
 I would like to move Aurphan into community.  I've added a number of
 features to it lately, and it has become an automated means of
 answering what can I do to help Arch, parsing and summarizing the
 todo list, the bugtracker and the orphans.  The one random dev I've
 asked seems cool with it, however he thought a wider consensus should
 be found.  It has enough votes but
 
 Aurphan could be considered an AUR helper.  By default it searches the
 AUR for AUR packages you already have installed.  It does not download
 anything.
 
 I will change it so the default behavior does not search the AUR.
 (New default would display the --help)  I won't change the name, on
 account of it being cute.
 
 aur page: http://aur.archlinux.org/packages.php?ID=43726
 project page: http://kmkeen.com/aurphan/
 
 This script seems like a really nice idea, but if it deals with
 unsupported packages it should remain in that domain. Maybe move the
 functionality that deals with unsupported into an add-on that you can
 install separately?

 We should also drop wget, curl and firefox from the repos as they can be
 used to download unsupported packages...   In fact, this script is safer
 because it does not even do that.

Allan, I appreciate your work but you completely missed the point.
wget, curl and firefox do not contain functionality to specifically
access the unsupported packages. They are general network programs.

I guess it depends on what your vision is. If you want more people
expecting support for unsupported packages, then put these scripts into
extra or community. I can't stop you, I'm just a lowly nobody and you're
a big bad dev.

Re: [aur-general] Aurphan in community

[Loui Chang]

On Fri 29 Apr 2011 21:49 -0400, keenerd wrote:
 I would like to move Aurphan into community.  I've added a number of
 features to it lately, and it has become an automated means of
 answering what can I do to help Arch, parsing and summarizing the
 todo list, the bugtracker and the orphans.  The one random dev I've
 asked seems cool with it, however he thought a wider consensus should
 be found.  It has enough votes but

 Aurphan could be considered an AUR helper.  By default it searches the
 AUR for AUR packages you already have installed.  It does not download
 anything.

 I will change it so the default behavior does not search the AUR.
 (New default would display the --help)  I won't change the name, on
 account of it being cute.

 aur page: http://aur.archlinux.org/packages.php?ID=43726
 project page: http://kmkeen.com/aurphan/

This script seems like a really nice idea, but if it deals with
unsupported packages it should remain in that domain. Maybe move the
functionality that deals with unsupported into an add-on that you can
install separately?

Re: [aur-general] Web-client for emails: [WAS:Reflector]

[Loui Chang]

On Tue 05 Apr 2011 18:00 +0800, Oon-Ee Ng wrote:
 Gmail's web interface has THE best approach to threading. Ever. If you
 have any other suggestion (web client or linux desktop client) which
 comes anywhere close please let me know. Evolution's threading just
 doesn't cut it, thunderbird's new one is close, but thunderbird is
 basically a mouse-only interface, the keyboard shortcuts are so
 horrific (and muttator is an abortion of a project AFAICS).

 I've spent quite some time exploring the options, and settled on this.
 Ideas always welcome, of course.

Sorry I don't know a desktop program, but sup (a console app) supposedly
emulates gmail.

http://sup.rubyforge.org/

Re: [aur-general] AUR message notification

[Loui Chang]

On Sun 03 Apr 2011 23:16 +0200, Lukas Fleischer wrote:
 On Sun, Apr 03, 2011 at 11:00:24PM +0200, Baptiste wrote:
  On Sun, Apr 03, 2011 at 10:36:03PM +0200, Pierre Bourdon wrote:
   On Sun, Apr 3, 2011 at 22:30, Baptiste zersto...@free.fr wrote:
I know there is a way to get an email notification when somebody
writes a comment on a given package.
  
   Simply click the Notify button on a package page
   (http://aur.archlinux.org/packages.php?ID=XX).
 
  Thanks a lot ... that was so obvious!
 
  By the way, I was mistaken by the incorrect french translation for
  `notify' : `annoncer', meaning `announce'.
 
  Seriously, was the AUR translated using the automatic google thing ?
  Better have used a babel fish or something similar :)
  (see wikipedia page : http://bit.ly/eVDCNX )

 Nah, I sent a patch fixing that to aur-dev a long time ago [1] - Loui
 rejected it back then for some reason tho. I'll probably just push it
 now...

 [1] http://mailman.archlinux.org/pipermail/aur-dev/2010-September/001260.html

Mainly because 'suivre' means 'follow' rather than 'notify'. I didn't
want to be pushing something incorrect that someone else would complain
about again.

Re: [aur-general] AUR message notification

[Loui Chang]

On Sun 03 Apr 2011 23:16 +0200, Lukas Fleischer wrote:
 Nah, I sent a patch fixing that to aur-dev a long time ago [1] - Loui
 rejected it back then for some reason tho. I'll probably just push it
 now...
 
 [1] http://mailman.archlinux.org/pipermail/aur-dev/2010-September/001260.html

https://bugs.archlinux.org/task/20111

Re: [aur-general] AUR 1.8.1 - Can No Longer Upload Packages

[Loui Chang]

On Mon 14 Mar 2011 03:44 +0100, Heiko Baums wrote:
 Am Sun, 13 Mar 2011 19:20:04 -0700
 schrieb Tony C crt@gmail.com:
 
  pkgname=lft
  pkgver=3.31
  pkgrel=1
  pkgdesc=A layer four traceroute implementing numerous other features
  arch=('i686' 'x86_64')
  license=('custom')
  url=http://oppleman.com/lft/;
 
 The new url is: http://pwhois.org/lft/
 
  depends=('glibc' 'libpcap=1.0.0')
 
 And you should remove the versioned dependency in AUR. This can have
 bad effects for the users if the system gets updated by pacman -Syu or
 yaourt -Syua or the like.
 
 Arch Linux is a rolling release distro which has only one version of a
 package in the repos and you can assume that people keep their systems
 up-to-date.
 
 I don't know if there's a reason for those versioned dependencies for
 the devs and TUs in the binary repos but in AUR they are usually not
 necessary and useful.
 
 Glibc can also be removed from depends, because it's already in the
 base group.

What does any of that have to do with a problem uploading the package?

Re: [aur-general] AUR 1.8.1 - Can No Longer Upload Packages

[Loui Chang]

On Sun 13 Mar 2011 20:19 -0700, Tony C wrote:
 On 03/13/2011 06:47 PM, Tony C wrote:
  Prior to AUR 1.8.1 being deployed, I could upload a *.tar.gz
  containing my PKGBUILD to AUR. Now with AUR 1.8.1, here I am trying to
  upload an updated PKGBUILD which I have verified does exist within my
  *.tar.gz - yet the AUR web-interface refuses to acknowledge that my
  PKGBUILD exists as I get stumped with ***Error trying to unpack
  upload - PKGBUILD does not exist.
 
  *Does this sound like a possible bug with AUR 1.8.1? I would like to
  think I have been quite diligent with the whole AUR process, but as I
  said this little road block has got me stumped with AUR 1.8.1

 I tried uploading a different package just to test with the necessary
 PKGBUILD, patches, and .install file using 'tar czf some-package.tar.gz
 *' which of course included all the necessary files. Tarball is indeed
 valid, upload, same bogus error on this different package. Maybe I am
 cursed.

Tony, can you open a new bug ticket and attach both source packages?
Thanks a lot.

Re: [aur-general] AUR 1.8.1 - Can No Longer Upload Packages

[Loui Chang]

On Sun 13 Mar 2011 20:44 -0700, Tony C wrote:
 Apologies for the noise. AUR does not reject my package now after first
 creating the directory name for the package I have. I do not ever
 remember needing to create a special directory before. So I simply did
 mkdir package-name and tar'd that up containing my source files.

You need to follow the format created by makepkg --source.

Re: [aur-general] AUR 1.8.1 - Can No Longer Upload Packages

[Loui Chang]

On Mon 14 Mar 2011 05:08 +0100, Heiko Baums wrote:
 Am Mon, 14 Mar 2011 11:59:38 +0800
 schrieb Ray Rashif sc...@archlinux.org:
 
  On 14 March 2011 10:32, Heiko Baums li...@baums-on-web.de wrote:
   Could the reason be some syntax errors?
   There are a lot of quotation marks too much. And the settings of
   your quotation marks seem to be quite inconsistent.
  
  It would be funny if the AUR rejected PKGBUILDs due to syntax errors
  or inconsistency [1], especially this one where curly braces and
  double quotes merely dictate whether the build succeeds - not whether
  it is a valid PKGBUILD.
 
 PKGBUILDs shouldn't be rejected due to syntax errors, but you never
 know, anything can happen.

Submitting PKGBUILDs to the AUR isn't exactly a magical happenstance.
If you look at the code you will discover that are certain things that
happen, and certain things that don't. I realise you're trying to help,
but let's please avoid sending people on wild goose hunts.

Thanks.

Re: [aur-general] Please delete minecraft-data

[Loui Chang]

On Fri 25 Feb 2011 16:31 +0100, Cédric Girard wrote:
 The package minecraft-data [1] is supposed to provide game data for
 Minecraft. This package is outdated, orphaned and does not comply with the
 game license [2] (hosting of original game content).
 
 Please delete it. Thanks.
 
 [1] http://aur.archlinux.org/packages.php?ID=40928
 [2] http://www.minecraft.net/copyright.jsp

Just for reference: a PKGBUILD does not actually distribute the data, so
it would be completely valid to have it in the AUR.

For example the acroread license doesn't allow redistribution, but that
doesn't disallow writing a script (PKGBUILD) for automatically fetching
it from Adobe and installing it yourself.

Re: [aur-general] AUR no more extracting source tarballs ( was: Upgraded AUR to 1.8.0)

[Loui Chang]

On Mon 21 Feb 2011 16:35 +0100, Lukas Fleischer wrote:
 On Mon, Feb 21, 2011 at 03:46:47PM +0100, Dieter Plaetinck wrote:
  On Mon, 21 Feb 2011 14:50:39 +0100
  Lukas Fleischer archli...@cryptocrack.de wrote:
  
  
   The only issue that might affect the end users as well is ZIP bombs.
   Most users will probably notice such a thing before it is entirely
   extracted, just interrupt tar(1)/gzip(1) and send a removal request to
   aur-general, however.
  
  hmmm. some good points.
  I guess I could try the suggested approach and see how I like it.
  However, now that you bring up the zip bombs, do you think it's
  feasible to scan for them serverside without compromising security
  and/or making things needlessly complicated? it would be useful for
  clients if that one aspect could be filtered out in advance.
 
 I don't think this is possible without decompressing the tarball which
 is again vulnerable to (D)DoS.

It might be possible. There are xz -l and gunzip -l functions to preview
the uncompressed size of archives without decompression.

Re: [aur-general] AUR no more extracting source tarballs ( was: Upgraded AUR to 1.8.0)

[Loui Chang]

On Mon 21 Feb 2011 16:42 +0100, Dieter Plaetinck wrote:
 On Mon, 21 Feb 2011 16:35:33 +0100
 Lukas Fleischer archli...@cryptocrack.de wrote:
 
  On Mon, Feb 21, 2011 at 03:46:47PM +0100, Dieter Plaetinck wrote:
   On Mon, 21 Feb 2011 14:50:39 +0100
   Lukas Fleischer archli...@cryptocrack.de wrote:
   
   
The only issue that might affect the end users as well is ZIP
bombs. Most users will probably notice such a thing before it is
entirely extracted, just interrupt tar(1)/gzip(1) and send a
removal request to aur-general, however.
   
   hmmm. some good points.
   I guess I could try the suggested approach and see how I like it.
   However, now that you bring up the zip bombs, do you think it's
   feasible to scan for them serverside without compromising security
   and/or making things needlessly complicated? it would be useful for
   clients if that one aspect could be filtered out in advance.
  
  I don't think this is possible without decompressing the tarball which
  is again vulnerable to (D)DoS.
 
 hmm maybe we mean different things.
 you are talking about exhausting ram/cpu/time, right?
 http://en.wikipedia.org/wiki/Zip_bomb
 In that case, sure, just leave it to the client. the problem is trivial
 enough.
 
 I was talking about bad filenames
 (like ../../foo, /foo, /root/foobar, /tmpl/blah, and whatever else is
 posible)
 that might be prevented with `tar -t`

Yeah I was thinking we could be more strict about the source package
format as well. For example rejecting any that have src or pkg
directories. Those often contain upstream source code our actual builds
by mistake. I think that's mostly from old packages where the uploader
didn't use makepkg --source.

Re: [aur-general] AUR no more extracting source tarballs ( was: Upgraded AUR to 1.8.0)

[Loui Chang]

On Tue 22 Feb 2011 00:51 +0200, Ionuț Bîru wrote:
 On 02/22/2011 12:35 AM, Isaac Dupree wrote:
 On 02/21/11 10:54, Lukas Fleischer wrote:
 Yes, like having two 1GB large files `tar -czf`'ed and uploading the
 resulting tarball to the AUR. I don't think that can be detected without
 being vulnerable to DoS attacks.
 
 What if the PKGBUILD itself is a 1GB file? For example a normal looking
 PKGBUILD followed by a billion newlines. That probably compresses pretty
 well.
 
 (/foolishly responding without reading code)
 
 -Isaac
 
 actually if i remember well somebody did that in the past.

Yeah we really need to figure out a reliable way to reject these
zip-bombs.

Re: [aur-general] [Announcement] First public git repo of the complete AUR.

[Loui Chang]

On Mon 07 Feb 2011 09:21 -0600, Thomas Dziedzic wrote:
 Well, whatever the case, I stayed up a while working on finishing this
 new version of the system.
 The new version syncs only the .tar.gz files, which makes it less
 resource hungry, and this also adds a natural ability to commit per
 packages :)
 I still need to test out deleting functionality, so if you could run
 the cleanup script at some point today, that would be awesome.

Just ran a clean up for you.

Re: [aur-general] [Announcement] First public git repo of the complete AUR.

[Loui Chang]

On Sun 06 Feb 2011 14:34 -0600, Thomas Dziedzic wrote:
 2011/2/6 Lukáš Jirkovský l.jirkov...@gmail.com:
  2011/2/6 Lukáš Jirkovský l.jirkov...@gmail.com:
 
  What's this?
  http://pkgbuild.com/git/aur.git/tree/PKGBUILD
 
  It seems there's more:
  apercu.tgz
 
 Since this clean up is more of an aur tree issue, not mine, it has to
 be done remotely to do it properly.
 
 Somebody ran a clean up script as evidenced by this commit :P
 http://pkgbuild.com/git/aur.git/commit/?id=19c10dddf1c78cb14f958e02cd6a4b2061db2c34

That was me hehe. I was curious to see what would happen.
So it looks like you're just copying over what's in the filesystem.
It might be a good idea to work with aur-dev to help make the source
cleaner, then everyone can benefit - even those who don't use your git
repo.

You probably want to grab the tarballs, and extract what's in those.
The next release of the AUR will only have tarballs and PKGBUILDs.
The other files won't be extracted.

Re: [aur-general] [Announcement] First public git repo of the complete AUR.

[Loui Chang]

On Sun 06 Feb 2011 17:52 -0600, Thomas Dziedzic wrote:
 On Sun, Feb 6, 2011 at 4:58 PM, keenerd keen...@gmail.com wrote:
  On 2/6/11, Loui Chang louipc@gmail.com wrote:
  You probably want to grab the tarballs, and extract what's in those.
  The next release of the AUR will only have tarballs and PKGBUILDs.
  The other files won't be extracted.
 
  Hey, you are stealing my idea!  :-)  AUR3 does that, and it saves
  several hundred megabytes.  Completely worth it.
 
 I fail to see how this is worth it, imo, a better system is to convert
 to git and not track the src.tar.gz

 Is there a good reason for this switch? To save 450mb is not a good
 reason imo, for an incomplete listing of all the files.

Well, there are several reasons. Lukas' commit message from commit ec0dfc2
briefly summarizes it.

 Automatic tarball extraction was vulnerable in different ways. Users
 should also only use source tarballs to build packages, so this has
 been removed completely. From now on, only the PKGBUILD is extracted
 in a secure manner.

Also,

I'm not really sure that git is the best way to distribute source
packages, but I'm glad that you're exploring different options. :D

If I want to obtain or share a few build scripts for a few packages I
really don't want to keep a 450mb repo.

I have heard about shallow checkouts being implemented in git though, so
maybe it could work. devtools uses subversion at least partially because
of this large checkout issue.

Re: [aur-general] new aur mirror

[Loui Chang]

On Thu, Jan 27, 2011 at 1:23 PM, keenerd keen...@gmail.com wrote:
 Hi all.  I am now mirroring the AUR continuously, and am starting to
 open it up to public access.  It is not a perfect byte-for-byte clone,
 as I felt like adding a few features :-)

 For now, there is an enhanced RPC database.  It's got everything from
 the original RPC calls, plus some extra fields that people always seem
 to want.  Access it through
 http://aur.kmkeen.com/rpc/name_of_package
 Yes, it is 100% static.  This was the only way my little VPS could
 keep up with the beastly Sigurd machine.

 I've also got all the tarballs mirrored, but forgot to add the links
 to the RPC info (mirror/pkgname/pkgname.tar.gz). Will fix that
 shortly.  There are also search indexes prepared for description,
 depends and required-by but the regex search is not open to the world
 yet.  Maybe after I get some sleep.

 Much thanks goes to Falconindy for ideas, encouragement and patience.

 I am currently taking feature requests.  Go wild.

Nice. I'm always glad to see people working on different ways to access
the AUR.

It seems like there are a few people that are interested in mirroring
the AUR. I've been thinking about how we could improve it for a long
time, but recently I thought it might be a good idea to just give some
resourceful users convenient access to the data so they can implement
novel ways of managing and distributing the packages.

I'd like to test a theory that one reason we haven't seen much
development is because all the data is held hostage on the AUR server.

Also, do you have an scm repo with the code you've used to implement
your interface? Thanks.

Re: [aur-general] AUR cleanup

[Loui Chang]

On Wed 26 Jan 2011 20:36 -0500, Dave Reisner wrote:
 So, on the subject of cleanup, I've come across a list of 530 packages
 on sigurd that aren't accessible from the web interface. Judging from
 some of the names, I'd wager that these are packages which were deleted
 but something went wrong, etc etc. In total, it's about 20mb of space
 that would be freed. Any reason these shouldn't just be purged by
 someone with root privs?

Packages that are deleted from the web interface aren't automatically
deleted from the filesystem. I run a clean up script periodically to get
rid of them. I figure, it gives a little window for people to recover
from deletion if needed.

Re: [aur-general] TU Application - Seblu

[Loui Chang]

On Sun 23 Jan 2011 11:53 +0200, Ionuț Bîru wrote:
 On 01/22/2011 08:35 PM, Loui Chang wrote:
 On Sat 22 Jan 2011 19:03 +0100, Ronald van Haren wrote:
 Seriously? Since when is adding a package that is already in the repos
 with a different configure flag a good idea? We don't even allow this
 in the AUR...
 
 Seriously. While it's not ideal, it has been done.
 I would consider it the same as including bin/lib32 packages just to
 include things like wine or whatever. The [community] repo is intended
 for this kind of experimentation and freedom.
 
 I think awesomewm has enough of a user base to justify such measures if
 a TU is willing to maintain it.

 While are you at this add firefox/thunderbird cairo system support. It has
 enough user base and a lot of complains about fonts that are not consistent
 with system, doesn't matter if firefox/tb is broken.

 We can do this /sarcasm

Sure, why not? This doesn't compare with awesome though, which doesn't
exist in the repos, and actually requires cairo-xcb. Firefox is
available in the repos and your font issues can likely be worked around.
At least I have no problems with fonts there.

 I'm starting to get a bit peeved with people confusing [community] and
 [unsupported] with the [core] and [extra] bits.

Re: [aur-general] TU Bylaws Amendment (SVP Section): Voting Period

[Loui Chang]

On Sat 15 Jan 2011 20:10 +0100, Xyne wrote:
 Christopher Brannon wrote:
  Shouldn't this be:
  the number of no votes is greater than or equal to half the number of
  active TUs?
 
 Yes it should. Here's a corrected patch:
 http://aur.pastebin.com/dBdinYb9

Thank you. I've applied the patch. See here:
http://aur.archlinux.org/trusted-user/TUbylaws.html#SVP

There were several technical problems with the patch, but I solved them.
For the future please attach the directly to the email.
Inline is always preferred, since it allows for contectual comments for
discussion.

Cheers!

Re: [aur-general] TU Application - Seblu

[Loui Chang]

On Fri 21 Jan 2011 21:38 +0200, Ionuț Bîru wrote:
 On 01/21/2011 09:10 PM, Grigorios Bouzakis wrote:
 Seblu wrote:
 It looks like a trick question!
 But if I want to be a good maintainer, I do understand the reasons.
 
 and **The trust does not exclude the audit.**
 
 Excuse me for asking but is there anything preventing you from moving
 cairo-xcb to community if you become a TU?
 
 Yes, us.
 
 As far as i know if you become a TU you can maintain anything you want
 that has more than 10 votes in the AUR.
 
 Becoming a TU means that you become a member in the developement team, a
 team in which we trust each other, respect each other decisions, use the
 same packaging standards, the same tools as developers etc.

I think if the package meets the guidelines then you shouldn't bully
someone into not maintaining it. As long as he's providing the support
that should suffice. Sometimes we may need to adjust the guidelines, and
we decide this as a group through a formal vote.

 If you are just going to ignore and say, screw Jan decisions, I'm going to
 upload it just because I can, you are not welcomed in the team.

The TUs are a separate group in the Arch community who can make
different decisions on what or what not to maintain.

 In the past theres been many patched beyond recongnition packages in
 community eg. many packages with lcd patches from ubuntu, urxvt with 256
 colour support and many other patches included etc.

 Do a list with the current packages that doesn't follow the arch way and i
 will take care of them.

 AFAIK the reason awesome was removed from community was that JGC removed
 the cairo backend from the package in extra AND the awesome maintainer
 didnt want to maintain a cairo-xcb package himself.
 If he did awesome would still be in community...

 He respected the decision and trusted Jan because we are a team and we have
 to work together to accomplish a goal.

I would encourage him to not be bullied out of maintaining things that
he would like to maintain in community. As long as they are not really
creating more work for anyone than himself, they should be fine.

Re: [aur-general] TU Application - Seblu

[Loui Chang]

On Sat 22 Jan 2011 19:03 +0100, Ronald van Haren wrote:
 On Sat, Jan 22, 2011 at 12:13 PM, Loui Chang louipc@gmail.com wrote:
  On Fri 21 Jan 2011 21:38 +0200, Ionuț Bîru wrote:
  On 01/21/2011 09:10 PM, Grigorios Bouzakis wrote:
  Seblu wrote:
  It looks like a trick question!
  But if I want to be a good maintainer, I do understand the reasons.
  
  and **The trust does not exclude the audit.**
  
  Excuse me for asking but is there anything preventing you from moving
  cairo-xcb to community if you become a TU?
 
  Yes, us.
 
  As far as i know if you become a TU you can maintain anything you want
  that has more than 10 votes in the AUR.
 
  Becoming a TU means that you become a member in the developement team, a
  team in which we trust each other, respect each other decisions, use the
  same packaging standards, the same tools as developers etc.
 
  I think if the package meets the guidelines then you shouldn't bully
  someone into not maintaining it. As long as he's providing the support
  that should suffice. Sometimes we may need to adjust the guidelines, and
  we decide this as a group through a formal vote.
 
 Seriously? Since when is adding a package that is already in the repos
 with a different configure flag a good idea? We don't even allow this
 in the AUR...

Seriously. While it's not ideal, it has been done.
I would consider it the same as including bin/lib32 packages just to
include things like wine or whatever. The [community] repo is intended
for this kind of experimentation and freedom.

I think awesomewm has enough of a user base to justify such measures if
a TU is willing to maintain it.

I'm starting to get a bit peeved with people confusing [community] and
[unsupported] with the [core] and [extra] bits.

[aur-general] Changing AUR development infrastructure.

[Loui Chang]

Recently I've had the idea that I should move the 'main' AUR git repo,
which I have been the caretaker of to the community server where all
other community and AUR development is done. This would also mean we
would have to run a git daemon, and should also install a web interface
like cgit to browse the repo. I'm hearing that there is some opposition
to this. I'd like to start a discussion to hear the reasons behind that.

Here are the reasons I have for moving the repo:
* The Trusted Users will have more control over the AUR development since
  it will be on their own server.
* We can use the new infrastructure to host other TU and community
  projects.
* We don't need to create superfluous shell accounts on gerolde to
  for push access to those repos. Those accounts already exist on
  sigurd.

The AUR and community development infrastructure used to all be hosted
on the main Arch Linux server, but we moved the community portion when a
new server was donated by sevenl.net. I think it makes a whole lot of
sense to also move the rest.

Cheers!

Re: [aur-general] Changing AUR development infrastructure.

[Loui Chang]

On Mon 17 Jan 2011 09:40 +0800, Gergely Imreh wrote:
 I know I'm an outsider (no TU, only did a bit of AUR developement
 before), so I just have a question:
 
 On 17 January 2011 09:19, Loui Chang louipc@gmail.com wrote:
  Here are the reasons I have for moving the repo:
  * We don't need to create superfluous shell accounts on gerolde to
   for push access to those repos. Those accounts already exist on
   sigurd.

 If the issue is having to create extra shell accounts, could it be
 eliminated using gitolite/gitosis?  That would allow more fine-grained
 control over the permissions of the different projects (which would
 definitely come up if there are more projects hosted on the same
 server). E.g. push privileges could be granted to people without TU
 status when needed, or TUs can be kept off projects they are not
 taking part in.

Yes, that is possible, but that still leave much control over the repo
on a foreign server. gitolite/gitosis might be something that we could
look at implementing even on the community server for people without
shell accounts who we want to give access.

Actually not all TUs are able to push to the repo. Only those that have
been given admin access. There has even been a non-dev, non-TU that was
granted devel/admin access because of proven merit.

Currently, any admin/dev of the AUR will need special access to the git
repo on gerolde, and to the AUR hosted on sigurd. Since it's not very
likely that we would move the hosting back to gerolde it makes a lot of
sense to me to move the devel infrastructure to sigurd. So admins of the
AUR will only need an account on one server.

Admin access includes mysql, web server, and the filesystem, so it
definitely requires a shell account.

Re: [aur-general] Breaking the unspoken rule: AUR helper in [community]

[Loui Chang]

 On 12/30/2010 12:36 AM, Brad Fanella wrote:
 On Dec 30, 2010, at 12:11 AM, Nathan Owens ndowens@gmail.com wrote:
 
 On 12/29/2010 08:56 PM, Heiko Baums wrote:
 
 I know I am not a TU, though I figured I would put in my two-cents. I
 agree it may be bad for first time users to have an AUR helper if they
 don't understand there is risks. Though this gave me a idea, that may
 not be liked or approved of, maybe if we split AUR into either packages
 with the most votes or maintainers that are concidered trusted or been
 around a while, from the vice versa. Kind of a trusted of the
 unsupported packages. Going along with the assumption that the idea
 would work and approved of, create a AUR helper, that would be in the
 community repo, that will only pull from the trusted AUR.
 
 Wouldn't it be easier just to add more TUs than to attempt what you
 proposed? When would we begin to draw the line between trusted and
 untrusted users?
 
 It's not a bad idea by any means. I'm just questioning the practicality of
 it.

On Thu 30 Dec 2010 00:44 -0600, Nathan Owens wrote:
 I know what you mean. Well I would THINK that maybe it could be determined
 how long the user has been active though their activity of the packages and
 look at the quality of the packages the user has adopted/created and maybe,
 assuming there is a system that would monitor the out-of-date packages, if
 the member maintains the packages by updating them in a decent amount of
 time. Possibility something similar to this as to determine a regular user
 is trusted.

Please bottom post.
Anyways, what you're speaking of is probably a feature that is best
implemented on the client side.

You could probably hack something up that interfaces with the current
AUR though. The RPC will return a list of packages by a named
maintainer via msearch. See http://aur.archlinux.org/rpc.php

Re: [aur-general] [arch-dev-public] Breaking the unspoken rule: AUR helper in [community]

[Loui Chang]

On Thu 30 Dec 2010 14:26 +0200, Ionuț Bîru wrote:
 On 12/30/2010 04:16 AM, Dan McGee wrote:
 http://www.archlinux.org/packages/community/i686/cower/
 
 Thoughts? I was under the impression we didn't do this, and definitely
 on purpose, otherwise people have *no* idea the AUR is different in a
 lot of ways. Making people go the hard way to get a helper installed
 at least presents some (necessary) barrier.
 
 i consider cower being a cli interface from aur and it much better than the
 html version. with it i can found more easily packages because it has bash
 completion, searching has regex. Just try to find the link for opera build
 from aur using the html interface vs cower.

Opera is in [community] I believe.
If we do want to adopt an 'official' AUR client then we should present
it on the AUR web page, and put it in the git repo along with the server
scripts, rather than putting it on [community].

 The only rule i found in wikis about this subject is:
 
 Note: There is not and will never be an official mechanism for installing
 build material from UNSUPPORTED. All users should be familiar with the build
 process.
 
 Maybe we should change that and include all aur helpers that interface with
 the official json api from aur.archlinux.org.

Yeah I think we should make an explicit rule to say that no programs
that purposely interface with the AUR will be in [community] or an
official repo. This way we don't need to have debates on what kind of
programs are kosher or not.

Re: [aur-general] Breaking the unspoken rule: AUR helper in [community]

[Loui Chang]

On Thu 30 Dec 2010 03:56 +0100, Heiko Baums wrote:
 Am Thu, 30 Dec 2010 04:43:46 +0200
 schrieb Evangelos Foutras foutre...@gmail.com:
 
  Personally, I don't feel strong either way. As it was explained to me
  on IRC, cower doesn't include any building or installation
  functionality, it only searches for packages, downloads them, and can
  also check for updates to installed, unsupported, packages.
 
 But when I see how many times people ask for adding packages from
 base-devel like gcc or pkg-config to depends and how many people don't
 read the AUR and ABS wiki pages I'm not sure that such tools should be
 in the repos.

I think this is a matter for TUs and devs to discuss and decide on
together. Since [community] is defacto official people may start to
expect more support from the [unsupported] repo. I can imagine that TUs
and devs wouldn't want this perception to prevail among users.

Even if the program doesn't build or install, it still interfaces with
the unsupported repo, and since it's in community, people may perceive
the packages in that repo as officially supported.

That's how it appears to me anyhow.

Re: [aur-general] Deletion request

[Loui Chang]

On Sun 19 Dec 2010 16:55 +0100, Seblu wrote:
 2010/12/13 Cédric Girard girard.ced...@gmail.com:
  On Mon, Dec 13, 2010 at 10:40 AM, Stefan Husmann stefan-husm...@t-online.de
  There is a similar case with packages like steinberg-vst [1]. The package
  just assumes the source are already downloaded in the build directory as
  explained in comment.
 
  [1] http://aur.archlinux.org/packages.php?ID=16748
 
 ok.
 
 do you have a trick to tell to makepkg --source to not include in
 src package the file which should be download manually?
 or you remove it from the tarball manually before uploading to AUR?

You could use
source=(file://source.tar.gz)

Re: [aur-general] Deletion request

[Loui Chang]

On Sun 19 Dec 2010 17:58 +0200, cantabile wrote:
 Le 19/12/2010 17:55, Seblu a écrit :
 2010/12/13 Cédric Girardgirard.ced...@gmail.com:
 On Mon, Dec 13, 2010 at 10:40 AM, Stefan Husmannstefan-husm...@t-online.de
 There is a similar case with packages like steinberg-vst [1]. The package
 just assumes the source are already downloaded in the build directory as
 explained in comment.
 
 [1] http://aur.archlinux.org/packages.php?ID=16748
 
 do you have a trick to tell to makepkg --source to not include in
 src package the file which should be download manually?
 or you remove it from the tarball manually before uploading to AUR?

 source=('http://dummy.address.com/file-already-downloaded.ext')
 That should work ^

Yeah any dummy address would work too. You should put a comment so
people understand that.

Re: [aur-general] Deletion request

[Loui Chang]

On Sun 19 Dec 2010 17:15 +0100, Seblu wrote:
 On Sun, Dec 19, 2010 at 4:58 PM, cantabile cantabile.d...@gmail.com wrote:
  Le 19/12/2010 17:55, Seblu a écrit :
 
  2010/12/13 Cédric Girardgirard.ced...@gmail.com:
 
  On Mon, Dec 13, 2010 at 10:40 AM, Stefan
  Husmannstefan-husm...@t-online.de
  There is a similar case with packages like steinberg-vst [1]. The package
  just assumes the source are already downloaded in the build directory as
  explained in comment.
 
  [1] http://aur.archlinux.org/packages.php?ID=16748
 
  ok.
 
  do you have a trick to tell to makepkg --source to not include in
  src package the file which should be download manually?
  or you remove it from the tarball manually before uploading to AUR?
 
  Regards,
 
 
  source=('http://dummy.address.com/file-already-downloaded.ext')
  That should work ^
 Yes but he does not like it.
 And this is not a pretty way, because makepkg download will just fail
 rather than showing a message to ask a manual download.
 So i think a better way is to not mark the file in source var, and
 doing checking by hand and ask to download if not present.
 
 But in this PKGBUILD, he uses source var to make checking. And on AUR
 zip file is not uploaded. So i'm wondering if they are an option or he
 deleting file manually.
 http://aur.archlinux.org/packages/steinberg-vst/steinberg-vst/PKGBUILD
 http://aur.archlinux.org/packages/steinberg-vst/steinberg-vst/vst_sdk2_3.zip

Well if the zip archive exists in the package tarball, then I removed it
during a recent cleanup.

Re: [aur-general] TU Bylaws Amendment (SVP Section): Discussion Period

[Loui Chang]

On Thu 16 Dec 2010 01:32 +0100, Xyne wrote:
 Ronald van Haren wrote:
 
  On Sun, Dec 12, 2010 at 9:01 AM, Ray Rashif sc...@archlinux.org wrote:
   On 12 December 2010 11:39, Loui Chang louipc@gmail.com wrote:
   On Sun 12 Dec 2010 04:21 +0100, Xyne wrote:
   The following is a proposed replacement for the current SVP
   section of the TU bylaws:
  
   https://wiki.archlinux.org/index.php?title=Bylaw_Amendmentoldid=124557
  
   The changes address several issues recently brought up on this
   list. Briefly, these include:
   * enabling a vote to pass in the absence of quorum when more
   than 50% of active   TUs have voted YES
   * enabling a vote to fail in the absence of quorum when 50% or
   more of active   TUs have voted NO
   * clarifying the text to eliminate ambiguities
  
   Please see Kaiting's [aur-general]Amendment thread and Loui's
   [aur-general][PATCH]tu-bylaws: Amend Standard Voting Procedure
   thread for more details.
  
   This message marks the beginning of the 5-day discussion period
   before the amendment is put to a vote.
  
   Can we get that as a patch so I may apply it to the hosted version if
   the vote passes? The content should probably be on the mailing list as
   well.
  
   We can compare-and-contrast better looking at a patch, so +1 to that.
  
  yes, please provide a patch.
 
 In the time that it would take me to find sources and create a patch
 you could have easily provided one from the submitted text. If someone
 wants to point me to the relative source and describe the preferred
 format of the patch then I will waste some of my time to create it,
 but I will tell you now that I think the request itself is a bit
 ridiculous. It's plain text.

Just make a copy of the bylaws html file, alter it, and make a diff.
It isn't a ridiculous request because people may not be clear on what
text is being removed or added, so you should make such changes
unambiguous with a patch. The bylaws also call for a patch for any
amendment.

Re: [aur-general] voting period for removing Ranguvar

[Loui Chang]

On Tue 14 Dec 2010 01:57 +0200, Ionuț Bîru wrote:
 On 12/08/2010 10:07 PM, Ionuț Bîru wrote:
 application is here: https://aur.archlinux.org/tu.php?id=43
 Ranguvar is not allowed to vote, therefor i temporally disabled his TU
 access.
 
 the voting period ended. The results are:
 
 yes17
 no  2
 abstain 7
 
 I'm sorry for your removal Ranguvar. You can reapply after 3 months or when
 you think you will have time to contribute.

Sorry to see you go. Hopefully you can continue to contribute to the
community if you've got the time. Cheers!

Re: [aur-general] Deletion request

[Loui Chang]

On Mon 13 Dec 2010 00:14 +0100, Seblu wrote:
 Delete package : oracle 11gR1-1
 (https://aur.archlinux.org/packages.php?ID=23730O=L=C=K=SB=SO=PP=do_Orphans=SeB=)
 
 Because, it's orphan, it's out-of-date, source link is broken
 (==cannot be built).

Well, I must have deleted the source file in a recent cleanup. Sources
should not be hosted on the AUR. Otherwise let whoever the new
maintainer may be fix the PKGBUILD to retrieve sources remotely.

Re: [aur-general] Tarball Guidelines

[Loui Chang]

On Fri 10 Dec 2010 15:15 +0100, Xyne wrote:
 Loui Chang wrote:
 
   If the patch is large then what's the problem with compressing it?
  
  I would argue that we should not have large patches applied to Arch, or
  AUR packages at all. If there is enough patching, that constitues a
  fork, and we shouldn't be hosting project files for defacto forks on the
  AUR.  They should find some other place to host their project. That
  large patch, and any other source tarballs should be downloadable from
  the project's webspace, not the AUR.
 
 I mostly agree. I thought about my post afterwards and realized that there are
 very few cases in which a patch could be large enough to be worth compressing
 while simultaneously being appropriate for the AUR.
 
 There are probably some cases though in which large patches might be required
 to make something play nicely with Arch, i.e. something that isn't a fork but
 just a relatively large compatibility fix.
 
 I also just realized that compressing the archive itself probably makes
 compressing internal files redundant.

Actually in the case of the current AUR implementation, it's actually
nicer to have them compressed since it will require less resources from
the server. That will change in the near future so that it won't make a
difference.

Re: [aur-general] TU Bylaws Amendment (SVP Section): Discussion Period

[Loui Chang]

On Sun 12 Dec 2010 04:21 +0100, Xyne wrote:
 The following is a proposed replacement for the current SVP section of the TU
 bylaws:
 
 https://wiki.archlinux.org/index.php?title=Bylaw_Amendmentoldid=124557
 
 The changes address several issues recently brought up on this list. Briefly,
 these include:
 * enabling a vote to pass in the absence of quorum when more than 50% of 
 active
   TUs have voted YES
 * enabling a vote to fail in the absence of quorum when 50% or more of active
   TUs have voted NO
 * clarifying the text to eliminate ambiguities
 
 Please see Kaiting's [aur-general]Amendment thread and Loui's
 [aur-general][PATCH]tu-bylaws: Amend Standard Voting Procedure thread for
 more details.
 
 This message marks the beginning of the 5-day discussion period before the
 amendment is put to a vote.

Can we get that as a patch so I may apply it to the hosted version if
the vote passes? The content should probably be on the mailing list as
well.

Other than that it looks good to me.

Re: [aur-general] TU application - Kyle Keen

[Loui Chang]

On Thu 09 Dec 2010 09:54 -0500, keenerd wrote:
 On Thu, Dec 9, 2010 at 2:49 AM, Xyne x...@archlinux.ca wrote:
  The issue as I see it is that you presented the idea on this list for
  discussion but didn't care to follow that discussion until a conclusion was
  reached.
 
 It seemed discussion had petered out.
 
  Some TUs objected to the bot and I think you should have taken those
  objections into consideration (e.g. that icons should be tolerated, etc).
 
 In the days before the launch there were seven replies.  Of these,
 three were positive and four were neutral.  Not one negative comment
 or objection.  (From just TUs: 1 positive, 2 neutral, 0 negative.)
 All advice given in the neutral comments was applied.  Tone of the
 message was greatly lightened in the case of icons.  Silly workarounds
 like base64 were removed.  No one commented on the number or choice of
 packages in the lists attached to the original post.
 
 I will look for stronger consensus in the future.

If in doubt start a vote. ;)

Re: [aur-general] Tarball Guidelines

[Loui Chang]

On Tue 07 Dec 2010 16:49 +0100, Xyne wrote:
 keenerd wrote:
 
  On Mon, Dec 6, 2010 at 4:59 AM, Nicky726 nicky...@gmail.com wrote:
   been told by the bot, that selinux-flex has a binary
   (selinux-flex/flex- arch.patch.gz), which is a gziped patch. Guess
   I can ungzip it, though as this package is just a copy of a [core]
   package from some time ago, I guess the original maintainers new,
   what they were doing, if they included it this way.  So should I
   do it to not include evil gziped patches?
  
  Evil is such a strong word.  It is just without benefit.  Disturbs the
  transparency of things.  Technically against the rules.
  
  Zipped patches was an edge case.  Here, I chose to take a strict
  interpritation of the edge cases.  It is only a comment after all,
  very little of consequence.  Besides, Arch tries hard to not patch
  things  :-)
  
  But thank you for taking the time to read and respond.  So many
  maintainers ignore comments.
 
 If the patch is large then what's the problem with compressing it?

I would argue that we should not have large patches applied to Arch, or
AUR packages at all. If there is enough patching, that constitues a
fork, and we shouldn't be hosting project files for defacto forks on the
AUR.  They should find some other place to host their project. That
large patch, and any other source tarballs should be downloadable from
the project's webspace, not the AUR.

Re: [aur-general] voting period for removing Ranguvar

[Loui Chang]

On Wed 08 Dec 2010 15:27 -0500, Ranguvar wrote:
 On Wed, Dec 8, 2010 at 15:07, Ionuț Bîru ib...@archlinux.org wrote:
  application is here: https://aur.archlinux.org/tu.php?id=43
  Ranguvar is not allowed to vote, therefor i temporally disabled his TU
  access.
 
 Just referring to my response, as there were no replies before and I'm
 unsure if it was read at all.
 http://mailman.archlinux.org/pipermail/aur-general/2010-December/012234.html

Thanks for the response.

Re: [aur-general] [PATCH] tu-bylaws: Amend Standard Voting Procedure

[Loui Chang]

On Wed 08 Dec 2010 16:23 +0100, Xyne wrote:
 I think the passage concerning similar proposals is too vague. There
 is no way to define those terms in a way that is unambiguous in all
 cases and trying to do so is futile and condemned to a pedantic
 spiral.
 
 I trust the human factor to handle those cases. People will be able to
 determine whether it's the same proposal or not.
 
 I've removed that passage, changed bylaws to by-laws, and changed YES /
 NO to YES or NO.

I would prefer the non hyphenated spelling. *shrug*

 As Loui pointed out, we should agree on a final version soon. I currently
 support this version:
 
 https://wiki.archlinux.org/index.php?title=Bylaw_Amendmentoldid=124479

Yeah we're starting to lump too many changes into one amendment.

Re: [aur-general] [PATCH] tu-bylaws: Amend Standard Voting Procedure

[Loui Chang]

On Wed 08 Dec 2010 11:59 -0500, Kaiting Chen wrote:
 On Wed, Dec 8, 2010 at 11:01 AM, Xyne x...@archlinux.ca wrote:
 
  Let's wait another day to get some more comments and incorporate any
  last changes. If it changes during the discussion period without
  unanimous consent then we would end up in a grey area when deciding
  which version to vote on (and we're limited by YES/NO proposals...
  haha).
 
 Also if we are putting stuff like five day discussion section, seven day
 voting period, 66% quorum in the Standard Voting Procedure section, are we
 going to remove the redundant information in the other sections? As it
 stands now every section says 66% quorum. --Kaiting.

I would leave them period, but definitely leave them for at least
another amendment.

Re: [aur-general] TU application - Kyle Keen

[Loui Chang]

On Tue 07 Dec 2010 16:44 -0500, keenerd wrote:
 After much heavy thought, I withdraw my application.  My apologies for
 the trouble.

N. I was interested in your analysis of the AUR and I think we could
make good use of it. I kind of wish I could spam users about their bad
packages. I have sent a few emails manually.

I guess the real issue is that if there is any action that has a
widespread effect on the AUR we should always decide what should be done
as a group of TUs. That's one reason that I made Jakob create a proposal
for the last mass AUR cleanup. I could have easily applied the changes
behind the scenes otherwise.

Re: [aur-general] TU Application

[Loui Chang]

On Sun 05 Dec 2010 22:50 +0100, Jelle van der Waa wrote:
 Hello all.
 
 I would like apply to become a TU! Daenyth has decided to sponsor me for
 my TU application  
 
 I'm 21 years old and a Bachelor student Computer Science. I have
 experience with C++, C, x86 ASM, Java, Python, PHP, SQL and
 javascript. I use archlinux on daily basis as a server and as desktop
 on my laptop. 
 
 My current packaging interests are haskell, LaTeX, cli apps,
 virtualization.
 
 In the future i am looking into improving tools such as namcap.
 
 Feel free ask any questions here or on irc. 

Nice. Are there any specific packages that you plan to adopt or add to
community? Do you see any relationship between community and arch-games?

I know that recently some people have been concerned that disk space on
the community server is getting tight, so it might not be a great idea
to bring more games. Usually those use a lot of disk.

Re: [aur-general] [PATCH] tu-bylaws: Amend Standard Voting Procedure

[Loui Chang]

On Tue 07 Dec 2010 20:27 +, Peter Lewis wrote:
 On Tuesday 07 December 2010 19:02:59 Xyne wrote:
  Peter Lewis wrote:
   This means that we cannot override (A) in the rest of the byelaws. I can
   imagine that we might want to create something requiring (say) a 2/3rds
  
   majority for some type of serious proposal at some point... How about:
  /snip
  
   Just more thoughts, trying to spot loopholes, etc... :-)
  
  The formatting got mangled. The format was
  
  The proposal is foo if EITHER
A) condition 1 OR
B) condition 2
  UNLESS some other condition
  
  The indentation should make it clear that the EITHER and UNLESS wrap
  the two choices. If you have a better idea of how to insert parentheses
  then let me know.
 
 Ah, thought so :-)
 
  Here's version 3 again without wrapping, hopefully:
 
 Nice.
 
 Yeah, I don't have any better suggestion really, and apart from my general 
 dislike for using whitespace to provide meaning (a la python) it's pretty 
 clear to me.

I do like to separate words by a space and paragraphs by a blank line.
It makes text easier to read and understand. ;)

It's nice to see this getting some development now, but I think we
should make a final revision soon, so this doesn't end up in endless
discussion. It doesn't need to be perfect. Making it better than it was
is good too.

Re: [aur-general] [PATCH] tu-bylaws: Amend Standard Voting Procedure

[Loui Chang]

On Mon 06 Dec 2010 17:31 +0100, Thorsten Töpper wrote:
 On Sun,  5 Dec 2010 16:13:55 -0500 Loui Chang louipc@gmail.com
 wrote:
  This proposal clarifies the Standard Voting Procedure, and allows
  another condition for passing a motion.
  
  Signed-off-by: Loui Chang louipc@gmail.com
  ---
   TUbylaws.html |   13 -
   1 files changed, 8 insertions(+), 5 deletions(-)
  
  diff --git a/TUbylaws.html b/TUbylaws.html
  index 2c4b854..a3fa84d 100644
  --- a/TUbylaws.html
  +++ b/TUbylaws.html
  @@ -10,8 +10,8 @@
  /headbody
  h1Trusted User Bylaws/h1
  
  -   div class=dateMay 21, 2008/div
  -   div class=version1.1/div
  +   div class=date2010-12-05/div
  +   div class=version1.2/div
  
  address
  Trusted Users
  @@ -79,9 +79,12 @@
  brbr
   
  At the expiration of the voting period, if a
  quorum was reached, votes are to be tallied.
  -   A simple majority is needed to pass or
  reject the motion. In the event of a draw, being 
  -   that 50% is not a majority, the motion does
  not pass. In the event that a quorum was not
  -   reached, a duplicate voting period opens
  immediately after the first ends, all previous votes are
  +   The motion is passed if quorum is reached
  and the number of YES votes is greater than the number of NO votes.
  +   The motion is also passed if quorum is not
  reached but the number of YES votes exceeds fifty percent of the
  number of active Trusted Users.
  +   The motion is rejected if quorum is reached
  and the number of NO votes is greater or equal to the number of YES
  votes. +
  +   In the event that a quorum was not reached
  and the motion is not passed,
  +   a duplicate voting period opens immediately
  after the first ends, all previous votes are struck from the record,
  and the voting period is repeated. If quorum cannot be reached for
  two consecutive voting periods, the motion fails to pass.brbr 
 
 So far it is mostly fine for me, however from this paragraph it is not
 clear if the vote is still open when the quorum was reached and the
 application passed. In my opinion it should be, so everyone has the
 chance to do a vote and express his way though it doesn't matter.
 (Yes it does not make any formal sense, however I think about human
 emotions that it's better to do so, so no one feels to be excluded
 just as the vote is another in a row where he/she could not
 participate. In other words: Kaiting that was what I meant yesterday.)
 
 Also I'd say to keep the old date format as it is really clear how it
 has to be read, I'm not aware of every date format around the world
 but I have the feeling that this one could be misread as May 12, 2010...

Those changes do not alter the voting period in any way. So the voting
period would still run for the same amount of time. Good point about the
date.

Re: [aur-general] Tarball Guidelines

[Loui Chang]

On Tue 07 Dec 2010 03:58 +0800, Ray Rashif wrote:
 On 6 December 2010 22:47, Dave Reisner d...@falconindy.com wrote:
  On Mon, Dec 06, 2010 at 03:20:06PM +0100, Heiko Baums wrote:
  In most cases there's a reason for having binaries, icons and the like
  in a package. And whether such a package actually has a bad quality or
  its contents are necessary can't be decided by a bot.
 
  In _all_ cases, binaries are not permissable as stated by the AUR
  guidelines [1]. Your opinion doesn't change this. A proposal to amend the
  guidelines can.
 
 There is no need to ammend the guidelines. We have been including
 desktop files, images (needed by the desktop files most of the time)
 and init scripts all along, because it should be a common
 understanding.
 
 find /var/abs -name *.png | wc -l == 60

I might be kind of crazy here, but maybe desktop files and icons are
things that should be distributed from upstream. So maintainers should
work to get those included like a patch or whatnot.

Re: [aur-general] Tarball Guidelines

[Loui Chang]

On Mon 06 Dec 2010 10:59 +0100, Nicky726 wrote:
 been told by the bot, that selinux-flex has a binary (selinux-flex/flex-
 arch.patch.gz), which is a gziped patch. Guess I can ungzip it, though as 
 this 
 package is just a copy of a [core] package from some time ago, I guess the 
 original maintainers new, what they were doing, if they included it this way. 
 So should I do it to not include evil gziped patches?

It would be best to avoid. It would be preferable to have the patch
incorporated upstream if possible.

Re: [aur-general] [PATCH] tu-bylaws: Amend Standard Voting Procedure

[Loui Chang]

On Mon 06 Dec 2010 23:08 -0500, Kaiting Chen wrote:
 On Mon, Dec 6, 2010 at 11:31 AM, Thorsten Töpper
 atsut...@freethoughts.dewrote:
 
  So far it is mostly fine for me, however from this paragraph it is not
  clear if the vote is still open when the quorum was reached and the
  application passed. In my opinion it should be, so everyone has the
  chance to do a vote and express his way though it doesn't matter.
  (Yes it does not make any formal sense, however I think about human
  emotions that it's better to do so, so no one feels to be excluded
  just as the vote is another in a row where he/she could not
  participate. In other words: Kaiting that was what I meant yesterday.)
 
 I'm not really one for human emotion, but I'll go ahead and conceded to a
 full voting period regardless of whether or not a vote is set.
 
 I've read through this a couple more times and I'm little concerned about
 the particular wording. Unfortunately I don't know how to make this any
 clearer so I guess I'll shut up...

Honestly, I wouldn't mind hearing your concerns.
I realise that I could improve my writing skills at least.

Do we have any technical writers in the community? :D

Re: [aur-general] [PATCH] tu-bylaws: Amend Standard Voting Procedure

[Loui Chang]

On Mon 06 Dec 2010 23:42 -0500, Kaiting Chen wrote:
 On Mon, Dec 6, 2010 at 11:37 PM, Loui Chang louipc@gmail.com wrote:
 
   I've read through this a couple more times and I'm little concerned about
   the particular wording. Unfortunately I don't know how to make this any
   clearer so I guess I'll shut up...
 
  Honestly, I wouldn't mind hearing your concerns.
  I realise that I could improve my writing skills at least.
 
  Do we have any technical writers in the community? :D
 
 I sent the proposed patch to some people who deal with this kind of thing
 and most of them were confused until I explained it thoroughly. I'm waiting
 to hear their suggestions. --Kaiting.

Wow. I didn't think it was that bad.

Re: [aur-general] Fix the Bylaws?

[Loui Chang]

On Sun 05 Dec 2010 03:35 -0500, Kaiting Chen wrote:
 Sorry for all the mail regarding the bylaws but let me take a quick moment
 to go through one extremely broken case of the current procedure.
 
 Let's take falconindy's vote as an example; at the moment he has seventeen
 votes for, one vote abstain, and zero votes against. There are thirty
 Trusted Users in total.
 
 Let us now assume that the remaining twelve Trusted Users are against
 falconindy becoming a Trusted User. In this case if each of them vote nay,
 then there will be seventeen votes for, twelve votes against and one vote
 abstained, which means that falconindy will be accepted as a Trusted User.
 
 However, if these remaining twelve Trusted Users are smart and adamant about
 their desire to block falconindy's application, they will simply *not vote*.
 A sixty-six percent quorum requires that at least twenty Trusted Users vote;
 if quorum is not reached for two consecutive votes the motion fails.
 Therefore by not voting these twelve Trusted Users will have effectively
 voted nay, and falconindy's application will not be accepted.

Well, this kind of gives us a mechanism to remove TUs that are actually
inactive or uncooperative, but maybe they should automatically be put up
for removal after blocking two proposals rather than three. That way it
operations would flow better. Either that, or we can make proposals go
for three tries to reach quorum.

I'd rather go for the time saver hehe.

Re: [aur-general] voting period for Dave Reisner

[Loui Chang]

On Sun 05 Dec 2010 08:19 -0500, Shacristo wrote:
 On Sun, Dec 5, 2010 at 3:07 AM, Kaiting Chen kaitocr...@gmail.com wrote:
  This is sort of what I was talking about in my previous mail about
  the refinement of the bylaws. Thirteen hours have passed since the
  beginning of the voting period and at this point according to this
  page:
 
  https://wiki.archlinux.org/index.php/Trusted_Users
 
  There are thirty Trusted Users. Seventeen yay's have been cast and a
  simple majority has already been reached. We should amend the bylaws
  such that the voting period may end because no amount of nay's can
  change the outcome of the vote at this point. There is no reason for
  falconindy to wait another seven days to receive his Trusted User
  privileges. --Kaiting.

 17/30 does not make a 66% quorum, so yes, the motion could still fail.

Kaiting is saying that even though quorum hasn't been met, that it's
impossible for the vote to fail on the basis of opposition.

If the rest of the TUs voted nay, then it would be 17 aye vs 13 nay
which would still be a majority for the motion.

How do they do it in real life if quorum isn't met, but support for the
motion is enough that it shouldn't really matter.

Re: [aur-general] Amendment

[Loui Chang]

On Sun 05 Dec 2010 11:53 -0500, Kaiting Chen wrote:
 On Sun, Dec 5, 2010 at 11:33 AM, Shacristo shacri...@gmail.com wrote:
 
  On Sun, Dec 5, 2010 at 11:16 AM, Kaiting Chen kaitocr...@gmail.com
  wrote:
  One of the stated purposes of the quorum is to ensure that TUs remain
  active in the job that they have taken on.  Allowing circumvention of
  the quorum requirements will obviously undermine that.
 
 TU's have a lot of different responsibilities. Prolonging a decided vote by
 six days to motivate or ensure that someone is active does not make sense to
 me. --Kaiting.

I would propose shortening the voting period then. I kind of like how
the system is set up (not perfectly though) to remove the inactive TUs
semi-automatically.

Re: [aur-general] Amendment

[Loui Chang]

On Sun 05 Dec 2010 14:23 -0500, Shacristo wrote:
 On Sun, Dec 5, 2010 at 2:20 PM, Xyne x...@archlinux.ca wrote:
  Xyne wrote:
 
  Xyne wrote:
   See attachment :P
 
  Trying again...
 
  ?
 
  Are attachments disabled or is there something wrong on my end?
 
  Here's the script in-line. Sorry for spamming the list.
 
  #!/usr/bin/env python2
  from sys import argv
 
  # Quorum (66%)
  quorum = 0.66
 
  # Total active TUs, yes votes, no votes, abstain votes.
  TUs, yes, no, abstain = [float(x) for x in argv[1:]]
  # Total number of votes.
  votes = yes + no + abstain
 
  # If an absolute majority has voted yes,
  if yes / TUs  0.50 \
  # or quorum has been established with a simple majority
  or (votes / TUs  quorum and yes / votes  0.50):
   print The motion has passed.
 
  else:
   print The motion has failed.
 
 
 You need to multiply 0.66 x TUs for the actual quorum requirement and
 you're counting no and abstain votes exactly the same.  My
 understanding is that abstain votes are only used for establishing a
 quorum.  Otherwise there's no reason to have them.

That's right. Abstained votes are counted for quorum (The TU was present
for the vote), but is a ruined or blank vote, so do not affect the final
result. The passing of the motion results from the number of 'aye' votes
being greater than 'nay'.

Re: [aur-general] Non-native English speakers and the AUR by-laws [WAS: removal proposal for Ranguvar]

[Loui Chang]

On Sun 05 Dec 2010 13:47 -0500, Kaiting Chen wrote:
 On Sun, Dec 5, 2010 at 1:42 PM, PyroPeter abi1...@googlemail.com wrote:
 
  On 12/05/2010 03:11 AM, Xyne wrote:
 
  I'm halfway tempted to create the flowchart but I just don't have the
  time. If
  someone wants to adapt the dot file from the Arch Linux Help Guide
  Flowchart,
  feel free:
 
 
  http://xyne.archlinux.ca/miscellaneous/#the-arch-linux-help-guide-flowchart
 
  Make sure that Blame Allan is in there somewhere (Was quorum reached?
  --no--
  Blame Allan --  etc)
 
 
  I created a flowchart about the Standard Voting Procedure [1], but I had
  problems understanding this bit:
 
   A simple majority is needed to pass or reject the motion. In the
   event of a draw, being that 50% is not a majority, the motion does
   not pass.
 
  Isn't reject the same as does not pass?
  And what means being that 50% is not a majority? (50% of what?)
 
  As I showed in the graph, I understood the quoted text as follows:
 
   If more than 50% of the votes cast for YES, the motion passes,
   if not, it is rejected.
 
 That's the correct interpretation. A simple majority requires *greater* than
 50% of the votes cast which is what the part up above was trying to express.

Did more than 50% of the votes cast for YES?
should be changed to:
Are the number of YES votes greater than the number of NO votes?

Remember abstained votes don't count as votes.

Re: [aur-general] Amendment

[Loui Chang]

On Sun 05 Dec 2010 19:55 +0100, Xyne wrote:
 On 2010-12-05 12:20 -0500 (48:7)
 Loui Chang wrote:
 
  On Sun 05 Dec 2010 11:53 -0500, Kaiting Chen wrote:
   On Sun, Dec 5, 2010 at 11:33 AM, Shacristo shacri...@gmail.com wrote:
   
On Sun, Dec 5, 2010 at 11:16 AM, Kaiting Chen kaitocr...@gmail.com
wrote:
One of the stated purposes of the quorum is to ensure that TUs remain
active in the job that they have taken on.  Allowing circumvention of
the quorum requirements will obviously undermine that.
   
   TU's have a lot of different responsibilities. Prolonging a decided vote 
   by
   six days to motivate or ensure that someone is active does not make sense 
   to
   me. --Kaiting.
  
  I would propose shortening the voting period then. I kind of like how
  the system is set up (not perfectly though) to remove the inactive TUs
  semi-automatically.
 
 I've copied my reply to another thread below for reference so you
 don't have to search for it (I tend to reply to messages as I read
 them instead of scanning everything first).
 
 After thinking about this more, I propose the following:
 
 The voting period should remain 7 days regardless of the current votes. It is
 rude to others to exclude them from participation even if the outcome is
 assured.
 
 Once the voting period is over, the motion shall pass if either an absolute
 majority were reached, or if a simple majority were reached with quorum.
 
 This will allow all TUs to have their say if they so choose and it sidesteps
 the issue of determining inactivity due to shortened voting periods while
 preventing motions with absolute (i.e. insurmountable) majorities from
 failing, which is what the real issue is here. Overall I think this is the
 simplest solution.

I like this solution.

Re: [aur-general] [PATCH] tu-bylaws: Amend Standard Voting Procedure

[Loui Chang]

On Sun 05 Dec 2010 16:19 -0500, Kaiting Chen wrote:
 On Sun, Dec 5, 2010 at 4:13 PM, Loui Chang louipc@gmail.com wrote:
 
  This proposal clarifies the Standard Voting Procedure, and allows
  another condition for passing a motion.
 
 address
 Trusted Users
  @@ -79,9 +79,12 @@
 brbr
 
 At the expiration of the voting period, if a quorum
  was reached, votes are to be tallied.
  -   A simple majority is needed to pass or reject the
  motion. In the event of a draw, being
  -   that 50% is not a majority, the motion does not
  pass. In the event that a quorum was not
  -   reached, a duplicate voting period opens
  immediately after the first ends, all previous votes are
  +   The motion is passed if quorum is reached and the
  number of YES votes is greater than the number of NO votes.
  +   The motion is also passed if quorum is not reached
  but the number of YES votes exceeds fifty percent of the number of active
  Trusted Users.
  +   The motion is rejected if quorum is reached and the
  number of NO votes is greater or equal to the number of YES votes.
  +
  +   In the event that a quorum was not reached and the
  motion is not passed,
  +   a duplicate voting period opens immediately after
  the first ends, all previous votes are
 struck from the record, and the voting period is
  repeated. If quorum cannot be reached
 for two consecutive voting periods, the motion fails
  to pass.brbr
 
 
 Looks good to me, except greater or equal to is usually written as
 greater than or equal to. --Kaiting.

Ah right good catch. Let's see what others think now before revising.

Re: [aur-general] Fix the Bylaws?

[Loui Chang]

On Sun 05 Dec 2010 23:23 +, Peter Lewis wrote:
 On Sunday 05 December 2010 23:14:14 Loui Chang wrote:
  On Sun 05 Dec 2010 22:52 +, Peter Lewis wrote:
   I'd support some kind of reworking of the quorum for TU votes, since as
   Kaitling points out, missing a meeting due to weather, car problems, etc.
   doesn't really apply (though a reasonable equivalent might be that
   someone's Internet connection goes down for a few days without warning.)
   
   It seems to me that if we are to basically expect that all TUs engage in
   all votes, then the assumption is that a fully constituted vote is
   everyone, not 66%. Therefore, a majority should be counted as a majority
   of all TUs, not just of those voting.
   
   We'd have to ensure though, I think, that a TU that didn't vote on
   more than n (consecutive?) occasions (possibly with the addition of
   them not giving a reason for this) triggers a removal process
   automatically.
   
   But, I'd be a little hesitant about having more complex quorum rules
   (i.e. exactly as Chris suggested). We should probably either get rid of
   it (in favour of the above higher expectation of participation) or else
   leave it as it is.
  
  Well, we don't need to get rid of quorum. We can just raise the needed
  quorum for the different type of motions which may achieve a better
  balance.
 
 Yeah, that's fine, I don't feel strongly about how we implement
 quorum, I just think it should be consistent and encourage everyone to
 vote.
 
 Incidentally, what did you mean by achieve a better balance?

A better balance of non voters vs voters, which really isn't something
that affects us as far as I can tell.

Re: [aur-general] Tarball Guidelines

[Loui Chang]

On Fri 03 Dec 2010 16:54 -0500, David Campbell wrote:
 Excerpts from keenerd's message of 2010-12-03 13:46:10 -0500:
  If no one can think of a better way to deal with the nonconforming
  packages, I'll write a bot to post insulting comments.  Personally, I
  really like this solution.  The AUR has always had a wild west
  frontier / insane asylum feel to it.  The less regulation, the better
  it works.  But a few well placed suggestions could help make the two
  thousand maintainers do a better job.
 
 Isn't this the sort of thing namcap was designed for? Maybe
 namcap should be extended to do checks on .src packages, and a
 report could be posted automatically using namcap when someone
 posts a .src package to the AUR.

The problem is that namcap's implementation is not meant for untrusted
PKGBUILDs. Sourcing those build files is a big security flaw, so we
can't do that for the AUR.

Re: [aur-general] TU application - Kyle Keen

[Loui Chang]

On Thu 02 Dec 2010 13:20 -0500, keenerd wrote:
 Hello all.  I am applying to become a TU.  My sponsor is Xyne.
 
 My name is Kyle Keen, though my handle for irc/bbs/the-last-12-years
 has been Keenerd.  I've been using Arch for a while now, from back
 when it was still known for refusing to package info files.  Before
 that I did a wee bit of dev work for Puppy Linux.  I actually got a
 bash gui app (yay xdialog) into the ISO but please don't look up the
 code, it was my first bash script and is rather terrifying.  Lately I
 am a 24 year old freelance electrical engineer and spend my days
 writing C, my nights writing Python and during the twilight hours some
 Bash.

 Right now I host the bugbot in #archlinux-bugs and I've got a few AUR
 packages(1).  Of them, ScrotWM and Slurm probably deserve to be in
 [community].  I've written several well-liked metatools for Arch
 including Pacgraph, Pacmatic, and Aurphan.  Aurphan is the main reason
 for trying to apply.

 Pierre requested a feature to cross check official packages as well as
 the AUR(2).  I was a little shocked to find 35 official orphans on my
 system.  Clearly, we are understaffed.  Arch has been nothing short of
 amazing and I want to do what I can to help keep it going.  Other
 goals include improving the maintenance tools and porting Arch to old
 or cheap architectures.  I also mirrored the AUR for a while and have
 a nearly complete copy of the old comments from before the Great Table
 Drop that should be re-inserted.

Well, we have most of the comments, they just haven't been merged back
into the database. I guess we can determine later if you have any others
that might be missing. How exactly did you mirror the AUR? Do you know
if there's a lot of this type of thing going on?

I wish people would mention this sort of thing. Maybe if there -really-
is a need we can make things more efficient and streamlined. Though I
still don't see why anyone would really need a whole copy of the AUR,
other than for research or something similar.

Glad to see you applying for TU. Cheers!

Re: [aur-general] removal proposal for Ranguvar

[Loui Chang]

On Sat 04 Dec 2010 22:19 +0200, Ionuț Bîru wrote:
 On 12/03/2010 12:06 AM, Ionuț Bîru wrote:
 
 I'm waiting to see your replies and then act based on them.
 
 
 i don't see this being discuss any further and all messages have been only
 in one direction.
 
 i modified his account on aur to normal user. Ranguvar, i'm sorry for this
 and when you'll have time again you should consider applying again.
 
 Loui can you disable his account on sigurd?
 Andrea can you remove his privileges from bugtracker and forum?

You still need to create a voting proposal.
Why doesn't anyone read the damned bylaws?

Re: [aur-general] removal proposal for Ranguvar

[Loui Chang]

On Sat 04 Dec 2010 23:59 +0200, Ionuț Bîru wrote:
 On 12/04/2010 11:53 PM, Ray Rashif wrote:
 On 5 December 2010 05:46, Loui Changlouipc@gmail.com  wrote:
 On Sat 04 Dec 2010 22:19 +0200, Ionuț Bîru wrote:
 On 12/03/2010 12:06 AM, Ionuț Bîru wrote:
 
 I'm waiting to see your replies and then act based on them.
 
 
 i don't see this being discuss any further and all messages have been only
 in one direction.
 
 i modified his account on aur to normal user. Ranguvar, i'm sorry for this
 and when you'll have time again you should consider applying again.
 
 Loui can you disable his account on sigurd?
 Andrea can you remove his privileges from bugtracker and forum?
 
 You still need to create a voting proposal.
 Why doesn't anyone read the damned bylaws?
 
 I myself thought there would be voting, but I just realised Ionut
 inferred that we needn't vote from the following:
 
 for which standard voting procedure deviates from the above.
 
 
 above being the voting procedure and from my understanding what is the
 opposite of having a voting? NO voting.
 
 
 we had this situation in the past and we didn't had any voting procedure. we
 just removed it and we continued our business.
 
 with or without the vote, the result would be the same. And to be fair, we
 are investing too much time in the removal, even more that he invested in
 community.

Then don't waste any time on it. Leave it alone.
But if you do want to remove a Trusted User you MUST follow the bylaws.
Three days discussion and Five days of voting for removal due to
inactivity. Read the bloody bylaws.

We cannot be at liberty to remove people without proper procedure.

Re: [aur-general] removal proposal for Ranguvar

[Loui Chang]

On Sun 05 Dec 2010 00:15 +0200, Ionuț Bîru wrote:
 On 12/05/2010 12:07 AM, Loui Chang wrote:
 On Sat 04 Dec 2010 23:59 +0200, Ionuț Bîru wrote:
 On 12/04/2010 11:53 PM, Ray Rashif wrote:
 On 5 December 2010 05:46, Loui Changlouipc@gmail.com   wrote:
 On Sat 04 Dec 2010 22:19 +0200, Ionuț Bîru wrote:
 On 12/03/2010 12:06 AM, Ionuț Bîru wrote:
 
 I'm waiting to see your replies and then act based on them.
 
 
 i don't see this being discuss any further and all messages have been 
 only
 in one direction.
 
 i modified his account on aur to normal user. Ranguvar, i'm sorry for 
 this
 and when you'll have time again you should consider applying again.
 
 Loui can you disable his account on sigurd?
 Andrea can you remove his privileges from bugtracker and forum?
 
 You still need to create a voting proposal.
 Why doesn't anyone read the damned bylaws?
 
 I myself thought there would be voting, but I just realised Ionut
 inferred that we needn't vote from the following:
 
 for which standard voting procedure deviates from the above.
 
 
 above being the voting procedure and from my understanding what is the
 opposite of having a voting? NO voting.
 
 
 we had this situation in the past and we didn't had any voting procedure. we
 just removed it and we continued our business.
 
 with or without the vote, the result would be the same. And to be fair, we
 are investing too much time in the removal, even more that he invested in
 community.
 
 Then don't waste any time on it. Leave it alone.
 But if you do want to remove a Trusted User you MUST follow the bylaws.
 Three days discussion and Five days of voting for removal due to
 inactivity. Read the bloody bylaws.
 
 
 maybe i lack the understanding of words and to quote from bylaws:
 
 The removal of a Trusted User may also occur at any time.
 
 A motion must be made by at least two active Trusted Users for the removal
 of a Trusted User. (THIS IS ME)
 Following the motion, standard voting procedure commences with a discussion
 period of 7 days.
 
 There is one special case for removal, removal due to unwarranted and
 undeclared inactivity, for which standard voting procedure deviates from the
 above.

The problem is your eyes stopped reading where you wanted them to stop.

The next two sentences read:
 This motion is also automatically triggered by repeated quorum
 offenses, as described in the Quorum subsection of this document. For
 this special case, SVP is followed with a discussion period of three
 days, a quorum of 66%, and a voting period of 5 days.

You can't just pick and choose the passage that fits best for goal.
You need to take the bylaws in their entirety.

[aur-general] Understanding the Trusted User Bylaws

[Loui Chang]

http://aur.archlinux.org/trusted-user/TUbylaws.html

I've noticed that there have been a few cases relatively recently where
people don't really understand the bylaws.

I'd like to encourage all Trusted Users to read over the bylaws
periodically to make sure that they fully understand the procedures.
Questions and clarifications are welcome on this list.

If something is hard to understand, the bylaws can be revised and amended.
If you don't agree with a certain procedure that may also be amended.

Thanks for your consideration.

Re: [aur-general] removal proposal for Ranguvar

[Loui Chang]

On Sun 05 Dec 2010 00:15 +0200, Ionuț Bîru wrote:
 
 maybe i lack the understanding of words and to quote from bylaws:
 
 The removal of a Trusted User may also occur at any time.
 
 A motion must be made by at least two active Trusted Users for the removal
 of a Trusted User. (THIS IS ME)

I also fail to see how you are two active Trusted Users, but I would
take the agreement of some other TUs as sufficient to count as a second
proposer.

Re: [aur-general] Understanding the Trusted User Bylaws

[Loui Chang]

On Sun 05 Dec 2010 00:44 +0200, Ionuț Bîru wrote:
 On 12/05/2010 12:25 AM, Loui Chang wrote:
 http://aur.archlinux.org/trusted-user/TUbylaws.html
 
 I've noticed that there have been a few cases relatively recently where
 people don't really understand the bylaws.
 
 I'd like to encourage all Trusted Users to read over the bylaws
 periodically to make sure that they fully understand the procedures.
 Questions and clarifications are welcome on this list.
 
 If something is hard to understand, the bylaws can be revised and amended.
 If you don't agree with a certain procedure that may also be amended.
 
 Thanks for your consideration.
 
 because the bylaws are cryptic and i would enumerate below the logic of the
 bylaws understand right now. in parentheses

Well, the biggest cryptic thing in the Bylaws are lines like:
 bool SVP( motion, unsigned short discussion_period, float quorum,
 unsigned short voting_period );
and
 SVP( addition_of_TU, 5, 0.66, 7 );

We probably shouldn't look at TU procedure so much like a computer
program. hah.

I would change the SVP lines to something like:

 Addition of a Trusted User:
5 Five days of discussion
7 Seven days of voting
  66% Sixty-six percent Quorum

 This is today logic. And this time my eyes read until the end.

I'm glad you figured it out. :)

Re: [aur-general] VCS PKGBUILDs

[Loui Chang]

On Thu 02 Dec 2010 10:39 -0500, Kaiting Chen wrote:
 On Thu, Dec 2, 2010 at 9:55 AM, Ray Rashif sc...@archlinux.org wrote:
 
 My original view had been that a package would be simply called 'package'
 regardless of whether or not a source tarball was offered. Then if someone
 makes a version that builds against upstream VCS, that package would be
 called package-vcs.
 
 In light of this new discussion however, I feel like the proper policy is to
 name a package without a suffix if there is a 'versioned release', no matter
 where this comes from (source tarball, vcs tag, etc.). Then the converse is
 that if a package has *no release* but just a rolling development trunk,
 then it is given a suffix.

I agree, but shouldn't this topic be in a separate thread?

Re: [aur-general] TUs: low disk space on sigurd

[Loui Chang]

On Mon 22 Nov 2010 20:17 +0100, Florian Pritz wrote:
 On 22.11.2010 20:16, Ionuț Bîru wrote:
  can we buy a new hard drive for that server?
 
 The server is a donation so no.
 

Who said no? It really wouldn't make any sense for them to refuse money
if offered, or would it?

Re: [aur-general] Various new packages in [community]

[Loui Chang]

On Wed 17 Nov 2010 22:22 +1000, Allan McRae wrote:
 On 17/11/10 21:59, Ionuț Bîru wrote:
 On 11/17/2010 03:03 AM, Gaetan Bisson wrote:
 Dear TUs,
 
 I'm Gaetan, a (discreet) junior dev, mentored by Allan. I recently got
 access to sigurd and thought I would use that opportunity to maintain in
 [community] a few packages I have been maintaining on the AUR so far,
 but which are just a bit too unpopular to go to [extra]:
 
 
 the main idea is that you are a junior dev without pushing rights on the
 mirrors. Now you got access on sigurd will full privileges.
 
 Do you guys (TUs) have some concern regarding this? Do we need to start
 a new applications to join our TU team?
 
 Just as an FYI, I would not have suggested these guys have access if
 I had any concerns.  They both have actually managed packages in the
 [extra] repo for a few months now without breaking anything.
 
 New TUs are provided full access to the [community] with zero total
 experience on our systems.  If you are really concerned then we
 should restrict new TUs from pushing packages as well...

That's not really the issue. Someone might be bothered by apparent
circumvention of the established system of sponsorship and voting to
gain those privileges.

Historically devs have access to community if they choose. Arch Linux
provides all the resources to host the AUR and community, and even
mirroring. I don't see anything wrong with that arrangement. I think we
can trust the junior devs the same as devs.

Re: [aur-general] AUR Improvement Thread

[Loui Chang]

On Tue 16 Nov 2010 23:17 -0500, Kaiting Chen wrote:
 How can we make the AUR even better? I'll start:
 
 1. Integrated distributed version control system
 2. User provided binaries (if case anyone wants to volunteer) (this should
 probably be carefully controlled)
 3. Time-adjusted 'relevance' measure (votes are useful but suck at the same
 time; nobody cares if a packages was upvoted 9000+ times a million years
 ago, especially if it's already been obsoleted by something else)
 4. An official client
 5. LDAP support because LDAP makes everything so much better

I'd almost say I'd like to see something like a Launchpad or Sourceforge
for the AUR, with everything you need available via a more-or-less
homogenous interface. But all features should be accessible via the
command line as the core interface. It seems like everything out there
is web based which bugs me for some reason.

Re: [aur-general] [community] repository cleanup

[Loui Chang]

On Tue 16 Nov 2010 13:06 +0100, Heiko Baums wrote:
 Am Tue, 16 Nov 2010 21:54:23 +1000
 schrieb Allan McRae al...@archlinux.org:
 
  It is true as long as the developers say it is true.  Just because I 
  tell GM their car is an aeroplane does not mean they will start
  flying.
 
 Wrong. It is true as soon as a distro becomes more and more popular.
 And this is the case for Arch Linux. As long as a distro is unknown and
 only used by a few people, mainly its developers, this distro may only
 be from the devs for the devs. But as soon as it is mentioned together
 with and equivalent to the other big distros and gets more popular this
 is not true anymore independent from what a single developer says.
 
 Otherwise you should write a big note on the homepage and/or the
 download page that this distro is free but not meant to be used for the
 public. Feel free to use it but don't expect anything. This distro is
 only meant to be used by us developers. Or something like this. Maybe
 a bit exaggerated.

You're right. A lot of open source software does have that no guarantee,
no liability disclaimer. Maybe it should be made more obvious.

Anyways, Arch Linux isn't bound by any unwritten or unspoken contracts
saying that it must deliver a certain level of support after reaching a
certain popularity. If you want that support, then go a head and
contribute the resources. I really don't forsee the distro signing any
support contracts though.

Re: [aur-general] [community] repository cleanup

[Loui Chang]

On Tue 16 Nov 2010 21:21 -0600, Brad Fanella wrote:
 On Tue, Nov 16, 2010 at 9:04 PM, Kaiting Chen kaitocr...@gmail.com wrote:
 
  Honestly if it were up to me I would remove half of the packages from the
  official repositories and stick them in the AUR because past 40 your
  packages start to develop major Quantity over Quality issues and I don't
  think that's what we're going for.
 
  I think this would be a much more constructive conversation if we all
  stopped complaining about the situation and started talking about how to
  improve the AUR. --Kaiting.
 
 That's not a very good argument.
 
 Sergej Pupykin: 1480 packages
 Jan de Groot: 1094 packages
 Andrea Scarpino: 809 packages
 
 They all do an excellent job with maintaining a massive amount of
 packages at one time. Therefore, it obviously can be done without the
 quantity over quality issue that you speak of.

I think he was talking about mere mortals when he wrote that.

Kaiting has a very good point though that much could be done to improve
the AUR making it easier to deal with source packages and maybe other
source based repos in Arch.

Re: [aur-general] Welcome our newest TU, Kaiting Chen!

[Loui Chang]

On Wed 10 Nov 2010 21:27 +1000, Allan McRae wrote:
 On 10/11/10 21:15, Xyne wrote:
 Xyne wrote:
 
 Ok, 5 days have passed. TUs, please cast your votes:
 
 http://aur.archlinux.org/tu.php?id=41
 
 
 The voting period is over. (Sorry for the delayed announcement.)
 
 Yes: 12
 No: 5
 Abstain: 6
 Total: 23
 
 Out of 28 TUs, 28% percent have participated and quorum has been
 established.
 The application is thereby accepted.
 
 28% is not a quorum!  :P

I think Xyne meant 82%.

Re: [aur-general] determining inverse AUR dependencies of binary packages

[Loui Chang]

On Wed 10 Nov 2010 14:05 +, Christopher Brannon wrote:
 Hi all,
 I'll start this discussion with an example of the problem.
 
 I notice that python-sqlalchemy is about to change in [community].
 Most of the packages which depend on it will need to change their
 dependency to python2-sqlalchemy.  This is handled quite nicely for
 packages in the binary repositories.  If you do a package search on
 www.archlinux.org, you'll see which packages require python-sqlalchemy.
 Likewise, it is easy to get a list of [unsupported] packages which
 require a given package from [unsupported].  However, I don't know of a
 way to get a list of [unsupported] packages which require a given
 package from the binary repositories.  If it were possible to build such
 lists, we could contact maintainers of [unsupported] packages, in order
 to inform them of upcoming changes which require their attention.

There is somewhat of a system in place to track dependencies in the AUR.
The AUR creates a hidden dummy packages for dependencies that haven't
already been uploaded. Work needs to be done to make that system more
reliable and accessible though.

Here's an example of a dummy package:
http://aur.archlinux.org/packages.php?ID=23600

Re: [aur-general] Proposal: Mass AUR Cleanup (Discussion Period)

[Loui Chang]

On Mon 18 Oct 2010 17:38 +0200, Jakob Gruber wrote:
  On 10/18/2010 04:10 PM, Stefan Husmann wrote:
 Am 10.10.2010 13:46, schrieb Jakob Gruber:
   On 10/04/2010 11:18 AM, Jakob Gruber wrote:
   In response to Louis objections about skipping the discussion period,

 I'm posting the full text of the proposal below. It has been
 altered from the original text to incorporate Xynes idea of adding
 the 'last maintainer activity rule.
 
 Sorry for making you guys vote twice.
 
 This marks the beginning of the discussion period.

 The discussion period has ended, please cast your votes.
 
 as someone already may have noticed, the voting period for Jakob's
 proposal about mass orphaning AUR packages is over. We had 22 votes
 with two abstains and 20 yes-votes.
 
 I am not sure if Jakob's detection of candidates-script can be used to
 automatically orphan the packages. If there is no autmatical way, we should
 find a way so that this has not to be done by one person. Suggestions?
 
 Seems like my earlier mail got lost somehow, so thanks for posting
 the results :)
 
 The plan was to do this directly on the mysql DB (pending Loui's approval),
 so no manual action should be necessary. I'm going to write the sql
 statements sometime later tonight.

Sorry for the horrible delay. I've just executed this proposal and I'll
attack a list of affected users and packages. Hopefully that attachment
sticks. I was going to send mail to the affected users, but I'm not too
sure how to go about mass emailing after all. If anyone can do that, I
can provide the emails. Cheers!

username

3ED
AlecSchueler
Andrew_NZ
ArchPetr
Baraclese
Black_Codec
Caved
Charlos
ChicoGeek
Cimi
Corsair
Creckx
Damnshock
Echtor2oo3
Erroneous
FaziBear
Filip
Gekko
Githzerai
InYourBase
Insane-Boy
J_Zar
Jack
JackDesBwa
Joekey
Kalidor
Lava Croft
Lava186
Michel
Mr Green
Nelani
OMouse
Operator23
PRAEDO
Pappa
Peter Pan
Raniz
RiceKills
Roberth
RustyNail
Schilis
SickHate
Storyteller
Subspace
Thar
TheThirdGhost
VuLTuRe
Warc3r
WeeDie
a.gambini
abarilla
abcde
adam.ciganek
akirayuki
al
alanger
aquila_deus
arkanoxlab
arooaroo
askadar
atlas95
avalan
b7j0c
bb
bbs
bizthepirate
bparsons
brandemk
bricem13
brynjolf
butze420
cdude
cf8
ch3m4
chori
ciccio.a
crebain
crmaxx
cute_dog
daelstorm
darkcoder
devik
devon
dgsiegel
dice
die-andis
dimaka
dir
djpharoah
dkite
dma147
donri
douglaswth
dr.cranium
eldarion
encrypted
eugeni_dodonov
ferama
festux
fivre
fogoh
freakz
gaara974
ganjolinux
gaston.borysiuk
giahra
gianvito
gondil
grumpytoad
gureito
haole
heidi
holst
hugo
ice799
ignis32
inaoya
jackuess
jerk
jesusfranco
jfryman
jimbo
jmcknight
josephmc
jul1
karreman
kontrast
kopsis
kozzi
kpiche
kru
kuvalski
kwiat
langedb
latz
lburton
litchi
lord
lucas
maclag
margent
martin.ufo
mathgl
mcfock
mebaran
mercurysquad
metzen
mingy
mrunion
mrvw0169
muiro
mxcl
nesl247
nggtony
nice_guy_eddy
nicros
nobange
nochternus
noob
notefinder
originof
pbw
pcarrier
pepakriz
pilli
plutonium
post
prakti
prim
priyank
psartini
pzykopilz
quiet
rfer
rickyc85
rijst
riklaunim
rivierrakid
robb_force
robbel
rooloo
rufius
ruinevil
rwanderley
rxvt
saintshakajin
sashko
sasv
sh__
shofs
silencer
simone
simone.lazzaris
siren
skulk
somm15
lang
stonedz
suw
sysrq
tariX
tebo
tetsuharu
thereidos
thesamet
thor_lin
timtux
tioan
tmaldo
trader
trusktr
tsangpo
turtle
tut
tutkudalmaz
unilogic
unixlust
uptimebox
v2punkt0
violagirl23
wamba
waterbear
wisp
wiwo192
wornaki
xpeppino
yiyus
zabijak

pkgname   link

acpi-eee900   http://aur.archlinux.org/packages.php?ID=18389
amazing-git   http://aur.archlinux.org/packages.php?ID=16319
amule-remote-cvs  http://aur.archlinux.org/packages.php?ID=10606
archfosterhttp://aur.archlinux.org/packages.php?ID=1935
arpalert  http://aur.archlinux.org/packages.php?ID=13835
aspell-ro http://aur.archlinux.org/packages.php?ID=7369
assh  http://aur.archlinux.org/packages.php?ID=19374
asus_oled http://aur.archlinux.org/packages.php?ID=13815
athena-jothttp://aur.archlinux.org/packages.php?ID=5681
autarchy  http://aur.archlinux.org/packages.php?ID=7112
banshee-1-svn http://aur.archlinux.org/packages.php?ID=15961
banshee-alarm-plugin-svn  http://aur.archlinux.org/packages.php?ID=10714
banshee-albumart-plugin-svn   http://aur.archlinux.org/packages.php?ID=10713
banshee-cleanup-plugin-svnhttp://aur.archlinux.org/packages.php?ID=10710
banshee-mirage-plugin http://aur.archlinux.org/packages.php?ID=19007
banshee-mirage-plugin-svn http://aur.archlinux.org/packages.php?ID=13138
banshee-showtrackonchange-plugin  http://aur.archlinux.org/packages.php?ID=10712
banshee-svn   http://aur.archlinux.org/packages.php?ID=8223
bcfg2  

Re: [aur-general] TU Application

[Loui Chang]

On Thu 28 Oct 2010 18:03 +0200, Xyne wrote:
 On 2010-10-27 00:33 -0400 (43:3)
 Kaiting Chen wrote:
 
  Hi aur-general, my name is Kaiting Chen and Xyne has decided to sponsor me
  for my TU application.
 
 /snip
 
 Hi all,
 
 I confirm that I have agreed to sponsor Kaiting. He has the skills and
 motivation to be a good TU and I believe that his interests in particular 
 areas
 will complement the team nicely.
 
 Let the discussion period begin. :)

Awesome.

Re: [aur-general] aur website default ssl

[Loui Chang]

On Thu 28 Oct 2010 18:01 +0300, Ionuț Bîru wrote:
 On 10/28/2010 03:27 AM, Loui Chang wrote:
 On Wed 27 Oct 2010 14:14 +0200, Pierre Schmitz wrote:
 On Wed, 27 Oct 2010 11:40:19 +0300, Ionuț Bîruib...@archlinux.org
 wrote:
 As i said earlier in a reply to Loui, maybe we can do it
 better.Having https only for login and then redirecting to http is
 like not having it at all.
 
 Simply using https for all connections is the easiest and best solution
 imho. Everything in between is either insecure or inconvenient for the
 users. And I also don't see the need for it. Every sane http client
 should handle a http redirect and https. If it does not it's just a bug
 in the client. Of course it is unfortunate that this wasn't tested by
 the clyde author before.
 
 I would appreciate if you consult aur-dev before making changes to the
 AUR. Can you please describe how you made this change, and how we can
 enable normal http?

 seriously, why did you changed it back to http over https?

 in less than 1 day all aur helpers are working again and i don't see
 a reason to use http again. Really, what's the point?

The AUR isn't yours alone to decide how everyone should use it.
That's one reason you should consult aur-dev before making such changes.

SSL will still work. The point is to allow users to make the choice
whether or not they want to use ssl.

That choice was impossible the way it was implemented.

Re: [aur-general] aur website default ssl

[Loui Chang]

On Wed 27 Oct 2010 14:14 +0200, Pierre Schmitz wrote:
 On Wed, 27 Oct 2010 11:40:19 +0300, Ionuț Bîru ib...@archlinux.org
 wrote:
  As i said earlier in a reply to Loui, maybe we can do it
  better.Having https only for login and then redirecting to http is
  like not having it at all.
 
 Simply using https for all connections is the easiest and best solution
 imho. Everything in between is either insecure or inconvenient for the
 users. And I also don't see the need for it. Every sane http client
 should handle a http redirect and https. If it does not it's just a bug
 in the client. Of course it is unfortunate that this wasn't tested by
 the clyde author before.

I would appreciate if you consult aur-dev before making changes to the
AUR. Can you please describe how you made this change, and how we can
enable normal http?

Re: [aur-general] pkgstats and unused [community] packages

[Loui Chang]

On Wed 27 Oct 2010 08:35 -0700, Aaron Bull Schaefer wrote:
 On Tue, Oct 26, 2010 at 6:53 PM, Loui Chang louipc@gmail.com wrote:
  I wouldn't say that. I would say that the only users who matter are the
  ones that participate. For example you can't justly complain about the
  results of an election if you haven't educated yourself about it and
  voted.
 
 The thing is, we're not voting on a single package that we feel is
 better than another package, so we're not looking for informed
 opinions...we're trying to establish objective/accurate usage numbers
 for every single package across all Arch Linux users (or at least a
 statistically appropriate sample of Arch Linux users), which is
 unrelated to people's activity in the community.

Sorry that wasn't meant as a direct example. I'm just saying if people
don't voice what packages are important, then Devs and TUs shouldn't
have to worry about maintaining them so much. The larger community can
maintain them in the AUR. Arch is based on community involvement and
participation. If something isn't done by a TU or dev, then a user
can take the initiative to implement it him/herself. Otherwise don't
complain.

  Let's be clear here. This isn't about removal of packages. It's about
  moving packages from one repo to another. Community to aur/unsupported.
 
 I don't think there's any confusion over these semantics, and I'd
 point out that there's a large difference between moving a package
 from Community to Unsupported compared with moving a package from
 Extra to Community. The fact that Community packages are available by
 default to all Arch users in binary form is a huge plus...the AUR is a
 fantastic resource, but there's no built-in way for users to track
 changes in Unsupported automatically. Also, moving packages from
 Community to Unsupported can be confusing for users who are expecting
 binary updates and don't use a wrapper like yaourt that will tell them
 about the updates after we remove packages from Community.

Indeed, binary packages are quite convenient but I believe that should
be a privilege reserved for the more commonly used packages. It is
unfortunate that we lack a good universal system to track and update
source based packages, but I don't think it necessarily means unused
packages should remain in a binary repo

I expect our savvy users to be able to figure out what's happening,
especially if we ask for their input and announce any moves beforehand.

Re: [aur-general] aur website default ssl

[Loui Chang]

On Tue 26 Oct 2010 23:50 +0300, Ionuț Bîru wrote:
 we are now using default https for aur.archlinux.org. Some aur
 helpers may need adjustment, others like cower/slurpy already works
 as expected.
 
 Kudos for their maintainers for following the aur development

Hmm. How did you go about doing this?
Can you make it possible to visit the site via normal http as well?

Thanks.

Re: [aur-general] pkgstats and unused [community] packages

[Loui Chang]

On Tue 26 Oct 2010 16:36 +0200, Xyne wrote:
 On 2010-10-26 08:20 +0800 (43:2)  Ray Rashif wrote:
  I take back part of what I mentioned earlier. There are indeed some
  packages that I believe no one uses. The best way to handle this is to
  selectively remove each package that we still want to keep from the
  wiki list. I've added a filter list, so remove from there (and not the
  original). Wiki diffs would tell us what has been removed (and by
  whom).
  
  Set up a timeframe along with an official discussion period for this,
  i.e how long we have until the filter list is final. And then the
  voting, if needed.
 
 I can see the point of removing orphans but I still think that using
 pkgstats as a metric is a bad idea for everything else. Casual users,
 i.e. those who are not actively involved on the forum or IRC won't
 even be aware of pkgstats.  Really, who installs a distro and actively
 looks for a way to submit user data?

 And please don't try to tell me that the only users who matter are the
 ones who form the core community.

I wouldn't say that. I would say that the only users who matter are the
ones that participate. For example you can't justly complain about the
results of an election if you haven't educated yourself about it and
voted.

I believe that before any action is taken to move packages back to
unsupported there should be a public notice, and users should be able to
give feedback.

 Several of those packages are niche packages too (e.g. python-sympy,
 vtk, avogadro), but ones that are important within their niche. If
 they are actively maintained then I see no reason to remove them even
 if they are not commonly used by the subset of users who submit stats.
 
 As it stands, I would support removal of the orphaned packages listed
 above but not the list based on pkgstats alone. We need a better usage
 metric for repo packages.

Let's be clear here. This isn't about removal of packages. It's about
moving packages from one repo to another. Community to aur/unsupported.

 Personally I think it would be better to implement a simple online
 vote and inform users that a package is a candidate for removal in a
 post_upgrade or post_install message. Users could then vote to keep
 the package and if it passes a threshold (e.g. 10, as required by
 AUR), then it does not get removed.

Hmm, now that's an interesting idea.
I like the idea of people giving feedback, and voting. I'm not too keen
on putting it in a package's install scripts though.

Re: [aur-general] pkgstats and unused [community] packages

[Loui Chang]

On Mon 25 Oct 2010 19:46 +0200, Xyne wrote:
 Brieuc ROBLIN wrote:
 
  On 25 October 2010 15:06, Florian Pritz bluew...@server-speed.net wrote:
  
   On 25.10.2010 12:35, Christopher Brannon wrote:
I've been polling https://archlinux.de/?page=PackageStatistics
regularly for several weeks, and I've noticed that roughly 50% of the
packages in [community] are not installed by anyone.
  
   The page doesn't show the whole database.
  
   --
   Florian Pritz -- 
   {flo,bluewi...@server-speed.netbluewind...@server-speed.net
  
  
  Is there a way to get the whole database ? Would be cool if we could play
  with the raw statistics from pkgstat ;)
 
 Not all users submit stats so unless Arch installs spyware on
 everyone's system or pools download stats from the mirrors, those
 states are not sufficient to motivate removals.

Well, I've argued in the past that if not enough users care enough to
give feedback to the developers about what they care about in the
distro, either through votes, or pkgstats, or some other way then it's
not something that the devs should have to worry about.

Re: [aur-general] pkgstats and unused [community] packages

[Loui Chang]

 On Mon, Oct 25, 2010 at 10:38 PM, Loui Chang louipc@gmail.com wrote:

  On Mon 25 Oct 2010 19:46 +0200, Xyne wrote:
  
   Not all users submit stats so unless Arch installs spyware on
   everyone's system or pools download stats from the mirrors, those
   states are not sufficient to motivate removals.
 
  Well, I've argued in the past that if not enough users care enough to
  give feedback to the developers about what they care about in the
  distro, either through votes, or pkgstats, or some other way then it's
  not something that the devs should have to worry about.

On Mon 25 Oct 2010 22:35 -0400, Kaiting Chen wrote:
 Can you vote on packages in community? Also wouldn't it make more sense to
 pull the usage data from the download servers?

You can no longer vote on community packages. Pulling usage data from
the mirrors would be pretty tricky. I remembered it being discussed
either on the bug tracker or mailing list. The only option in this case
is pkgstats. I think it would be great to have voting for official
packages though.

[aur-general] New Trusted User: Lukas Fleischer

[Loui Chang]

Hello TUs

With 21 yes, 0 no, and 4 abstains out of 27 active members, we
have a 92.5% quorum and a new Trusted User!

Lukas please follow the steps described in the Trusted User Guidelines
for new members.
http://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#TODO_list_for_new_Trusted_Users

Congrats and welcome!

Re: [aur-general] TU Application: Lukas Fleischer - Voting!

[Loui Chang]

On Sun 10 Oct 2010 21:27 +0200, Lukas Fleischer wrote:
 Hi!
 
 My name is Lukas Fleischer, I'm a 20-year-old student from Germany,
 studying Computer Science at the University of Stuttgart, freelance
 web-developper, IT consultant and hobbyist DJ.
 
 I've been using GNU/Linux for about three years (used OpenBSD and
 FreeBSD before) and Arch Linux probably for about two years. Since then,
 Arch Linux has become my Desktop distribution of choice being installed
 and used on four of my workstations and one server (i686 as well as
 x86_64, one box using [testing] and [community-testing] repos). Besides
 Arch Linux, I'm still using Debian, Gentoo and *BSD as server
 distributions/OS.
 
 I'm a hardcore CLI user (zsh, tmux, mutt, irssi, mplayer, calcurse just
 rock!), experienced programmer (10+ years) specialized in Perl, C and
 Assembly and, as I already said, web-developper (PHP, MySQL,
 PostgreSQL).
 
 As I read about Loui looking for help with the AUR multiple times on
 aur-dev, I thought I'd just give a try and apply for TU. My main
 interests would be to help out with AUR development (just check some of
 the patches I sent to aur-dev) and AUR cleanups (you might e.g. want to
 have a look at aurdupes [1] and some of my mails to aur-general),
 double-check popular AUR packages, and, of course, to maintain a couple
 of packages in [community] including remuco, redshift, tinyproxy, mixxx
 (I'd also like to see xwax in [community] but sadly, it's not really
 popular), pytyle, optionally surf and tabbed and maybe some of the
 OpenSync stuff (I'm still trying to get it work with calcurse and my
 Symbian phone).
 
 I currently maintain 22 packages in the AUR [2] and previously
 maintained some other packages that have been moved to [community] (e.g.
 perl-datetime-format-iso8601, perl-task-weaken, winetricks). You might
 also want to check my archlinux-packages GIT repository [3] which is
 (almost) always up-to-date. If you check some of the PKGBUILDs you might
 notice that I care about consistency and conformity with standards
 (although not all of the packages might stick to that, especially
 virtualbox_bin still looks kinda ugly and contains some legacy stuff).
 I'd really appreciate any kind of positive criticism and improvement
 suggestions as regards that!
 
 Well, if there are any questions left, feel free to ask. And before I
 forget, Loui has agreed to be my sponsor :)
 
 Regards,
 Lukas
 
 [1] https://aur.archlinux.org/packages.php?ID=40869
 [2] https://aur.archlinux.org/packages.php?SeB=mK=cryptocrack
 [3] http://git.cryptocrack.de/?p=archlinux-packages.git;a=summary

The discussion period has ended!
Please vote on Lukas' Trusted User application.
http://aur.archlinux.org/tu.php?id=40

Thanks!

Re: [aur-general] TU Application: Lukas Fleischer

[Loui Chang]

On Sun 10 Oct 2010 21:27 +0200, Lukas Fleischer wrote:
 My name is Lukas Fleischer, I'm a 20-year-old student from Germany,
 studying Computer Science at the University of Stuttgart, freelance
 web-developper, IT consultant and hobbyist DJ.


 As I read about Loui looking for help with the AUR multiple times on
 aur-dev, I thought I'd just give a try and apply for TU. My main
 interests would be to help out with AUR development (just check some of
 the patches I sent to aur-dev) and AUR cleanups (you might e.g. want to
 have a look at aurdupes [1] and some of my mails to aur-general),
 double-check popular AUR packages, and, of course, to maintain a couple
 of packages in [community] including remuco, redshift, tinyproxy, mixxx
 (I'd also like to see xwax in [community] but sadly, it's not really
 popular), pytyle, optionally surf and tabbed and maybe some of the
 OpenSync stuff (I'm still trying to get it work with calcurse and my
 Symbian phone).
 
 Well, if there are any questions left, feel free to ask. And before I
 forget, Loui has agreed to be my sponsor :)

Yep! I fully endorse Lukas' application. He has shown interest in
development of the AUR and seems to be quite aware and skilled in those
areas. I'm really happy someone is finally showing that initiative, and
I would gladly welcome him into the team.