- Aur-general - lists.archlinux.org

[aur-general] [deletion request] cant and cannot
by SanskritFritz 02 Apr '11

02 Apr '11

Please remove those packages from AUR: cant - http://aur.archlinux.org/packages.php?ID=47852 cannot - http://aur.archlinux.org/packages.php?ID=47859 Those packages must be deleted immediately, they have hurt my feelings! Also several packaging standards were violated, so numerous, I cant even list them. :)

3 3

[aur-general] Salt 0.7.0
by Thomas S Hatch 02 Apr '11

02 Apr '11

I have received a great deal of feedback from Arch users about salt, so I will announce releases here a few more times. Salt is a parallel remote execution system, the release announcement is in the salt mailing list and my blog: http://groups.google.com/group/salt-users/browse_thread/thread/25f31b5c79c0… http://red45.wordpress.com/2011/04/02/salt-0-7-0/ Arch package is available in the Arch AUR: https://aur.archlinux.org/packages.php?ID=47512 -Thomas S Hatch

1 0

[aur-general] When should pkgrel be updated?
by Oon-Ee Ng 01 Apr '11

01 Apr '11

I've seen (in the past) various packages on the AUR which jumped by 3 or 4 pkgrels in a very short period of time. Sometimes it happens like this:- 1. Maintainer changes something and breaks the package with pkgrel=2 2. Bug reported on comments. Maintainer reverts change and makes pkgrel=3 It can also happen like this:- 1. Maintainer makes changes to pkgdesc or cleans up some of the commands, depends, etc. sets pkgrel=2 For both of the cases above, is pkgrel updating really necessary? For the second one, I think not, as changing documentation doesn't (shouldn't) require recompilation of the package by its users. Similarly if depends changes, users who already have the package installed would already have the dep, so no reason for such users to upgrade? For the first case its a bit more tricky. My reasoning is that if the PKGBUILD breaks and can't be built at all, the maintainer could simply release with the same pkgrel. Noone would have been able to build pkgrel=2 in that example anyway, so why jump to pkgrel=3? The reason I bring this up is because there's no easy way (yet) to diff what's changed between versions of the package, and hence when I notice a pkgrel change I can't really check to see what has been changed and whether its worth recompiling the package (for larger packages like firefox4 this can be significant). Comments appreciated.

7 8

[aur-general] Delete request: firefox-i18n-zh-cn
by zlowly 01 Apr '11

01 Apr '11

Please remove the following package: firefox-i18n-zh-cn: https://aur.archlinux.org/packages.php?ID=20527 It's in [extra] now. Thanks, zlowly

2 1

[aur-general] [deletion request] ryzom_client_open, ryzom-server-hg, ryzom-client-hg
by Caemir 01 Apr '11

01 Apr '11

Hi, can your delete my break packages, please? - ryzom_client_open - ryzom-server-hg - ryzom-client-hg Thx. and sorry for this...

2 1

[aur-general] [deletion request] spacechem
by Alex Griffin 01 Apr '11

01 Apr '11

I submitted the package this morning but regretted it almost immediately. It does not meet the submission guidelines (doesn't download/verify) and my spacechem-demo PKGBUILD can also be used for the purchased full game anyway.

2 1

[aur-general] Should nvidia(-beta)-all replace all the other nvidia-* packages in the AUR?
by Det 01 Apr '11

01 Apr '11

Helloooo, So I've been thinking about this for some time now and I finally decided to ask the ones who know the best: would it be enough to only have 'nvidia-beta-all' and 'nvidia-all' in the AUR to replace all those nvidia-ice, nvidia-bfs, eg. packages? (Decluding nvidia-utils*, of course.) As far as I can think of, I can't see any downside(s) (whatsoever) of using those *-all packages instead of those 'specifc-kernel' packages, since they do in fact auto-detect all the kernels on the system. Now to the important part: what do you think? Det

6 12

[aur-general] Dealing with python-* versus python2-* packages
by Aaron DeVore 31 Mar '11

31 Mar '11

I started maintaining some Python 2 packages that currently use the python- prefix, but need to be renamed to use python2-. Python 3 versions will soon come out, so I don't want people using the python-* package until then. I want to still have the packages in the AUR so that someone doesn't accidentally recreate the python-* package. How do I make sure that people don't use the python-* packages until it's appropriate? -Aaron DeVore

2 1

[aur-general] Deletion request: gtk3
by Károly Pados 31 Mar '11

31 Mar '11

I created a basic gtk3 package in AUR, though later I noticed that there is a gnome-unstable repository, with gtk3 in it. Please delete my gtk3 package in AUR, I don't want it to start conflicting with gnome-unstable things and it is also redundant as it turns out. So I guess it is probably unwanted, or else let me know and I'll keep maintaining it until it gets stable. Thank you and sorry for the trouble.

2 1

[aur-general] orphan and deletion requests (stormlib and stormlib-linux)
by william 56 31 Mar '11

31 Mar '11

i am requesting that stormlib become orphaned, and stormlib-linux be deleted. stormlib-linux (21638) appears to be a duplicate of stormlib (21634), and both packages are unbuildable, as the stormlib source archive which both aur packages compile from has been altered. i sent an email to the package maintainer, zarra (8415), regarding updating his packages, and have yet to receive a response. also, a user commented on the stormlib package with an updated PKGBUILD file on september 23, 2010, though it appeared to go unnoticed by the maintainer. thanks, arch users!

2 1