- Aur-general - lists.archlinux.org

[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

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

01 Dec '08

> 89/97 packages with 0% usage on package stats have 5 votes or less. So this > would achieve a net result of nothing. > Allan > I didn't realize that was the case. I retract my point then.

1 0

Re: [aur-general] TU Meeting
by Daenyth Blank 01 Dec '08

01 Dec '08

On Mon, Dec 1, 2008 at 08:23, Daenyth Blank <daenyth(a)gmail.com> wrote: >> - It was proposed to add a safe flag on TUs packages in the AUR to encourage >> TUs to leave packages out of community while still being marked in a way as >> they are known to be good PKGBUILDs > > I missed this part... luckily. Safe flags were happily killed with a > few months ago. If you mean to add them to [community] packages only, > then it doesn't make sense to me: to make a TU you don't just need the > User, you also need the Trust. Either you don't T the U from the > beginning (and s/he doesn't get elected) or you T, and then you don't > need to flag anything. If someone notices an anomaly in a TU's > PKGBUILD quality, it should readily be reported to the list to take > action. The idea was that some people were putting packages in community which didn't need to be there, for the reason that having it in community assures that it's safe. If it were brought back, it would be for the purpose of encouraging TUs to use unsupported for packages that don't belong in community, while still allowing users to see *at a glance* if the package was made by a TU or not. Maybe code can explain better... on_upload { [...do stuff...] flag_unsafe $package if $uploader.is_a_tu then flag_safe $package }

1 0

[aur-general] TU Meeting
by Allan McRae 01 Dec '08

01 Dec '08

Hi TU's, I would like to organize a TU meeting on IRC to discuss the results of the pkgstats script and the direction for the [community] repo. I am probably the person with the worst time zone issues so I am happy to take a very late night time slot. I guess a weekend would be best to deal with the multiple time zones. So how are peoples availabilities (provide times/timezones): 15/16 November 22/23 November 29/30 November It would be good if someone (who isn't me...) sets up a temporary wiki page to handle this. Allan

15 37

Re: [aur-general] community back-end rewrite
by Loui Chang 01 Dec '08

01 Dec '08

On Mon, Dec 01, 2008 at 11:35:18AM +1000, Allan McRae wrote: > 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!). I'm involved with AUR development and have recently studied and begin to understand the tupkg code. Some improvements based on that activity will be put into action soon. I'll continue to help maintain AUR until I feel it has reached a certain point of efficiency and effectiveness where it no longer needs major maintenance. My plan from there is to start design and development on a new system that can be used for repo maintenance in AUR as well as any other package repo project, like arch-games, or even maybe official repos. These were actually some of my main goals in becoming a TU. I don't there is any benefit from putting tupkg code in a different repo than the AUR web interface. They are tied together by the DB and separating them may cause disjointed development and other problems. However we could organise the source tree and document how the system works a little better. Cheers!

1 0

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

01 Dec '08

On Mon, Dec 01, 2008 at 01:27:33PM +1000, Allan McRae 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. > 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] Thank you for taking the initiative to put this forward Allan. I really think we've had enough discussion about this topic. Nevertheless the motion requires a set discussion period and voting period. How about five days discussion, and five days voting? Cheers!

2 1

[aur-general] mailing list archives not showing up
by Abhishek Dasgupta 30 Nov '08

30 Nov '08

The mailing list archives at http://archlinux.org/pipermail/* are returning a 404. -- Abhishek

2 1

[aur-general] My thoughts on the [Community] policy discussion
by Drew Frank 30 Nov '08

30 Nov '08

Hi all, First off, I'd like to introduce myself so you can weigh my observations appropriately. My name is Drew. I'm a casual Arch user, and until recently my only experience with the AUR was using yaourt to download and install packages (and pacman to install from [Community], but I didn't really understand what that meant). Recently I've been following the discussion on this list regarding how to determine which packages belong in [Community]. Despite my lack of Arch/AUR mastery, I'd like to offer my two cents. I claim: 1. If it were possible to know with certainty that a given package were not in use by anybody (or only by a very small number of people), there would be overwhelming agreement that the package does not belong in [Community]. 2. Both vote counts and pkgstats statistics, as they are currently generated, are flawed metrics of package popularity. 3. Nearly all of the controversy over various [Community] admission policies stems from the fact that different people place different levels of trust in the information provided by votes and pkgstats. I feel like I'm a bit late to the party, but unless there is a critical need to act now my recommendation would be to first set up a system whereby accurate usage statistics are obtained and then proceed to develop policy based on accurate, interpretable statistics. Drew

2 2

[aur-general] huge differencies between i686 and x86_64 community repo
by Jaroslav Lichtblau 30 Nov '08

30 Nov '08

Hi fellow TUs! A quick look on the nice page showing differencies between our i686 and x86_64 repos [1], shows a pretty impresive list in our [community] repository. Could we please work on this a bit and keep it synchronised! IMHO even if some of us don't have access to both architectures, we can talk to someone who does and builds it for us. Have a nice day Jaroslav [1] http://www.archlinux.de/?page=ArchitectureDifferences -- Die Liebe ist der einzige Weg, auf dem selbst die Dummen zu einer gewissen Größe gelangen. -- Honoré de Balzac

4 3

Re: [aur-general] TU Meeting
by stefan-husmann＠t-online.de 30 Nov '08

30 Nov '08

-----Original Message----- > Date: Sun, 30 Nov 2008 00:02:22 +0100 > Subject: Re: [aur-general] TU Meeting > From: Allan McRae <allan(a)archlinux.org> > To: "Discussion about the Arch User Repository (AUR)" > <aur-general(a)archlinux.org> > Hey all, > > Well the meeting went ahead. Not a great turn out.... > > Here is the log: > http://dev.archlinux.org/~allan/tu-meeting-2008-11-29.txt > > Allan > > Hello, maybe it is due to my low irc experiences but I believes I was in the correct channel at nine pm. yesterday and ten yesterday , but nothing happened. Stefan

2 1

Re: [aur-general] TU Meeting
by Loui Chang 30 Nov '08

30 Nov '08

On Sat, Nov 29, 2008 at 07:03:10PM -0700, w9ya wrote: > On Sat, Nov 29, 2008 at 1:58 PM, Loui Chang <louipc.ist(a)gmail.com> wrote: > > > On Sat, Nov 29, 2008 at 01:44:30PM -0700, w9ya wrote: > > > On Sat, Nov 29, 2008 at 1:15 PM, Loui Chang <louipc.ist(a)gmail.com> > > wrote: > > > > My apologies. The list [1] is a survey of packages with under four > > votes > > > > done a couple of weeks ago. > > > > > > > > This is the data represented, in order: > > > > number of votes > > > > size in KB > > > > package name > > > > > > > > Remove: [0] 2888.58 jump-project > > > > > > > > At the end are some totals. > > > > > > > > [1] http://omploader.org/veDEy > > > > > > > > > ANALYSIS of your data as presented: The data you have generated merely > > shows > > > some low single digit reduced server space reductions gained from removal > > of > > > these pacakges. It does NOT show any other impact in and of itself. I > > again > > > ask for a declared meaning to the numbers. > > > > Please look at the totals Bob. These are not low single digit > > reductions. > > Yes, as a percentage they would be. And when looking at statistics, that > would be the most important numbers; i.e. How big a percentage difference > will this make. I'm not going to look up exact numbers right now, but [community] takes up about 11G. This would reduce space usage by about 1G, so that would make about 9% reduction in disk space. The proposal that will currently be tabled will not effect packages currently in [community] though. Cheers.

1 0