[arch-dev-public] Second list of removal candidates
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) aria Superceded by aria2? aumix what console audio mixers do we provide? bidwatcher broken: bidding in bidwatcher is indefinitely broken because eBay has forced all bidding to occur only through signed-in clients bind DNS server. Should stay in repo. blam yet another RSS reader cccp dead project, could (maybe?) be replaced by dctc cdw project (ncurse cd-writer) has been revived, is there another console cd-writer in repo? chgres old, low usage? cplay yet another curses audio player cvsfs Discontinued. Developement has stopped in favor of cvsfs-fuse. dcd yet another command-line CD player divx4linux unused lib/codec dump tapedrive utility. it it worthy to keep? edb enlightenment db, unused efax utilities to send and receive faxes, I guess we should keep it unless another package provides fax support epic4 yet another console irc client exim what mta will we keep? font-bh-ttf should we keep it? font-bitstream-speedo who uses speedo fonts? font-misc-ethiopic i18n support, should be kept font-misc-meltho i18n support, should be kept freetype1 unused lib galeon yet another web browser gentoo yet another file manager gimp-perl low usage: perl plugin and modules for gimp gnet1 unused lib gnome-audio audio files for gnome. Are they still useful? gpgme03 obsoleted by gpgme??? gprolog Can be removed, I guess. There is another prolog compiler (swi-prolog) in repo. gpsdrive new dependencies in community, should be in community or unsupported ==> to be moved to community for Damir grcm dead project. no release since 2003 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 ircii-pana yet another console irc client irda-utils Utilities for infrared communication between devices: should be kept isapnptools ISA Plug-And-Play devices support: shopuld be kept lam MPI programming environment: low usage lib3ds free alternative to Autodesk's 3DS File Toolkit for handling 3DS files: low usage libast unused lib libflashsupport (in unstable) unused lib libgnomesu gksu and kdesu provide same functionality libping Anyone use ding in their scripts? Otherwise, unused lib/package libtrash unused lib 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 lprng we have cups standard now madplay yet another curses audio player mail-notification mail notification icon for gnome: low usage masqmail home page disappeared, another MTA mod_python used on Archlinux.org for django? nautilus-sendto nautilus extension, can be removed from extra netdude with libnetdude & libpcapnav used to inspect/manipulate tcpdump trace files. Should we keep it? netgo a tool for changing network settings quickly and easily: Is it still useful/usable with the latest network scripts? netkit-ntalk Isn't talk obsoleted by Instant Messaging and IRC? oidentd ident server like pidentd (orphaned). Which one should we keep or should we remove both? openchrome graphics drivers, should be kept unless it can be replaced by xf86-video-unichrome pdns Do we keep it? pdns-ldap unused lib, might be included in pdns (currently orphaned) pdns-mysql unused lib, might be included in pdns (currently orphaned) pdns-pgsql unused lib, might be included in pdns (currently orphaned) perl-email-date unused perl module. To Jan: You added it to the repo 2 months ago with several other perl packages. Did you forgot to adopt them or are they future dependencies? pidentd ident server like oidentd (orphaned). Which one should we keep or should we remove both? powernowd Do we need it? We already have cpudyn and cpufreq. prozilla multi-threaded download accelerator: low usage/usefulness ptabtools low usage: utilities to read files created by PowerTab Guitar Tablature editor (a Windows app) pure-ftpd yet another ftp server quick-lounge-applet gnome applet: low usage/usefulness samplicator home page has disappeared, looks like dead project service-discovery-applet gnome applet: low usage/usefulness setserial support for serial device, should be kept unless it's no longer needed speedtouch modem drivers, should be kept splitvt splitvt takes any VT100 terminal window and splits it vertically into two shell windows: screen does that ssmtp what mta will we keep? tiacx (in unstable) wireless drivers, should be kept tiacx-mm (in unstable) wireless drivers, should be kept tpop3d yet another pop3 server xf86-video-unichrome graphics drivers, should be kept, somebody with that hardware or the Xorg maintainer should take it xforms old, low usage 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 zsh very popular. iphitus will adopt if nobody else will ======================================================================================= -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
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 -- K. Piche <kpiche@rogers.com>
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, 2007-11-14 at 18:19 -0500, Eric Belanger wrote:
On Tue, 13 Nov 2007, K. Piche wrote:
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.
Cool. Yer the best! -- K. Piche <kpiche@rogers.com>
On Tue, Nov 13, 2007 at 08:34:00PM -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) aria Superceded by aria2?
Actually, aria and aria2 are totally different. I think the biggest difference is that aria is supported by FlashGot as a download manager but aria2 isn't (aria2 has a totally different focus than aria).
aumix what console audio mixers do we provide? bidwatcher broken: bidding in bidwatcher is indefinitely broken because eBay has forced all bidding to occur only through signed-in clients
[snip]
efax utilities to send and receive faxes, I guess we should keep it unless another package provides fax support epic4 yet another console irc client exim what mta will we keep?
If I'm not mistaken, doesn't gerolde still use this right now? We use exim for work here, so I would probably be able to maintain it if need be.
font-bh-ttf should we keep it? font-bitstream-speedo who uses speedo fonts? font-misc-ethiopic i18n support, should be kept
[snip]
setserial support for serial device, should be kept unless it's no longer needed speedtouch modem drivers, should be kept splitvt splitvt takes any VT100 terminal window and splits it vertically into two shell windows: screen does that ssmtp what mta will we keep?
I use ssmtp. I will maintain it. Jason
On Wed, 14 Nov 2007, Jason Chu wrote:
On Tue, Nov 13, 2007 at 08:34:00PM -0500, Eric Belanger wrote:
aria Superceded by aria2?
Actually, aria and aria2 are totally different. I think the biggest difference is that aria is supported by FlashGot as a download manager but aria2 isn't (aria2 has a totally different focus than aria).
That answers my original question. The question is now: Do we keep it and who will maintain it? Is the maintainer of aria2 interested?
I use ssmtp. I will maintain it.
I removed it from the list. Don't forget to adopt it. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
2007/11/14, Eric Belanger <belanger@astro.umontreal.ca>:
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)
it seems yes.
aumix what console audio mixers do we provide? In previous thread the answer was given - alsamixer (in alsa-utils), so aumix can be removed.
bind DNS server. Should stay in repo. Any volunteer to take this is important package?
cdw project (ncurse cd-writer) has been revived, is there another console cd-writer in repo? I adopted it.
chgres old, low usage? Seems pretty useless to me -> Unsupported.
cplay yet another curses audio player The new homepage is http://mask.tf.hut.fi/~flu/cplay/ The latest version is 1.50pre7 dated 2006-05-09. Seems like a dead project -> Unsupported.
dump tapedrive utility. it it worthy to keep? Heh, it was the first package that I touched (fixed PKGBUILD) in Extra. :-) I've just read http://dump.sourceforge.net/isdumpdeprecated.html and still don't find it useful. -> Unsupported
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.
font-bitstream-speedo who uses speedo fonts? Not me. :-P
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).
gnome-audio audio files for gnome. Are they still useful? Yes. They are in gnome-extra group. I'm volunteering to maintain anything Gnome (except Mono stuff) that JGC doesn't maintain.
gpgme03 obsoleted by gpgme??? I haven't seen any package that (make)depends on this (I maintain at least 2 gpg(me) frontends 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.
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.
libgnomesu gksu and kdesu provide same functionality @JGC: is this some crap from previous Gnome?
libtrash unused lib "A shared library which, when preloaded, implements a trash can under GNU/Linux" Hm, I don't think anybody uses it -> Unsupported.
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.
madplay yet another curses audio player And it depends on esd which is expected to not live long in Extra. -> Unsupported
mail-notification mail notification icon for gnome: low usage Move to Community, I'll adopt it.
masqmail home page disappeared, another MTA Sources and patches can be found on Debian's site (http://packages.debian.org/uk/etch/masqmail) But still -> Unsupported I think.
nautilus-sendto nautilus extension, can be removed from extra Move to Community -> I'll adopt it.
oidentd ident server like pidentd (orphaned). Which one should we keep or should we remove both? Are they used by someone? I'd say both.
powernowd Do we need it? We already have cpudyn and cpufreq. Not needed.
pure-ftpd yet another ftp server This is pretty good server, I guess somebody will maintain it in Extra/Community. I will take it if noone else will.
quick-lounge-applet gnome applet: low usage/usefulness Move to Community, I'll adopt it.
setserial support for serial device, should be kept unless it's no longer needed Used by lirc. See FS#3995 & FS#6224
tpop3d yet another pop3 server -> Community, I'll maintain it if noone else will
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.
-- Roman Kyrylych (Роман Кирилич)
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.
2007/11/15, Eric Belanger <belanger@astro.umontreal.ca>:
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. -- Roman Kyrylych (Роман Кирилич)
On Thu, 15 Nov 2007, Roman Kyrylych wrote:
2007/11/15, Eric Belanger <belanger@astro.umontreal.ca>:
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/15, Eric Belanger <belanger@astro.umontreal.ca>:
On Thu, 15 Nov 2007, Roman Kyrylych wrote: 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.
Ok. Adopting... :-) -- Roman Kyrylych (Роман Кирилич)
2007/11/14, Roman Kyrylych <roman.kyrylych@gmail.com>:
2007/11/14, Eric Belanger <belanger@astro.umontreal.ca>:
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 (Роман Кирилич)
On Nov 13, 2007 7:34 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
bind DNS server. Should stay in repo. Adopted. Keeping this one
exim what mta will we keep? This is mine too - we should keep it. Killing exim or postfix is like killing one of vim or emacs. Holy war, etc.
gentoo yet another file manager Also, really confusing to pacman -S gentoo 8)
mod_python used on Archlinux.org for django? I think we should hold onto this for now, but I don't have the.... know-how to maintain it
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
setserial support for serial device, should be kept unless it's no longer needed Adopted.
zsh very popular. iphitus will adopt if nobody else will Yeah, let's not remove this 8)
2007/11/14, Aaron Griffin <aaronmgriffin@gmail.com>:
On Nov 13, 2007 7:34 PM, Eric Belanger <belanger@astro.umontreal.ca> 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 11:30 AM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/11/14, Aaron Griffin <aaronmgriffin@gmail.com>:
On Nov 13, 2007 7:34 PM, Eric Belanger <belanger@astro.umontreal.ca> 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.
Aha! I think I was mentally confusing powernowd with the powernow *modules*
On Nov 14, 2007 12:17 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Nov 13, 2007 7:34 PM, Eric Belanger <belanger@astro.umontreal.ca> 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 <kpiche@rogers.com> wrote:
On Wed, 2007-11-14 at 11:17 -0600, Aaron Griffin wrote:
On Nov 13, 2007 7:34 PM, Eric Belanger <belanger@astro.umontreal.ca> 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)
participants (6)
-
Aaron Griffin
-
Eric Belanger
-
Jason Chu
-
Jeff Mickey
-
K. Piche
-
Roman Kyrylych