- Aur-general - lists.archlinux.org

[aur-general] can't upload [community] packages
by Ronald van Haren 05 Dec '08

05 Dec '08

I can't image I changed something on both my build partitions without noticing it, but I can't seem to upload packages into the [community] repo. The PKGBUILDs are updated though (and no error is printed). Anybody else having issues uploading ? Ronald

4 3

[aur-general] 64bits Sun's Java Plugin
by Kessia 'even' Pinheiro 05 Dec '08

05 Dec '08

Hi all, Me and my friend Paulo made a Sun's java plugin with jre for x86_64 arch. This is for solve problems with some authentication systems, like our most famous public Brazillian Bank. So, we made a tutorial and published in english to help the international project. I'm fixing some english phases yet, but i think you can undestand well. Any doubts you can ask. http://even.archlinux-br.org/blog/64bits-suns-java-plugin-with-jre-for-arch… -- Kessia Pinheiro Student at Computer Science - UFBa Trainee with ProCaTI founds - DiSup/CPD - UFBa Arch Linux Trusted User Linux Counter User #389695 - [http://counter.li.org] http://even.archlinux-br.org --- X Fórum Internacional Software Livre - fisl10 24 a 27 de junho de 2009 PUCRS - Porto Alegre - Brasil

3 2

Re: [aur-general] Proposed rules for packages entering [community]
by stefan-husmann＠t-online.de 05 Dec '08

05 Dec '08

-----Original Message----- > Date: Mon, 01 Dec 2008 04:27:33 +0100 > Subject: [aur-general] Proposed rules for packages entering > [community] > From: Allan McRae <allan(a)archlinux.org> > To: "Discussion about the Arch User Repository (AUR)" > <aur-general(a)archlinux.org> > Hi all, > > As part of the TU meetings it was decided to post the proposal for > restricting packages entering [community] here for discussion before > voting. Here is the current wording: > > [proposal] > > * Only "popular" packages may enter the repo, as defined by 1% usage > from pkgstats or 10 votes on the AUR. > > * Automatic exceptions to this rule are: > - i18n packages > - accessibility packages > - drivers > - dependencies, including makedeps and optdeps > - packages that are part of a collection and are intended to be > distributed together, provided the primary part of this collection > satisfies the definition of popular > > * Any additions not covered by the above criteria must first be > proposed on the aur-general mailing list, explaining the reason for > the exemption (e.g. renamed package, new package) at which point a > general consensus from the TUs will be reached. TUs with large numbers > of "non-popular" packages are more likely to be rejected. > > * TUs are strongly encouraged to move packages they currently maintain > from [community] if they have low usage. No enforcement will be made, > although resigning TUs packages may be filtered before adoption can > occur. > > [end proposal] > > > So, go ahead and discuss. Especially focus on the wording and regions > that people would feel need clarification before I call for a formal > vote. In particular, I think the process for addition of packages > which do not meet the popularity criteria needs to be defined better, > so any ideas there would be appreciated. > > Any further additions to do with cleaning the current package load in > [community] for low usage package is a separate issue and will be > discussed at a later date. > > Allan > > Hello, sorry, something must be wrong with my IRC-environment or with my knowledge about it. Again I did not manage to join. So let me discuss the proposal here. First I have some questions. What are accessibility packages? Things like ssh? > - packages that are part of a collection and are intended to be > distributed together, provided the primary part of this collection > satisfies the definition of popular To whose intention do you reflect here? I guess to upstreamer's intention? I think of the texlive-doc packages here I maintain in community. >TUs with large numbers of "non-popular" packages are more likely to be rejected. Do you mean that? Or should it be"packages of TUs with large numbers of "non-popular" packages are more likely to be rejected."? Some thoughts. - If we encourage people to drop packages that are not popular, we should also encourage them to take packages in "usupported" that _are_ popular to "community". - What if there are popular third party repos with packages? Should this give an impact on our decision to put these packages to community or not? - The benefit for the user of packages being distributed in binary form varies. I.e. a package with low complexity or no compile time could easily stay in AUR even if it is popular. Just my 2 cents, regards Stefan

15 34

[aur-general] Donations and upgrades
by Aaron Griffin 04 Dec '08

04 Dec '08

On Thu, Dec 4, 2008 at 12:40 PM, w9ya <w9ya(a)qrparci.net> wrote: > If you guys put > the same vigor and effort into promoting a fundraising effort, you would > have the resources to host all manner of binary packages MUCH AS OTHER > DISTROS DO WITHOUT A NEED TO CULL OUT THINGS AS A FIRST STEP. And it's really that easy, is it? Do you know I have to pay taxes on our donation money? We're not a non-profit organization. You can't just donate to a person and make it a tax writeoff. There's many many things in there that I think you're missing. More to the point, it takes EFFORT from people. The last upgrade took a lot of Dale's, Dan's, and my time. It's easy to sit on the outside and say "It's easy! Just do this!". There are many many hurdles. Throwing money at a problem isn't the way to fix it.

3 11

[aur-general] are ${pkgname}.install files source files?
by kludge 04 Dec '08

04 Dec '08

should i include them in the source= array and provide md5 sums for them? -kludge

2 1

Re: [aur-general] Proposed rules for packages entering [community]
by Drew Frank 04 Dec '08

04 Dec '08

On Thu, Dec 4, 2008 at 10:27 AM, Drew Frank <ajfrank(a)ics.uci.edu> wrote: > On Thu, Dec 4, 2008 at 10:23 AM, Aaron Griffin <aaronmgriffin(a)gmail.com> wrote: >> On Thu, Dec 4, 2008 at 12:20 PM, Drew Frank <goodgrue(a)archlinux.us> wrote: >>> I do this all the time as well. One possible solution: if an "I use >>> this!" message were sent to the stat-tracking server automatically >>> from pacman upon installing a package, it would not be much of an >>> extension to send a "Oops, not anymore" message when it is >>> uninstalled. Thoughts? >> >> That's (a) a breach of privacy and (b) something that would never get >> integrated into pacman. >> >> The pkgstats server doesn't keep track of user info. THe old archstats >> did, but we have proven time and time again that no one ever uses >> archstats.... we've had it for ages, have you ever used it? >> > > Nope, I've never heard of archstats =p. Maybe it could be integrated > into yaourt, if not pacman. I know aurvote already is, but perhaps it > could be just made automated unless a user specifically opts-out. > Also, maybe anonymous usage info could be allowed from those users who > don't have AUR accounts. It could be treated differently (as less > reliable) but would probably be better than nothing. Would that > address the breach of privacy issue? > Also, if my ideas are so off-base as to just be a waste of time, feel free to tell me so =)...I certainly don't want to make this process any harder for you all than it already is. Drew

2 1

Re: [aur-general] Circle that A
by kludge 04 Dec '08

04 Dec '08

Aaron Griffin wrote: > Keep that in mind - the people > doing work *for you* to make your lives easier, want some moderation > on this system before it gets out of hand. People will *always* abuse > a system with no rules. wow, can't believe this thread is still running on this subject line. back to my original intent: i think it's entirely fair (and often *necessary*) to establish concrete systems to regulate the use of shared resources. and of course those most familiar with the whys and wherefores of these resources should get special consideration for their intimate knowledge of the challenges to hand. that said, if the holders of the reins have already decided how to proceed, they should go on and proceed. if they want the input of the affected community, it's dishonest to dismiss that input. we're debating how to use the available metrics to tune the management of [community]. there is an outstanding and unanswered concern with the accuracy of those metrics. it seems to me that folks will not be happy with the proposal until that concern is resolved. so can anyone either (concretely) answer that concern or (concretely) propose better metrics? -kludge p.s: i'm participating in the hopes of facilitating actual consensus on this. if that's not welcome, let me know and i'll sod off.

1 0

[aur-general] can't update my packages?
by Amanai 04 Dec '08

04 Dec '08

Could not create incoming directory: /srv/http/sites/aur/unsupported-temp/68181228389746 Please one TU update

4 4

[aur-general] cannot update emacs-org-mode
by Jiyunatori 04 Dec '08

04 Dec '08

Hi there. Because of this message, I'm directly writing to you : http://archlinux.org/pipermail/aur-general/2008-December/003066.html I can't update office/emacs-org-mode : > Could not create incoming directory: > /srv/http/sites/aur/unsupported-temp/88991228392678. Jiyunatori

3 2

Re: [aur-general] Proposed rules for packages entering [community]
by Loui Chang 04 Dec '08

04 Dec '08

On Wed, Dec 03, 2008 at 08:31:05PM -0600, kludge wrote: > >> but i don't. if it's explicitly installed, it's because i wanted the > >> damn thing. > > > > That's good. I occaisionally download apps to try them and remove them > > soon after. Those are packages I would not vote on. > > > > Don't tell me you haven't ever done that. > > fair enough. > > what about votes:downloads, accompanied by a big push to get people voting? This proposal should be the signal that we are going to start taking votes more seriously, but no packages will be removed for now. > (btw, as a result of this debate, i'm finally voting for the packages i > use.) Good to hear! Here's a little script to help figure out what's installed from a particular repo. Use `repo-installed community` for [community], etc. This'll help people figure out what to vote for. #!/bin/bash # Print a list of packages installed from a given repo. # # Not everything will be listed if your installed packages # are out of date. # # This will work for most standard installations. # If you have an exotic setup just edit pacmandb. # # Usage: repo-installed <repo> pacmandb=/var/lib/pacman if [ -z "$1" ] ; then echo "Please specify a repo." echo -e "\tUsage: $0 <repo>" exit 1 fi installed=($(/bin/ls "$pacmandb/local")) for pkg in ${installed[@]} do if [ -e "$pacmandb/sync/$1/$pkg" ] ; then echo $pkg fi done

1 0

[aur-general] Server side community changes
by Aaron Griffin 04 Dec '08

04 Dec '08

I fiddled with some of the community daemons on the server side, mainly changing permissions, log locations, and things of the sort. If anyone has any issues, poke Dan or myself about it, and we can fix it.

1 0

[aur-general] TU's please update your packages!
by Amanai 04 Dec '08

04 Dec '08

pizzapunk = acroread, filezilla, wxsvg, vegai = warzone thank you

1 0

Re: [aur-general] Direct attack on Bob
by Grigorios Bouzakis 03 Dec '08

03 Dec '08

On Wed, Dec 3, 2008 at 9:46 AM, Allan McRae <allan(a)archlinux.org> wrote: > Grigorios Bouzakis wrote: >> >> <tl:dr> >> > > This is becoming a direct attack on Bob here. I could probably go through > anyones packages in [community] and find something that could be improved > (except mine - because I am perfect.... ). But it is not productive in > anyway. I did not bother reading much beyond that. > > Anyway, if people are going to rant on a different topic than that in the > subject line, change it to something more appropriate. Anyway its not like that. Its never been. This is the last you will hear from me at least your discussion is over. I meant to write that on the prvious mail but forgot. Take care Greg

1 0

[aur-general] Hello!
by Aaron Griffin 03 Dec '08

03 Dec '08

Just wanted to send a hello to the list, and see how everyone is doing. I've noticed a lot of negative emails being thrown around, so I figured I'd lighten the mood with a humerous image. http://img.phraktured.net/funny/tldr.jpg So how was your day?

4 4

Re: [aur-general] pkgstats and community - attempt 2
by w9ya 03 Dec '08

03 Dec '08

Here are the short answer to your questions/comments/reflections from below. - I have already answered, on the 29th, with a lengthy list of consequences. Some people have said the list is too long to read through !! - I have already (in previous emails) pointed out that these very issues **were** discussed in the adoption of aurvotes and in the matters concerning sergej. On other occasions there have been TU discussions about other restrictions based on numbers of packages and appropriateness of whether TUs should be asked to submit packages for approval. - As has already been discussed in the past couple of weeks, there is NO basis for any statistical standard. Your trust in Allan is noted, but even he has not come out and discussed any particulars. I would like to see the system proposed BEFORE I am asked to vote on its' acceptance. - As has already been pointed out; NO ONE is suggesting waiting until the last gasp (or last breath) of a resources issue. The engineer joke was cute, but it IS over the top also. - In fact there is NO resource issue. The folks in charge of such thing have commented in just the past few days as much. In fact they have pointed out that there is no looming issue either; not even in the not-so-near future. - There are other alternatives, a few of which have been suggested in the past few weeks. It would have been nice if these had been acknowledged. -FINALLY, by removing 10% or so of the programs in community, how do we SOLVE a resources problem that will not come up again within a few short months ? Then what, a 20% reduction ? *** You see the REAL problem is that this is a poor way to solve a resources problem. More effort AND expense and so forth than simply spending a small amount of money and beefing up some hardware. Regards; Bob Finch On Tue, Dec 2, 2008 at 5:40 PM, James Rayner <iphitus(a)iphitus.org> wrote: > On Wed, Dec 3, 2008 at 9:33 AM, w9ya <w9ya(a)qrparci.net> wrote: > > (This should NOT require a reply, as it is merely some short > observations.) > > > > Hey Allan and those who are still bothering to read all the emails on > this; > > > > I decided to review some of the early emails leading up to your current > > proposal to modify the 'community' repo and how it is used. And I found > this > > thread you forked and it seemed like a good idea to write you this > personal > > but public reply. I am quoting your email in it's entirety below. I am > going > > to ask you to do something at the end of this message, and I hope you > have > > the courage and foresight to read through this email twice. I will NOT be > > mincing words, because quite frankly now is not the time to do so. > > I've read it twice. > > > But most importantly I can answer your concerns about server/system > loading > > this way; It is not a concern because the folks that are in charge of > > maintaining such things say it is not a concern, and this just two days > ago > > in another email thread about 'what belongs in the community repo'. > Further, > > when things in the past have gotten overloaded, they have been fixed by > more > > direct means than what you are asking about. i.e. Servers are upgraded, > > software is upgraded, connections and so forth are improved. > > While size is presently not an issue, Arch will grow, [community] will > grow, and I think it's prudent to consider Allan's suggestions. > > Back when the original TUR repositories existed, the TU's then used > them respectfully. Packages tended to be of a popular nature, and no > TU maintained an excessive number of packages. I recall I used your > repo a great deal. > > Since then we've seen at least one situation where this trust has been > abused. If you remember WillySilly, who added literally every package > he built to the repositories. I don't recall how many he ended up > maintaining, but it was over 500. When he disappeared, that left 500 > unmaintained packages. Many of them were of questionable value, some > poorly packaged. > > As Arch's grown, we now have x86_64. This adds a new requirement - > most packages need to be built twice. This effectively doubles the > requirements for maintainers. WillySilly's over 500 questionable > packages, becomes over 1000. We have always dealt with these problems when they came to our attention with needing to "think ahead" and so forth. When quality and server issues became apparent. we dealt with them. Why do we suppose we are not up to task now ? > > > This isn't about server resources, it's about _efficient_ use of both > maintainer and server resources. Resources are scarce, if we have a > temporary excess we shouldn't go blow it - we'll regret it later. Again, this has always been dealt with in the past and there is NO reason to suppose we cannot in the future. > > > Consider my package NPPAngband. Recently in the census it became > clear, and not surprisingly, that there's very few users. It's an > awesome little game though (don't go install it, it's broken atm). At > first my reaction to removing it was negative, like yours. I thought > that there should be some allowance for 'pet' packages of questionable > value. After considering this, it became clear that this was a > somewhat selfish view. I struggle to find any real justification to > keep it there. The extra use of maintainer time and server resources > don't justify the insignificant number of people who use it and nobody > would mind at all if I moved it back to the AUR where it belongs. O.k. and that is your decision. Since I knwo some of my packages do not receive any votes yet are used by dozens of people that have NOT placed aurvote unto there machines, including those who use DIRECTLY the archlinux install, I already know that your program mightbe used by many more people htan you suspect. In fact much of my current repo is used by ham radio operators that are not interested in fiquring out how to install yaourt of aurvote and so forth. They jsut want a tool.. It is a BIG community that Arch should ignore because of a lfawed voting and statistical package that cannot be counted on to yeild useful data ? > > > > THE REAL QUESTION you are asking about is whether such a restriction and > > fundamental change makes sense. And the answer is, once again as it has > been > > several times in the past years, NOT A NEW ITEM to vote upon. This > question > > comes up quite regularly for the TUs to vote upon. > > I recall no situation in the last 3 years where a baseline requirement > for package popularity has been voted. I said, as you quoted above "restrictions" . You speak about "baseline requirements". I stand by my statement. And yes we did vote on whether someone should be allowed to enter certain things into the repo in the past. In fact the discussion/cum vote on whether sergej should be alowed to maintain his pacakges WAS a vote on "baseline" issues. That was recent too. > > > > You see Allan, the TU system is an experiment that can be found NO WHERE > > ELSE in computing I am aware of. NOWHERE else can a group of users be so > > involved and with the freedom to contribute as we, (individually OR in > > groups,) find it useful to do so. ONLY with this CURRENT system. We have > > ALWAYS sought to create the most freedom herein so we could get the most > > benefit. Quite frankly your proposal seeks to replace this with a system > of > > rules for inclusion and voting for exceptions and one TU seeking the > > approval of other TUs before adding something and so forth. This is a > > FUNDAMENTAL change in the way things are. And the is NO GOOD reason to do > > so. You have been given several weeks to outline why, and you have yet to > do > > so. Some future resource problem is not a good enough reason. And yes we > > HAVE discussed this very issue in past voting on other proposals. > > I can't see how this proposal 'destroys' the TU system as you imply. > The vote requirement suggested by Allan is extremely low - it's > trivial for a package to get 10 votes. It is a fundamental change for the reasons discussed inthe paragraph you quote above. I have NEVER seen fundamental changes such as these that do NOT lead to what I described. > > > > I want you to consider that we ALSO have been seeing some rather elitist > > behavior from those supporting your proposal too. It has been rather well > > established that there is no way to know what even a vote of 0 > represents, > > let alone ANY number. Yet I have seen MANY messages talking about the > > "useless glut" of programs in community, and that if someone does not > vote > > they do not "count" and what packages they use should not be "considered" > > for what programs are "allowed" to be in the community repo". Well if you > do > > not know what people are using, how can ANYTHING be either "useless" or > part > > of a "glut". All of this should be a concern to you. IS this what you > want ? > > Are you so fed up with the way things are now that you are willing to be > a > > part of such a disreputable thing ? > > Allan is a professional statistician. He's qualified to analyse data > sets. We have a data set in pkgstats. If Allan believes there is a > correlation between votes and pkgstats package usage, I am more than > happy to take his professional opinion. Then I am sure Allan will be happy to show us the statistical analysis and stand by it. To date that has nto happened. Instead what has happened in people on BOTH sides of this discussion have pointed out the manner and amoutn of error inthe surrent pkgstats and aurvotes. In some of these emails it has become clear that even as little as 3 votes can mean 3 or severla humndred actual suers. And we do NOT know which of those number extremes is most likely either. > > > > Quite simply, are you willing to let Archlinux remove the ONLY unique > thing > > that separates it from other *nix distros. Are you willing to be a part > of > > turning the "community repo and the TU/Aur system" into something that > only > > a majority can decide what will be in it, when there is now space for all > to > > contribute ? > > 10 votes is not a majority - it's an insignificant number of votes. > It's effectively 9, as the packager can vote himself. > > This is a pythonic 'ask for forgiveness' situation, rather than 'ask > for permission' as you describe. If a TU believes he can justify a > packages place within the repository, then there's no issue with him > adding it. The TU makes the decision, not the masses. Our system, as you know, is NOT one of asking someone else;'s permission. It is unique and has worked well. It has not failed. Your saying the TU makes a decision with the new proposal is wrong He gets to sak and others make the decision. > > > > So I will leave you with this comment; Please do not seek to "fix" > something > > that is NOT BROKEN. > > As easy as that cliche is to use, it doesn't always apply. Would you > prefer that airlines wait for aircraft to break before they consider > maintenance? I think in this situation we're really trying to avoid > future problems with excessive growth. > > Engineer: Wing spar's not broken yet! My calculations say that it > might have one more flight left in it! Good to go! Nonsense and you know it. No one is saying it is on the brink of failure or even close. In fact the folks here at archlinux that maintain the systems say there is no problem now and there is PLENTY of room for storage and growth. > > > > It is a fool's errand, and you will not be able to > > moderate or contain any unintended consequences from your actions any > better > > than you have been able to contain any of the poor behavior your proposal > is > > creating. > > What consequences do you speak of? You've mentioned these, but failed > to outline what how these unintended consequences of Allan's proposal > would manifest themselves. Yes i have. I got some nasty mail in reply too. A few days back, definately inthe past 8 days or so. Someone else asked and I answered this in quite some detail. It was not complete as there are MANY such issues and consequences. > > > > Your message that I quoted below begins with your concern about > > things getting out of hand. I hope you reconsider your proposal. > Rescinding > > it now would show real courage and understanding; Wisdom beyond your > years, > > so to speak. > > Wisdom or just another manifestation of Clarke's first law? > > > Best regards; > > Cheers! > > James > Bob F.

1 0

[aur-general] Please remove the followings from AUR
by Yufei Chen 03 Dec '08

03 Dec '08

Hello, I'm the maintainer of UCIMF suites (including libucimf openvanilla ucimf-openvanilla and ucimf-fbterm), however, the package names are wrong for the reason that UCIMF currently is distributed via SVN. So it will be better in appending -svn after each. Sorry for this mistake but could you please remove these packages and I will upload svn devel PKGBUILDs later. libucimf http://aur.archlinux.org/packages.php?ID=21330 openvanilla http://aur.archlinux.org/packages.php?ID=21332 ucimf-openvanilla http://aur.archlinux.org/packages.php?ID=21331 ucimf-fbterm http://aur.archlinux.org/packages.php?ID=21333 Thanks! AndyWxy

2 1

[aur-general] Fwd: AUR Out-of-date Notification for asciidoc
by Dan McGee 03 Dec '08

03 Dec '08

Any TU's want to maintain AsciiDoc? It is really easy, I just want to drop my 1 package I keep in community. Just steal it if you want to adopt it, first-come first-serve. -Dan ---------- Forwarded message ---------- From: <aur-notify(a)archlinux.org> Date: Sat, Nov 29, 2008 at 3:58 AM Subject: AUR Out-of-date Notification for asciidoc To: dpmcgee(a)gmail.com Your package asciidoc has been flagged out of date by bwalle. You may view your package at: http://aur.archlinux.org/packages.php?do_Details=1&ID=2307

1 0

Re: [aur-general] [arch-general] opensp compile fails
by Daenyth Blank 03 Dec '08

03 Dec '08

On Tue, Dec 2, 2008 at 20:33, Baho Utot <baho-utot(a)columbus.rr.com> wrote: > > OpenSp PKGBUILD fails to compile with the following error: > > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../generic -march=native -O2 -pipe -fomit-frame-pointer -c > ArcEngine.cxx -MT > ArcEngine.lo -MD -MP -MF .deps/ArcEngine.TPlo -fPIC -DPIC -o .libs/ArcEngine.lo > In file included from ArcEngine.cxx:20: > ../include/InternalInputSource.h:37: error: extra > qualification 'OpenSP::InternalInputSource::' on > member 'asInternalInputSource' > make[3]: *** [ArcEngine.lo] Error 1 > make[3]: Leaving directory `/home/scrat/ARCH/opensp/src/OpenSP-1.5.1/lib' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/home/scrat/ARCH/opensp/src/OpenSP-1.5.1/lib' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/scrat/ARCH/opensp/src/OpenSP-1.5.1' > make: *** [all] Error 2 > ==> ERROR: Build Failed. > > It looks like it is orphaned so > > Here is a patch to fix this: > > cat InternalInputSource.patch > > --- OpenSP-1.5.1~/include/InternalInputSource.h 2003-07-17 > 14:14:00.000000000 -0400 > +++ OpenSP-1.5.1/include/InternalInputSource.h 2008-11-13 > 12:24:04.591406546 -0500 > @@ -34,7 +34,7 @@ > void pushCharRef(Char ch, const NamedCharRef &); > Boolean rewind(Messenger &); > const StringC *contents(); > - InternalInputSource *InternalInputSource::asInternalInputSource(); > + InternalInputSource *asInternalInputSource(); > ~InternalInputSource(); > private: > InternalInputSource(const InternalInputSource &); // undefined > > Here is a patch file for the PKGBUILD > > cat PKGBUILD.patch > > --- PKGBUILD 2008-12-02 20:27:40.102778984 -0500 > +++ pkgbuild 2008-12-02 20:27:29.412780668 -0500 > @@ -15,6 +15,7 @@ > cd $startdir/src/OpenSP-$pkgver > pwd > patch -Np1 -i ../opensp-gcc34.patch || return 1 > + patch -Np1 -i ../InternalInputSource.patch || return 1 > ./configure --prefix=/usr \ > --disable-nls \ > --enable-http \ > If it's orphaned in the AUR, simply adopt it and update it with your fixes.

1 0

[aur-general] Orphan request: nestopia gens yabause
by Tiago Pierezan Camargo 03 Dec '08

03 Dec '08

Hi, Those packages (nestopia, gens, and yabause) are flagged out of date for some time. I tried to contact the maintainer without success. I'd like to adopt those packages. -- Tiago Pierezan Camargo milopi @ irc.freenode.net

5 8

[aur-general] pkgstats and community - attempt 2
by Allan McRae 03 Dec '08

03 Dec '08

This whole thing has got a bit out of hand... All I wanted to do was organize a meeting for TUs to discuss the results of the pkgstats script. And now I arrive back to ~70 email with back and forward about how things should be. I am actually quite disappointed with some of the responses there. I'll put this out there first before I carry on with this email. I am a dev. I am a TU. I do not care about titles and my only aim here is to serve the Arch community better. I am not taking a dev or TU point of view here at all. I may not have been around as long as others but I know the history of the community repo and the AUR voting system. That being said, the pkgstats results point to a problem in the [community] repo. I suggested we should discuss this on IRC at some stage. ~70 emails later, that option seems to have been forgotten. So here is the issue: * There is no point taking up server space and bandwidth with packages that nobody or very, very few people use. * pkgstats points to a few hundred packages that fall into the not very used category in both [extra] and [community]. The devs are discussing what to with packages in [extra]. Note that does not necessarily mean those packages are automatically dropped to the AUR as that make no sense for some packages. I.e. compromise is being made. Please read that again. Compromise... So we need to think about what the purpose of the [community] repo is. It is obviously to supplement [core] and [extra]. Packages in [core] are the base of a system, packages in [extra] define Arch as a distro and are widely used by its users, packages in [community] do what? 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 ..." Allan

6 5

[aur-general] package update request
by Henri Häkkinen 02 Dec '08

02 Dec '08

Hello, The vala 0.3.5-1 package seems to be seriously out of date and the author is not responding to my requests. Could somebody update this or can I assume the ownership of it? http://aur.archlinux.org/packages.php?ID=7203 -- Henri Häkkinen

3 4

[aur-general] community back-end rewrite
by Allan McRae 02 Dec '08

02 Dec '08

Hi all, In the TU meetings there was some discussion about doing a rewrite/update/fix-up of the [community] back-end. I am not sure who all is looking at this and what the plans are - hence this email. Can people who are looking at this or interested in looking at this give a ping back to this message with whatever plans you have or work you have already done. Things I want to flag: - we should get a git repo for a community-backend project on the arch server and separate this from the aur site code. - we should switch SCM tools from CVS. I am strongly in favour of using the same system as the main repos which would allow much code reuse and easily get us a testing repo for community packages. (No more big rebuild issues!). Allan

5 11

[aur-general] Proposed rules for packages entering [community]
by Allan McRae 01 Dec '08

01 Dec '08

Hi all, As part of the TU meetings it was decided to post the proposal for restricting packages entering [community] here for discussion before voting. Here is the current wording: [proposal] * Only "popular" packages may enter the repo, as defined by 1% usage from pkgstats or 10 votes on the AUR. * Automatic exceptions to this rule are: - i18n packages - accessibility packages - drivers - dependencies, including makedeps and optdeps - packages that are part of a collection and are intended to be distributed together, provided the primary part of this collection satisfies the definition of popular * Any additions not covered by the above criteria must first be proposed on the aur-general mailing list, explaining the reason for the exemption (e.g. renamed package, new package) at which point a general consensus from the TUs will be reached. TUs with large numbers of "non-popular" packages are more likely to be rejected. * TUs are strongly encouraged to move packages they currently maintain from [community] if they have low usage. No enforcement will be made, although resigning TUs packages may be filtered before adoption can occur. [end proposal] So, go ahead and discuss. Especially focus on the wording and regions that people would feel need clarification before I call for a formal vote. In particular, I think the process for addition of packages which do not meet the popularity criteria needs to be defined better, so any ideas there would be appreciated. Any further additions to do with cleaning the current package load in [community] for low usage package is a separate issue and will be discussed at a later date. Allan

6 9

[aur-general] Current TUs
by Aaron Griffin 01 Dec '08

01 Dec '08

Would someone mind telling me which people on this list are no longer TUs? This is the CVS passwd file... whoops http://dev.archlinux.org/~aaron/tu_names

8 16

Re: [aur-general] Proposed rules for packages entering [community]
by Loui Chang 01 Dec '08

01 Dec '08

On Mon, Dec 01, 2008 at 11:54:20PM +1000, Allan McRae wrote: > Daenyth Blank wrote: > > On Sun, Nov 30, 2008 at 22:27, Allan McRae <allan(a)archlinux.org> wrote: > > > >> Hi all, > >> > >> As part of the TU meetings it was decided to post the proposal for > >> restricting packages entering [community] here for discussion before > >> voting. > >> > > > > My primary issue with the current proposal is that I feel 10 votes is > > slightly high for a first step. I'd *much* rather see 3-5 as a > > minimum, and I think others would as well. > > > > 89/97 packages with 0% usage on package stats have 5 votes or less. So this > would achieve a net result of nothing. How does that achieve a net result of nothing? If these rules were already in place it could have meant a net result of more than 500 less packages in community that we need to deal with.

2 1