On Sat, Sep 18, 2010 at 10:04:09PM -0400, Daenyth Blank wrote:

Done

Btw, can we automate this in some way? Is there any TU running aurdupes regularly? Or should I just continue sending removal requests every week or so...?

On Sat, Sep 18, 2010 at 10:22:52PM -0400, Daenyth Blank wrote:

It's definitely got some margin for error. What does the dupes script check? pkgname?

Yep, it checks for duplicate package names in the official repos and the AUR, see [1]. It'll output duplicate package names and, optionally, AUR links to affected packes. Of course, packages will always have to be checked manually before removing but since AUR packages usually should *never* have the same name as packages in the official repos, this shouldn't be a big deal... It would just be much easier if any TU would do that. No need for constant additional removal requests via aur-general. [1] http://aur.archlinux.org/packages.php?ID=40869

On Sun, Sep 19, 2010 at 02:20:13PM +0200, Jakob Gruber wrote:

I've also played around with automated AUR quality checks on dumps of the SQL DB. Looking at things like 'flagged out of date' and 'date of last action on package', I initially came up with around 500-1000 packages that should be either disowned or deleted.

Sounds good to me.

I was thinking about defining a few SQL queries which would run regularly and could report things like

* duplicates (by name AND by other criteria such as sources)

Checking sources is not that good imho. There's a bunch of packages that use the same sources as other official/AUR packages but provide completely different features (e.g. extract an SDK from the source tarball). If there was something like that, there should be a manual filter or something to automatically ignore such packages.

* out of date packages with no maintainer action since some date threshold * maintainers with the most out of date packages * maintainers with no action since some date threshold

Sounds good, but as you said before, all packages should be checked before removal in any case.

Here are some initial results from a recent dump of the DB: ---------------------- 1) packages which are marked 'out of date' but the last action date [1] is < 2009 http://pastebin.com/GVPYcvLC 2) maintainers with last action date across all owned packages < 2009 http://pastebin.com/9ja2fXqY 3) packages owned by maintainers from the previous query http://pastebin.com/sWdEbrsS ---------------------- Lists 1 and 3 overlap, so we have between 1000 and 1500 packages to check. I'd suggest waiting a week or 2 to give people a chance to look over these lists and raise objections. Afterwards we could either orphan these packages in the DB itself (if our admins agree) or start going through these packages manually. Any ideas? Objections? schuay [1] last action date is either the date of the last modification, or if a package has never been modified the date of submission

Am 22.09.2010 13:26, schrieb Jakob Gruber:

Here are some initial results from a recent dump of the DB:

----------------------

1) packages which are marked 'out of date' but the last action date [1] is < 2009

http://pastebin.com/GVPYcvLC

2) maintainers with last action date across all owned packages < 2009

http://pastebin.com/9ja2fXqY

3) packages owned by maintainers from the previous query

http://pastebin.com/sWdEbrsS

----------------------

Lists 1 and 3 overlap, so we have between 1000 and 1500 packages to check.

I'd suggest waiting a week or 2 to give people a chance to look over these lists and raise objections. Afterwards we could either orphan these packages in the DB itself (if our admins agree) or start going through these packages manually.

Any ideas? Objections?

schuay

[1] last action date is either the date of the last modification, or if a package has never been modified the date of submission

Hello, I wrote the first PKGBUILDs for the englab packages mentioned in http://pastebin.com/GVPYcvLC. I handed them over to the maintainer Verminoz because he was (is?) in contact with the upstream project. The project has its own pacman-repositories (e.g. http://englab.bugfest.net/arch/x86_64/) for the englab packages. The PKGBUILDS are also available from their sourceforge project file area. I am quite sure that englab-cimg and englab-plot can be removed (older duplicates of libenglab-cimg resp.libenglab-plot). The documentation (package englab-doc) maybe should be removed, because it is only one file and can be downloaded from sourceforge easily. Not sure about the other plugins, which do not have a counterpart with prefix "lib" (englab-matrix, englab-special-functions). Are they still valid? Have they been replaced? Hope this clarifies some issues. Stefan