[aur-general] AUR Cleanup Day organization
Hi all, I think there is enough support for this to go forward. So it is time we nut out the details. Here is how I suggest we go about it. Firstly, I make a post to the announcements section of the forums along the lines of: <draft> The AUR has a large number of obsolete packages which could use cleaning up. Examples of packages that may be cleaned up are: - packages that have been renamed or replaced - old and unmaintained developmental (cvs/svn/etc) packages - outdated and orphaned packages with few or no votes This is where you can help. Post suggestions of packages in the AUR Cleanup wiki page (url here) or as a reply to this thread. TUs will get together and go though the list in a couple of weeks and confirm which packages should be removed. Please do not remove suggestions from the wiki page but add a comment on why it should be kept instead. </draft> I suggest we get together in the TU IRC channel on the weekend of 17/18 May and go through the list. I think we should take care not to get too carried away when we remove packages. While some packages may be orphans, if they are not out of date then the PKGBUILD could still be useful for some people. Any comments before I create the wiki page and post to the forums? Cheers, Allan PS. Someone will have to give me the TU IRC channel key because I never got around to getting it given I rarely use IRC.
Le Fri, 02 May 2008 23:53:51 +1000, Allan McRae <mcrae_allan@hotmail.com> a écrit :
I suggest we get together in the TU IRC channel on the weekend of 17/18 May and go through the list. I think we should take care not to get too carried away when we remove packages. While some packages may be orphans, if they are not out of date then the PKGBUILD could still be useful for some people.
I suggest you use a public channel instead of the TU channel, so that other Arch users can participate and why not adopt packages live. Not the Arch one though, it's too crowded. Maybe you could create a temporary channel for the event... -- catwell
Just my 2 cents: I think, that packages without arch=() field should be also removed. 2008/5/2 Pierre CHAPUIS <catwell@free.fr>:
Le Fri, 02 May 2008 23:53:51 +1000, Allan McRae <mcrae_allan@hotmail.com> a écrit :
I suggest we get together in the TU IRC channel on the weekend of 17/18 May and go through the list. I think we should take care not to get too carried away when we remove packages. While some packages may be orphans, if they are not out of date then the PKGBUILD could still be useful for some people.
I suggest you use a public channel instead of the TU channel, so that other Arch users can participate and why not adopt packages live. Not the Arch one though, it's too crowded. Maybe you could create a temporary channel for the event...
-- catwell
On Fri, May 2, 2008 at 10:08 PM, Lukáš Jirkovský <l.jirkovsky@gmail.com> wrote:
Just my 2 cents: I think, that packages without arch=() field should be also removed.
That seems like a bit much. There's probably a lot of good packages in the AUR without this field and it's not like it's that hard to add it in yourself.
2008/5/2 Pierre CHAPUIS <catwell@free.fr>:
Le Fri, 02 May 2008 23:53:51 +1000, Allan McRae <mcrae_allan@hotmail.com> a écrit :
I suggest we get together in the TU IRC channel on the weekend of 17/18 May and go through the list. I think we should take care not to get too carried away when we remove packages. While some packages may be orphans, if they are not out of date then the PKGBUILD could still be useful for some people.
I suggest you use a public channel instead of the TU channel, so that other Arch users can participate and why not adopt packages live. Not the Arch one though, it's too crowded. Maybe you could create a temporary channel for the event...
Agree with this, why not let as many people as possible get involved to get the most done. -- Callan Barrett
Callan Barrett wrote:
On Fri, May 2, 2008 at 10:08 PM, Lukáš Jirkovský <l.jirkovsky@gmail.com> wrote:
Just my 2 cents: I think, that packages without arch=() field should be also removed.
That seems like a bit much. There's probably a lot of good packages in the AUR without this field and it's not like it's that hard to add it in yourself.
I agree we should not remove packages on the basis of the arch field. We don't want to delete potentially useful packages.
I suggest you use a public channel instead of the TU channel, so that other Arch users can participate and why not adopt packages live. Not the Arch one though, it's too crowded. Maybe you could create a temporary channel for the event...
Agree with this, why not let as many people as possible get involved to get the most done.
OK. Given I know very, very little about IRC, does someone else want to make an IRC channel. Either that, or we could ask if it would be OK to use the archlinux-bugs (or whatever it is called) channel which tends to have very low traffic levels apart from bug days. Allan
But in other way, packages without arch field are usually very, very old. 2008/5/2 Allan McRae <mcrae_allan@hotmail.com>:
Callan Barrett wrote:
On Fri, May 2, 2008 at 10:08 PM, Lukáš Jirkovský <l.jirkovsky@gmail.com> wrote:
Just my 2 cents: I think, that packages without arch=() field should be also removed.
That seems like a bit much. There's probably a lot of good packages in the AUR without this field and it's not like it's that hard to add it in yourself.
I agree we should not remove packages on the basis of the arch field. We don't want to delete potentially useful packages.
I suggest you use a public channel instead of the TU channel, so that
other Arch users can participate and why not adopt packages live. Not the Arch one though, it's too crowded. Maybe you could create a temporary channel for the event...
Agree with this, why not let as many people as possible get involved to get the most done.
OK. Given I know very, very little about IRC, does someone else want to make an IRC channel. Either that, or we could ask if it would be OK to use the archlinux-bugs (or whatever it is called) channel which tends to have very low traffic levels apart from bug days.
Allan
Lukáš Jirkovský wrote:
But in other way, packages without arch field are usually very, very old.
Then they probably fall in this category of the suggest removal guidelines - outdated and orphaned packages with few or no votes This situation is behind my reasoning to create a list of potential removals first. I think we need to be careful of removing too many packages, especially in our first cleanup attempt. Just the really unneeded ones as a first step. I had even considered that once the list was made, then I would archive all the relevant PKGBUILDs before deleting them. But it would be better to just not delete useful packages in the first place... Cheers, Allan
I think you should announce that on a news. A news will be translated for each communities whereas a post in the forum will probably get ignored and non english speaking people won't be advised a cleanup is pending. Maybe a link should be added to the front page of AUR ? Cilyan 2008/5/2, Allan McRae <mcrae_allan@hotmail.com>:
Lukáš Jirkovský wrote:
But in other way, packages without arch field are usually very, very old.
Then they probably fall in this category of the suggest removal guidelines - outdated and orphaned packages with few or no votes
This situation is behind my reasoning to create a list of potential removals first. I think we need to be careful of removing too many packages, especially in our first cleanup attempt. Just the really unneeded ones as a first step. I had even considered that once the list was made, then I would archive all the relevant PKGBUILDs before deleting them. But it would be better to just not delete useful packages in the first place...
Cheers, Allan
On Sat, 3 May 2008, Allan McRae wrote:
Luká Jirkovský wrote:
But in other way, packages without arch field are usually very, very old.
Then they probably fall in this category of the suggest removal guidelines - outdated and orphaned packages with few or no votes
This situation is behind my reasoning to create a list of potential removals first. I think we need to be careful of removing too many packages, especially in our first cleanup attempt. Just the really unneeded ones as a first step. I had even considered that once the list was made, then I would archive all the relevant PKGBUILDs before deleting them. But it would be better to just not delete useful packages in the first place...
Cheers, Allan
I don't think it's a good idea to remove orphaned packages simply because they are out-of-date. Even out-of-date they can still be useful as it's better than having no PKGBUILD at all and maybe someone will adopt them eventually. That's the reason why we call it unsupported: the PKGBUILD can be out-of-date, unmaintained or not very good quality-wise. A lot of work has been invested in these PKGBUILD. However, I don't have any problems about removing old SCM/devel packages, duplicates of packages in repo (patched or using different configure option) or obsoleted packages. Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Fri 2008-05-02 12:08 , Eric Belanger wrote:
On Sat, 3 May 2008, Allan McRae wrote:
Luká Jirkovský wrote:
But in other way, packages without arch field are usually very, very old.
Then they probably fall in this category of the suggest removal guidelines - outdated and orphaned packages with few or no votes
This situation is behind my reasoning to create a list of potential removals first. I think we need to be careful of removing too many packages, especially in our first cleanup attempt. Just the really unneeded ones as a first step. I had even considered that once the list was made, then I would archive all the relevant PKGBUILDs before deleting them. But it would be better to just not delete useful packages in the first place...
I don't think it's a good idea to remove orphaned packages simply because they are out-of-date. Even out-of-date they can still be useful as it's better than having no PKGBUILD at all and maybe someone will adopt them eventually. That's the reason why we call it unsupported: the PKGBUILD can be out-of-date, unmaintained or not very good quality-wise. A lot of work has been invested in these PKGBUILD.
I totally agree with Eric here. I'm a bit worried about this "cleanup frenzy": there is a package in the AUR that is out-of-date and doesn't even compile. Why should we remove it? As Eric said, it's better than nothing. Unless the package is obsolete (e.g. gaim/pidgin) or it is a package already in the repos, IMHO there is no need to remove it. If a PKGBUILD contains errors, fix it, if you want to, but do not remove it. What about a "bug-fix day" instead of a "cleanup day" ? -- Alessio (molok) Bolognino Please send personal email to themolok@gmail.com Public Key http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xFE0270FB GPG Key ID = 1024D / FE0270FB 2007-04-11 Key Fingerprint = 9AF8 9011 F271 450D 59CF 2D7D 96C9 8F2A FE02 70FB
I agree with Alessio here. However, if the upstream development has stopped and the sources for the package can no longer be located, then I think the package should be removed. -- Abhishek
Alessio Bolognino wrote:
On Fri 2008-05-02 12:08 , Eric Belanger wrote:
On Sat, 3 May 2008, Allan McRae wrote:
Luká Jirkovský wrote:
But in other way, packages without arch field are usually very, very old.
Then they probably fall in this category of the suggest removal guidelines - outdated and orphaned packages with few or no votes
This situation is behind my reasoning to create a list of potential removals first. I think we need to be careful of removing too many packages, especially in our first cleanup attempt. Just the really unneeded ones as a first step. I had even considered that once the list was made, then I would archive all the relevant PKGBUILDs before deleting them. But it would be better to just not delete useful packages in the first place...
I don't think it's a good idea to remove orphaned packages simply because they are out-of-date. Even out-of-date they can still be useful as it's better than having no PKGBUILD at all and maybe someone will adopt them eventually. That's the reason why we call it unsupported: the PKGBUILD can be out-of-date, unmaintained or not very good quality-wise. A lot of work has been invested in these PKGBUILD.
I totally agree with Eric here. I'm a bit worried about this "cleanup frenzy": there is a package in the AUR that is out-of-date and doesn't even compile. Why should we remove it? As Eric said, it's better than nothing.
Unless the package is obsolete (e.g. gaim/pidgin) or it is a package already in the repos, IMHO there is no need to remove it.
If a PKGBUILD contains errors, fix it, if you want to, but do not remove it. What about a "bug-fix day" instead of a "cleanup day" ?
Let me be clear here that I will in now way encourage the deletion of anything that may be useful in the future. I now how annoying it can be to have packages you have spent time on deleted from the AUR even if you have orphaned them (who deleted dpkg & rpm... I am actually quite pissed off about that). This is my reasoning behind creating a list first. That way there is time for people to object to the removals before it happens. As an example, look at the alienarena packages. I'm reasonably sure alienarena2007 is replaced by alienarena. And I only looked at a couple of pages... Allan
The list is good idea, maybe someone (eg me ;-)) finds out that there is some interesting package and he will adopt it. 2008/5/3 Allan McRae <mcrae_allan@hotmail.com>:
Alessio Bolognino wrote:
On Fri 2008-05-02 12:08 , Eric Belanger wrote:
On Sat, 3 May 2008, Allan McRae wrote:
Luká Jirkovský wrote:
But in other way, packages without arch field are usually very, very old.
Then they probably fall in this category of the suggest removal guidelines - outdated and orphaned packages with few or no votes
This situation is behind my reasoning to create a list of potential removals first. I think we need to be careful of removing too many packages, especially in our first cleanup attempt. Just the really unneeded ones as a first step. I had even considered that once the list was made, then I would archive all the relevant PKGBUILDs before deleting them. But it would be better to just not delete useful packages in the first place...
I don't think it's a good idea to remove orphaned packages simply because they are out-of-date. Even out-of-date they can still be useful as it's better than having no PKGBUILD at all and maybe someone will adopt them eventually. That's the reason why we call it unsupported: the PKGBUILD can be out-of-date, unmaintained or not very good quality-wise. A lot of work has been invested in these PKGBUILD.
I totally agree with Eric here. I'm a bit worried about this "cleanup frenzy": there is a package in the AUR that is out-of-date and doesn't even compile. Why should we remove it? As Eric said, it's better than nothing.
Unless the package is obsolete (e.g. gaim/pidgin) or it is a package already in the repos, IMHO there is no need to remove it.
If a PKGBUILD contains errors, fix it, if you want to, but do not remove it. What about a "bug-fix day" instead of a "cleanup day" ?
Let me be clear here that I will in now way encourage the deletion of anything that may be useful in the future. I now how annoying it can be to have packages you have spent time on deleted from the AUR even if you have orphaned them (who deleted dpkg & rpm... I am actually quite pissed off about that). This is my reasoning behind creating a list first. That way there is time for people to object to the removals before it happens.
As an example, look at the alienarena packages. I'm reasonably sure alienarena2007 is replaced by alienarena. And I only looked at a couple of pages...
Allan
Allan McRae wrote:
Alessio Bolognino wrote:
On Fri 2008-05-02 12:08 , Eric Belanger wrote:
On Sat, 3 May 2008, Allan McRae wrote:
Luká Jirkovský wrote:
But in other way, packages without arch field are usually very, very old.
Then they probably fall in this category of the suggest removal guidelines - outdated and orphaned packages with few or no votes
This situation is behind my reasoning to create a list of potential removals first. I think we need to be careful of removing too many packages, especially in our first cleanup attempt. Just the really unneeded ones as a first step. I had even considered that once the list was made, then I would archive all the relevant PKGBUILDs before deleting them. But it would be better to just not delete useful packages in the first place...
I don't think it's a good idea to remove orphaned packages simply because they are out-of-date. Even out-of-date they can still be useful as it's better than having no PKGBUILD at all and maybe someone will adopt them eventually. That's the reason why we call it unsupported: the PKGBUILD can be out-of-date, unmaintained or not very good quality-wise. A lot of work has been invested in these PKGBUILD.
I totally agree with Eric here. I'm a bit worried about this "cleanup frenzy": there is a package in the AUR that is out-of-date and doesn't even compile. Why should we remove it? As Eric said, it's better than nothing.
Unless the package is obsolete (e.g. gaim/pidgin) or it is a package already in the repos, IMHO there is no need to remove it.
If a PKGBUILD contains errors, fix it, if you want to, but do not remove it. What about a "bug-fix day" instead of a "cleanup day" ?
Let me be clear here that I will in now way encourage the deletion of anything that may be useful in the future. I now how annoying it can be to have packages you have spent time on deleted from the AUR even if you have orphaned them (who deleted dpkg & rpm... I am actually quite pissed off about that). This is my reasoning behind creating a list first. That way there is time for people to object to the removals before it happens.
As an example, look at the alienarena packages. I'm reasonably sure alienarena2007 is replaced by alienarena. And I only looked at a couple of pages...
Allan
Btw OT but I was the one who added dpkg (along with po4a), mainly used dpkg-deb from it to play with deb packages. Still should have old PKGBUILDs lying around if you want :p
When I run $ yaourt –Syu –-aur I get this messages. I think this need to be clean up in Aur. libol: not found on AUR perl-archive-extract: (local=0.24-1 aur=0.18-3) perl-ipc-cmd: (local=0.40-1 aur=0.36-3) perl-locale-maketext-simple: (local=0.18-2 aur=0.16-3) perl-module-load: (local=0.12-1 aur=0.10-2) perl-module-load-conditional: (local=0.22-1 aur=0.16-3) tpctl: not found on AUR xorg: not found on AUR Following packages have not been installed: libol tpctl xorg
That one may be depending on the xorg meta package, and 2 other packages that may be in official repos with different names, or are gone/replaced in AUR. I think there's a huge number of packages that need to be cleaned up themselves, some even have the buildscript and installscript as executables; all sorts of funny stuff. But that's AUR, it's inevitable.
On Sat, 3 May 2008, Uwe Vogt wrote:
When I run $ yaourt Syu -aur I get this messages. I think this need to be clean up in Aur.
libol: not found on AUR perl-archive-extract: (local=0.24-1 aur=0.18-3) perl-ipc-cmd: (local=0.40-1 aur=0.36-3) perl-locale-maketext-simple: (local=0.18-2 aur=0.16-3) perl-module-load: (local=0.12-1 aur=0.10-2) perl-module-load-conditional: (local=0.22-1 aur=0.16-3) tpctl: not found on AUR xorg: not found on AUR Following packages have not been installed: libol tpctl xorg
libol and tpctl have been removed from the repo. They were not added to AUR because they were obsolete. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Uwe Vogt a écrit :
perl-archive-extract: (local=0.24-1 aur=0.18-3) perl-ipc-cmd: (local=0.40-1 aur=0.36-3) perl-locale-maketext-simple: (local=0.18-2 aur=0.16-3) perl-module-load: (local=0.12-1 aur=0.10-2) perl-module-load-conditional: (local=0.22-1 aur=0.16-3)
The perl packages listed above are no longer needed because they are included in core perl 5.10. They may reappear in community if new versions are available on CTAN that justify updating them. F
On Sat 2008-05-03 22:19 , Mikko Seppälä wrote:
[...] Btw OT but I was the one who added dpkg (along with po4a), mainly used dpkg-deb from it to play with deb packages.
Still should have old PKGBUILDs lying around if you want :p
Protip: wget http://aur.archlinux.org/packages/dpkg/dpkg.tar.gz wget http://aur.archlinux.org/packages/rpm/rpm.tar.gz I don't know if this is a bug or a feature, but AUR doesn't delete the files when the packages are removed from the web interface. :) -- Alessio (molok) Bolognino Please send personal email to themolok@gmail.com Public Key http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xFE0270FB GPG Key ID = 1024D / FE0270FB 2007-04-11 Key Fingerprint = 9AF8 9011 F271 450D 59CF 2D7D 96C9 8F2A FE02 70FB
On 5/2/08, Allan McRae <mcrae_allan@hotmail.com> wrote:
This situation is behind my reasoning to create a list of potential removals first. I think we need to be careful of removing too many packages, especially in our first cleanup attempt. Just the really unneeded ones as a first step. I had even considered that once the list was made, then I would archive all the relevant PKGBUILDs before deleting them. But it would be better to just not delete useful packages in the first place...
I second your proposition. In case we want to work on IRC for the CU day as proposed earlier (which I think is a good idea), I wrote a IRC bot. Just say ":d pkgname" (I use vim...) and it will download it for backup, then make a report. I'll make an archive of the result packages at the end. Running for now on #archlinux-cleanup@freenode, http://koon.fr/~gcarrier/cleanup/ -- Geoffroy Carrier
Geoffroy Carrier wrote:
On 5/2/08, Allan McRae <mcrae_allan@hotmail.com> wrote:
This situation is behind my reasoning to create a list of potential removals first. I think we need to be careful of removing too many packages, especially in our first cleanup attempt. Just the really unneeded ones as a first step. I had even considered that once the list was made, then I would archive all the relevant PKGBUILDs before deleting them. But it would be better to just not delete useful packages in the first place...
I second your proposition. In case we want to work on IRC for the CU day as proposed earlier (which I think is a good idea), I wrote a IRC bot. Just say ":d pkgname" (I use vim...) and it will download it for backup, then make a report. I'll make an archive of the result packages at the end. Running for now on #archlinux-cleanup@freenode, http://koon.fr/~gcarrier/cleanup/
This sounds interesting. So if I understand this correctly (which is a big assumption), the packages downloaded to your website? What do you mean by "make a report"? Allan
On 5/3/08, Allan McRae <mcrae_allan@hotmail.com> wrote:
This sounds interesting. So if I understand this correctly (which is a big assumption), the packages downloaded to your website? What do you mean by "make a report"?
Yes. Everything is on my server, including the bot's code and its logs. Example session: 12:34 <@gcarrier> pacstik: how do you work? 12:34 < pacstik> gcarrier: I'm the Cleanup day AUR pkg downloader. Just say :g pkgname, I'll archive it from AUR and make a report. I'm owned by gcarrier. 12:34 <@gcarrier> :g puzzles 12:34 < pacstik> puzzles now available at http://koon.fr/~gcarrier/cleanup/puzzles.tar.gz 12:34 <@gcarrier> :g puzzling 12:34 < pacstik> Something went TERRIBLY wrong with puzzling, don't expect it in my place. And you get in irclogs : [10:34:32] Joined #archlinux-cleanup [12:34:47] Got puzzles. [12:34:54] Failed at puzzling! That's all. -- Geoffroy Carrier
On Sat, 03 May 2008 00:57:00 +1000 Allan McRae <mcrae_allan@hotmail.com> wrote:
OK. Given I know very, very little about IRC, does someone else want to make an IRC channel. Either that, or we could ask if it would be OK to use the archlinux-bugs (or whatever it is called) channel which tends to have very low traffic levels apart from bug days.
Allan
Why not use #archlinux-aur as the IRC channel? Another thing you might want to do for this clean up is gain access to the filesystem behind AUR so you can clean up old build files for packages that have already been removed from the database.
I too never got around to getting my IRC channel key for the same reason! Email the announcement to arch-announce@archlinux.org too... Then people who don't follow the forums will also get to know. Abhishek
Allan McRae wrote:
<draft> The AUR has a large number of obsolete packages which could use cleaning up. Examples of packages that may be cleaned up are: - packages that have been renamed or replaced - old and unmaintained developmental (cvs/svn/etc) packages
This is where you can help. Post suggestions of packages in the AUR Cleanup wiki page (http://wiki.archlinux.org/index.php/AUR_CleanUp_Day) or as a reply to this thread. TUs will get together and go though the list in a couple of weeks and confirm which packages should be removed. Please do not remove suggestions from the wiki page but add a comment on why it should be kept instead. </draft>
Well, I have adjusted the above draft and made the wiki page. If there are no further comments on the draft, I will post it on the forums and organize a front page news item. Cheers, Allan
participants (14)
-
Abhishek Dasgupta
-
Alessio Bolognino
-
Allan McRae
-
Callan Barrett
-
Cilyan Olowen
-
Eric Belanger
-
Firmicus
-
Geoffroy Carrier
-
Loui
-
Lukáš Jirkovský
-
Mikko Seppälä
-
Pierre CHAPUIS
-
Ray Rashif
-
Uwe Vogt