- Aur-general - lists.archlinux.org

[aur-general] Someone hug sergej
by Callan Barrett 05 Dec '08

05 Dec '08

sergej I'm sorry for trying to vote you out. It was a pretty big dick move on my part. I think you've shown yourself to be perfectly capable of maintaining all these packages and like other people have said although it's impossible for you to put complete care into each package you're very good at fixing stuff when it's reported. I JUST WANT YOU TO KNOW I APPRECIATE YOUR WORK. :') -- Callan Barrett

15 35

[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