On Tue, 13 Nov 2007, K. Piche wrote:

On Tue, 2007-11-13 at 20:34 -0500, Eric Belanger wrote:

...

Hi,

Here is the second list of removal candidates. Please go through it to make sure we don't remove a package that, for some reason, should remain in extra. Some of the reason are actually questions or discussion topics so it would be nice to get some feedback on them. As said before, some of these packages can be depends of community packages. Please just dicuss them for now. I would prefer to do the actual removal myself. I will do so when the discussions will be over.

======================================================================================= Package Reason to remove it or Reason to keep it. Any comments, concerns, etc. ======================================================================================= akode will be dependency of kde4, right? (dp) apmd replaced by acpi (incorrect. needed for older machines)

Can you add castle-combat to your list? It's a python game that will happily work in your home directory but not from /usr/{bin,lib} and I don't know enough about python to make it. Also it hasn't been updated in a long time.

k

Sure. I added to the list in the wiki. BTW, if anyone else has orphaned a package since the cleanup began, let me know. I haven't bothered syncing the wiki list with the current orphans. I'll do that at the end of the cleanup/adoption process. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

On Wed, 14 Nov 2007, Roman Kyrylych wrote:

...

font-bh-ttf should we keep it? I can maintain it in Community, you can move it right there (if there are no objections). Instead, I'd like to bring ttf-freefont and ttf-liberation to Extra, which are much more important.

Why moving it (and the other packages you propose to adopt) to community? Why not adopting them and maintaining them in extra? To me it seems like unecessary work, unless you have a personal preference in maintaining suff in community. I don't see any problem in keeping most of these packages in extra IF they have a maintainer. The 'if' is the key part here. Some of the packages that were/will be removed are more worthy to remain in extra than some stupid package like xsnow but the fact of the matter is that they don't have a maintainer while xsnow has one. Unless someone think of them being worthy enough to say: "Wait a minute! This package should stay in extra. We must find a maintainer for it.", much like what has happened with bind and exim, they 'll go in unsupported.

...

gnet1 unused lib Hm, probably it is a (make)depend for some community package IIRC, but that's not critical if you move it to Unsupported (can be moved back to Community if needed).

Before removing anything, I'll check for community repo dependencies and such packages will be moved directly in community.

...

gstreamer0.10-alsaspdif gstreamer0.10-cdaudio gstreamer0.10-jack should not be removed (drastic loss of function for any gstreamer using app) - if nobody takes the gstreamer pkgs, i will (damir) gstreamer0.10-mpeg2enc gstreamer0.10-musicbrainz gstreamer0.10-pitfdll gstreamer0.10-sndfile gstreamer0.10-wavpack gstreamer0.10-x264

IMO all gsteamer0.10 packages should be kept in the same repo (Extra) for easier maintainence. I can offer my help in this.

I also think it would be nice if they stay in extra. I could also help out in maintaining some of them or their dependencies.

...

lineak_defaultplugin The lineak packages could be substituted by my (Eric) keytouch pkg in community. It has more dependencies (gtk2) but has much or more functionality. lineak_xosdplugin same comment as above

Lineak is pretty old but it may still be used by someone. I think it shouldn't be just deleted, but moved to Unsupported.

That's what I meant: moving lineak to unsupported and keytouch to extra (after the cleanup, I plan to consolidate my packages so some (all?) my community packages will be moved to extra).

...

xpdf-arabic i18n support, should be kept xpdf-chinese-simplified i18n support, should be kept xpdf-chinese-traditional i18n support, should be kept xpdf-cyrillic i18n support, should be kept xpdf-greek i18n support, should be kept xpdf-hebrew i18n support, should be kept xpdf-japanese i18n support, should be kept xpdf-korean i18n support, should be kept xpdf-latin2 i18n support, should be kept xpdf-thai i18n support, should be kept xpdf-turkish i18n support, should be kept Weren't we going to remove xpdf from Extra? (and lesstiff?) If no, then xpdf maintainer should maintain packages above, I think.

xpdf is one of the rare packages that have a maintainer but were submitted to removal. The others are achessclock and arch. I had planned bringing that up later on. Anyway, I won't remove these packages without the consent of their current maintainer. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

On Thu, 15 Nov 2007, Roman Kyrylych wrote:

2007/11/15, Eric Belanger :

...

On Wed, 14 Nov 2007, Roman Kyrylych wrote:

...

...

font-bh-ttf should we keep it? I can maintain it in Community, you can move it right there (if there are no objections). Instead, I'd like to bring ttf-freefont and ttf-liberation to Extra, which are much more important.

Why moving it (and the other packages you propose to adopt) to community? Why not adopting them and maintaining them in extra? To me it seems like unecessary work, unless you have a personal preference in maintaining suff in community. I don't see any problem in keeping most of these packages in extra IF they have a maintainer. The 'if' is the key part here. Some of the packages that were/will be removed are more worthy to remain in extra than some stupid package like xsnow but the fact of the matter is that they don't have a maintainer while xsnow has one. Unless someone think of them being worthy enough to say: "Wait a minute! This package should stay in extra. We must find a maintainer for it.", much like what has happened with bind and exim, they 'll go in unsupported.

Yeah, that's kind of my preference to maintain not so popular/important packages in Community. That's the subject of "Extra/Community line & Mantle/Crust" thread. Plus, I used to maintain all packages in Community, because I was doing just bugtracker work with no package maintaining in Extra in the past. That doesn't mean I don't want to move some good Community packages to Extra though.

If you are interested in these packages, please adopt them so I can remove them from the wiki list, but I won't move them to community. You'll need to do that yourself. The reason is that I'm against the repo reorganization idea, at least in its actual form (you are probably already aware about that ;) ). Plus, no decision have been made upon the matter and the cleanup itself is already a lot of work. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

2007/11/14, Roman Kyrylych :

2007/11/14, Eric Belanger :

...

libflashsupport (in unstable) unused lib It was optional addition for old flashplugin, that offered ALSA support etc. (AFAIR) I think isn't needed for flashplugin-9, there's no mention of it on Adobe's Flash Plugin page now.

Update: there are 2 reasons to keep it. 1) http://www.kaourantin.net/2007/01/non-beta-flash-player-9-for-linux.html Here is a list of some of the Linux specific items we are working on right now, it is far from complete and each of the items might or might not make it into the next version: [skipped] Finish the flashsupport add-on library. Adding camera, microphone support etc. Move the project to sourceforge.net or similar site. BTW, it's my fault that this has not seen too many changes lately since I own this piece. :-) 2) http://wiki.archlinux.org/index.php/PulseAudio#Configuration_of_the_Adobe_Fl... The default Adobe Flash plugin for Mozilla doesn't work well with the PulseAudio plugin for ALSA so you'll get no sound but there is a way to make the Flash plugin work with PulseAudio even though you might end up with a little delay. This is done through the libflashsupport and there is a package for it on the AUR. Link: http://aur.archlinux.org/packages.php?do_Details=1&ID=13384 @JGC: keep that AUR package in mind when replacing ESD with PulseAudio. ;-) -- Roman Kyrylych (Роман Кирилич)

2007/11/14, Aaron Griffin :

On Nov 13, 2007 7:34 PM, Eric Belanger wrote:

...

powernowd Do we need it? We already have cpudyn and cpufreq. I think this one is needed... it's AMD related... I'd have to look into it I have AMD and always used cpufrequtils for this (and powernow-k8 kernel module). Powernowd is old.

-- Roman Kyrylych (Роман Кирилич)

On Nov 14, 2007 12:17 PM, Aaron Griffin wrote:

On Nov 13, 2007 7:34 PM, Eric Belanger wrote:

...

zsh very popular. iphitus will adopt if nobody else will Yeah, let's not remove this 8) I will adopt if nobody else will as well.

// jeff -- . : [ + carpe diem totus tuus + ] : .

On Nov 14, 2007 8:08 PM, K. Piche wrote:

On Wed, 2007-11-14 at 11:17 -0600, Aaron Griffin wrote:

...

On Nov 13, 2007 7:34 PM, Eric Belanger wrote:

...

bind DNS server. Should stay in repo. Adopted. Keeping this one

Aaron, if you want I can take it. I build it for work all the time...

Great, I'll orphan it - please pick it up - I just didn't want it to go to waste 8)