- Aur-general - lists.archlinux.org

Re: [aur-general] aur-general Digest, Vol 49, Issue 17
by Abdul Halim 11 Nov '08

11 Nov '08

The community repository should still exist as there several packages that i use daily or weekly in fact such as amsn, dar, openobex, obexfs, compiz. Please don't remove the repository as i would like to see my daily applications being updated and easily downloaded. There are also some other useful package in community repository that i would like to try and not easily available from the previous distro I use. It is just 3 months that I have use Arch linux and I have yet to exploit the full power and unlimited possibilities of Arch linux. :-( On Tue, Nov 11, 2008 at 9:39 AM, <aur-general-request(a)archlinux.org> wrote: > Send aur-general mailing list submissions to > aur-general(a)archlinux.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://archlinux.org/mailman/listinfo/aur-general > or, via email, send a message with subject or body 'help' to > aur-general-request(a)archlinux.org > > You can reach the person managing the list at > aur-general-owner(a)archlinux.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of aur-general digest..." > > > Today's Topics: > > 1. Re: Packages in Community and votes. (Aaron Griffin) > 2. Re: pkgstats and community - attempt 2 (Ond?ej Ku?era) > 3. Re: pkgstats and community - attempt 2 (Brandon Martin) > 4. Re: pkgstats and community - attempt 2 (Ronald van Haren) > 5. Re: Packages in Community and votes. (Aaron Schaefer) > 6. Re: Packages in Community and votes. (Loui Chang) > 7. Re: Packages in Community and votes. (Aaron Schaefer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 10 Nov 2008 17:05:40 -0600 > From: "Aaron Griffin" <aaronmgriffin(a)gmail.com> > Subject: Re: [aur-general] Packages in Community and votes. > To: "Discussion about the Arch User Repository (AUR)" > <aur-general(a)archlinux.org> > Message-ID: > <d64a48980811101505g3a970bedtaaf399e460ed1da1(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Mon, Nov 10, 2008 at 4:32 PM, Daenyth Blank <daenyth+arch(a)gmail.com> wrote: >> 1) The server is being strained (what parts exactly?) by the community repo. > > It's primarily disk space and IO load issues. > > The community repo and AUR are fairly large. A cron job which WAS > keeping the AUR's permissions in check was actually pegging our system > with so much load that we had to remove any handling of the AUR files > (hope the code is good enough for that). > > The AUR backend daemon opens every single package file (wtf?) when it > runs, which is a HUGE resource hog. In an ideal world, someone would > rewrite this to work the same way the offical repos work - with > repo-add and a separate decoupled script to load the mysql database > from a pacman DB. > > Sizes on disk: > community: 11G > extra: 11G > core: 330M > unsupported: 800M > > > ------------------------------ > > Message: 2 > Date: Tue, 11 Nov 2008 00:17:20 +0100 > From: Ond?ej Ku?era <ondrej.kucera(a)centrum.cz> > Subject: Re: [aur-general] pkgstats and community - attempt 2 > To: "Discussion about the Arch User Repository (AUR)" > <aur-general(a)archlinux.org> > Message-ID: <4918C100.30907(a)centrum.cz> > Content-Type: text/plain; charset=ISO-8859-2; format=flowed > > Hi, > > Allan McRae wrote: >> So lets start there. What should the [community] repo be doing? What >> is its purpose? There is no point discussing anything else until that >> is well defined. >> All responses must start with "The [community] repo is ..." > > The [community] repo is - in my non-dev, non-TU very humble opinion - a > repository for packages that are perhaps not as widely used as those in > [core] or those in [extra] but still used by enough users, so that it's > reasonable to provide them in binary form, providing that there is a way > to do so. I always figured that there is only so many devs and only so > many packages a single dev can maintain, which leads to a limited number > of packages in [core]/[extra]. That's why there are TUs and that's why > there is [community] - so that the number of packages provided in binary > form (by people that hopefully can be trusted) is larger. > > But what I actually wanted most to say was "amen" to your e-mail, Allan, > I think you've summarized feelings of many people... > > Ond?ej > > > -- > Cheers, > Ond?ej Ku?era > > > ------------------------------ > > Message: 3 > Date: Mon, 10 Nov 2008 17:23:43 -0600 > From: Brandon Martin <bmartin(a)cu3edweb.com> > Subject: Re: [aur-general] pkgstats and community - attempt 2 > To: "Discussion about the Arch User Repository (AUR)" > <aur-general(a)archlinux.org> > Message-ID: <afeffc3803b972349e442188e1eae9cf(a)cu3edweb.com> > Content-Type: text/plain; charset="UTF-8" > > On Tue, 11 Nov 2008 00:17:20 +0100, Ond?ej Ku?era > <ondrej.kucera(a)centrum.cz> wrote: >> Hi, >> >> Allan McRae wrote: >>> So lets start there. What should the [community] repo be doing? What >>> is its purpose? There is no point discussing anything else until that >>> is well defined. >>> All responses must start with "The [community] repo is ..." >> >> The [community] repo is - in my non-dev, non-TU very humble opinion - a >> repository for packages that are perhaps not as widely used as those in >> [core] or those in [extra] but still used by enough users, so that it's >> reasonable to provide them in binary form, providing that there is a way >> to do so. I always figured that there is only so many devs and only so >> many packages a single dev can maintain, which leads to a limited number >> of packages in [core]/[extra]. That's why there are TUs and that's why >> there is [community] - so that the number of packages provided in binary >> form (by people that hopefully can be trusted) is larger. >> >> But what I actually wanted most to say was "amen" to your e-mail, Allan, >> I think you've summarized feelings of many people... > > The [community] repo is - > > Very well put this is what I thougth the community repo was for also. > > -- > Brandon Martin > > > > ------------------------------ > > Message: 4 > Date: Tue, 11 Nov 2008 01:17:09 +0100 > From: "Ronald van Haren" <pressh(a)gmail.com> > Subject: Re: [aur-general] pkgstats and community - attempt 2 > To: "Discussion about the Arch User Repository (AUR)" > <aur-general(a)archlinux.org> > Message-ID: > <9fcf70360811101617h422b2615r5abd64eb2b064900(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-2 > > 2008/11/11 Ond?ej Ku?era <ondrej.kucera(a)centrum.cz>: >> Hi, >> >> Allan McRae wrote: >>> >>> So lets start there. What should the [community] repo be doing? What is >>> its purpose? There is no point discussing anything else until that is well >>> defined. >>> All responses must start with "The [community] repo is ..." >> >> The [community] repo is - in my non-dev, non-TU very humble opinion - a >> repository for packages that are perhaps not as widely used as those in >> [core] or those in [extra] but still used by enough users, so that it's >> reasonable to provide them in binary form, providing that there is a way to >> do so. I always figured that there is only so many devs and only so many >> packages a single dev can maintain, which leads to a limited number of >> packages in [core]/[extra]. That's why there are TUs and that's why there is >> [community] - so that the number of packages provided in binary form (by >> people that hopefully can be trusted) is larger. >> >> But what I actually wanted most to say was "amen" to your e-mail, Allan, I >> think you've summarized feelings of many people... >> >> Ond?ej >> >> >> -- >> Cheers, >> Ond?ej Ku?era >> > > IMO all that but without your last argument. Quite some TUs are also > Devs at this very moment, so for the workload for them it doesn't > matter. Still most of the packages they maintain should stay in > community. Packages in community should be there because they are used > by quite some people, but not enough to have them in extra, or > packages that are a hype and have to prove that they are there to stay > before they are put into extra (bmpx in extra comes to mind which > development has stopped after like little over 1 year (?),just an > example to make clear what I mean). Alpha software (for example e17) > should also never be included in extra IMO (though some packages may > not follow this rule if needed). > > Hope it is clear enough, it's already late :p > > Ronald > > ------------------------------ > > Message: 5 > Date: Mon, 10 Nov 2008 19:22:01 -0500 > From: "Aaron Schaefer" <aaron(a)elasticdog.com> > Subject: Re: [aur-general] Packages in Community and votes. > To: "Discussion about the Arch User Repository (AUR)" > <aur-general(a)archlinux.org> > Message-ID: > <e36e8c790811101622oeb928f9q25e3b0d908ba49d7(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > >> It's primarily disk space and IO load issues. > > I have questions, mostly meant to get people thinking about > alternatives and ramifications of any solutions... > > If the real issue is disk space and IO, what about the possibility of > a hardware upgrade? What about moving the largest packages to > unsupported (or something like arch-games) instead of basing it on > votes? It looks like eliminating just the top 10 largest community > packages would save 1.8 GB of space! See > http://rafb.net/p/Xfw0gh39.html for package sizes. What about putting > community on it's own server? What about fixing the AUR backend? What > about adding a CVS commit hook in the mean time to fix permissions on > upload instead of running a single cron job? > > If we make these proposed changes, how will they actually impact the > server and it's current problems? How will they effect Arch users? > What is the price of convenience that the community repo provides to > Arch users? Will there be a way to easily differentiate packages in > unsupported that are actually maintained by TUs? How can we reliably > tell what is popular? Download numbers, voting, pkgstats, etc. all > have their own issues and biases...is there a better way? What makes > the most sense in the long run when there are sure to be more TUs and > packages in community eventually? Should we worry about things that > are currently in community, or just new packages? > > My main point is that there are many options, and any solution that > gets acted upon needs to be based on hard evidence for improvement and > account for all consequences of that change rather than just basing it > on what sounds good. There has been a lot of rabble-rousing and not > much investigation into the underlying problems and proposed > solutions. > > -- > Aaron "ElasticDog" Schaefer > > > ------------------------------ > > Message: 6 > Date: Mon, 10 Nov 2008 20:00:10 -0500 > From: Loui Chang <louipc.ist(a)gmail.com> > Subject: Re: [aur-general] Packages in Community and votes. > To: "Discussion about the Arch User Repository (AUR)" > <aur-general(a)archlinux.org> > Message-ID: <20081111010010.GK1071(a)lynn.lan> > Content-Type: text/plain; charset=us-ascii > > On Mon, Nov 10, 2008 at 07:22:01PM -0500, Aaron Schaefer wrote: >> > It's primarily disk space and IO load issues. >> >> I have questions, mostly meant to get people thinking about >> alternatives and ramifications of any solutions... >> >> If the real issue is disk space and IO, what about the possibility of >> a hardware upgrade? What about moving the largest packages to >> unsupported (or something like arch-games) instead of basing it on >> votes? It looks like eliminating just the top 10 largest community >> packages would save 1.8 GB of space! See >> http://rafb.net/p/Xfw0gh39.html for package sizes. What about putting >> community on it's own server? What about fixing the AUR backend? What >> about adding a CVS commit hook in the mean time to fix permissions on >> upload instead of running a single cron job? >> >> If we make these proposed changes, how will they actually impact the >> server and it's current problems? How will they effect Arch users? >> What is the price of convenience that the community repo provides to >> Arch users? Will there be a way to easily differentiate packages in >> unsupported that are actually maintained by TUs? How can we reliably >> tell what is popular? Download numbers, voting, pkgstats, etc. all >> have their own issues and biases...is there a better way? What makes >> the most sense in the long run when there are sure to be more TUs and >> packages in community eventually? Should we worry about things that >> are currently in community, or just new packages? >> >> My main point is that there are many options, and any solution that >> gets acted upon needs to be based on hard evidence for improvement and >> account for all consequences of that change rather than just basing it >> on what sounds good. There has been a lot of rabble-rousing and not >> much investigation into the underlying problems and proposed >> solutions. > > I've said this already in discussions but I'll say this again. > Fixing the community back end, removing large packages, and removing > unused packages are all possible solutions to the problem. > > If we implement all the solutions, then we get an incremental > improvment. Each solution will build upon the others. We shouldn't only > implement one measure. We should implement ALL measures within reason. > > I only raised the issue of unused or barely used packages in Community > and pruning the repo. We should really be focusing on that before > diverting the discussion and delving into other areas. > > http://wiki.archlinux.org/index.php/Community > > > > ------------------------------ > > Message: 7 > Date: Mon, 10 Nov 2008 20:39:25 -0500 > From: "Aaron Schaefer" <aaron(a)elasticdog.com> > Subject: Re: [aur-general] Packages in Community and votes. > To: "Discussion about the Arch User Repository (AUR)" > <aur-general(a)archlinux.org> > Message-ID: > <e36e8c790811101739g413cc24dvb86c5fa00bc877ae(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Mon, Nov 10, 2008 at 8:00 PM, Loui Chang <louipc.ist(a)gmail.com> wrote: >> I only raised the issue of unused or barely used packages in Community >> and pruning the repo. We should really be focusing on that before >> diverting the discussion and delving into other areas. > > I know we've discussed this in IRC, but again my question is _why_ > should this be the focus? Does it give us the most improvement for the > least effort? Does it inconvenience users the least? Is it the > cheapest? By how much? Is it the fastest? Why? Why? Why? > > I'm open-minded about suggestions, but need something more substantial > to back them up than just saying "we should do this". Where are the > numbers to support the claim? Also, it seems as though the issue of > popularity/voting and the community repo might be altogether different > than the issue of server resources. Are we linking the two together > because of a twist of fate with timing and pkgstats coming to > fruition? > > > Aaron "ElasticDog" Schaefer > > p.s. my link for package sizes will disappear in a day, here's a > better one: http://omploader.org/vd3Vx > -- > > > ------------------------------ > > _______________________________________________ > aur-general mailing list > aur-general(a)archlinux.org > http://archlinux.org/mailman/listinfo/aur-general > > > End of aur-general Digest, Vol 49, Issue 17 > ******************************************* >

2 1

Re: [aur-general] [arch-general] Fwd: [arch-dev-public] pkgstats: first results
by w9ya 10 Nov '08

10 Nov '08

You guys asked for some numbers. Below I both answer Aaron and make a stab at how lousy our data really is. On Mon, Nov 10, 2008 at 2:04 PM, Aaron Griffin <aaronmgriffin(a)gmail.com>wrote: > On Mon, Nov 10, 2008 at 2:44 PM, w9ya <w9ya(a)qrparci.net> wrote: > > If there is a problem with the servers and the load becuase of the > community > > repo, please let's talk about that and how the community can help. I was > > reacting to input that was already forming a basis for using a bot's > output > > to determine and regulate a TU's contribution. Further it was NOT clearly > > pointed out that this was being discussed because of a server/trunk load > > issue UNTIL it was challenged. > > Ok, let me put my entire reasoning quite plainly. > > You think "when the voting was added to the TU system the community > and TUs were SPECIFICALLY told that the voting system would NEVER be > used to make decisions about or demands concerning what any individual > TU decided to add" (which, I might add, I cannot find recorded > anywhere. Would you mind pointing me to some links, please?) > > I think that that's fine, but there is WAY too much garbage thrown > around for no reason other than "oh, I wanted to try this new app, and > put it into community! I stopped using it 3 minutes later, so I > orphaned it" (read: WillySilly). This is unacceptable on the official > archlinux server. It's not in the _spirit_ of the repo. We need SOME > form of metrics, SOME form of control, and we have one. > > So no matter what "TUs were SPECIFICALLY told", I think that's a load > of crap. You will always have people abusing a system. It is my > personally opinion that the voting should matter more to people. If > the voting system is flawed, propose another system. Don't claim "I > should be totally free to do whatever I want on your server" - that > reminds me too much of the Dave Chapelle skit where Rick James puts > his dirty shoes all over the couch. You are not Rick James. I am really trying to understand why you insist on using such limiting an self-depreciating launguage and so forth. I guess to make a point. I wonder about how it reflects on you. In any event; Here are some specifics. There are 11,800 (approx.) registered users and yet the most popular package gets a mere 400 or so votes. Now this is an interesting number as it both represents close to 90 % of the eligible voters AND only 3-4% of the REGISTERED users !! How is this so ? Well, only 500 or so users have downloaded the aurvote package. Further, and this is EQUALLY important to consider, a user can download and NOT be registered at all !! In other words 3 votes can represent a large number (several hundred users). If 3 votes represents many hundreds of users, is having only 2 votes, and let's say a potential of 60 - 150 ACTUAL users ,not a good enough reason to maintain a binary package ? I could go on, but you should be able to understand that before the voting system CAN be used for a metric, it has to reasonably be able to used as such. The current system simply cannot be used as such because the numbers have NO MEANING because they represent nothing of value. Do three votes mean 300 users, or only 10 ? Since we cannot pint to download data, and correlate it to those who(m) vote, and whether those that vote are the most focused users or that they represent the average user, or some other sort of user, you have NOTHING real that can be taken away form the number of votes. Further it should be noted that IF the problem is storage/cpu/networking resources then doing this accomplishes merely a temporary solution, and one that comes with a serious cost that I have touched upon earlier today. I suggest that we look at ways to have a on-going fund raising program to allow for proper resources for the "community" system. *Nothing* I have said above is either new or something that hasn't been said earlier today on one form or another. Yet a proposal has been offered, and ONLY this one proposal has had your support so far today. If you are worried about server resources as an issue Aaron, please let us offer other solutions to you, after all a good fundraising effort was NOT something I saw you get behind or discuss so far, so I am left to wonder if you would support it ? Best regards; Bob Finch P.S... The emails for the TU voting system discussion should be extant for you to view, although I say "should be" in as much as there have been some issues with users, passwords, and presumably other email list storage over the past few years going "south", so to speak. And as you suggest above, your input on this is based on the needs of the future and in previous emails you have declared that that was history, and "stupid: to be discussing as it was "regressive". Of course I disagree with this assessment as history can tell us not only what was promised, but what the reasons are behind previous discussions and courses of action. To be blunt, I also reject the idea that looking backwards is "regressive: and forward is "progressive". As any dictator from the 20th century has ALWAYS done NEW "regressive" things, things called regressive in that such thngs take away prerogatives from the public, all in the guise of "improvement". The results are ephemeral at best, and yes you fell into a trap of using the same language they used, Ala; "progressive".

1 0

Re: [aur-general] Packages in Community and votes.
by Daenyth Blank 10 Nov '08

10 Nov '08

I really don't see a vote thing as a requirement. Consider it a strong suggestion, one that the maintainer is able to break at his or her discretion. Bfinch I think you are overreacting a ton to this.

3 3

[aur-general] Courtesy when moving packages to community
by Allan McRae 10 Nov '08

10 Nov '08

Hi TUs, Following this post on the forums (http://bbs.archlinux.org/viewtopic.php?pid=447186) I would like to remind people that it is good etiquette to let the maintainer of a package in the AUR know when you are moving their package to [community]. Either a direct email, or a nice thank you for their work as an AUR comment. Allan

3 3

[aur-general] Please delete bash_completion_lib
by Henning Garus 09 Nov '08

09 Nov '08

Hi, my package bash_completion_lib is broken and doesnt work like I thought it would, can someone delete it from AUR? Furthermore, while browsing the AUR I stumbled upon the following packages: eclipse-bin: This should be obsolete, now eclipse in extra is the binary version from the eclipse site. eclipse-kde: upstream looks pretty dead. thanks in advance

2 1

[aur-general] TU Application - Ghost1227
by Daniel J Griffiths 08 Nov '08

08 Nov '08

Hello again. For those of you who missed my greetings email, my name is Dan Griffiths and I am a 26-year-old independent contractor in Delaware, US. I have been using one form of *NIX or another for most of my life, wandering through MINIX, RedHat, Mandrake, Slackware, Debian, Gentoo and even two home made distros before finally finding Arch about a year ago. I instantly fell in love with Arch and haven't looked back once. I am currently maintaining 32 packages in the AUR, including one of my own (co-written) scripts. I go by the name Ghost1227 on the bugtracker, AUR, Wiki and on IRC. I have spent the last year getting to know Arch and learning from (as well as trying to assist) the community as a whole, and would now appreciate the opportunity to give something back to that community. Loui Chang (Louipc) has offered to sponsor me, and for that he has my thanks. If you have any questions, please feel free to ask. Dan Griffiths, aka Ghost1227 Apologies if this posts twice, I'm having issues with my email atm...

7 8

[aur-general] disown http-replicator
by Jens 08 Nov '08

08 Nov '08

Hello list, Could somebody please orphan http-replicator? The maintainer isn't responding, and there is a new (although alpha) version of the package which is modular and fixes several fairly important issues when handling ftp transfers. Kind Regards, jensp

3 2

[aur-general] Fwd: Stolen material
by Aaron "Hussein" Griffin 07 Nov '08

07 Nov '08

Hey guys, I just got the email below and want to take this opportunity to point a few things out: Licenses are important. If a project has no license that DOES NOT mean you are able to redistribute it by adding a file that says "Free to use". Just because it is in the AUR doesn't mean we are in the clear. That said, I believe this email is a little silly for three reasons: a) Nothing there is stolen. It is a PKGBUILD. If it is illegal to redistribute the source, then the end user is liable (something we DON'T want). b) The original tarball no longer exists. c) I have seen no proof of copyright. Still, I do want to take this opportunity to point out that we NEED to be more careful here. ---------- Forwarded message ---------- From: Richard Northcott <richard(a)enfour.co.jp> Date: Fri, Oct 31, 2008 at 3:03 AM Subject: Stolen material To: aaron(a)archlinux.org, jvinet(a)zeroflux.org This is stolen copyrighted material. Please remove. http://aur.archlinux.org/packages/stardict-longman/ Richard Northcott Enfour,Inc. Tokyo

11 13

Re: [aur-general] AUR milestone passed
by Loui Chang 07 Nov '08

07 Nov '08

On Fri, Nov 07, 2008 at 03:49:44PM +1000, Allan McRae wrote: > We have just passed 10,000 packages in the AUR (unsupported part). > > Allan It's over nine thousand!

3 2

[aur-general] Gnu/GLOBAL 5.7.3 version
by zhengyi 07 Nov '08

07 Nov '08

Hi, I found the GLOBAL 5.7.3 in GNU. Would you please update your aur ? In the attachment, my PKGBUILD is added. It _maybe_ works, I'm a newbie of this software, and reading doc now. I alwayse don't know the docs policy of Arch. Must I delete docs of a package? Or to build another package only for docs ? Thanks for your PKGBUILD. # Author: timlee tl1234562004.at.yahoo.com> # Contributor: Philipp Robbel robbel(a)gmail.com> # Zhengy Goodme goodmenzy(a)gmail.com> pkgname=global pkgver=5.7.3 pkgrel=1 pkgdesc="A source code tag system" arch=(i686 x86_64) url="http://www.gnu.org/software/global/" license=('GPL') depends=() backup=('etc/gtags.conf') source=(ftp://ftp.gnu.org/pub/gnu/$pkgname/$pkgname-$pkgver.tar.gz) md5sums=('e975983619bae02b63ffc3aae1a645b8') build() { cd $startdir/src/$pkgname-$pkgver ./configure --prefix=$startdir/pkg/usr # here is the docs. # It seems necessary to creat a global-doc pkg instead make pdf html || return 1 make install-info || return 1 install -d $startdir/pkg/usr/share/gtags install -d $startdir/pkg/usr/share/gtags/global.html install -m644 -D doc/global.pdf $startdir/pkg/usr/share/gtags/ install -m644 -D doc/global.html/* $startdir/pkg/usr/share/gtags/global.html/ # compile and install make || return 1 make install # copy gtags.conf and apply patch mkdir -p $startdir/pkg/etc cp $startdir/pkg/usr/share/gtags/gtags.conf $startdir/pkg/etc # symbolic link to gtags.el mkdir -p $startdir/pkg/usr/share/emacs/site-lisp ln -s /usr/share/gtags/gtags.el $startdir/pkg/usr/share/emacs/site-lisp/gtags.el }

3 2