Re: [aur-general] AUR cleanup

[Daniel Bermond via aur-general]

On 07/12/2019 11:59, Lukas Fleischer via aur-general wrote:
> Here's an up-to-date list of duplicates reported by `aurdupes -A`. I did
> not check for false positives. Maybe somebody can go through that list
> and either remove duplicate packages or file deletion requests. I'll
> post a separate list with VCS duplicates.
>
> svt-vp9
> * svt-vp9 [community]
> * svt-vp9 http://aur.archlinux.org/packages/svt-vp9/

It was recently moved to [community].

Filing a deletion request.

-- 
Best regards,
Daniel Bermond




signature.asc
Description: OpenPGP digital signature

Re: [aur-general] AUR cleanup

[Stefan Husmann]

Lukas Fleischer via aur-general  writes:

> Here's an up-to-date list of duplicates reported by `aurdupes -A`. I did
> not check for false positives. Maybe somebody can go through that list
> and either remove duplicate packages or file deletion requests. I'll
> post a separate list with VCS duplicates.
>
> jabref
> * jabref http://aur.archlinux.org/packages/jabref/
> * jabref-latest http://aur.archlinux.org/packages/jabref-latest/
false positive, jabref-latest provides JabRef 5.x, which uses modern
Java VMs, whereas jabref uses Java 8. 
> nyacc
> * nyacc [extra]
> * nyacc http://aur.archlinux.org/packages/nyacc/
I just filed a deletion request.  

Best Regards

Stefan Husmann

[aur-general] AUR cleanup

[Lukas Fleischer via aur-general]

Here's an up-to-date list of duplicates reported by `aurdupes -A`. I did
not check for false positives. Maybe somebody can go through that list
and either remove duplicate packages or file deletion requests. I'll
post a separate list with VCS duplicates.

atlassian-plugin-sdk
* atlassian-plugin-sdk http://aur.archlinux.org/packages/atlassian-plugin-sdk/
* atlassian-plugin-sdk-latest 
http://aur.archlinux.org/packages/atlassian-plugin-sdk-latest/
cx
* cx http://aur.archlinux.org/packages/cx/
* cx-latest http://aur.archlinux.org/packages/cx-latest/
domoticz
* domoticz http://aur.archlinux.org/packages/domoticz/
* domoticz-latest http://aur.archlinux.org/packages/domoticz-latest/
dontpanic
* dontpanic [community]
* dontpanic-latest http://aur.archlinux.org/packages/dontpanic-latest/
dpkg
* dpkg [community]
* dpkg http://aur.archlinux.org/packages/dpkg/
firefox-i18n-ca-valencia
* firefox-i18n-ca-valencia [extra]
* firefox-i18n-ca-valencia 
http://aur.archlinux.org/packages/firefox-i18n-ca-valencia/
guile-bytestructures
* guile-bytestructures [extra]
* guile-bytestructures http://aur.archlinux.org/packages/guile-bytestructures/
icewm-themes
* icewm-themes http://aur.archlinux.org/packages/icewm-themes/
* icewm-themes-new http://aur.archlinux.org/packages/icewm-themes-new/
jabref
* jabref http://aur.archlinux.org/packages/jabref/
* jabref-latest http://aur.archlinux.org/packages/jabref-latest/
mruby
* mruby [community]
* mruby http://aur.archlinux.org/packages/mruby/
mse-mtg
* mse-mtg http://aur.archlinux.org/packages/mse-mtg/
* mse-mtg-new http://aur.archlinux.org/packages/mse-mtg-new/
nyacc
* nyacc [extra]
* nyacc http://aur.archlinux.org/packages/nyacc/
opensmtpd-filter-rspamd
* opensmtpd-filter-rspamd [community]
* opensmtpd-filter-rspamd 
http://aur.archlinux.org/packages/opensmtpd-filter-rspamd/
perl-locale-codes
* perl-locale-codes [community]
* perl-locale-codes http://aur.archlinux.org/packages/perl-locale-codes/
plymouth-theme-arch-logo
* plymouth-theme-arch-logo 
http://aur.archlinux.org/packages/plymouth-theme-arch-logo/
* plymouth-theme-arch-logo-new 
http://aur.archlinux.org/packages/plymouth-theme-arch-logo-new/
python-flask-compress
* python-flask-compress [community]
* python-flask-compress http://aur.archlinux.org/packages/python-flask-compress/
python-ordered-set
* python-ordered-set [extra]
* python-ordered-set http://aur.archlinux.org/packages/python-ordered-set/
python-pytest-pylint
* python-pytest-pylint [community]
* python-pytest-pylint http://aur.archlinux.org/packages/python-pytest-pylint/
python2-ordered-set
* python2-ordered-set [extra]
* python2-ordered-set http://aur.archlinux.org/packages/python2-ordered-set/
sigrok-firmware-fx2lafw
* sigrok-firmware-fx2lafw [community]
* sigrok-firmware-fx2lafw 
http://aur.archlinux.org/packages/sigrok-firmware-fx2lafw/
skycoin
* skycoin http://aur.archlinux.org/packages/skycoin/
* skycoin-latest http://aur.archlinux.org/packages/skycoin-latest/
smlnj
* smlnj [community]
* smlnj [multilib]
svt-vp9
* svt-vp9 [community]
* svt-vp9 http://aur.archlinux.org/packages/svt-vp9/
teamviewer
* teamviewer http://aur.archlinux.org/packages/teamviewer/
* teamviewer-latest http://aur.archlinux.org/packages/teamviewer-latest/
treeify
* treeify [community]
* treeify http://aur.archlinux.org/packages/treeify/
typora
* typora http://aur.archlinux.org/packages/typora/
* typora-latest http://aur.archlinux.org/packages/typora-latest/

atlassian-plugin-sdk
* atlassian-plugin-sdk
* http://aur.archlinux.org/packages/atlassian-plugin-sdk/
* atlassian-plugin-sdk-latest
* http://aur.archlinux.org/packages/atlassian-plugin-sdk-latest/
cx
* cx http://aur.archlinux.org/packages/cx/
* cx-latest http://aur.archlinux.org/packages/cx-latest/
domoticz
* domoticz http://aur.archlinux.org/packages/domoticz/
* domoticz-latest http://aur.archlinux.org/packages/domoticz-latest/
dontpanic
* dontpanic [community]
* dontpanic-latest http://aur.archlinux.org/packages/dontpanic-latest/
dpkg
* dpkg [community]
* dpkg http://aur.archlinux.org/packages/dpkg/
firefox-i18n-ca-valencia
* firefox-i18n-ca-valencia [extra]
* firefox-i18n-ca-valencia
* http://aur.archlinux.org/packages/firefox-i18n-ca-valencia/
guile-bytestructures
* guile-bytestructures [extra]
* guile-bytestructures
* http://aur.archlinux.org/packages/guile-bytestructures/
icewm-themes
* icewm-themes http://aur.archlinux.org/packages/icewm-themes/
* icewm-themes-new http://aur.archlinux.org/packages/icewm-themes-new/
jabref
* jabref http://aur.archlinux.org/packages/jabref/
* jabref-latest http://aur.archlinux.org/packages/jabref-latest/
mruby
* mruby [community]
* mruby http://aur.archlinux.org/packages/mruby/
mse-mtg
* mse-mtg http://aur.archlinux.org/packages/mse-mtg/
* mse-mtg-new http://aur.archlinux.org/packages/mse-mtg-new/
nyacc
* nyacc [extra]
* nyacc http://aur.archlinux.org/packages/nyacc/
opensmtpd-filter-rspamd
* opensmtpd-filter-rspamd [community]
* opensmtpd-filter-rspamd
* http://aur.archlinux.org/packages/opensmtpd

Re: [aur-general] AUR Cleanup Day September 20th 2019

[Daniel M. Capella via aur-general]

On September 20, 2019 12:20:31 PM EDT, Michael Straube via aur-general 
 wrote:
> 
> 
> Am 20.09.19 um 18:06 schrieb Michael Straube via aur-general:
> > Am 20.09.19 um 06:41 schrieb Daniel M. Capella via aur-general:
> >> _Today_ is our bi-yearly AUR Cleanup Day. It seems a few of us got
> a
> >> head start -- much appreciated.
> >>
> >>> The wiki article[1] has instructions for how to proceed and space
> to
> >>> compile our list of candidates. Here's[2] an example from a
> previous
> >>> rendition of Purge Day.
> >>>
> >>> [1]
> https://wiki.archlinux.org/index.php/DeveloperWiki:AUR_Cleanup_Day
> >>> [2]
> https://wiki.archlinux.org/index.php?title=AUR_Cleanup_Day/2010&oldid=353326
> >>> -- 
> >>> Good hunting,
> >>> Daniel 
> > 
> > Below is a list of python/python2 split packages whose python3
> versions are in [community].
> > So the python3 versions in AUR are duplicates, but not the python2
> versions.
> > 
> > I think the split packages should be removed from AUR and re-added
> as python2 only
> > versions. (Or perhaps just re-add the python2 versions that are
> dependencies for
> > other packages..)
> > 
> > https://aur.archlinux.org/packages/python-dominate/
> > https://aur.archlinux.org/packages/python-funcparserlib/
> > https://aur.archlinux.org/packages/python-inflection/
> > https://aur.archlinux.org/packages/python-pipreqs/
> > https://aur.archlinux.org/packages/python-rstr/
> > https://aur.archlinux.org/packages/python-tomlkit/
> > 
> 
> Oh sorry, I missed this one:
> 
> https://aur.archlinux.org/packages/python-yarg/
> 
> > Cheers,
> > Michael

Filed deletion requests for the rest of these.

--
Best,
Daniel 

Re: [aur-general] AUR Cleanup Day September 20th 2019

[Michael Straube via aur-general]

Am 20.09.19 um 18:06 schrieb Michael Straube via aur-general:

Am 20.09.19 um 06:41 schrieb Daniel M. Capella via aur-general:

_Today_ is our bi-yearly AUR Cleanup Day. It seems a few of us got a
head start -- much appreciated.


The wiki article[1] has instructions for how to proceed and space to
compile our list of candidates. Here's[2] an example from a previous
rendition of Purge Day.

[1] https://wiki.archlinux.org/index.php/DeveloperWiki:AUR_Cleanup_Day
[2] https://wiki.archlinux.org/index.php?title=AUR_Cleanup_Day/2010&oldid=353326
--
Good hunting,
Daniel 


Below is a list of python/python2 split packages whose python3 versions are in 
[community].
So the python3 versions in AUR are duplicates, but not the python2 versions.

I think the split packages should be removed from AUR and re-added as python2 
only
versions. (Or perhaps just re-add the python2 versions that are dependencies for
other packages..)

https://aur.archlinux.org/packages/python-dominate/
https://aur.archlinux.org/packages/python-funcparserlib/
https://aur.archlinux.org/packages/python-inflection/
https://aur.archlinux.org/packages/python-pipreqs/
https://aur.archlinux.org/packages/python-rstr/
https://aur.archlinux.org/packages/python-tomlkit/



Oh sorry, I missed this one:

https://aur.archlinux.org/packages/python-yarg/


Cheers,
Michael

Re: [aur-general] AUR Cleanup Day September 20th 2019

[Michael Straube via aur-general]

Am 20.09.19 um 06:41 schrieb Daniel M. Capella via aur-general:

_Today_ is our bi-yearly AUR Cleanup Day. It seems a few of us got a
head start -- much appreciated.


The wiki article[1] has instructions for how to proceed and space to
compile our list of candidates. Here's[2] an example from a previous
rendition of Purge Day.

[1] https://wiki.archlinux.org/index.php/DeveloperWiki:AUR_Cleanup_Day
[2] https://wiki.archlinux.org/index.php?title=AUR_Cleanup_Day/2010&oldid=353326
--
Good hunting,
Daniel 


Below is a list of python/python2 split packages whose python3 versions are in 
[community].
So the python3 versions in AUR are duplicates, but not the python2 versions.

I think the split packages should be removed from AUR and re-added as python2 
only
versions. (Or perhaps just re-add the python2 versions that are dependencies for
other packages..)

https://aur.archlinux.org/packages/python-dominate/
https://aur.archlinux.org/packages/python-funcparserlib/
https://aur.archlinux.org/packages/python-inflection/
https://aur.archlinux.org/packages/python-pipreqs/
https://aur.archlinux.org/packages/python-rstr/
https://aur.archlinux.org/packages/python-tomlkit/

Cheers,
Michael

Re: [aur-general] AUR Cleanup Day September 20th 2019

[Daniel M. Capella via aur-general]

_Today_ is our bi-yearly AUR Cleanup Day. It seems a few of us got a
head start -- much appreciated.

> The wiki article[1] has instructions for how to proceed and space to
> compile our list of candidates. Here's[2] an example from a previous
> rendition of Purge Day.
>
> [1] https://wiki.archlinux.org/index.php/DeveloperWiki:AUR_Cleanup_Day
> [2] 
> https://wiki.archlinux.org/index.php?title=AUR_Cleanup_Day/2010&oldid=353326
> --
> Good hunting,
> Daniel 


signature.asc
Description: signature

[aur-general] AUR Cleanup Day September 20th 2019

[Daniel M. Capella via aur-general]

Do you like popping other people's pimples? Gross, me neither.

Anyways, next Friday is our bi-yearly AUR Cleanup Day -- join
#archlinux-aur and BYOB.

The wiki article[1] has instructions for how to proceed and space to
compile our list of candidates. Here's[2] an example from a previous
rendition of Purge Day.

[1] https://wiki.archlinux.org/index.php/DeveloperWiki:AUR_Cleanup_Day
[2] https://wiki.archlinux.org/index.php?title=AUR_Cleanup_Day/2010&oldid=353326

--
Good hunting,
Daniel 


signature.asc
Description: signature

Re: [aur-general] AUR cleanup

[Martin Wimpress]

On 17/03/14 08:52, Alexander wrote:
> Please remove the following package:
> 
> https://aur.archlinux.org/packages/jcloisterzone2/
> 
> as it provides the same stuff as
> 
> https://aur.archlinux.org/packages/jcloisterzone/
> 

Deleted as requested.

-- 
Regards, Martin.

[aur-general] AUR cleanup

[Alexander]

Please remove the following package:

https://aur.archlinux.org/packages/jcloisterzone2/

as it provides the same stuff as

https://aur.archlinux.org/packages/jcloisterzone/

--
With regards,
Polovtcev Alexander

Re: [aur-general] AUR cleanup policy

[Sam S.]

> The search returns a dozen unmaintained packages and you have to look
> through them [...] I prefer to have a reasonable signal-to-noise ratio.

This could be solved by having search results list "stale" packages
last (and/or greyed-out or something).

"stale" could be defined as "is unmaintained and has not been updated
in 6 months", so it could be automatically derived without introducing
an extra flag..

Re: [aur-general] AUR cleanup policy

[Karol Blazewicz]

On Thu, Jun 20, 2013 at 1:27 AM, Karol Woźniak  wrote:
> On 19 June 2013 23:49, Doug Newgard  wrote:
>> 
>>
>> I don't think anyone's suggesting just removing them en mass, but removing 
>> them if upstream is gone, they don't build, and haven't been updated in a 
>> long time. In that situation, what would the reason be to keep them?
>>
>
> For example there might be some patches already applied which could
> help a possible future maintainer to bring the package back to life.
> And even if not, someone might find an application he needs through
> our search and then adopt it. I sometimes do it myself, instead of
> googling around for something, I go straight to yaourt -Ss with some
> keywords :).

The search returns a dozen unmaintained packages and you have to look
through them, check the PKGBUILDs for any bits that are still
relevant, find where upstream has gone etc. Sometimes the first
package will be what you need, other times none of them will fit.
I don't want to remove valuable info, but I prefer to have a
reasonable signal-to-noise ratio.

>
> --
> Pozdrawiam,
> Karol Woźniak
> aka Kenji Takahashi
>  @  kenji.sx
> "Don't shoot the messenger."

Re: [aur-general] AUR cleanup policy

[Karol Woźniak]

On 19 June 2013 23:49, Doug Newgard  wrote:
> 
>
> I don't think anyone's suggesting just removing them en mass, but removing 
> them if upstream is gone, they don't build, and haven't been updated in a 
> long time. In that situation, what would the reason be to keep them?
>

For example there might be some patches already applied which could
help a possible future maintainer to bring the package back to life.
And even if not, someone might find an application he needs through
our search and then adopt it. I sometimes do it myself, instead of
googling around for something, I go straight to yaourt -Ss with some
keywords :).

--
Pozdrawiam,
Karol Woźniak
aka Kenji Takahashi
 @  kenji.sx
"Don't shoot the messenger."

Re: [aur-general] AUR cleanup policy

[Karol Woźniak]

On 19 June 2013 23:48, Karol Blazewicz  wrote:
>
> How can I get the sources? If you provide a mirror, I think it's OK.
> When talking about ded upstream, I'm not talking about upstream
> website being 404, I'm talking about the sources for the package being
> gone.

We have a different definitions of "dead upstream" then :).
I consider it dead when people are gone, not necessarily taking their
past work with them.

>
>
> BTW, please don't top-post.

Dah, damn gmail caught me into this again. Sorry.

--
Pozdrawiam,
Karol Woźniak
aka Kenji Takahashi
 @  kenji.sx
"Don't shoot the messenger."

Re: [aur-general] AUR cleanup policy

[Doug Newgard]

> Date: Wed, 19 Jun 2013 23:44:44 +0200
> From: wozni...@gmail.com
> To: aur-general@archlinux.org
> Subject: Re: [aur-general] AUR cleanup policy
>
> I am against removing "dead upstream" packages, unless upstream is
> completely gone, i.e. there is no way to obtain necessary files. I am
> maintaining at least two packages with upstream long dead, but (after my
> patches, of course) they're still working and are used by some people.

I don't think anyone's suggesting just removing them en mass, but removing them 
if upstream is gone, they don't build, and haven't been updated in a long time. 
In that situation, what would the reason be to keep them?

>
>
> On 19 June 2013 22:49, Connor Behan  wrote:
>
>> On 19/06/13 12:53 PM, Karol Blazewicz wrote:
>>> On Wed, Jun 19, 2013 at 8:57 PM, Xyne  wrote:
>>>> On 2013-06-18 13:48 +0200
>>>> Karol Blazewicz wrote:
>>>>
>>>>> What's the policy wrt to packages that have been submitted years ago
>>>>> and are neither developed upstream nor maintained in the AUR since
>>>>> then? Just let them be or get rid of them as they're of no use?
>>>>> If there're old unmaintained packages foo and foo-git, is it OK to
>>>>> request removing at least one of them? Which one?
>>>>>
>>>>> https://aur.archlinux.org/packages/a4/
>>>>> https://aur.archlinux.org/packages/a4-bzr/
>>>>>
>>>>> The PKGBUILD need updating but it still builds and runs so I can pick
>>>>> it up, update and orphan it. I don't know which filetypes does it open
>>>>> (.odp is not recognized) and the editor doesn't work, so you can't
>>>>> create a new presentation from scratch.
>>>>> It's man page is of no help.
>>>>
>>>> Packages should only be removed if they conflict with policy (copies of
>>>> official repo packages, malware, illegal packages) or if upstream is
>> dead. Even
>>>> if the PKGBUILD is an ancient relic from the age of Judd in need of a
>> complete
>>>> rewrite, we tend to leave them as placeholders.
>>> AUR lacks 'mark package as broken' feature, I guess I can leave a
>>> comment that says it's broken + post compile errors etc. Maybe
>>> somebody will post a fix ...
>>>
>>> With regard to dead upstream, do I have to Google around to see if
>>> they moved it somewhere or is it OK to lazily submit for deletion? I'm
>>> talking about orphaned packages w/o an updated PKGBUILD in the
>>> comments or at least a comment that says upstream moved to a different
>>> place.
>>>
>>
>> I would only submit such packages for deletion if their PKGBUILDs do a
>> simple ./configure && make && make install. If there are non-trivial
>> patches, even if they are long broken, I would leave it in the AUR. When
>> someone comes along and says "I want to make this dead package work
>> again" patches that once work can be a useful starting point.
>>
>>
>
>
> --
> Pozdrawiam,
> Karol Woźniak
> aka Kenji Takahashi
> @ kenji.sx
> "Don't shoot the messenger."

Re: [aur-general] AUR cleanup policy

[Karol Blazewicz]

On Wed, Jun 19, 2013 at 11:44 PM, Karol Woźniak  wrote:
> I am against removing "dead upstream" packages, unless upstream is
> completely gone, i.e. there is no way to obtain necessary files. I am
> maintaining at least two packages with upstream long dead, but (after my
> patches, of course) they're still working and are used by some people.

How can I get the sources? If you provide a mirror, I think it's OK.
When talking about ded upstream, I'm not talking about upstream
website being 404, I'm talking about the sources for the package being
gone.

BTW, please don't top-post.

Re: [aur-general] AUR cleanup policy

[Karol Woźniak]

I am against removing "dead upstream" packages, unless upstream is
completely gone, i.e. there is no way to obtain necessary files. I am
maintaining at least two packages with upstream long dead, but (after my
patches, of course) they're still working and are used by some people.


On 19 June 2013 22:49, Connor Behan  wrote:

> On 19/06/13 12:53 PM, Karol Blazewicz wrote:
> > On Wed, Jun 19, 2013 at 8:57 PM, Xyne  wrote:
> >> On 2013-06-18 13:48 +0200
> >> Karol Blazewicz wrote:
> >>
> >>> What's the policy wrt to packages that have been submitted years ago
> >>> and are neither developed upstream nor maintained in the AUR since
> >>> then? Just let them be or get rid of them as they're of no use?
> >>> If there're old unmaintained packages foo and foo-git, is it OK to
> >>> request removing at least one of them? Which one?
> >>>
> >>> https://aur.archlinux.org/packages/a4/
> >>> https://aur.archlinux.org/packages/a4-bzr/
> >>>
> >>> The PKGBUILD need updating but it still builds and runs so I can pick
> >>> it up, update and orphan it. I don't know which filetypes does it open
> >>> (.odp is not recognized) and the editor doesn't work, so you can't
> >>> create a new presentation from scratch.
> >>> It's man page is of no help.
> >>
> >> Packages should only be removed if they conflict with policy (copies of
> >> official repo packages, malware, illegal packages) or if upstream is
> dead. Even
> >> if the PKGBUILD is an ancient relic from the age of Judd in need of a
> complete
> >> rewrite, we tend to leave them as placeholders.
> > AUR lacks 'mark package as broken' feature, I guess I can leave a
> > comment that says it's broken + post compile errors etc. Maybe
> > somebody will post a fix ...
> >
> > With regard to dead upstream, do I have to Google around to see if
> > they moved it somewhere or is it OK to lazily submit for deletion? I'm
> > talking about orphaned packages w/o an updated PKGBUILD in the
> > comments or at least a comment that says upstream moved to a different
> > place.
> >
>
> I would only submit such packages for deletion if their PKGBUILDs do a
> simple ./configure && make && make install. If there are non-trivial
> patches, even if they are long broken, I would leave it in the AUR. When
> someone comes along and says "I want to make this dead package work
> again" patches that once work can be a useful starting point.
>
>


-- 
Pozdrawiam,
Karol Woźniak
aka Kenji Takahashi
 @  kenji.sx
"Don't shoot the messenger."

Re: [aur-general] AUR cleanup policy

[Connor Behan]

On 19/06/13 12:53 PM, Karol Blazewicz wrote:
> On Wed, Jun 19, 2013 at 8:57 PM, Xyne  wrote:
>> On 2013-06-18 13:48 +0200
>> Karol Blazewicz wrote:
>>
>>> What's the policy wrt to packages that have been submitted years ago
>>> and are neither developed upstream nor maintained in the AUR since
>>> then? Just let them be or get rid of them as they're of no use?
>>> If there're old unmaintained packages foo and foo-git, is it OK to
>>> request removing at least one of them? Which one?
>>>
>>> https://aur.archlinux.org/packages/a4/
>>> https://aur.archlinux.org/packages/a4-bzr/
>>>
>>> The PKGBUILD need updating but it still builds and runs so I can pick
>>> it up, update and orphan it. I don't know which filetypes does it open
>>> (.odp is not recognized) and the editor doesn't work, so you can't
>>> create a new presentation from scratch.
>>> It's man page is of no help.
>>
>> Packages should only be removed if they conflict with policy (copies of
>> official repo packages, malware, illegal packages) or if upstream is dead. 
>> Even
>> if the PKGBUILD is an ancient relic from the age of Judd in need of a 
>> complete
>> rewrite, we tend to leave them as placeholders.
> AUR lacks 'mark package as broken' feature, I guess I can leave a
> comment that says it's broken + post compile errors etc. Maybe
> somebody will post a fix ...
>
> With regard to dead upstream, do I have to Google around to see if
> they moved it somewhere or is it OK to lazily submit for deletion? I'm
> talking about orphaned packages w/o an updated PKGBUILD in the
> comments or at least a comment that says upstream moved to a different
> place.
>

I would only submit such packages for deletion if their PKGBUILDs do a
simple ./configure && make && make install. If there are non-trivial
patches, even if they are long broken, I would leave it in the AUR. When
someone comes along and says "I want to make this dead package work
again" patches that once work can be a useful starting point.



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] AUR cleanup policy

[Karol Blazewicz]

On Wed, Jun 19, 2013 at 8:57 PM, Xyne  wrote:
> On 2013-06-18 13:48 +0200
> Karol Blazewicz wrote:
>
>>What's the policy wrt to packages that have been submitted years ago
>>and are neither developed upstream nor maintained in the AUR since
>>then? Just let them be or get rid of them as they're of no use?
>>If there're old unmaintained packages foo and foo-git, is it OK to
>>request removing at least one of them? Which one?
>>
>>https://aur.archlinux.org/packages/a4/
>>https://aur.archlinux.org/packages/a4-bzr/
>>
>>The PKGBUILD need updating but it still builds and runs so I can pick
>>it up, update and orphan it. I don't know which filetypes does it open
>>(.odp is not recognized) and the editor doesn't work, so you can't
>>create a new presentation from scratch.
>>It's man page is of no help.
>
>
> Packages should only be removed if they conflict with policy (copies of
> official repo packages, malware, illegal packages) or if upstream is dead. 
> Even
> if the PKGBUILD is an ancient relic from the age of Judd in need of a complete
> rewrite, we tend to leave them as placeholders.

AUR lacks 'mark package as broken' feature, I guess I can leave a
comment that says it's broken + post compile errors etc. Maybe
somebody will post a fix ...

With regard to dead upstream, do I have to Google around to see if
they moved it somewhere or is it OK to lazily submit for deletion? I'm
talking about orphaned packages w/o an updated PKGBUILD in the
comments or at least a comment that says upstream moved to a different
place.


> .odp is a Libre-/OpenOffice file extension btw.

I know, I didn't expect it tow work, but I have no idea what kind of
presentations are they talking about.

> Regards,
> Xyne

Re: [aur-general] AUR cleanup policy

[Xyne]

On 2013-06-18 13:48 +0200
Karol Blazewicz wrote:

>What's the policy wrt to packages that have been submitted years ago
>and are neither developed upstream nor maintained in the AUR since
>then? Just let them be or get rid of them as they're of no use?
>If there're old unmaintained packages foo and foo-git, is it OK to
>request removing at least one of them? Which one?
>
>https://aur.archlinux.org/packages/a4/
>https://aur.archlinux.org/packages/a4-bzr/
>
>The PKGBUILD need updating but it still builds and runs so I can pick
>it up, update and orphan it. I don't know which filetypes does it open
>(.odp is not recognized) and the editor doesn't work, so you can't
>create a new presentation from scratch.
>It's man page is of no help.


Packages should only be removed if they conflict with policy (copies of
official repo packages, malware, illegal packages) or if upstream is dead. Even
if the PKGBUILD is an ancient relic from the age of Judd in need of a complete
rewrite, we tend to leave them as placeholders.

.odp is a Libre-/OpenOffice file extension btw.

Regards,
Xyne

[aur-general] AUR cleanup policy

[Karol Blazewicz]

What's the policy wrt to packages that have been submitted years ago
and are neither developed upstream nor maintained in the AUR since
then? Just let them be or get rid of them as they're of no use?
If there're old unmaintained packages foo and foo-git, is it OK to
request removing at least one of them? Which one?

https://aur.archlinux.org/packages/a4/
https://aur.archlinux.org/packages/a4-bzr/

The PKGBUILD need updating but it still builds and runs so I can pick
it up, update and orphan it. I don't know which filetypes does it open
(.odp is not recognized) and the editor doesn't work, so you can't
create a new presentation from scratch.
It's man page is of no help.

Re: [aur-general] AUR cleanup

[Bartłomiej Piotrowski]

On 2013-05-29 17:06, Alexander wrote:
> Please remove the following packages:
> 
> https://aur.archlinux.org/packages/antlr3.5/
> https://aur.archlinux.org/packages/antlr3/
> 
> 
> Both of them provide the same thing and can be replaced by the package
> in [extra]:
> 
> https://www.archlinux.org/packages/extra/any/java-antlr3/
> 

Done.

-- 
Bartłomiej Piotrowski
http://bpiotrowski.pl/



signature.asc
Description: OpenPGP digital signature

[aur-general] AUR cleanup

[Alexander]

Please remove the following packages:

https://aur.archlinux.org/packages/antlr3.5/
https://aur.archlinux.org/packages/antlr3/

Both of them provide the same thing and can be replaced by the package 
in [extra]:


https://www.archlinux.org/packages/extra/any/java-antlr3/

--
With regards,
Polovtcev Alexander

Re: [aur-general] AUR cleanup - Removal Request

[Nicola Bignami]

- Messaggio originale -
> Damn, sorry. Done now.
> 
> Bartłomiej Piotrowski

Thanks.

Re: [aur-general] AUR cleanup - Removal Request

[Bartłomiej Piotrowski]

Damn, sorry. Done now.

Bartłomiej Piotrowski

Re: [aur-general] AUR cleanup - Removal Request

[Nicola Bignami]

Il 20/11/2011 10:38, Bartłomiej Piotrowski ha scritto:

Name: asym

Merged into asym-git.


Name: daphne
Name: gnash-git
Name: squidguard

I'm not sure about naming scheme of "replacements".


Indeed.
I'll try to contact the maintainers.


Name: drakfire-caffe-gtk3

Merged into drakfire-caffe-gtk-theme.


Name: agnclient
Name: android-compatibility-package
Name: firefox-branded-bin-es-es
Name: firefox-branded-bin-hu
Name: firefox-beta-bin-hu
Name: firefox-nightly-es
Name: firefox4-rc2-es
Name: freecol-unstable
Name: python-msnlib
Name: python3-sqlalchemy and python-sqlalchemy-py3k
Name: python3-yaml
Name: python-yaml-py
Name: zen-kernel-stable-latest

Removed.


Name: android-compatibility-package - 
https://aur.archlinux.org/packages.php?ID=52967
Name: python-msnlib - https://aur.archlinux.org/packages.php?ID=17919
Name: python-yaml-py - https://aur.archlinux.org/packages.php?ID=12769


Still present in AUR.




Name: icecat-as

Merged into icecat-ast.


Name: icecat-bin

Merged into icecat.


Name: plasma-theme-gremix

Merged into plasma-theme-helium.


Name: trash

Merged into trash-cli.

Bartłomiej Piotrowski

Re: [aur-general] AUR cleanup - Removal Request

[Bartłomiej Piotrowski]

> Name: asym
Merged into asym-git.

> Name: daphne
> Name: gnash-git
> Name: squidguard
I'm not sure about naming scheme of "replacements".

> Name: drakfire-caffe-gtk3
Merged into drakfire-caffe-gtk-theme.

> Name: agnclient
> Name: android-compatibility-package
> Name: firefox-branded-bin-es-es
> Name: firefox-branded-bin-hu
> Name: firefox-beta-bin-hu
> Name: firefox-nightly-es
> Name: firefox4-rc2-es
> Name: freecol-unstable
> Name: python-msnlib
> Name: python3-sqlalchemy and python-sqlalchemy-py3k
> Name: python3-yaml
> Name: python-yaml-py
> Name: zen-kernel-stable-latest
Removed.

> Name: icecat-as
Merged into icecat-ast.

> Name: icecat-bin
Merged into icecat.

> Name: plasma-theme-gremix
Merged into plasma-theme-helium.

> Name: trash
Merged into trash-cli.

Bartłomiej Piotrowski





signature.asc
Description: OpenPGP digital signature

Re: [aur-general] AUR cleanup - Removal Request

[Stefan Wilkens]

2011/11/19 Karol Blazewicz :
> On Sat, Nov 19, 2011 at 12:25 PM, Nicola Bignami
>  wrote:
>> Please remove the following packages:
>>
>
> 
>
> Please include the names of the packages so that we know what has been 
> removed.
>

same list as before, names provided:

Name: agnclient
URL: https://aur.archlinux.org/packages.php?ID=41942
Reason: Orphan, outdated, replaced by package
https://aur.archlinux.org/packages.php?ID=41943

Name: android-compatibility-package
URL: https://aur.archlinux.org/packages.php?ID=52967
Reason: Orphan, outdated, replaced by package
https://aur.archlinux.org/packages.php?ID=53266

Name: asym
URL: https://aur.archlinux.org/packages.php?ID=27418
Reason: Orphan, does not compile, has been replaced by
https://aur.archlinux.org/packages.php?ID=39218

Name: daphne
URL: https://aur.archlinux.org/packages.php?ID=7615
Reason: Orphan, outdated, replaced by
https://aur.archlinux.org/packages.php?ID=15268

Name: drakfire-caffe-gtk3
URL: https://aur.archlinux.org/packages.php?ID=52461
Reason: Orphan, dublicate of https://aur.archlinux.org/packages.php?ID=48638

Name: firefox-branded-bin-es-es
URL: https://aur.archlinux.org/packages.php?ID=38909
Reason: Orphan, Out of Date, abandoned as present in [extra]

Name: firefox-branded-bin-hu
URL: https://aur.archlinux.org/packages.php?ID=47652
Reason: Orphan, Out of Date, abandoned as present in [extra]

Name: firefox-beta-bin-hu
URL: https://aur.archlinux.org/packages.php?ID=42191
Reason: Old RC, Orphan, Out of Date, current stable version present in [extra]

Name: firefox-nightly-es
URL: https://aur.archlinux.org/packages.php?ID=46429
Reason: Old RC, Orphan, Out of Date, current stable version present in [extra]

Name: firefox4-rc2-es
URL: https://aur.archlinux.org/packages.php?ID=47567
Reason: Old RC, Orphan, Out of Date, current stable version present in [extra]

Name: freecol-unstable
URL: https://aur.archlinux.org/packages.php?ID=49591
Reason: Orphan, Out of Date, current stable version present in [community]

Name: gnash-git
URL: https://aur.archlinux.org/packages.php?ID=49364
Reason: Orphan, outdated, provides the same package as maintained
https://aur.archlinux.org/packages.php?ID=39699

Name: icecat-as
URL: https://aur.archlinux.org/packages.php?ID=38385
Reason: Orphan, outdated, replaced by
https://aur.archlinux.org/packages.php?ID=48162

Name: icecat-bin
URL: https://aur.archlinux.org/packages.php?ID=18296
Reason: Orphan, outdated, provides the same package as
https://aur.archlinux.org/packages.php?ID=14169

Name: plasma-theme-gremix
URL: https://aur.archlinux.org/packages.php?ID=52832
Reason: Orphan, Out of Date, replaced by maintained
https://aur.archlinux.org/packages.php?ID=53085

Name: python-msnlib
URL: https://aur.archlinux.org/packages.php?ID=17919
Reason: Orphan, outdated, has been updated and renamed as
https://aur.archlinux.org/packages.php?ID=53134

Name: python3-sqlalchemy and python-sqlalchemy-py3k
URL: https://aur.archlinux.org/packages.php?ID=42252 and
https://aur.archlinux.org/packages.php?ID=42161
Reason: Orphan and is in [community] as
http://www.archlinux.org/packages/community/any/python-sqlalchemy/

Name: python3-yaml
URL: https://aur.archlinux.org/packages.php?ID=38214
Reason: Orphan, and provided by package in [community]
http://www.archlinux.org/packages/community/x86_64/python-yaml/

Name: python-yaml-py
URL: https://aur.archlinux.org/packages.php?ID=12769
Reason: Orphan, and provided by package in [community]
http://www.archlinux.org/packages/community/i686/python2-yaml/

Name: squidguard
URL: https://aur.archlinux.org/packages.php?ID=1464
Reason: Orphan, outdated, replaced by maintained
https://aur.archlinux.org/packages.php?ID=24284

Name: trash
URL: https://aur.archlinux.org/packages.php?ID=9874
Reason: Orphan, replaced ue to an upstream name change by
https://aur.archlinux.org/packages.php?ID=19076

Name: zen-kernel-stable-latest
URL: https://aur.archlinux.org/packages.php?ID=49554
Reason: Orphan, outdated, replaced by maintained
https://aur.archlinux.org/packages.php?ID=44068

Re: [aur-general] AUR cleanup - Removal Request

[Karol Blazewicz]

On Sat, Nov 19, 2011 at 12:25 PM, Nicola Bignami
 wrote:
> Please remove the following packages:
>



Please include the names of the packages so that we know what has been removed.

Re: [aur-general] AUR cleanup - Removal Request

[Nicola Bignami]

Please remove the following packages:

https://aur.archlinux.org/packages.php?ID=41942Orphan, outdated, 
replaced by package https://aur.archlinux.org/packages.php?ID=41943


https://aur.archlinux.org/packages.php?ID=52967 Orphan, outdated, 
replaced by package https://aur.archlinux.org/packages.php?ID=53266


https://aur.archlinux.org/packages.php?ID=27418 Orphan, does not 
compile, has been replaced by 
https://aur.archlinux.org/packages.php?ID=39218


https://aur.archlinux.org/packages.php?ID=7615 Orphan, outdated, 
replaced by https://aur.archlinux.org/packages.php?ID=15268


https://aur.archlinux.org/packages.php?ID=52461 Orphan, dublicate of 
https://aur.archlinux.org/packages.php?ID=48638


https://aur.archlinux.org/packages.php?ID=38909 Orphan, Out of Date, 
abandoned as present in [extra]


https://aur.archlinux.org/packages.php?ID=47652 Orphan, Out of Date, 
abandoned as present in [extra]


https://aur.archlinux.org/packages.php?ID=42191 Old RC, Orphan, Out of 
Date, current stable version present in [extra]


https://aur.archlinux.org/packages.php?ID=46429 Old RC, Orphan, Out of 
Date, current stable version present in [extra]


https://aur.archlinux.org/packages.php?ID=47567 Old RC, Orphan, Out of 
Date, current stable version present in [extra]


https://aur.archlinux.org/packages.php?ID=49591 Orphan, Out of Date, 
current stable version present in [community]


https://aur.archlinux.org/packages.php?ID=49364 Orphan, outdated, 
provides the same package as maintained 
https://aur.archlinux.org/packages.php?ID=39699


https://aur.archlinux.org/packages.php?ID=38385 Orphan, outdated, 
replaced by https://aur.archlinux.org/packages.php?ID=48162


https://aur.archlinux.org/packages.php?ID=18296 Orphan, outdated, 
provides the same package as https://aur.archlinux.org/packages.php?ID=14169


https://aur.archlinux.org/packages.php?ID=52832 Orphan, Out of Date, 
replaced by maintained https://aur.archlinux.org/packages.php?ID=53085


https://aur.archlinux.org/packages.php?ID=17919 Orphan, outdated, has 
been updated and renamed as https://aur.archlinux.org/packages.php?ID=53134


https://aur.archlinux.org/packages.php?ID=42252 and 
https://aur.archlinux.org/packages.php?ID=42161 Orphan and is in 
[community] as 
http://www.archlinux.org/packages/community/any/python-sqlalchemy/


https://aur.archlinux.org/packages.php?ID=38214 Orphan, and provided by 
package in [community] 
http://www.archlinux.org/packages/community/x86_64/python-yaml/


https://aur.archlinux.org/packages.php?ID=12769 Orphan, and provided by 
package in [community] 
http://www.archlinux.org/packages/community/i686/python2-yaml/


https://aur.archlinux.org/packages.php?ID=1464 Orphan, outdated, 
replaced by maintained https://aur.archlinux.org/packages.php?ID=24284


https://aur.archlinux.org/packages.php?ID=9874 Orphan, replaced ue to an 
upstream name change by https://aur.archlinux.org/packages.php?ID=19076


https://aur.archlinux.org/packages.php?ID=49554 Orphan, outdated, 
replaced by maintained https://aur.archlinux.org/packages.php?ID=44068

Re: [aur-general] AUR cleanup

[Nicola Bignami]

Update:

The list has seen a rapid growth: there are now 90+ packages proposed 
for deletion and about 15 packages that could either go or stay.

I'm preparing the first removal request to submit here in the ML.

If anybody wants to join our efforts, please write on the discussion I 
opened on my ArchWiki user page [0].



[0]: https://wiki.archlinux.org/index.php/User_talk:Thebishop

Re: [aur-general] AUR cleanup

[Nicola Bignami]

Hi there.
I want to post a little update to the initiative.

As for now we have found 26 packages eligible to deletion. More packages 
are still out there: who wants to help may use this discussion [0] on my 
user page.
The next week I want to submit the first removal request to the ML, so 
if someone believe that some of the packages of the list should not be 
deleted can add some comment on the same page [0].


[0]: https://wiki.archlinux.org/index.php/User_talk:Thebishop

Re: [aur-general] AUR cleanup

[Nicola Bignami]

Il 07/11/2011 21:00, Sven-Hendrik Haase ha scritto:

Looks like you are good to go then. As already suggested, a wiki page
page (your user page would be fine) for this would likely be a good idea.


I've opened a discussion on my user page.

https://wiki.archlinux.org/index.php/User_talk:Thebishop

Re: [aur-general] AUR cleanup

[gadget3000]

On 7 November 2011 19:40, Matej Ľach  wrote:

> On 07/11/11 19:30, 郑文辉 wrote:
>
>> 在 2011-11-8 上午3:09，"Stefan 
>> Wilkens"
>> >写道：
>>
>>  2011/11/7 Nicola 
>> Bignami
>>> >:
>>>
 I see that there are more than 6700 orphan packages. Of those, more than
 2400 are also flagged out of date (some packages have not been updated

>>> since
>>>
 2007).
 Many packages are only waiting for a new maintainer but I think that
 many
 are only waiting to be scrapped as they're already been replaced by some
 other package in the AUR or in the community repository (or just become
 obsolete).

 I'm wondering if the time has come to look into them to find out what

>>> worth
>>>
 to keep and what have to be removed and thus do some cleanup.

 If can be useful, I can start working on it.

  Keeping the user repository clean and up-to-date sounds very KISS and
>>> Arch to me, but some criteria should be stated. Many packages that
>>> depend on python v2, for instance, are simply broken because they were
>>> not properly updated to reflect repository changes [1]. The goal with
>>> these packages should likely be to adapt the build, not consider them
>>> broken.
>>>
>>> Perhaps create a page on the wiki so that this work can be shared with
>>> others in the community. Such a page might also allow us to have a
>>> nice final list that can be fed to the nearest TU in one go, rather
>>> than a flood of deletion requests.
>>>
>>> Should you initiate this, I would surely help out. Who knows what fun
>>> software one might run into :)
>>>
>>> [1] 
>>> http://www.archlinux.org/news/**python-is-now-python-3/
>>>
>>
>> Maybe we should have some category system to help manage the PKGBUILDs in
>> AUR.We can tag them by "package whith third-party patch" , "CVS package"
>> ,"SVN package","GIT package","nightly builds","Beta version","need
>> review","need to be dropped" and so on.Let the community vote for each tag
>> to produce a squence of some tag ie. "need to be dropped" to let the TUs
>> working on.
>>
> (As a user) - I think this is a great idea.
>
> --
> Best Regards,
> Matej Ľach
>
> e-mail: cont...@matej-lach.net
> web: www.matej-lach.net
>
> Use Arch Linux on your desktop and CyanogenMod on your mobile device!
>
>
>
aurdupes is good place to start because it lists packages that already
exist in repos, among other things.

During my AUR cleaning over summer I made a script to help me find packages
that could be deleted. It's very buggy and incomplete but I've attached it
for you or anyone else to use or build upon.

Gadget3000


aurtools
Description: Binary data

Re: [aur-general] AUR cleanup

[Sven-Hendrik Haase]

On 07.11.2011 20:16, Nicola Bignami wrote:
> - Messaggio originale -
>> On 07.11.2011 18:41, Nicola Bignami wrote:
>>> I see that there are more than 6700 orphan packages. Of those, more
>>> than 2400 are also flagged out of date (some packages have not been
>>> updated since 2007).
>>> Many packages are only waiting for a new maintainer but I think that
>>> many are only waiting to be scrapped as they're already been replaced
>>> by some other package in the AUR or in the community repository (or
>>> just become obsolete).
>>>
>>> I'm wondering if the time has come to look into them to find out what
>>> worth to keep and what have to be removed and thus do some cleanup.
>>>
>>> If can be useful, I can start working on it.
>> Of course, clean up work like that is always appreciated. Keep in mind
>> though that people might resubmit missing but obsolete software to AUR.
>> Technically, there is no rule against that.
> I know.
>  
>> So in case you do this work, you should look for packages that truly
>> have no need for existence anymore as opposed to merely software that
>> somebody forked and improved. Dead upstream sucks but it's no an
>> immediate reason to drop something from AUR. in my opinion.
>>
>> Good candidates for deletion: Unmaintained downstream variants of
>> software patched with various little things, software that switched vcs
>> but has old vcs packages remaining in AUR, totally broken and
>> unmaintained software, renamed packages that didn't get deleted. You get
>> the idea.
> That's exactly what I have in mind, and that's why IMHO it's necessary look 
> carefully to the packages and not just delete them because they're orphan and 
> out of date.
>
>> -- Sven-Hendrik
Looks like you are good to go then. As already suggested, a wiki page
page (your user page would be fine) for this would likely be a good idea.

Re: [aur-general] AUR cleanup

[Matej Ľach]

On 07/11/11 19:30, 郑文辉 wrote:

在 2011-11-8 上午3:09，"Stefan Wilkens"写道：


2011/11/7 Nicola Bignami:

I see that there are more than 6700 orphan packages. Of those, more than
2400 are also flagged out of date (some packages have not been updated

since

2007).
Many packages are only waiting for a new maintainer but I think that many
are only waiting to be scrapped as they're already been replaced by some
other package in the AUR or in the community repository (or just become
obsolete).

I'm wondering if the time has come to look into them to find out what

worth

to keep and what have to be removed and thus do some cleanup.

If can be useful, I can start working on it.


Keeping the user repository clean and up-to-date sounds very KISS and
Arch to me, but some criteria should be stated. Many packages that
depend on python v2, for instance, are simply broken because they were
not properly updated to reflect repository changes [1]. The goal with
these packages should likely be to adapt the build, not consider them
broken.

Perhaps create a page on the wiki so that this work can be shared with
others in the community. Such a page might also allow us to have a
nice final list that can be fed to the nearest TU in one go, rather
than a flood of deletion requests.

Should you initiate this, I would surely help out. Who knows what fun
software one might run into :)

[1] http://www.archlinux.org/news/python-is-now-python-3/


Maybe we should have some category system to help manage the PKGBUILDs in
AUR.We can tag them by "package whith third-party patch" , "CVS package"
,"SVN package","GIT package","nightly builds","Beta version","need
review","need to be dropped" and so on.Let the community vote for each tag
to produce a squence of some tag ie. "need to be dropped" to let the TUs
working on.

(As a user) - I think this is a great idea.

--
Best Regards,
Matej Ľach

e-mail: cont...@matej-lach.net
web: www.matej-lach.net

Use Arch Linux on your desktop and CyanogenMod on your mobile device!

Re: [aur-general] AUR cleanup

[郑文辉]

在 2011-11-8 上午3:09，"Stefan Wilkens" 写道：

> 2011/11/7 Nicola Bignami :
> > I see that there are more than 6700 orphan packages. Of those, more than
> > 2400 are also flagged out of date (some packages have not been updated
> since
> > 2007).
> > Many packages are only waiting for a new maintainer but I think that many
> > are only waiting to be scrapped as they're already been replaced by some
> > other package in the AUR or in the community repository (or just become
> > obsolete).
> >
> > I'm wondering if the time has come to look into them to find out what
> worth
> > to keep and what have to be removed and thus do some cleanup.
> >
> > If can be useful, I can start working on it.
> >
>
> Keeping the user repository clean and up-to-date sounds very KISS and
> Arch to me, but some criteria should be stated. Many packages that
> depend on python v2, for instance, are simply broken because they were
> not properly updated to reflect repository changes [1]. The goal with
> these packages should likely be to adapt the build, not consider them
> broken.
>
> Perhaps create a page on the wiki so that this work can be shared with
> others in the community. Such a page might also allow us to have a
> nice final list that can be fed to the nearest TU in one go, rather
> than a flood of deletion requests.
>
> Should you initiate this, I would surely help out. Who knows what fun
> software one might run into :)
>
> [1] http://www.archlinux.org/news/python-is-now-python-3/


Maybe we should have some category system to help manage the PKGBUILDs in
AUR.We can tag them by "package whith third-party patch" , "CVS package"
,"SVN package","GIT package","nightly builds","Beta version","need
review","need to be dropped" and so on.Let the community vote for each tag
to produce a squence of some tag ie. "need to be dropped" to let the TUs
working on.

Re: [aur-general] AUR cleanup

[Nicola Bignami]

- Messaggio originale -
> On 07.11.2011 18:41, Nicola Bignami wrote:
> > I see that there are more than 6700 orphan packages. Of those, more
> > than 2400 are also flagged out of date (some packages have not been
> > updated since 2007).
> > Many packages are only waiting for a new maintainer but I think that
> > many are only waiting to be scrapped as they're already been replaced
> > by some other package in the AUR or in the community repository (or
> > just become obsolete).
> > 
> > I'm wondering if the time has come to look into them to find out what
> > worth to keep and what have to be removed and thus do some cleanup.
> > 
> > If can be useful, I can start working on it.
> Of course, clean up work like that is always appreciated. Keep in mind
> though that people might resubmit missing but obsolete software to AUR.
> Technically, there is no rule against that.

I know.
 
> So in case you do this work, you should look for packages that truly
> have no need for existence anymore as opposed to merely software that
> somebody forked and improved. Dead upstream sucks but it's no an
> immediate reason to drop something from AUR. in my opinion.
> 
> Good candidates for deletion: Unmaintained downstream variants of
> software patched with various little things, software that switched vcs
> but has old vcs packages remaining in AUR, totally broken and
> unmaintained software, renamed packages that didn't get deleted. You get
> the idea.

That's exactly what I have in mind, and that's why IMHO it's necessary look 
carefully to the packages and not just delete them because they're orphan and 
out of date.

> -- Sven-Hendrik

Re: [aur-general] AUR cleanup

[Stefan Wilkens]

2011/11/7 Nicola Bignami :
> I see that there are more than 6700 orphan packages. Of those, more than
> 2400 are also flagged out of date (some packages have not been updated since
> 2007).
> Many packages are only waiting for a new maintainer but I think that many
> are only waiting to be scrapped as they're already been replaced by some
> other package in the AUR or in the community repository (or just become
> obsolete).
>
> I'm wondering if the time has come to look into them to find out what worth
> to keep and what have to be removed and thus do some cleanup.
>
> If can be useful, I can start working on it.
>

Keeping the user repository clean and up-to-date sounds very KISS and
Arch to me, but some criteria should be stated. Many packages that
depend on python v2, for instance, are simply broken because they were
not properly updated to reflect repository changes [1]. The goal with
these packages should likely be to adapt the build, not consider them
broken.

Perhaps create a page on the wiki so that this work can be shared with
others in the community. Such a page might also allow us to have a
nice final list that can be fed to the nearest TU in one go, rather
than a flood of deletion requests.

Should you initiate this, I would surely help out. Who knows what fun
software one might run into :)

[1] http://www.archlinux.org/news/python-is-now-python-3/

Re: [aur-general] AUR cleanup

[Sven-Hendrik Haase]

On 07.11.2011 18:41, Nicola Bignami wrote:
> I see that there are more than 6700 orphan packages. Of those, more
> than 2400 are also flagged out of date (some packages have not been
> updated since 2007).
> Many packages are only waiting for a new maintainer but I think that
> many are only waiting to be scrapped as they're already been replaced
> by some other package in the AUR or in the community repository (or
> just become obsolete).
>
> I'm wondering if the time has come to look into them to find out what
> worth to keep and what have to be removed and thus do some cleanup.
>
> If can be useful, I can start working on it.
Of course, clean up work like that is always appreciated. Keep in mind
though that people might resubmit missing but obsolete software to AUR.
Technically, there is no rule against that.

So in case you do this work, you should look for packages that truly
have no need for existence anymore as opposed to merely software that
somebody forked and improved. Dead upstream sucks but it's no an
immediate reason to drop something from AUR. in my opinion.

Good candidates for deletion: Unmaintained downstream variants of
software patched with various little things, software that switched vcs
but has old vcs packages remaining in AUR, totally broken and
unmaintained software, renamed packages that didn't get deleted. You get
the idea.

-- Sven-Hendrik

[aur-general] AUR cleanup

[Nicola Bignami]

I see that there are more than 6700 orphan packages. Of those, more than 
2400 are also flagged out of date (some packages have not been updated 
since 2007).
Many packages are only waiting for a new maintainer but I think that 
many are only waiting to be scrapped as they're already been replaced by 
some other package in the AUR or in the community repository (or just 
become obsolete).


I'm wondering if the time has come to look into them to find out what 
worth to keep and what have to be removed and thus do some cleanup.


If can be useful, I can start working on it.

Re: [aur-general] AUR Cleanup Day or aur-general for deletes?

[Stefan Husmann]

Am 24.03.2011 02:58, schrieb Seblu:
> On Thu, Mar 24, 2011 at 2:56 AM, Aaron DeVore  wrote:
>> To delete a package, is it better to use the AUR Cleanup Day page on
>> the Arch wiki or send an email to this mailing list?
>>
> This list.
> 
1+,  definitely this list.

Re: [aur-general] AUR Cleanup Day or aur-general for deletes?

[Seblu]

On Thu, Mar 24, 2011 at 2:56 AM, Aaron DeVore  wrote:
> To delete a package, is it better to use the AUR Cleanup Day page on
> the Arch wiki or send an email to this mailing list?
>
This list.

-- 
Sébastien Luttringer
www.seblu.net

[aur-general] AUR Cleanup Day or aur-general for deletes?

[Aaron DeVore]

To delete a package, is it better to use the AUR Cleanup Day page on
the Arch wiki or send an email to this mailing list?

-Aaron DeVore

Re: [aur-general] AUR cleanup

[Dave Reisner]

On Thu, Jan 27, 2011 at 12:54:25PM +1000, Allan McRae wrote:
> On 27/01/11 12:45, Thomas Dziedzic wrote:
> >2011/1/26 Dave Reisner:
> >>So, on the subject of cleanup, I've come across a list of 530 packages
> >>on sigurd that aren't accessible from the web interface. Judging from
> >>some of the names, I'd wager that these are packages which were deleted
> >>but something went wrong, etc etc. In total, it's about 20mb of space
> >>that would be freed. Any reason these shouldn't just be purged by
> >>someone with root privs?
> >>
> >>dave
> >>
> >
> >Do you know if any of those are actually in the main repos?
> >
> 
> These are just things deleted from the AUR.  Removing a package from
> the AUR interface does not remove the files off the server.
> 
> Allan
> 
> 

aha. I wasn't aware of this extra process. 121 of these packages are in
the official repos.

d

Re: [aur-general] AUR cleanup

[Loui Chang]

On Wed 26 Jan 2011 20:36 -0500, Dave Reisner wrote:
> So, on the subject of cleanup, I've come across a list of 530 packages
> on sigurd that aren't accessible from the web interface. Judging from
> some of the names, I'd wager that these are packages which were deleted
> but something went wrong, etc etc. In total, it's about 20mb of space
> that would be freed. Any reason these shouldn't just be purged by
> someone with root privs?

Packages that are deleted from the web interface aren't automatically
deleted from the filesystem. I run a clean up script periodically to get
rid of them. I figure, it gives a little window for people to recover
from deletion if needed.

Re: [aur-general] AUR cleanup

[Allan McRae]

On 27/01/11 12:45, Thomas Dziedzic wrote:

2011/1/26 Dave Reisner:

So, on the subject of cleanup, I've come across a list of 530 packages
on sigurd that aren't accessible from the web interface. Judging from
some of the names, I'd wager that these are packages which were deleted
but something went wrong, etc etc. In total, it's about 20mb of space
that would be freed. Any reason these shouldn't just be purged by
someone with root privs?

dave



Do you know if any of those are actually in the main repos?



These are just things deleted from the AUR.  Removing a package from the 
AUR interface does not remove the files off the server.


Allan

Re: [aur-general] AUR cleanup

[Thomas Dziedzic]

2011/1/26 Dave Reisner :
> So, on the subject of cleanup, I've come across a list of 530 packages
> on sigurd that aren't accessible from the web interface. Judging from
> some of the names, I'd wager that these are packages which were deleted
> but something went wrong, etc etc. In total, it's about 20mb of space
> that would be freed. Any reason these shouldn't just be purged by
> someone with root privs?
>
> dave
>

Do you know if any of those are actually in the main repos?

[aur-general] AUR cleanup

[Dave Reisner]

So, on the subject of cleanup, I've come across a list of 530 packages
on sigurd that aren't accessible from the web interface. Judging from
some of the names, I'd wager that these are packages which were deleted
but something went wrong, etc etc. In total, it's about 20mb of space
that would be freed. Any reason these shouldn't just be purged by
someone with root privs?

dave
3gpconverter
airsnort
alienarena
aniworld-bzr
apache-ant-old
apache-cassandra
apache-maven
asio
aspell-hu
aspell6-sk
atheros-wired-1005-ha
autofs
avalon
balazar
banshee-1-alarm-clock-svn
banshee-mirage-plugin
banshee-mirage-plugin-svn
bash-completion-netcfg
biblatex
biblatex-chicago
biblatex-dw
bibledesktop
binutils-gold
bitlbee-msn
borderless-elementary-gtk-theme
c-lit
caduntu-svn
cairo-cleartype-xcb
calibre
ccid
cdparanoia-devel
cinchi
cinchi-beta
cl-opengl-darcs
coin
confuse
convertlit
cortex-command
cwiid-svn
dblatex
dbus-systemd
deadbeef
digikam
digikam2-svn
dkms-virtualbox
dmenu-xmms-patch
emoc
eric5
euphoria4
evolution-added-plugins
exalt-client-svn
facter-ruby1.8
faust-cvs
festvox-ru
ffmpeg-svn
ffmpeg-vp8-svn
ffmpeg-webm
firefox-nightly-webm
firefox-spell-en-gb
firefox-spell-pl
flickrnet
flvstreamer
freehdl
fswebcam
gambc
gammu-svn
gcm
geda-gaf
gerbv
ghdl
gimp-layerfx
gimp-plugin-wavelet-decompose
gmic
gnome-packagekit-pacman
gnuradio-svn
go-oo-bin-base
go-oo-bin-de
go-oo-bin-es
go-oo-bin-fr
go-oo-bin-gnome
go-oo-bin-it
go-oo-bin-pt-br
go-oo-bin-ru
go-oo-bin-zh-tw
go-oo-calc
go-oo-draw
go-oo-impress
go-oo-math
go-openoffice-3.2.1-es-i686
go-openoffice-3.2.1-es-x86_64
go-openoffice-af
go-openoffice-ar
go-openoffice-as-in
go-openoffice-be-by
go-openoffice-bg
go-openoffice-bn
go-openoffice-bn-bd
go-openoffice-bn-in
go-openoffice-bo
go-openoffice-br
go-openoffice-brx
go-openoffice-bs
go-openoffice-by
go-openoffice-ca
go-openoffice-cs
go-openoffice-cy
go-openoffice-da
go-openoffice-dark-gtk-fix
go-openoffice-de
go-openoffice-dgo
go-openoffice-dz
go-openoffice-el
go-openoffice-en-gb
go-openoffice-en-us
go-openoffice-en-za
go-openoffice-eo
go-openoffice-es
go-openoffice-et
go-openoffice-eu
go-openoffice-fa
go-openoffice-fi
go-openoffice-fr
go-openoffice-ga
go-openoffice-gd
go-openoffice-git
go-openoffice-gl
go-openoffice-gu
go-openoffice-gu-in
go-openoffice-he
go-openoffice-hi-in
go-openoffice-hr
go-openoffice-hu
go-openoffice-is
go-openoffice-it
go-openoffice-ja
go-openoffice-ka
go-openoffice-kid
go-openoffice-kk
go-openoffice-km
go-openoffice-kn
go-openoffice-ko
go-openoffice-kok
go-openoffice-ks
go-openoffice-ku
go-openoffice-ky
go-openoffice-lo
go-openoffice-lt
go-openoffice-lv
go-openoffice-mai
go-openoffice-mk
go-openoffice-ml-in
go-openoffice-mn
go-openoffice-mni
go-openoffice-mr-in
go-openoffice-ms
go-openoffice-my
go-openoffice-nb
go-openoffice-ne
go-openoffice-nl
go-openoffice-nn
go-openoffice-nr
go-openoffice-ns
go-openoffice-oc
go-openoffice-om
go-openoffice-or-in
go-openoffice-pa-in
go-openoffice-pap
go-openoffice-pl
go-openoffice-ps
go-openoffice-pt
go-openoffice-pt-br
go-openoffice-qt-native
go-openoffice-ro
go-openoffice-ru
go-openoffice-rw
go-openoffice-sa-in
go-openoffice-sat
go-openoffice-sc
go-openoffice-sd
go-openoffice-sh
go-openoffice-si
go-openoffice-sk
go-openoffice-sl
go-openoffice-sr
go-openoffice-ss
go-openoffice-st
go-openoffice-sv
go-openoffice-sw
go-openoffice-sw-tz
go-openoffice-ta-in
go-openoffice-te-in
go-openoffice-tg
go-openoffice-th
go-openoffice-ti-er
go-openoffice-tn
go-openoffice-tr
go-openoffice-ts
go-openoffice-ug
go-openoffice-uk
go-openoffice-ur-in
go-openoffice-uz
go-openoffice-ve
go-openoffice-vi
go-openoffice-xh
go-openoffice-zh-cn
go-openoffice-zh-tw
go-openoffice-zh_cn
go-openoffice-zu
go-openoffice.org-es
google-gadgets-gtk
google-gdata-sharp
gpac
gplanarity
gqview
grub4dos_foo
gsettings-desktop-schemas
gsm
gsoap
gst-python
gtk2.18
gtkwave
haddock
haskell-array
haskell-bytestring
haskell-cabal
haskell-containers
haskell-dbus
haskell-directory
haskell-filepath
haskell-hpc
haskell-hslogger
haskell-old-locale
haskell-old-time
haskell-pretty
haskell-process
haskell-syb
haskell-template-haskell
haskell-time
haskell-unix
hostapd-svn
hsetroot
hunspell-de-de
hunspell-en-gb
hunspell-en-us
hunspell-es-es
hunspell-fr
hunspell-gl-es
hunspell-hu-hu
hunspell-it
hunspell-it-it
hunspell-ro
hwinfo
hypervideoconverter
ibus-chewing
ibus-hangul
ibus-m17n
ibus-qt
ibus-unikey
ifuse
igerman98
intellij-idea-community-edition
ipset4
ipython3
iron
jack-audio-connection-kit-dbus
jedit-pkgbuild
jmeter
jwm-svn
k3b-svn
kadu-svn
kcm-touchpad
kde-theme-uniq
kde4powerdevil-svn
kdedecor-dekorator-kde4
kdedecor-dekorator-kde4-svn
kdedecor-linstasquared
kdedecor-smaragd-svn
kdevelop-extra-plugins-controlflowgraph-svn
kdevelop-extra-plugins-python-svn
keditbookmarks
keditbookmarks-svn
kernel26-slk
kernel26-x86_64
kernel26zen-git
knetworkmanager-svn
knetworkmanager-unstable
kopete-facebook-git
ksmoothdock
kwebkitpart-svn
latex-epic
ldns
lgob-svn
lib32-wineasio
libaio
libexalt-svn
libexalt_dbus-svn
libflickrnet
libgme
lib

Re: [aur-general] AUR cleanup (was: Removal request (aurdupes output 2010-09-15))

[Loui Chang]

On Wed 22 Sep 2010 13:26 +0200, Jakob Gruber wrote:
>  Here are some initial results from a recent dump of the DB:
>
> 2) maintainers with last action date across all owned packages < 2009
> http://pastebin.com/9ja2fXqY

I wouldn't orphan any of these unless they are also out of date.

Re: [aur-general] AUR cleanup

[Stefan Husmann]

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

Re: [aur-general] AUR cleanup (was: Removal request (aurdupes output 2010-09-15))

[Heiko Baums]

Am Wed, 22 Sep 2010 13:26:07 +0200
schrieb Jakob Gruber :

> 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?

ttf-alee
http://aur.archlinux.org/packages.php?ID=6264
ttf-baekmuk
http://aur.archlinux.org/packages.php?ID=6266
ttf-castlequeen
http://aur.archlinux.org/packages.php?ID=18556
ttf-computer-modern-fonts
http://aur.archlinux.org/packages.php?ID=2100
ttf-ffftusj
http://aur.archlinux.org/packages.php?ID=18567
ttf-garagesh
http://aur.archlinux.org/packages.php?ID=8097
ttf-gill-sans
http://aur.archlinux.org/packages.php?ID=18570
ttf-halftone
http://aur.archlinux.org/packages.php?ID=17721

These fonts are all up-to-date and downloadable. So they should be kept
in AUR.

ttf-okolaks
http://aur.archlinux.org/packages.php?ID=22494
ttf-aefonts
http://aur.archlinux.org/packages.php?ID=13692

These fonts are not available anymore. So they can be removed.

dd_rescue
http://aur.archlinux.org/packages.php?ID=447
ttf-essays
http://aur.archlinux.org/packages.php?ID=5

These packages are just out-of-date in AUR. Upstream is still active.
So these packages should be kept in AUR and orphaned if the usual
requirements are fulfilled.

Heiko

Re: [aur-general] AUR cleanup (was: Removal request (aurdupes output 2010-09-15))

[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

Re: [aur-general] AUR cleanup page

[Stefan Husmann]

Xavier schrieb:

On Fri, Sep 25, 2009 at 6:32 PM, Daenyth Blank  wrote:

On Fri, Sep 25, 2009 at 11:58, Stefan Husmann
 wrote:

Hello,

I will go and delete the entries, whose packages are already gon from AUR.
But on th long hand we should decide if we use and keep that wiki page or
remove it completely.

Regards Stefan


I don't really think a wiki page is worth it. We're going to be
constantly struggling to keep it up to date.



But what do you do with all the existing contents then ?
That work should just get lost ?

Couldn't all the users or TUs interested in AUR cleanup check that
page, come up with a good list of packages to be cleaned up, clean it,
and then kill the page if it's not worth it ?


1+

[aur-general] AUR cleanup page

[Xavier]

On Fri, Sep 25, 2009 at 6:32 PM, Daenyth Blank  wrote:
> On Fri, Sep 25, 2009 at 11:58, Stefan Husmann
>  wrote:
>> Hello,
>>
>> I will go and delete the entries, whose packages are already gon from AUR.
>> But on th long hand we should decide if we use and keep that wiki page or
>> remove it completely.
>>
>> Regards Stefan
>>
>
> I don't really think a wiki page is worth it. We're going to be
> constantly struggling to keep it up to date.
>

But what do you do with all the existing contents then ?
That work should just get lost ?

Couldn't all the users or TUs interested in AUR cleanup check that
page, come up with a good list of packages to be cleaned up, clean it,
and then kill the page if it's not worth it ?

Re: [aur-general] AUR CleanUp Day v2

[[EMAIL PROTECTED]]

> -Original Message-
> Date: Tue, 07 Oct 2008 19:23:29 +0200
> Subject: Re: [aur-general] AUR CleanUp Day v2
> From: "Ronald van Haren" <[EMAIL PROTECTED] style="margin:0px;">
> To: "Discussion about the Arch User Repository (AUR)"


> On Tue, Oct 7, 2008 at 5:05 PM, DaNiMoTh <[EMAIL PROTECTED]> wrote:
> > 2008/10/7 Ángel Velásquez <[EMAIL PROTECTED]>:
> >> Hi all,
> >>
> >> This idea was originally sent in this thread:
> >>
> >> http://archlinux.org/pipermail/aur-general/2008-May/007539.html
> >>
> >> At the end, we didn't decide a final day, but the work was done, so
I
> >> propose another CleanUp Day following the model that we used the
last time.
> >>
> >> http://wiki.archlinux.org/index.php/AUR_CleanUp_Day --> here you
can obtain
> >> information and put suggestion, ideas, etc.
> >>
> >> What do you recommend to maintain a more efficient thread?, a post
on the
> >> forum ? and what do you suggest for the Day that we will do the
clean.?.
> >>
> >> Opinions are open!.
> >
> > I know that isn't the right thread but What about another
BugDay?
> > IMHO it have an high priority than cleanupday
> >

> I think a bug day is a good idea indeed (preferebly on a Sunday as I
> have most time on that day).

> About a cleanup day, maybe it is a better idea to better inform the
> users we have such a wikipage where packages can be added (and yes we
> should actually better maintain that wikipage and pay more attention
> to it). Maybe a sticky in the 'forum and aur discussion part of the
> forum). That is just an idea though that comes to mind.

> Ronald


Hello,

I dislike the idea of a bug day. We have well defined bugtracking
interfaces (Community Bugtracker or AUR comment-pages).

The AUR cleanup day was announced on the Arch Linux start page at
www.archlinux.org. We can do that again, but I think the problem was not
that there are too few reactions of users on that announcement but too
few TUs making a decision of packages to keep and packages to delete. We
still have a rather long list of packages undecided on the wiki list and
only a few under the lists "to be kept" and "to be deleted".

So I agree with Ronald in his wish to have us pay more attention on the
Wiki page.

Regards Stefan

Re: [aur-general] AUR CleanUp Day v2

[Ronald van Haren]

On Tue, Oct 7, 2008 at 5:05 PM, DaNiMoTh <[EMAIL PROTECTED]> wrote:
> 2008/10/7 Ángel Velásquez <[EMAIL PROTECTED]>:
>> Hi all,
>>
>> This idea was originally sent in this thread:
>>
>> http://archlinux.org/pipermail/aur-general/2008-May/007539.html
>>
>> At the end, we didn't decide a final day, but the work was done, so I
>> propose another CleanUp Day following the model that we used the last time.
>>
>> http://wiki.archlinux.org/index.php/AUR_CleanUp_Day --> here you can obtain
>> information and put suggestion, ideas, etc.
>>
>> What do you recommend to maintain a more efficient thread?, a post on the
>> forum ? and what do you suggest for the Day that we will do the clean.?.
>>
>> Opinions are open!.
>
> I know that isn't the right thread but What about another BugDay?
> IMHO it have an high priority than cleanupday
>

I think a bug day is a good idea indeed (preferebly on a Sunday as I
have most time on that day).

About a cleanup day, maybe it is a better idea to better inform the
users we have such a wikipage where packages can be added (and yes we
should actually better maintain that wikipage and pay more attention
to it). Maybe a sticky in the 'forum and aur discussion part of the
forum). That is just an idea though that comes to mind.

Ronald

Re: [aur-general] AUR CleanUp Day v2

[DaNiMoTh]

2008/10/7 Ángel Velásquez <[EMAIL PROTECTED]>:
> Hi all,
>
> This idea was originally sent in this thread:
>
> http://archlinux.org/pipermail/aur-general/2008-May/007539.html
>
> At the end, we didn't decide a final day, but the work was done, so I
> propose another CleanUp Day following the model that we used the last time.
>
> http://wiki.archlinux.org/index.php/AUR_CleanUp_Day --> here you can obtain
> information and put suggestion, ideas, etc.
>
> What do you recommend to maintain a more efficient thread?, a post on the
> forum ? and what do you suggest for the Day that we will do the clean.?.
>
> Opinions are open!.

I know that isn't the right thread but What about another BugDay?
IMHO it have an high priority than cleanupday

[aur-general] AUR CleanUp Day v2

[Ángel Velásquez]

Hi all,

This idea was originally sent in this thread:

http://archlinux.org/pipermail/aur-general/2008-May/007539.html

At the end, we didn't decide a final day, but the work was done, so I 
propose another CleanUp Day following the model that we used the last time.


http://wiki.archlinux.org/index.php/AUR_CleanUp_Day --> here you can 
obtain information and put suggestion, ideas, etc.


What do you recommend to maintain a more efficient thread?, a post on 
the forum ? and what do you suggest for the Day that we will do the clean.?.


Opinions are open!.



--
Angel Velásquez
angvp @ irc.freenode.net
Arch Linux Trusted User (TU)
http://www.angvp.com

Re: [aur-general] AUR cleanup package list

[Eric Belanger]

On Sun, 1 Jun 2008, Allan McRae wrote:


Hi all,

I have done most of the cleanup of the suggested packages in the AUR.  I have 
tarballs for all deleted packages so any complaints can be pointed my way. 
I also orphaned any package that was decided to be kept but was suggested 
because of how out-of-date it was.


There is still ~20 packages that need sorted but I don't know much about 
those (http://wiki.archlinux.org/index.php/AUR_CleanUp_Day).  Please give 
these a quick look over and sort any you can.


Three packages in community have been flagged for deletion.  I agree with all 
suggestions so I will remove them later in the week if I hear no objections. 
The packages are (with maintainer in brackets):
  * ion-modules - ion3 is not part of official repos anymore (sergej) - move 
to AUR

  * lmctl - gets replaced by lomoco which is in community (codemac) - delete
  * wildfire - renamed openfire (phrakture) - delete

Allan



You can remove sonic-rainbow.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [aur-general] AUR cleanup package list

[Allan McRae]

Hi all,

I have done most of the cleanup of the suggested packages in the AUR.  I 
have tarballs for all deleted packages so any complaints can be pointed 
my way.   I also orphaned any package that was decided to be kept but 
was suggested because of how out-of-date it was.


There is still ~20 packages that need sorted but I don't know much about 
those (http://wiki.archlinux.org/index.php/AUR_CleanUp_Day).  Please 
give these a quick look over and sort any you can.


Three packages in community have been flagged for deletion.  I agree 
with all suggestions so I will remove them later in the week if I hear 
no objections.  The packages are (with maintainer in brackets):
   * ion-modules - ion3 is not part of official repos anymore (sergej) 
- move to AUR
   * lmctl - gets replaced by lomoco which is in community (codemac) - 
delete

   * wildfire - renamed openfire (phrakture) - delete

Allan

Re: [aur-general] AUR cleanup package list

[Abhishek Dasgupta]

On Tue, May 27, 2008 at 09:52:16PM +1000, Allan McRae wrote:
> org - included in emacs 22+?

The Emacs 22.2 release ships with Org-mode version 4.67d. (orgmode.org)

The current version is 6.04c. I don't know what should be done in this
case. Data::Dumper is also part of perl 5.10 and it's there as a
separate CPAN package as well.

ion-modules should not be removed but should be moved to unsupported
as ion3 is no longer in [extra].

gshare's website is down for quite a long time. I think it should be
moved to unsupported.

Also moved some packages into the keep/remove list.

-- 
Abhishek Dasgupta 
GPG 67972DOF pgp.mit.edu

Re: [aur-general] AUR cleanup package list

[Lukáš Jirkovský]

2008/5/27 Hugo Doria <[EMAIL PROTECTED]>:
> kernel26thinkpad could be removed. I moved him to the to "packages to
> remove" list.
>
> I added a comment to mplayer-w32codecs package. It would be better if
> we could rename it to "codecs-extra" as suggested before.
>
> openarena could be kept since some servers still runs the older version.
>
> I also moved some other packages.
>
> --
> Hugo Doria
> http://hdoria.archlinux-br.org
>
>

[EMAIL PROTECTED] ~]$ pacman -Qo `which ionice`
/usr/bin/ionice is owned by util-linux-ng 2.13.0.1-2

If you have recent Arch, you should will it same.

Re: [aur-general] AUR cleanup package list

[Hugo Doria]

kernel26thinkpad could be removed. I moved him to the to "packages to
remove" list.

I added a comment to mplayer-w32codecs package. It would be better if
we could rename it to "codecs-extra" as suggested before.

openarena could be kept since some servers still runs the older version.

I also moved some other packages.

-- 
Hugo Doria
http://hdoria.archlinux-br.org

Re: [aur-general] AUR cleanup package list

[Xavier]

On Tue, May 27, 2008 at 1:52 PM, Allan McRae <[EMAIL PROTECTED]> wrote:
>
> librtorrent - package in community?
> rs_rtorrent - package in community?
>

First comment on AUR :
Current version of rakshasa`s libTorrrent library modifyied not to
conflict with rb_libtorrent.

from http://libtorrent.rakshasa.no/ :
<>
Also this :
http://libtorrent.rakshasa.no/ticket/854

rasterbar project is there :
http://www.rasterbar.com/products/libtorrent/
http://sourceforge.net/projects/libtorrent

That situation is so stupid but how to deal with it?
Personally, I use only rtorrent + libtorrent which are great, and I
like to use them as distributed by upstream, without ugly hacks for
renaming libtorrent to librtorrent.
On the other hand, rakshasa libtorrent is apparently only used by
rtorrent, while rasterbar libtorrent is used by many clients :
http://www.rasterbar.com/products/libtorrent/projects.html

So if you want to use both in the same time, it makes more sense to
rename rakshasa one.

However, Arch is supposed to follow upstream, so Arch should consider
this is not its issue and let upstreams resolve it. In the meantime
(forever?), the users simply have to make their mind between both. No
need to have a thousand torrent clients installed in the same time.

Re: [aur-general] AUR cleanup package list

[Ronald van Haren]

On 5/27/08, Allan McRae <[EMAIL PROTECTED]> wrote:
> Allan McRae wrote:
>
>  librtorrent - package in community?
>  rs_rtorrent - package in community?
>
>  And of course, feel free to move any other packages into the sorted list...
>
>  Cheers,
>  Allan
>

I just moved librtorrent to the to be removed section minutes before I
saw your mail. I will move rs_rtorrent to that same section too now,
as it is indeed already in community. Both are owned by codemac.

librtorrent: http://aur.archlinux.org/packages.php?do_Details=1&ID=9459
rs_torrent: http://aur.archlinux.org/packages.php?do_Details=1&ID=8720

Re: [aur-general] AUR cleanup package list

[Allan McRae]

Allan McRae wrote:


All TUs should go to the wiki page 
(http://wiki.archlinux.org/index.php/AUR_CleanUp_Day) and see if they 
can move any packages from the suggestion list to the TU signoff 
list.  It doesn't take much.  For example, there are packages to do 
with pidgin, blender, and gimp that have apparently be merged 
upstream.  If you use those, check that you agree with the comment and 
move the package to the correct section.  I expect everyone who said 
+1 good idea to do something!



Well, I count a total of three TU's other than me who did anything about 
this.  Thanks to those TUs. 

I am going through this list when I have time but I still need some 
help. Can TUs in the know please help me with the following packages 
which I am unfamiliar with:


gnuserv - is it depreciated with emacs 22+?
ionice - anyone confirm it is part of util-linux-ng now?
kernel26thinkpad - obsolete?
org - included in emacs 22+?

librtorrent - package in community?
rs_rtorrent - package in community?

And of course, feel free to move any other packages into the sorted list...

Cheers,
Allan

Re: [aur-general] AUR cleanup package list

[Allan McRae]

Hugo Doria wrote:

Could we rename mplayer-w32codecs to something like codecs-extras?
Since this package provides more codecs i think we should keep him.

  


Good idea.  It should probably only provide the extra files not already 
in the codecs package. Added note to wiki that I will follow up with the 
maintainer later (unless you want to...)


Allan

Re: [aur-general] AUR cleanup package list

[Hugo Doria]

Could we rename mplayer-w32codecs to something like codecs-extras?
Since this package provides more codecs i think we should keep him.

-- 
Hugo Doria
http://hdoria.archlinux-br.org

Re: [aur-general] AUR cleanup package list

[Allan McRae]

Dragonlord wrote:

Not much traffic on the wiki page until now! Do we have at least
any unofficial date to finish this thing? Not that it stays this way
for one month or so ...
  


I will do the removals this weekend so that is the unofficial date...

All TUs should go to the wiki page 
(http://wiki.archlinux.org/index.php/AUR_CleanUp_Day) and see if they 
can move any packages from the suggestion list to the TU signoff list.  
It doesn't take much.  For example, there are packages to do with 
pidgin, blender, and gimp that have apparently be merged upstream.  If 
you use those, check that you agree with the comment and move the 
package to the correct section.  I expect everyone who said +1 good idea 
to do something!


Allan

Re: [aur-general] AUR cleanup package list

[Dragonlord]

Not much traffic on the wiki page until now! Do we have at least
any unofficial date to finish this thing? Not that it stays this way
for one month or so ...

Cheers
Jaro


On Fri, May 16, 2008 at 01:51:24PM +0200, Allan McRae wrote:
> HI TUs,
>
> The call for people to list packages in the AUR to cleanup has been quite 
> successful with around 100 packages recommended.  See the wiki page: 
> http://wiki.archlinux.org/index.php/AUR_CleanUp_Day
>
> Now we have to go through the list and confirm which packages deserve to be 
> deleted.  Remember not to get carried away here.  We don't want to delete 
> work that may still be useful.
>
> [snip]
>
> If you have a disagreement with another TUs decision, move it to a new 
> section call "further discussion" or something.  If the suggestions are 
> checked properly before moving the the remove or keep list, then this 
> shouldn't happen but we will deal with it if it happens.
>
> I will go through and make the removals in a few days.
>
> Cheers,
> Allan
>



pgpSOdgmfRd0U.pgp
Description: PGP signature

Re: [aur-general] AUR cleanup package list

[Slash]

Comrades,

I see a lot of CVS/SVN/etc packages on there with notes along the
lines of "Hasn't been updated since ..." Unless the project has
SWITCHED source revision control systems (CVS to SVN) or the
repository is completely and forever gone, there is no reason to
remove CVS/SVN/etc packages. As mentioned a billion times before, even
if the PKGBUILD does not work, it's (usually) a better starting point
for another user to fix it than starting from scratch.

Thanks,

Slash

[aur-general] AUR cleanup package list

[Allan McRae]

HI TUs,

The call for people to list packages in the AUR to cleanup has been 
quite successful with around 100 packages recommended.  See the wiki 
page: http://wiki.archlinux.org/index.php/AUR_CleanUp_Day


Now we have to go through the list and confirm which packages deserve to 
be deleted.  Remember not to get carried away here.  We don't want to 
delete work that may still be useful.


Reasons to flag a package for deletion:
 - packages that have been renamed or replaced
 - developmental packages (cvs/svn/etc) that have change source 
management systems


Reasons not to flag a package for deletion:
 - out of date

I have made a section of the wiki page where we can sort the packages.  
Please sign your name by any package that you put in the remove/keep 
list.  This will allow me to monitor any abuse of the system more 
easily.  It also makes you take responsibility for your decision to 
remove a package which should never be taken lightly.


If you have a disagreement with another TUs decision, move it to a new 
section call "further discussion" or something.  If the suggestions are 
checked properly before moving the the remove or keep list, then this 
shouldn't happen but we will deal with it if it happens.


I will go through and make the removals in a few days.

Cheers,
Allan

Re: [aur-general] AUR Cleanup Day organization

[Firmicus]

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

[aur-general] AUR Cleanup

[Allan McRae]

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).  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.  TUs will 
take great care not to delete any useful package.


Cheers,
Allan

--
Allan McRae
Arch Linux Trusted User

Re: [aur-general] AUR Cleanup Day organization

[Eric Belanger]

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.

Re: [aur-general] AUR Cleanup Day organization

[Alessio Bolognino]

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 [EMAIL PROTECTED]

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


pgpIABAGWqjqK.pgp
Description: PGP signature

Re: [aur-general] AUR Cleanup Day organization

[Ray Rashif]

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.

Re: [aur-general] AUR Cleanup Day organization

[Uwe Vogt]

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

Re: [aur-general] AUR Cleanup Day organization

[Mikko Seppälä]

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

Re: [aur-general] AUR Cleanup Day organization

[Geoffroy Carrier]

On 5/3/08, Allan McRae <[EMAIL PROTECTED]> 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

Re: [aur-general] AUR Cleanup Day organization

[Allan McRae]

Allan McRae wrote:



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.



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

Re: [aur-general] AUR Cleanup Day organization

[Allan McRae]

Geoffroy Carrier wrote:

On 5/2/08, Allan McRae <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED],
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

Re: [aur-general] AUR Cleanup Day organization

[Geoffroy Carrier]

On 5/2/08, Allan McRae <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED],
http://koon.fr/~gcarrier/cleanup/

-- 
Geoffroy Carrier

Re: [aur-general] AUR Cleanup Day organization

[Lukáš Jirkovský]

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 <[EMAIL PROTECTED]>:
> 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
>
>
>
>
>

Re: [aur-general] AUR Cleanup Day organization

[Allan McRae]

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

Re: [aur-general] AUR Cleanup Day organization

[Abhishek Dasgupta]

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

Re: [aur-general] AUR Cleanup Day organization

[Alessio Bolognino]

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 [EMAIL PROTECTED]

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


pgpQ9MDE2lcVD.pgp
Description: PGP signature

Re: [aur-general] AUR Cleanup Day organization

[Loui]

On Sat, 03 May 2008 00:57:00 +1000
Allan McRae <[EMAIL PROTECTED]> 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.

Re: [aur-general] AUR Cleanup Day organization

[Eric Belanger]

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.

Re: [aur-general] AUR Cleanup Day organization

[Cilyan Olowen]

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 <[EMAIL PROTECTED]>:
>
> 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
>
>
>
>
>

Re: [aur-general] AUR Cleanup Day organization

[Allan McRae]

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

Re: [aur-general] AUR Cleanup Day organization

[Lukáš Jirkovský]

But in other way, packages without arch field are usually very, very old.

2008/5/2 Allan McRae <[EMAIL PROTECTED]>:
> Callan Barrett wrote:
>
> > On Fri, May 2, 2008 at 10:08 PM, Lukáš Jirkovský <[EMAIL PROTECTED]>
> 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
>
>
>
>

Re: [aur-general] AUR Cleanup Day organization

[Allan McRae]

Callan Barrett wrote:

On Fri, May 2, 2008 at 10:08 PM, Lukáš Jirkovský <[EMAIL PROTECTED]> 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

Re: [aur-general] AUR Cleanup Day organization

[Callan Barrett]

On Fri, May 2, 2008 at 10:08 PM, Lukáš Jirkovský <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
>
>
> > Le Fri, 02 May 2008 23:53:51 +1000,
>  >  Allan McRae <[EMAIL PROTECTED]> 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

Re: [aur-general] AUR Cleanup Day organization

[Lukáš Jirkovský]

Just my 2 cents: I think, that packages without arch=() field should
be also removed.

2008/5/2 Pierre CHAPUIS <[EMAIL PROTECTED]>:
> Le Fri, 02 May 2008 23:53:51 +1000,
>  Allan McRae <[EMAIL PROTECTED]> 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
>
>

Re: [aur-general] AUR Cleanup Day organization

[Pierre CHAPUIS]

Le Fri, 02 May 2008 23:53:51 +1000,
Allan McRae <[EMAIL PROTECTED]> 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

Re: [aur-general] AUR Cleanup Day organization

[Abhishek Dasgupta]

I too never got around to getting my IRC channel key for the same reason!
Email the announcement to [EMAIL PROTECTED] too... Then people
who don't follow the forums will also get to know.

Abhishek

[aur-general] AUR Cleanup Day organization

[Allan McRae]

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:



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.



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.