Retiring ksensors, possibly id3lib as well?
Greetings all... I believe the time has come to retire ksensors. The last update/release was 18/08/2004, and it appears upstream has been defunct since at least that time. Unless there are objections voiced and/or a maintainer steps forward before Oct 9 (Friday), I will go ahead and retire this package. id3lib also needs to be looked at, as it's upstream has been defunct since March 2 2003. This one might hurt more than ksensors will, since several programs depend on id3lib. This is a list of the programs that require id3lib: audio-convert-mod easytag tagtool id3lib-devel id3v2 gmediaserver liblicense-modules kid3 grip The list is alot shorter than I thought it would be, but it's still enough to cause problems. Is there anyone willing to take up upstream development of id3lib? Is there a possible (more active) replacement for id3lib? Is there a valid reason for continuing to carry such a defunct package in Fedora? I'm more than happy to continue maintaining id3lib if there is a valid reason to do so, but my reasons are more sentimental than valid logical reasoning. So I turn to you to answer that question: Is there valid, logical, reasoning to continue to support such old code? Lyos Gemini Norezel -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
Lyos Gemini Norezel wrote: > Is there valid, logical, reasoning to continue to support such old code? Are there any bugs that are so severe that we can't continue using the software? If not: Why throw out working software just because it's old? Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
Lyos Gemini Norezel wrote: ... id3lib also needs to be looked at, as it's upstream has been defunct since March 2 2003. This one might hurt more than ksensors will, since several programs depend on id3lib. This is a list of the programs that require id3lib: audio-convert-mod easytag tagtool id3lib-devel id3v2 gmediaserver liblicense-modules kid3 grip The list is alot shorter than I thought it would be, but it's still enough to cause problems. Is there anyone willing to take up upstream development of id3lib? Is there a possible (more active) replacement for id3lib? Is there a valid reason for continuing to carry such a defunct package in Fedora? s/defunct/old/ - and yes there is a valid reason - 8 or so at least, see your list of packages above ;) I'm more than happy to continue maintaining id3lib if there is a valid reason to do so, but my reasons are more sentimental than valid logical reasoning. So I turn to you to answer that question: Is there valid, logical, reasoning to continue to support such old code? Yes, because other useful packages depend on it IMHO. I'll take it if you don't want to keep it, I think that library needs to live on in Fedora. -Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
Lyos Gemini Norezel wrote: > I believe the time has come to retire ksensors. ksensors never sensed anything it is an old kde3 program that has been superseded by a nice kde4 system monitor plasmoid keeping kde3 programs that aren't absolutely essential, for which a kde4 program already exists, is very confusing and causes for things not to work -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On 10/07/2009 03:19 PM, Björn Persson wrote: Lyos Gemini Norezel wrote: Is there valid, logical, reasoning to continue to support such old code? Are there any bugs that are so severe that we can't continue using the software? No, actually. Surprisingly enough... there are no current bugs open against id3lib. If not: Why throw out working software just because it's old? Don't security risks grow exponentially as software 'bit rots'? Björn Persson Lyos Gemini Norezel <>-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On 10/07/2009 03:25 PM, Eric Sandeen wrote: Lyos Gemini Norezel wrote: ... id3lib also needs to be looked at, as it's upstream has been defunct since March 2 2003. This one might hurt more than ksensors will, since several programs depend on id3lib. This is a list of the programs that require id3lib: audio-convert-mod easytag tagtool id3lib-devel id3v2 gmediaserver liblicense-modules kid3 grip The list is alot shorter than I thought it would be, but it's still enough to cause problems. Is there anyone willing to take up upstream development of id3lib? Is there a possible (more active) replacement for id3lib? Is there a valid reason for continuing to carry such a defunct package in Fedora? s/defunct/old/ - and yes there is a valid reason - 8 or so at least, see your list of packages above ;) Heh... sure, but surely such software could be made to work with a piece of code that's more recent than id3lib? I'm more than happy to continue maintaining id3lib if there is a valid reason to do so, but my reasons are more sentimental than valid logical reasoning. So I turn to you to answer that question: Is there valid, logical, reasoning to continue to support such old code? Yes, because other useful packages depend on it IMHO. I'll take it if you don't want to keep it, I think that library needs to live on in Fedora. I'm happy to maintain it... though I could definitely use a coder as a co-maintainer, or, really, anyone who wishes to help. The problem I have with continuing such code, is both the lack of an upstream... and the potential for security risks as this piece of code is left to rot. I have neither the skills, nor the time to take over upstream, and software cannot last/stay compatible forever. -Eric Lyos Gemini Norezel <>-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On Wednesday 07 October 2009 12:55:10 pm Lyos Gemini Norezel wrote: > On 10/07/2009 03:19 PM, Björn Persson wrote: > > Lyos Gemini Norezel wrote: > >> Is there valid, logical, reasoning to continue to support such old code? > > > > Are there any bugs that are so severe that we can't continue using the > > software? > > No, actually. > > Surprisingly enough... there are no current bugs open against id3lib. > > > If not: Why throw out working software just because it's old? > > Don't security risks grow exponentially as software 'bit rots'? Is it possible that id3lib is 'complete'? The id3 format isn't extremely complicated, it may just be a completely finished library. (Keep in mind, though, that I'm not familiar with the code.) As far as being a security risk... it's not a network daemon, and there's no reason it should have suid root or anything like that. I imagine the worst you could do is throw a malformed media file at it. Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On 10/07/2009 03:37 PM, Petrus de Calguarium wrote: Lyos Gemini Norezel wrote: I believe the time has come to retire ksensors. ksensors never sensed anything it is an old kde3 program that has been superseded by a nice kde4 system monitor plasmoid keeping kde3 programs that aren't absolutely essential, for which a kde4 program already exists, is very confusing and causes for things not to work LOL... I find it to still be fully functional on the rare occasions I actually fire it up . Of course... I actually use gnome ;-) . At any rate, since it has been 'superseded', as you say, I'm going to guess there's not going to be any objection to retiring ksensors. Never-the-less, I will wait until Friday, like I said, to actually retire it. Lyos Gemini Norezel <>-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On 10/07/2009 04:04 PM, Conrad Meyer wrote: Is it possible that id3lib is 'complete'? The id3 format isn't extremely complicated, it may just be a completely finished library. (Keep in mind, though, that I'm not familiar with the code.) I suppose it's possible, but even 'finished' software should have bug fixes and compatibility updates. As far as being a security risk... it's not a network daemon, and there's no reason it should have suid root or anything like that. I imagine the worst you could do is throw a malformed media file at it. LOL... makes sense. Regards, Lyos Gemini Norezel <>-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
Lyos Gemini Norezel wrote: On 10/07/2009 03:25 PM, Eric Sandeen wrote: Lyos Gemini Norezel wrote: ... Is there a valid reason for continuing to carry such a defunct package in Fedora? s/defunct/old/ - and yes there is a valid reason - 8 or so at least, see your list of packages above ;) Heh... sure, but surely such software could be made to work with a piece of code that's more recent than id3lib? Is there a more recent id3 library? I dunno. If there is, and all the packages you mentioned can find/use it, then sure I'm more than happy to continue maintaining id3lib if there is a valid reason to do so, but my reasons are more sentimental than valid logical reasoning. So I turn to you to answer that question: Is there valid, logical, reasoning to continue to support such old code? Yes, because other useful packages depend on it IMHO. I'll take it if you don't want to keep it, I think that library needs to live on in Fedora. I'm happy to maintain it... though I could definitely use a coder as a co-maintainer, or, really, anyone who wishes to help. The problem I have with continuing such code, is both the lack of an upstream... and the potential for security risks as this piece of code is left to rot. I have neither the skills, nor the time to take over upstream, and software cannot last/stay compatible forever. I'd say that if/when problems crop up you could revisit it. Maybe the reason it's been idle for so long is that it's simple/done/perfect and could just stay that way. :) If you have any need for a comaintainer I'd be glad to though in any case. -Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On Wed, 2009-10-07 at 16:29 -0400, Lyos Gemini Norezel wrote: > On 10/07/2009 04:04 PM, Conrad Meyer wrote: > > Is it possible that id3lib is 'complete'? The id3 format isn't extremely > > complicated, it may just be a completely finished library. (Keep in mind, > > though, that I'm not familiar with the code.) > > > > I suppose it's possible, but even 'finished' software should have bug fixes > and compatibility updates. Compatibility with what? As noted, the IDv3 format hasn't changed. There are some open bugs, though: http://sourceforge.net/tracker/?limit=10&func=&group_id=979&atid=100979&assignee=&status=1&category=&artgroup=&submitter=&keyword=&artifact_id=&submit=Filter so it seems it's not quite complete. taglib is probably the best actively-developed modern alternative. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On Wed, 2009-10-07 at 13:40 -0700, Adam Williamson wrote: > There are some open bugs, though: > > http://sourceforge.net/tracker/?limit=10&func=&group_id=979&atid=100979&assignee=&status=1&category=&artgroup=&submitter=&keyword=&artifact_id=&submit=Filter > > so it seems it's not quite complete. > > taglib is probably the best actively-developed modern alternative. There's also an Ubuntu bug report indicating the use of id3lib causes some problems: https://bugs.launchpad.net/ubuntu/+source/tagtool/+bug/180110 That bug report also points out that id3lib is optional for easytag. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On Wednesday 07 October 2009, Adam Williamson wrote: > taglib is probably the best actively-developed modern alternative. I might not apply to all cases - kid3 for example uses both. Based on a brief look in the code and http://kid3.sourceforge.net/kid3_en.html#settings-menu, id3lib is used for ID3 2.3.0 tags and taglib for 2.4.0 ones, e.g. when converting from 2.4.0 to 2.3.0. I don't know why though, I'm not sufficiently familiar with either. Nor am I sure why one would convert from 2.4.0 to 2.3.0, maybe for compatibility reasons with $something. And yes, this is quite a corner case. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
Lyos Gemini Norezel wrote: > Don't security risks grow exponentially as software 'bit rots'? If someone finds and publishes a security hole, and no one tries to fix it, then the risk increases dramatically. If no holes are published and the software doesn't change, then I'd say the risk is fairly constant. There is always the possibility that some bad guy finds a hole that the good guys haven't found and fixed yet. The bad guy can then use the hole in a few directed attacks against selected targets. (In the case of id3lib he could for example send a malformed MP3 file to the victim by email.) In that case you're at risk only if you are the bad guy's target. He can also use the hole in a large-scale attack against the entire userbase (for example publish a malformed MP3 file on some popular file sharing networks), but only once, because then the hole will become publicly known and presumably fixed, and after that the risk is the same as for any other published hole. All of this is true both for stable software and for software in active development, and although the developers in an active project may occasionally find a hole and fix it, they may also introduce a new hole at any time. I'm much more nervous over programs like Squirrelmail, Firefox and Thunderbird, for which there is a steady stream of security fixes, because it indicates that the code is of low quality or that the design is fundamentally flawed. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On 10/07/2009 04:40 PM, Adam Williamson wrote: On Wed, 2009-10-07 at 16:29 -0400, Lyos Gemini Norezel wrote: On 10/07/2009 04:04 PM, Conrad Meyer wrote: Is it possible that id3lib is 'complete'? The id3 format isn't extremely complicated, it may just be a completely finished library. (Keep in mind, though, that I'm not familiar with the code.) I suppose it's possible, but even 'finished' software should have bug fixes and compatibility updates. Compatibility with what? As noted, the IDv3 format hasn't changed. Kernel changes, soname changes, api changes, etc. The IDv3 format is not the only thing this program needs to be compatible with. There are some open bugs, though: http://sourceforge.net/tracker/?limit=10&func=&group_id=979&atid=100979&assignee=&status=1&category=&artgroup=&submitter=&keyword=&artifact_id=&submit=Filter so it seems it's not quite complete. taglib is probably the best actively-developed modern alternative. Hmmm... might be worth looking into... if taglib is still being actively developed. Lyos Gemini Norezel <>-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On 10/07/2009 04:48 PM, Adam Williamson wrote: On Wed, 2009-10-07 at 13:40 -0700, Adam Williamson wrote: There are some open bugs, though: http://sourceforge.net/tracker/?limit=10&func=&group_id=979&atid=100979&assignee=&status=1&category=&artgroup=&submitter=&keyword=&artifact_id=&submit=Filter so it seems it's not quite complete. taglib is probably the best actively-developed modern alternative. There's also an Ubuntu bug report indicating the use of id3lib causes some problems: https://bugs.launchpad.net/ubuntu/+source/tagtool/+bug/180110 That bug report also points out that id3lib is optional for easytag. Nice. Good to know I'm not the only one pondering dropping id3lib from a modern distro, also... these Ubuntu bugs/issues should be investigated on Fedora. It's possible they've caught a bug we have not, though it could be Ubuntu specific (granted, not likely). Lyos Gemini Norezel <>-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
Lyos Gemini Norezel wrote: > I believe the time has come to retire ksensors. > > The last update/release was 18/08/2004, and it appears upstream has been > defunct since at least that time. > > Unless there are objections voiced and/or a maintainer steps forward > before Oct 9 (Friday), I will go ahead and retire this package. Here's an objection! I still use KSensors all the time, it still works perfectly fine and it presents the information in a better way than the plasmoids. (For example, you can have actual numbers for the temperature in the systray as opposed to some funky curves or analog indicators which are hard to read on my small panel.) The plasmoids also seem not to display hddtemp information. But I'm willing to pick up KSensors maintainership if you want to orphan it. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On 10/07/2009 05:00 PM, Ville Skyttä wrote: On Wednesday 07 October 2009, Adam Williamson wrote: taglib is probably the best actively-developed modern alternative. I might not apply to all cases - kid3 for example uses both. Based on a brief look in the code and http://kid3.sourceforge.net/kid3_en.html#settings-menu, id3lib is used for ID3 2.3.0 tags and taglib for 2.4.0 ones, e.g. when converting from 2.4.0 to 2.3.0. I don't know why though, I'm not sufficiently familiar with either. Nor am I sure why one would convert from 2.4.0 to 2.3.0, maybe for compatibility reasons with $something. And yes, this is quite a corner case. That's odd. Surely a modern ID3 tag program should support all of the IDv3 formats/versions? Lyos Gemini Norezel <>-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On 10/07/2009 04:39 PM, Eric Sandeen wrote: I'd say that if/when problems crop up you could revisit it. Maybe the reason it's been idle for so long is that it's simple/done/perfect and could just stay that way. :) If you have any need for a comaintainer I'd be glad to though in any case. Need? Not really. Though I would love to have another set of eyes on this program. So in this case '$want = yes, while $need = no' ;-) -Eric Lyos Gemini Norezel <>-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On Wed, 2009-10-07 at 17:10 -0400, Lyos Gemini Norezel wrote: > > Compatibility with what? As noted, the IDv3 format hasn't changed. > > > > Kernel changes, soname changes, api changes, etc. > The IDv3 format is not the only thing this program needs to be > compatible with. id3lib depends on very little else, only very low-level libraries which very rarely change API. Probably the last one to do so was libstdc++ , and that was years ago. As it works perfectly fine in current Rawhide, it would seem apparent that none of these changes has been needed. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On 10/07/2009 05:13 PM, Kevin Kofler wrote: Lyos Gemini Norezel wrote: I believe the time has come to retire ksensors. The last update/release was 18/08/2004, and it appears upstream has been defunct since at least that time. Unless there are objections voiced and/or a maintainer steps forward before Oct 9 (Friday), I will go ahead and retire this package. Here's an objection! I still use KSensors all the time, it still works perfectly fine and it presents the information in a better way than the plasmoids. (For example, you can have actual numbers for the temperature in the systray as opposed to some funky curves or analog indicators which are hard to read on my small panel.) The plasmoids also seem not to display hddtemp information. I don't use KDE... so I cannot comment there. However... have you considered trying gnome-applet-sensors? But I'm willing to pick up KSensors maintainership if you want to orphan it. It seems odd to continue such a package despite upstream being defunct. As I no longer use ksensors, if you wish to maintain this package... I will happily surrender maintainership to you. Kevin Kofler Lyos Gemini Norezel <>-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
Lyos Gemini Norezel wrote: > However... have you considered trying gnome-applet-sensors? gnome-applet-* doesn't work under KDE, that stuff only works in gnome-panel. > It seems odd to continue such a package despite upstream being defunct. > > As I no longer use ksensors, if you wish to maintain this package... I > will happily > surrender maintainership to you. I picked it up, thanks! Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
2009/10/8 Kevin Kofler : > Lyos Gemini Norezel wrote: >> However... have you considered trying gnome-applet-sensors? > > gnome-applet-* doesn't work under KDE, that stuff only works in gnome-panel. > >> It seems odd to continue such a package despite upstream being defunct. >> >> As I no longer use ksensors, if you wish to maintain this package... I >> will happily >> surrender maintainership to you. > > I picked it up, thanks! Thanks Kevin, i use it here as well. -- LG Thomas Dubium sapientiae initium -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On Wed, 7 Oct 2009 13:04:35 -0700, Conrad wrote: > On Wednesday 07 October 2009 12:55:10 pm Lyos Gemini Norezel wrote: > > On 10/07/2009 03:19 PM, Björn Persson wrote: > > > Lyos Gemini Norezel wrote: > > >> Is there valid, logical, reasoning to continue to support such old code? > > > > > > Are there any bugs that are so severe that we can't continue using the > > > software? > > > > No, actually. > > > > Surprisingly enough... there are no current bugs open against id3lib. > > > > > If not: Why throw out working software just because it's old? > > > > Don't security risks grow exponentially as software 'bit rots'? > > Is it possible that id3lib is 'complete'? Would be unusual, considering how complex the later ID3v2 specs are. > The id3 format isn't extremely complicated, Define "extremely complicated". http://www.id3.org/Compliance_Issues -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
