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 .

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

Re: [aur-general] Misconceptions about the AUR?

[Loui Chang]

On Sat 03 Mar 2012 01:15 +0100, Heiko Baums wrote:
> Am Fri, 2 Mar 2012 17:16:16 -0500
> schrieb Loui Chang :
> 
> > 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.
> 
> I'm not wrong, I didn't hijack anything, and I didn't rant. I gave my
> concerns about György's TU application and explained them. Afterwards I
> just answered some not so nice reactions and kept giving my arguments.
> So nothing to be ashamed, nothing to apologise. And, no, I'm not wrong.
> Just because you say so?

Yes. Because I say so. Because everyone else says so. Because you are
one of those imbeciles that don't stop to listen and simply talk over
everyone so that you can only hear yourself shouting.

> Like I already said, give some factual and reasonable arguments. You,
> too, didn't give even one.
>
> > 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.
>
> Also wrong. If a PKGBUILD has no syntax errors does not mean that it is
> valid resp. good. See my example of the package with the `rm -Rf /` in
> its post_install(). This package is totally valid, because it's totally
> valid bash without any syntax errors. This package can perfectly
> uploaded to AUR, is fully supported by AUR and every AUR helper, and can
> flawlessly be installed. Is it a good package, just because it is
> valid and has no syntax errors? Just think about that and think about
> the meaning of quality, quality assurance (QA) and good packaging.

Obviously you don't know the meaning of the word 'valid'. For instance:
I could write a program in C with gotos. It could be perfectly valid,
since goto is a valid instruction, but it might not be pretty, or good
practice, or recommended.

If I put a 'rm -Rf /' command in a script I damned well meant to put it
there. It's a valid command. The script does not magically become
invalid because you don't like what it's doing. If it runs, it's valid.
(permissions errors aside)

> The AUR helpers - all of them - support everything what AUR supports.
> AUR does NOT support split packages. Otherwise such a hackish
> workaround wouldn't be needed. So there's no problem with the AUR
> helpers. Would this be a problem with an AUR helper I would have filed
> a bug report for this.
>
> > 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.
>
> Wrong again. AUR is meant to provide PKGBUILDs so that other people can
> use and install them without rewriting them by themselves. They don't
> parse them only for my convenience, they parse the PKGBUILDs to assure
> that the PKGBUILDs are valid and most likely working.

Lemme see... Do you have any experience writing or otherwise hacking on
an AUR helper, or for that matter the AUR itself? Otherwise how on earth
are you able to declare the intents of its developers? Anyways, no the
AUR was not meant to do your work for you - at least while it was on my
watch.

> > 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.
>
> I know these discussions, and I know the results of these discussions.
> You seem to have forgotten them. And, yes, the result of the discussion
> about implementing support for split packages into AUR, which was
> requested by a lot of people, btw., was that it does not going to be
> supported, because nobody wanted to write the patches. Maybe you have
> missed this discussion.

The issue has been hinted at by Xyne in the previous thread. Your
problem is that your skull is too thick for that notion to seep deep
enough to reach that pistachio nut you call a brain.

Thanks for playing.

[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 :
> 
> > 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 
> sig P65D0FD58 2011-04-19  CA Cert Signing Authority (Root CA)
> 

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: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 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: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 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 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 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 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:
> 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 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  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 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 :
> 
> > On 14 March 2011 10:32, Heiko Baums  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] 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 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 Mon 14 Mar 2011 03:44 +0100, Heiko Baums wrote:
> Am Sun, 13 Mar 2011 19:20:04 -0700
> schrieb Tony C :
> 
> > 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] 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] [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] 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] Upgraded AUR to 1.8.0

[Loui Chang]

On Tue 22 Feb 2011 02:31 +0800, Ray Rashif wrote:
> On 22 February 2011 02:06, Lukas Fleischer  wrote:
> > On Tue, Feb 22, 2011 at 02:03:38AM +0800, Ray Rashif wrote:
> >> On 21 February 2011 18:08, Dieter Plaetinck  wrote:
> >> > On Mon, 21 Feb 2011 10:47:50 +0100
> >> > Lukas Fleischer  wrote:
> >> >
> >> >> The official Arch Linux AUR setup has been upgraded to 1.8.0. For a
> >> >> short list of changes, read [1].
> >> >>
> >> >> Please report any issues on the AUR bug tracker [2].
> >> >>
> >> >> [1]
> >> >> http://mailman.archlinux.org/pipermail/aur-dev/2011-February/001433.html
> >> >> [2] https://bugs.archlinux.org/index.php?project=2
> >> >
> >> > what's the reasoning behind no longer showing all files in the "source
> >> > package"? I found this feature quite useful.
> >>
> >> I've _always_ used this, almost on every package I came across. I
> >> don't want to be downloading anything I just want to take a rough look
> >> at. Would be good to have this back in some way or another.
> >> Brainstorm!
> >
> > Did you read all my replies on this topic? If you still think that this
> > should be implemented no matter what, you'd better open a feature
> > request on the bug tracker.
> 
> You do not really address this issue aside from shrugging it off as an
> unneeded feature that costs one or two vulnerabilities. If it was
> really that useless it would not have been implemented in the first
> place. The loopholes are real, but the feature should not be
> forgotten.
> 
> I will leave it up to the community to file a request to have this
> back, because with that we can really see whether it actually is as
> useful as a few of us claim :)

As another AUR developer I will echo Lukas' statements.
Actually, even if there were no security issues I would support this
change one hundred percent. Functionality needs to be moved to the
clients for the better future of the AUR. Let's not think of the AUR as
a mere webapp. I understand that there will be some growing pains, some
users may not really like or understand why certain changes are being
made. I did anticipate this, and that's one reason why I asked that the
PKGBUILD still be available for easy viewing. Think of it as a
screenshot - it will give you a glimpse into the package but not the
whole idea. You will need to download it for that.

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

[Loui Chang]

On Mon 21 Feb 2011 16:57 +0100, Lukas Fleischer wrote:
> On Mon, Feb 21, 2011 at 10:51:01AM -0500, Loui Chang wrote:
> > On Mon 21 Feb 2011 16:35 +0100, Lukas Fleischer wrote:
> > > On Mon, Feb 21, 2011 at 03:46:47PM +0100, Dieter Plaetinck wrote:
> > > > 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.
> 
> Hm, that doesn't sound too bad. We'd need to integrate this with
> Archive::Tar tho... It might be best to open a feature request on the
> AUR bug tracker at this point.

Voila!
https://bugs.archlinux.org/task/22991?project=2

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  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  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 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  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] [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  wrote:
> > On 2/6/11, Loui Chang  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] [Announcement] First public git repo of the complete AUR.

[Loui Chang]

On Sun 06 Feb 2011 17:19 -0600, Thomas Dziedzic wrote:
> On Sun, Feb 6, 2011 at 4:43 PM, Loui Chang  wrote:
> > On Sun 06 Feb 2011 14:34 -0600, Thomas Dziedzic wrote:
> >> 2011/2/6 Lukáš Jirkovský :
> >> > 2011/2/6 Lukáš Jirkovský :
> >> >>
> >> >> 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.
> 
> So PKGBUILDs aren't going to be able to be viewed?

Yes they will, but not the other files.

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ý :
> > 2011/2/6 Lukáš Jirkovský :
> >>
> >> 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] new aur mirror

[Loui Chang]

On Thu, Jan 27, 2011 at 1:23 PM, keenerd  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 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 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 

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

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

[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] [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 12/30/2010 12:36 AM, Brad Fanella wrote:
> >On Dec 30, 2010, at 12:11 AM, Nathan Owens  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] 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 :
> 
> > 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 17:15 +0100, Seblu wrote:
> On Sun, Dec 19, 2010 at 4:58 PM, cantabile  wrote:
> > Le 19/12/2010 17:55, Seblu a écrit :
> >>
> >> 2010/12/13 Cédric Girard:
> >>>
> >>> On Mon, Dec 13, 2010 at 10:40 AM, Stefan
> >>> Husmann >>> 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] 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 Girard:
> >>On Mon, Dec 13, 2010 at 10:40 AM, Stefan Husmann >>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 16:55 +0100, Seblu wrote:
> 2010/12/13 Cédric Girard :
> > On Mon, Dec 13, 2010 at 10:40 AM, Stefan Husmann  > 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] 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  wrote:
> > > On 12 December 2010 11:39, Loui Chang  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_Amendment&oldid=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=23730&O=&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] 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_Amendment&oldid=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] 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] 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  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] 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  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] [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  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] [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_Amendment&oldid=124479

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

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  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 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] 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] 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] [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  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] [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
> wrote:
> 
> > 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] 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] Tarball Guidelines

[Loui Chang]

On Tue 07 Dec 2010 03:58 +0800, Ray Rashif wrote:
> On 6 December 2010 22:47, Dave Reisner  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] [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 
> wrote:
> > This proposal clarifies the Standard Voting Procedure, and allows
> > another condition for passing a motion.
> > 
> > Signed-off-by: Loui Chang 
> > ---
> >  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 @@
> > 
> > Trusted User Bylaws
> > 
> > -   May 21, 2008
> > -   1.1
> > +   2010-12-05
> > +   1.2
> > 
> > 
> > Trusted Users
> > @@ -79,9 +79,12 @@
> > 
> >  
> > 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. 
> 
> 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] 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] 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] 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] Fix the Bylaws?

[Loui Chang]

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.

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  wrote:
> 
> > This proposal clarifies the Standard Voting Procedure, and allows
> > another condition for passing a motion.
> >
> >
> >Trusted Users
> > @@ -79,9 +79,12 @@
> >
> >
> >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.
> >
> 
> 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.

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

[Loui Chang]

This proposal clarifies the Standard Voting Procedure, and allows
another condition for passing a motion.

Signed-off-by: Loui Chang 
---
 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 @@

Trusted User Bylaws

-   May 21, 2008
-   1.1
+   2010-12-05
+   1.2


Trusted Users
@@ -79,9 +79,12 @@

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

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  wrote:
> > > 
> > > > On Sun, Dec 5, 2010 at 11:16 AM, Kaiting Chen 
> > > > 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] Amendment

[Loui Chang]

On Sun 05 Dec 2010 14:40 -0500, Shacristo wrote:
> On Sun, Dec 5, 2010 at 2:32 PM, Xyne  wrote:
> > Shacristo wrote:
> >
> >> > 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.
> >
> > Um, "votes > TUs * quorum" is the same thing as "votes / TUs > quorum".
> >
> > There is no difference between voting "no" and "abstain" currently.
> > The simple majority is counted by dividing the number of "yes" votes
> > by the total number of users that have participated, including those
> > who "abstain".
> >
> > I agree that there should be a difference between "no" and "abstain", but I
> > didn't write the bylaws and I have proposed alternatives that would draw a
> > distinction before, although I don't remember what.
> 
> Ah, you are correct, I missed the division there.
> 
> I agree that a strict reading of the bylaws treats 'abstain' the same
> as 'no' despite people interpreting them to be different.  Perhaps the
> wording should be changed now while everybody is looking over the
> bylaws.

Well as far as I can interpret it the bylaws don't actually say what
abstain means, so it could mean anything: yes, no, or pineapple.
Nor does it define what a simple majority is uhhh.

Ambiguity abounds. The bylaws should be made clearer. If we read them
carefully I hope we're clever enough to understand their intention as
they are right now though.

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  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 14:23 -0500, Shacristo wrote:
> On Sun, Dec 5, 2010 at 2:20 PM, Xyne  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] Amendment

[Loui Chang]

On Sun 05 Dec 2010 11:53 -0500, Kaiting Chen wrote:
> On Sun, Dec 5, 2010 at 11:33 AM, Shacristo  wrote:
> 
> > On Sun, Dec 5, 2010 at 11:16 AM, Kaiting Chen 
> > 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] 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  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] 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] 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] 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.

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

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 Chang  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 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] 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  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] AUR helpers in [community]?

[Loui Chang]

On Fri 19 Nov 2010 04:43 +0800, Ray Rashif wrote:
> On 18 November 2010 16:30, Kaiting Chen  wrote:
> > Can AUR helpers go into [community]? `burp` and `cower` each have
> > over ten votes and qualify, but I never see AUR helpers in binary
> > form so I thought I would ask. --Kaiting.
>
> So, IMO, it is best that such tools, regardless of the extent of
> features, be left in AUR. I myself use slurpy for upload, and rarely
> do I use the search/download features :)

I agree. Keep the AUR tools in the AUR where they belong.

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] 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] [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  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] What to do about raggle?

[Loui Chang]

On Tue 16 Nov 2010 21:38 -0500, Kaiting Chen wrote:
> I'm maintaining raggle in [unsupported] and it seems to be broken despite my
> attempts to patch it as best I can. The project has been abandoned upstream
> since 2005, and I don't think ruby-ncurses which it depends on really even
> works. I would delete it except that it has 75 votes. What to do?

I'd encourage you to leave it, maybe orphan it if you're no longer
interested in tinkering with it. Someone else may come along and have
greater success.

Cheers!

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 :
> 
> > 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] 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

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] 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] 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îru
> >>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] 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.