- Aur-general - lists.archlinux.org

[aur-general] Delete request for perl-scalar-util
by Justin Davis 17 Jan '11

17 Jan '11

Please delete perl-scalar-util: http://aur.archlinux.org/packages.php?ID=26539 I adopted it long ago and noticed it recently. The package should be called perl-scalar-list-utils (which already exists) and is generally not needed because it is included with perl. Thanks, juster / aurperl

2 1

[aur-general] Is it okay to mark broken packages out-of-date on AUR?
by Peter Simons 16 Jan '11

16 Jan '11

Hi guys, the AUR user palmfron has recently flagged the package "haskell-haskcore" out-of-date, because the PKGBUILD is broken. It cannot be compiled, because it depends on other packages that no longer exist: http://aur.archlinux.org/packages.php?ID=20383 Now, there is disagreement among the members of the ArchHaskell team about whether it's okay to flag that package out-of-date. Some argue that the package is *not* out-of-date, because the published version 0.1.0.4 is the latest one available, so the package cannot be updated to a newer version. These people argue that flagging a package out-of-date just because it's broken is not alright. Others say that it's perfectly alright to flag that package out-of-date, because it's *broken*, so clearly the PKGBUILD does need updating to be useful. Is there some sort of consensus among AUR maintainers how to deal with that kind of situation? If an AUR package is current, so to speak, but it doesn't compile, then what should be done with it? This issue is of some importance for us, because the 'arch-haskell' user has published an approximated 500 packages on AUR that are broken, i.e. these packages cannot be built because of unsatisfiable dependencies: https://github.com/archhaskell/habs/issues#issue/4 I'd appreciate any advice that you could offer. Take care, Peter

6 7

[aur-general] Stable (and obsolete) CrystalHD package in the AUR
by Stijn Segers 16 Jan '11

16 Jan '11

Hello, Broadcom's CrystalHD drivers has two development trees online - an SVN one (maintained by Davilla, an Xbmc developer), and a git one, which seems to have some of Broadcom's people on board. Davilla periodically syncs with the git tree. There is a package on the AUR simply called 'crystalhd' which points to the git tree in its package info, but is in fact built from the original Broadcom release tarball [1], which, by now, is obsolete, and hasn't been updated by its maintainer in quite a while, despite being flagged out of date; there is a new tarball available from July 2010, which is out of data as well; furthermore, the driver is included in staging. I would like to upload a stable package based on the SVN tree (which has release tags), and think simply naming 'crystalhd' - since it's a stable release tagged as such by the Xbmc developer - would best, but I'm not sure. Calling it crystalhd-svn might be more appropriate, especially to differentiate it from the crystalhd-git tree, but it might confuse people as well (e.g. a crystalhd-svn-3.8.0-1-i686.tar.xz package looks kinda bizarre). Either way, I think the package [1] can be safely deleted, so I would like to request that, and have opinions on the best name for the new stable package based on the svn sources. Thanks B [1] http://aur.archlinux.org/packages.php?ID=34193

2 1

[aur-general] deletion request - ocamlgraph-withoutfindlib
by Thomas S Hatch 16 Jan '11

16 Jan '11

There was a triple duplicate package of ocamlgraph, I have been working with the other 2 maintainers to come to a consensus as to how it should be packaged. A consensus has been reached, please delete the last duplicate! https://aur.archlinux.org/packages.php?ID=31755 -Tom Hatch

2 1

[aur-general] Duplicate package
by Thomas S Hatch 16 Jan '11

16 Jan '11

https://aur.archlinux.org/packages.php?ID=41219 Is a duplicate of community/python-pexpect This should be deleted right?

2 2

[aur-general] Package deletion request
by Thomas S Hatch 15 Jan '11

15 Jan '11

https://aur.archlinux.org/packages.php?ID=21687 is a duplicate of the correctly named ocaml-ocamlgraph, please delete it. -Tom Hatch

2 1

[aur-general] Time to Step Down
by Aaron Bull Schaefer 15 Jan '11

15 Jan '11

Fellow Trusted Users, After almost 4 years of being a TU, I've had less and less time to dedicate toward maintaining my packages, and so I think it's finally time for me to step down. Arch users definitely deserve a better response time than what I've been able to provide lately, and unfortunately, my priorities have shifted elsewhere. Most of my packages should be pretty straight forward to maintain, but feel free to poke me if you have any questions on them. I do have two open bugs (one for woof and one for pv) that I've updated with what info I know. Thanks for everything you've taught me over the years...it's been an honor working with you all to maintain this fantastic distro, and rest assured that I'll always be involved in the community in one form or another. Keep up the great work! -- Aaron "ElasticDog" Schaefer

11 14

[aur-general] Orphan Request
by speps 15 Jan '11

15 Jan '11

Hi, can you please orphan libircclient? ==> http://aur.archlinux.org/packages.php?ID=14047 The package is not outdated, but it does not build and install any shared lib, also it installs headers into a no proper path according to ==> http://packages.debian.org/squeeze/amd64/libircclient-dev/filelist Last maintainer action go up to july 2010, also one of his packages (ibus-handwrite) is outdated since November 2010 with a user PKGBUILD proposal in the comments. I have also sent him an e-mail without responses Thanks

2 2

[aur-general] Renaming package
by Sebastien Duthil 15 Jan '11

15 Jan '11

Hi, I'd like to know how to rename an AUR package. In this case, I must rename gplanarity to gplanarity-svn. Is it possible ? Can I do it or does anyone else have to do it ? Or shoud I create a new package ? In this case, should the old one be removed ? I didn't find anything about that case ... Thank you ! Sebastien Duthil

2 3

[aur-general] qt3 backend in python-matplotlib
by Stéphane Gaudreault 14 Jan '11

14 Jan '11

Dear TUs, I am preparing an update of python-matplotlib to version 1.0.1. This package supports multiple backends for rendering graphics and plotting windows. So far, our PKGBUILD supported QTAgg which requires the old qt3. Considering that qt3 has no future, I wonder if it is still necessary to provide this backend. Any objections if I drop it ? I will also set the default backend to QT4Agg (user will still be able to change the default in the matplotlibrc file or in their scripts). Stéphane

2 2