Re: Considerations for 'xmms' removal from Debian
* 07-08-2007, Andrei Popescu: [] Did you even try adding a directory? It might even work ;) xmms2... Well, when we have a decent client, then can are an option. Now, isn't it. Same as with mpd :-/ Server is `(mu-)mplayer` (seek isn't working in ogg), client is `dd`, playlist is small `sh` script: ftp://flower.upol.cz/mu-player/ Regards, Andrei --=20 If you can't explain it simply, you don't understand it well enough. (Albert Einstein) -- Hard to disagree :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
David Lopez Zajara (Er_Maqui er_maqui at darkbolt.net writes: Simply you can read this thread and can find a report of audacious (main candidate for xmms replace) crashing on a max time of 2 minutes running. It's not our fault that Debian packaged an old, buggy, and generally speaking, broken version of Audacious with a bunch of backported patches that may or may not be fully compatible. It's not our fault that Debian still has not promoted our current stable offering to testing, which has many of these crash fix and design defect fix things you may have heard about. It's not our fault that Etch did not ship with 1.3. 1.3 had been out for a considerable amount of time when Etch shipped. Please don't claim that the most recent versions of audacious (as shipped and maintained by us) crashes every 2 minutes because that's simply not true -- Debian Etch ships 1.2, and so does Lenny at this time. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Julien BLACHE jblache at debian.org writes: As you don't seem to have understood at all, none of the xmms alternatives are up to par with xmms, with many of them having usability or stability problems. Please stop blaming the faults and defects of your packaging process on upstream developers. Audacious 1.3 is perfectly capable of replacing XMMS, and has done so in many other distributions already. Moreover, Adam Cecile has tried to get 1.3 into both Etch and now Lenny, and has so far been met with trouble doing so. You want your fixes? Guess what -- they are in 1.3. Perhaps all that is needed is for Audacious in Debian testing to actually reflect the current offering of upstream. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On 8/12/07, William Pitcock [EMAIL PROTECTED] wrote: It's not our fault that Etch did not ship with 1.3. 1.3 had been out for a considerable amount of time when Etch shipped. Please don't claim that the most recent versions of audacious (as shipped and maintained by us) crashes every 2 minutes because that's simply not true -- Debian Etch ships 1.2, and so does Lenny at this time. Lenny has had 1.3 for over a month now. http://packages.qa.debian.org/a/audacious/news/20070706T223908Z.html FYI: The status of the audacious source package in Debian's testing distribution has changed. Previous version: 1.2.2-4 Current version: 1.3.2-4 -- Andrew Donnellan ajdlinuxATgmailDOTcom (primary)ajdlinuxATexemailDOTcomDOTau (secure) http://andrewdonnellan.comhttp://ajdlinux.wordpress.com [EMAIL PROTECTED]hkp://subkeys.pgp.net 0x5D4C0C58 http://linux.org.auhttp://debian.org Spammers only === [EMAIL PROTECTED] === -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
William Pitcock [EMAIL PROTECTED] wrote: As you don't seem to have understood at all, none of the xmms alternatives are up to par with xmms, with many of them having usability or stability problems. Please stop blaming the faults and defects of your packaging process on upstream developers. Audacious 1.3 is perfectly capable of replacing XMMS, and has done so in many other distributions already. Moreover, Adam Cecile has tried to get 1.3 into both Etch and now Lenny, and has so far been met with trouble doing so. You want your fixes? Guess what -- they are in 1.3. Perhaps all that is needed is for Audacious in Debian testing to actually reflect the current offering of upstream. [07-08-12 - 11:52:13] [EMAIL PROTECTED](pts/2 300):~% dpkg -l audacious Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii audacious 1.3.2-4Small and fast audio player which supports l I propose you STFU and go fix your bugs. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
David Lopez Zajara (Er_Maqui er_maqui at darkbolt.net writes: GTK+ 1.2 are unmantained upstream, yes. No it's not. GTK1 maintainance ceased in Feburary 2001. I've read on this thread, on a critical for audacious as xmms replacement, I've pointed who audacious doesn't have many features present on xmms. THAT'S BECAUSE WE ARE NOT AN XMMS REPLACEMENT. HOW MANY FUCKING TIMES DO I HAVE TO SAY THIS? We are a BMP *classic* replacement, which had OTHER ideas for the direction of the player. We are the continuation of those ideas combined with my own ideas, and definitely not the ideas of the XMMS developers for how the player should be. Therefore, we are NOT AN XMMS REPLACEMENT, OK? I've read a reply: Contact with the main upstream and ask for these features. We will not implement features only because XMMS does them. Feature requests have to include a sane reasoning and use case for why it is necessary to be implemented in Audacious. For instance, plugins can extend the GUI in many ways that they can not in XMMS, meaning that most features can be added by plugins. This is especially true in the work in progress Audacious 1.4. The same can be for application here: We can suggest to the main upstreams for all these GTK+ 1.2 application for port them to GTK+2. This work it's harder than a simple feature, but its the same, a suggestion. This are applicable for these thread, for all GTK+ 1.2 applications on the archive, and for the precipitate reaction on another distributions (mentioned on this thread). Debian is not the only distribution considering or have already removed GTK1. It was just as dead to the GTK developers in 2001 as it is now. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
ajdlinux at gmail.com writes: Lenny has had 1.3 for over a month now. http://packages.qa.debian.org/a/audacious/news/20070706T223908Z.html FYI: The status of the audacious source package in Debian's testing distribution has changed. Previous version: 1.2.2-4 Current version: 1.3.2-4 Then it is supported by us upstream. Therefore, if it crashes or blows up in your face, people should tell us about it, and not complain on a mailing list or talk about commandeering projects to make Audacious into some sort of XMMS replacement. We were very happy when the only Debian users using Audacious were those who were interested in it and understood that we were not an XMMS replacement. I would prefer if we remain happy with Debian. I am glad to hear that Audacious is finally updated in Lenny, but, it should have shipped with Etch. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Le dimanche 12 août 2007 à 09:34 +, William Pitcock a écrit : It's not our fault that Debian packaged an old, buggy, and generally speaking, broken version of Audacious with a bunch of backported patches that may or may not be fully compatible. You should talk about this with the maintainer; this has nothing to do with our processes. If that version was so buggy as not to be usable, the maintainer should have prevented it from entering a stable release. It's not our fault that Debian still has not promoted our current stable offering to testing, which has many of these crash fix and design defect fix things you may have heard about. 1.3.2 has been in testing for more than a month. It's not our fault that Etch did not ship with 1.3. 1.3 had been out for a considerable amount of time when Etch shipped. I wonder what kind of crack you are on. Your website shows the 1.3.0 release date as being 2 march 2007. This was only one month before the etch release, during the deep freeze phase. If you think one month is a considerable amount of time, you have no idea of what integrating a distribution means. Please don't claim that the most recent versions of audacious (as shipped and maintained by us) crashes every 2 minutes because that's simply not true -- Debian Etch ships 1.2, and so does Lenny at this time. Please check your facts. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Considerations for 'xmms' removal from Debian
Le dimanche 12 août 2007 à 09:58 +, William Pitcock a écrit : Then it is supported by us upstream. Therefore, if it crashes or blows up in your face, people should tell us about it, and not complain on a mailing list or talk about commandeering projects to make Audacious into some sort of XMMS replacement. http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=audacious;dist=unstable I am glad to hear that Audacious is finally updated in Lenny, but, it should have shipped with Etch. Sorry. We're working on it, but our space-time bending powers aren't yet developed enough to make your software having been released 4 months earlier. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Considerations for 'xmms' removal from Debian
Julien BLACHE jblache at debian.org writes: I propose you STFU and go fix your bugs. JB. I propose you stop classifying bugs which state is not XMMS as bugs in Audacious, or generally talking about commandeering my project. Thanks! William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Le dimanche 12 août 2007 à 10:00 +, William Pitcock a écrit : I propose you stop classifying bugs which state is not XMMS as bugs in Audacious, or generally talking about commandeering my project. Thanks! Crashes and locks up randomly sounds much like is XMMS to me, so I don't think that's the issue. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Considerations for 'xmms' removal from Debian
William Pitcock [EMAIL PROTECTED] wrote: I propose you STFU and go fix your bugs. I propose you stop classifying bugs which state is not XMMS as bugs in Audacious, or generally talking about commandeering my project. Thanks! Two bugs: - random crashes while scrolling the playlist - segfault in the ALSA output plugin That's http://bugs.debian.org/435557 in case you're interested in fixing the pile of crap that is your ALSA output plugin (hey, XMMS' one behaves perfectly...). That bug has been discussed upstream already and I provided the requested information already. I never complained about audacious not being XMMS, there's no special XMMS feature that I miss in audacious. Now if only it'd stop segfaulting in under 2 minutes, that would render it usable. Now, will you please go fix your bugs ? Thanks, JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Josselin Mouette joss at debian.org writes: Le dimanche 12 août 2007 à 09:34 +, William Pitcock a écrit : You should talk about this with the maintainer; this has nothing to do with our processes. If that version was so buggy as not to be usable, the maintainer should have prevented it from entering a stable release. Well, 1.2 was usable for most people. 1.3.2 has been in testing for more than a month. That's nice. I'm sorry for getting that wrong. I wonder what kind of crack you are on. Your website shows the 1.3.0 release date as being 2 march 2007. This was only one month before the etch release, during the deep freeze phase. If you think one month is a considerable amount of time, you have no idea of what integrating a distribution means. I find it funny that Fedora Core 5, 6, and 7, all included the latest versions of Audacious at the time of their releases, which had similar time windows. Please check your facts. Please stop calling my project an XMMS replacement. Because it's not. I'm simply providing the mailing list the same courtesy of assuming facts and deriving facts from old, outdated information instead of doing research (as many others have done). It seems appropriate here. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Le dimanche 12 août 2007 à 10:13 +, William Pitcock a écrit : If you think one month is a considerable amount of time, you have no idea of what integrating a distribution means. I find it funny that Fedora Core 5, 6, and 7, all included the latest versions of Audacious at the time of their releases, which had similar time windows. And you can see the result. I don't think our users eat the same rillettes. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Considerations for 'xmms' removal from Debian
Josselin Mouette joss at debian.org writes: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=audacious;dist=unstable Yes, I have discussed these with Adam Cecile. Many of those bugs have been fixed in 1.4, and cannot be fixed in current 1.3 due to architectural shift from the old XMMS paradigm to a new event driven paradigm. I apologize if I seem like a jerk, but I must watch out for disinformation campaigns as the same thing happened in Gentoo with users who had intentions to make outlandish claims about the state of our development (really it does work for most users) in order to keep XMMS -- which simply isn't cool. Basically I am trying to maintain Audacious's good standing in the community it intends to serve (which is not really the XMMS community, but instead, the people who thought XMMS was a good idea, but not implemented well.) So, I apologize if I seem like a jerk about this. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On Sun, Aug 12, 2007 at 10:13:45AM +, William Pitcock wrote: Josselin Mouette joss at debian.org writes: Le dimanche 12 août 2007 à 09:34 +, William Pitcock a écrit : I wonder what kind of crack you are on. Your website shows the 1.3.0 release date as being 2 march 2007. This was only one month before the etch release, during the deep freeze phase. If you think one month is a considerable amount of time, you have no idea of what integrating a distribution means. I find it funny that Fedora Core 5, 6, and 7, all included the latest versions of Audacious at the time of their releases, which had similar time windows. Well Debian has another focus than Fedora Core, I won't comment further on the implications... Please check your facts. Please stop calling my project an XMMS replacement. Because it's not. I'm simply providing the mailing list the same courtesy of assuming facts and deriving facts from old, outdated information instead of doing research (as many others have done). It seems appropriate here. It seems that you don't understand why we call it an XMMS replacement: it's not at all about having all the same features, it's about the core functionality. If we consider audacious an XMMS replacement it means that we think audacious is as good or even better then XMMS for the core functionality. If you don't like audacious to get many more users because of it, we might indeed consider other replacements... Cheers Luk
Re: Considerations for 'xmms' removal from Debian
Julien BLACHE jblache at debian.org writes: Two bugs: - random crashes while scrolling the playlist - segfault in the ALSA output plugin That's http://bugs.debian.org/435557 in case you're interested in fixing the pile of crap that is your ALSA output plugin (hey, XMMS' one behaves perfectly...). That bug has been discussed upstream already and I provided the requested information already. Yes, we are indeed aware of your bug, however, after inquiring with the people responsible for the ALSA plugin, the conclusion we presently have is that we are unable to reproduce it, so it will take some time before we can come up with a patch for 1.3 in Debian or even perhaps a release which resolves the issue. But don't worry, since your bug is indeed valid, it will be fixed in audacious-plugins-1.3.6; even if I have to do it myself. I presently do not use ALSA, so I cannot help much there at the moment. If you are interested in fixing this, please hang around our IRC channel at irc.atheme.org #audacious, and ask to talk to either Chainsaw or giacomo, who jointly maintain the plugin. Be sure to identify yourself and note that I specifically sent you there, because some of our inhabitants who will for the interest of transparency, remain nameless at this time are capable of being very rude and abusive -- and would likely be more pleasant if they knew that someone high up in the project directly requested your presence for debugging. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
William Pitcock [EMAIL PROTECTED] wrote: Yes, we are indeed aware of your bug, however, after inquiring with the people responsible for the ALSA plugin, the conclusion we presently have is that we are unable to reproduce it, so it will take some time before we can come up with a patch for 1.3 in Debian or even perhaps a release which resolves the issue. But don't worry, since your bug is indeed valid, it will be fixed in audacious-plugins-1.3.6; even if I have to do it myself. I think you need at least an Intel HDA card to reproduce that problem, as it's probably the driver that presents something weird to the lib. Might even need a MacBook with the same setup :| I'll see on another machine if the ALSA plugin behaves better. I presently do not use ALSA, so I cannot help much there at the moment. If you Still using OSS ? :) are interested in fixing this, please hang around our IRC channel at irc.atheme.org #audacious, and ask to talk to either Chainsaw or giacomo, who I'll try to take a closer look at the problem if I can find some time to do so. jointly maintain the plugin. Be sure to identify yourself and note that I specifically sent you there, because some of our inhabitants who will for the interest of transparency, remain nameless at this time are capable of being very rude and abusive -- and would likely be more pleasant if they knew that someone high up in the project directly requested your presence for debugging. Can't be worse than -devel ;) JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Julien BLACHE jblache at debian.org writes: I think you need at least an Intel HDA card to reproduce that problem, as it's probably the driver that presents something weird to the lib. Might even need a MacBook with the same setup :| I'll see on another machine if the ALSA plugin behaves better. Yes, we have received reports about problems with the intel HDA driver in ALSA and audacious. I think it's because per Takashi Iwai, we removed the mmap mode from our plugin, but as I do not use ALSA anymore I can't honestly say what the problem is, as I do not know for certain. Still using OSS ? :) If by OSS you mean that crappy OSS/Free, then no. I use the recently open sourced OSS4, created by the guys who ironically sponsored XMMS development. The reason being is that ALSA has never really worked well for my hardware (in any application, including XMMS), and OSS4 supports my current hardware while ALSA's support is still unimplemented (Soundblaster XFi). If you're having issues with ALSA, I strongly recommend giving OSS4 a go, it works very well (although some people with political interests over technical ones are probably likely to disagree). You can find out more information at http://developer.opensound.com if you're interested in it. I'll try to take a closer look at the problem if I can find some time to do so. Ok, I'm sure they would indeed be happy to look into your problem. Reviewing IRC logs it looks like at least Chainsaw is interested in it. Can't be worse than -devel ;) If you say so. Well, actually, it's very similar. Probably because everyone feels that they are doing what is best for Audacious, even if it's perhaps not. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
I propose you STFU and go fix your bugs. I propose you stop classifying bugs Now, will you please go fix your bugs ? Gentlemen, I think that your discussion about who is faulty or not is going far from the topic of this list, which is the development of the Debian distribution. Please do not take offence, but could you continue it in private ? Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Luk Claes luk at zomers.be writes: Well Debian has another focus than Fedora Core, I won't comment further on the implications... I'm not qualified to comment on that either. However, I was simply demonstrating that other distributions found it possible to integrate within the time window. It seems that you don't understand why we call it an XMMS replacement: it's not at all about having all the same features, it's about the core functionality. If we consider audacious an XMMS replacement it means that we think audacious is as good or even better then XMMS for the core functionality. If you don't like audacious to get many more users because of it, we might indeed consider other replacements... It's not that we don't like having a userbase, it's that Audacious is philosophically different from XMMS which may result in a high support case load upon XMMS being replaced with Audacious, and people saying bad things about Audacious because it's not like XMMS. I have observed that people consider the phrase XMMS replacement to be synonymous to XMMS clone, which results in unnecessary support cases concerning deviations in featureset. What somebody should do is propose to take Audacious 1.2 (since it is more like XMMS than other offerings we have) and mix it with XMMS, and then ask XMMS upstream what they feel. If they go for it, then everyone is happy, are they not? Because while XMMS is indeed different, Audacious could be a decent basis for a GTK2 XMMS release series (call it XMMS 1.3 or something, since XMMS2 is something else clearly). That is what I would like to see happen, anyway. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
William Pitcock a écrit : Julien BLACHE jblache at debian.org writes: I think you need at least an Intel HDA card to reproduce that problem, as it's probably the driver that presents something weird to the lib. Might even need a MacBook with the same setup :| I'll see on another machine if the ALSA plugin behaves better. Yes, we have received reports about problems with the intel HDA driver in ALSA and audacious. I think it's because per Takashi Iwai, we removed the mmap mode from our plugin, but as I do not use ALSA anymore I can't honestly say what the problem is, as I do not know for certain. Not reproductible on my recent Apple iMac : │ Card: HDA Intel │ Chip: SigmaTel STAC9221 A1 Still using OSS ? :) If by OSS you mean that crappy OSS/Free, then no. I use the recently open sourced OSS4, created by the guys who ironically sponsored XMMS development. The reason being is that ALSA has never really worked well for my hardware (in any application, including XMMS), and OSS4 supports my current hardware while ALSA's support is still unimplemented (Soundblaster XFi). If you're having issues with ALSA, I strongly recommend giving OSS4 a go, it works very well (although some people with political interests over technical ones are probably likely to disagree). You can find out more information at http://developer.opensound.com if you're interested in it. I'll try to take a closer look at the problem if I can find some time to do so. Ok, I'm sure they would indeed be happy to look into your problem. Reviewing IRC logs it looks like at least Chainsaw is interested in it. Can't be worse than -devel ;) If you say so. Well, actually, it's very similar. Probably because everyone feels that they are doing what is best for Audacious, even if it's perhaps not. William
Re: Considerations for 'xmms' removal from Debian
On Sun, Aug 12, 2007 at 01:18:32PM +, William Pitcock wrote: It seems that you don't understand why we call it an XMMS replacement: it's not at all about having all the same features, it's about the core functionality. If we consider audacious an XMMS replacement it means that we think audacious is as good or even better then XMMS for the core functionality. If you don't like audacious to get many more users because of it, we might indeed consider other replacements... It's not that we don't like having a userbase, it's that Audacious is philosophically different from XMMS which may result in a high support case load upon XMMS being replaced with Audacious, and people saying bad things about Audacious because it's not like XMMS. I have observed that people consider the phrase XMMS replacement to be synonymous to XMMS clone So take it up with these people who don't understand English instead of yelling at Debian on our -devel list, yeesh. It sounds to me like it *is* the case that you don't like having a userbase. The only way to avoid people drawing comparisons between XMMS and audacious is to not let them become aware of audacious's existence. If you have users, you're going to have support requests, and some of those are going to be about the differences with XMMS, because that's the space in which audacious exists. It would be nice if you came to terms with this fact instead of abusing Debian for true and reasonable statements that developers have made -- it's not our fault that audacious is a music player whose basic UI design imitates that of winamp/xmms. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
GTK1 Apps (was: Re: Considerations for 'xmms' removal from Debian)
Josselin Mouette wrote: I don't have any power to remove their packages from Debian, but I urge every maintainer of a package depending on GTK+ 1.2 to either start the work on GTK2 porting it or consider its removal. And now is more than the time to start this. Neil Williams wrote: If anyone wants *any* packages on http://wiki.debian.org/GTK+_1%2e2_leftovers to remain in Debian after Lenny, then do as I have done and take over the upstream maintenance of the old code and do the port yourself. Nobody else is apparently willing to do it. I am the gbib maintainer and despite the fact that it is fairly unmaintained upstream I use it regularly and know of no good replacement. I would love to port it it to GTK2, and it is a fairly simple UI, but while I can keep on top of any RC bugs which may arise (there are none at the moment), and do the odd tweak, I certainly don't know enough GTK to be able to port it to GTK2; nor do I have the time to learn right now. Are there any guides, howtos, instructions or anything else useful for porting gtk1 apps to gtk2? I certainly would like to keep this package I use daily in Debian, as I'm sure would many of my 350*(popcon factor) users. Thanks, Matt -- Matthew Johnson Trinity Hall IT Support signature.asc Description: Digital signature
Re: GTK1 Apps (was: Re: Considerations for 'xmms' removal from Debian)
On Sun, 12 Aug 2007 23:36:40 +0100 Matthew Johnson [EMAIL PROTECTED] wrote: Josselin Mouette wrote: I don't have any power to remove their packages from Debian, but I urge every maintainer of a package depending on GTK+ 1.2 to either start the work on GTK2 porting it or consider its removal. And now is more than the time to start this. Neil Williams wrote: If anyone wants *any* packages on http://wiki.debian.org/GTK+_1%2e2_leftovers to remain in Debian after Lenny, then do as I have done and take over the upstream maintenance of the old code and do the port yourself. Nobody else is apparently willing to do it. I am the gbib maintainer and despite the fact that it is fairly unmaintained upstream I use it regularly and know of no good replacement. I would love to port it it to GTK2, and it is a fairly simple UI, but while I can keep on top of any RC bugs which may arise (there are none at the moment), and do the odd tweak, I certainly don't know enough GTK to be able to port it to GTK2; nor do I have the time to learn right now. Are there any guides, howtos, instructions or anything else useful for porting gtk1 apps to gtk2? I certainly would like to keep this package I use daily in Debian, as I'm sure would many of my 350*(popcon factor) users. Thanks, Matt The GTK documentation itself contains instructions on porting from gtk1 to gtk2. http://developer.gnome.org/doc/API/2.0/gtk/migrating.html Beyond that, the changes are almost entirely package-specific. Depending on the amount of customisation of Gtk widgets within the gtk1 codebase, it can be a lengthy task involving quite a lot of detailed C hacking. It comes down to this analysis of your upstream code: 1. Does the code customise Gtk widgets into new forms? 2. How much logic is 'hidden' in the GUI? (checks on missing values in dialog boxes, etc.) 3. Was any work done to port from gtk1.0 to gtk1.2 because much of that will have to be undone. 4. Basically, how easy would it be to rewrite your application for Qt - if you knew the Qt libraries as well as you know Gtk1? The more affirmative answers you get, the more work is involved. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpKFdoRhjTQC.pgp Description: PGP signature
Re: Considerations for 'xmms' removal from Debian
David Lopez Zajara (Er_Maqui er_maqui at darkbolt.net writes: .. I doesn't have more for this, but a comment: I've read on this thread, on a critical for audacious as xmms replacement, I've pointed who audacious doesn't have many features present on xmms. Hello everyone, I'm a regular Debian user, and I have followed this rather intense discussion about the removal of Xmms, and like to add two things: First of all, I think Audacious is really good and mature enough to replace Xmms. I have been using Xmms until some weeks ago, when I first read this discussion. Then I gave Audacious a try, and I like it even better then Xmms, and I think I am rather picky. I use Debian testing, and I think all stories about millions of huge bugs in Audacious are exaggerated. Audacious looks much better (partly because it uses the newer gtk I think), text is much better readable and from what I see it is at least evenly configurable. It also has quite some plugins available. Second, from my point of view, Xmms is unmaintained upstream. There's no active community that is improving Xmms, the site is rather dead and the previous mentioned list of 'future improvements' has not been updated for at least three years, see http://web.archive.org/web/*/http://www.xmms.org/next_version.php . Periodically, something does change, but it cannot be considered as maintaining IMHO. So what I'm saying; I would understand the removal of Xmms. Regards, Andre Offringa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Le samedi 11 août 2007 à 12:25 +0900, Charles Plessy a écrit : Le Fri, Aug 10, 2007 at 04:00:18PM +0200, Josselin Mouette a écrit : As you don't seem to have understood at all, let me repeat it: XMMS is unmaintained. Dear Josselin, why do you write this while it has been said the contrary and that visiting www.xmms.org strongly supports the fact that it is not abandonned? I don't want to play on words, but I won't call a software that hasn't been updated to the new GTK+ API after more than five years maintained. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Considerations for 'xmms' removal from Debian
Le samedi 11 août 2007 à 06:57 +0200, David Lopez Zajara (Er_Maqui) a écrit : You are saying to the mantainers who if they doesnt work on a GTK+ 1.2 - 2.0 port their packages will go out of debian now? I don't have any power to remove their packages from Debian, but I urge every maintainer of a package depending on GTK+ 1.2 to either start the work on GTK2 porting it or consider its removal. And now is more than the time to start this. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Considerations for 'xmms' removal from Debian
On 8/12/07, Josselin Mouette [EMAIL PROTECTED] wrote: Le samedi 11 août 2007 à 06:57 +0200, David Lopez Zajara (Er_Maqui) a écrit : You are saying to the mantainers who if they doesnt work on a GTK+ 1.2 - 2.0 port their packages will go out of debian now? I don't have any power to remove their packages from Debian, but I urge every maintainer of a package depending on GTK+ 1.2 to either start the work on GTK2 porting it or consider its removal. And now is more than the time to start this. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. Just because I had nothing to do, I generated a list on the wiki on all packages that depends on gtk+ 1.2; see: http://wiki.debian.org/GTK+_1%2e2_leftovers -- /Carl Fürstenberg [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Josselin Mouette [EMAIL PROTECTED] wrote: As you don't seem to have understood at all, let me repeat it: XMMS is unmaintained. GTK+ 1.2 is unmaintained. Anyone who wants to see xmms remain in Debian should take over maintainership for both, including upstream maintenance and all that it implies. As you don't seem to have understood at all, none of the xmms alternatives are up to par with xmms, with many of them having usability or stability problems. Anyone who wants to see xmms removed from Debian should step up and do whatever is required to get at least one of the alternatives in a somewhat usable shape. See? It works the other way around too :-) I really don't see the problem in keeping xmms around until there's a viable alternative. It's not like it's the last GTK+ 1.2 application in the archive, and it's most certainly not the least useful of the lot. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On 07-Aug-07, 18:53 (CDT), David Lopez Zajara (Er_Maqui) [EMAIL PROTECTED] wrote: But, we can you read on this thread, the point isn't to make an remaked-xmms on audacious, its makes users switch to another player. I wish people would stop saying this. Nothing is going remove xmms from *your* system except you. It simply won't be available as a Debian package from the Debian archive on new installs. Why not? Because nobody is willing to make the effort to support it. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Le vendredi 10 août 2007 à 04:48 +0200, David Lopez Zajara (Er_Maqui) a écrit : I've read the complete thread, and i understand who the main reason from the mantainers are these. But, in the other hand, have the reason of gtk1.2 removal porposal. I understand this, but, i say who SAME of the given reasons are incorrect. On what grounds? As you don't seem to have understood at all, let me repeat it: XMMS is unmaintained. GTK+ 1.2 is unmaintained. Anyone who wants to see xmms remain in Debian should take over maintainership for both, including upstream maintenance and all that it implies. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: Considerations for 'xmms' removal from Debian
On Fri, 10 Aug 2007, Julien BLACHE wrote: I really don't see the problem in keeping xmms around until there's a viable alternative. There's no problem so long as there as someone who is actually willing to maintain it and be responsible for both it and GTK+ 1.2. Unless you are willing to step up and maintain it, arguing against the current maintainer's decision to request the removal XMMS seems kind of odd. [Surely you don't expect -qa to maintain it?] Don Armstrong -- Our days are precious, but we gladly see them going If in their place we find a thing more precious growing A rare, exotic plant, our gardener's heart delighting A child whom we are teaching, a booklet we are writing -- Frederick Rükert _Wisdom of the Brahmans_ [Hermann Hesse _Glass Bead Game_] http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Considerations for 'xmms' removal from Debian
Julien BLACHE [EMAIL PROTECTED] writes: Josselin Mouette [EMAIL PROTECTED] wrote: As you don't seem to have understood at all, let me repeat it: XMMS is unmaintained. GTK+ 1.2 is unmaintained. Anyone who wants to see xmms remain in Debian should take over maintainership for both, including upstream maintenance and all that it implies. As you don't seem to have understood at all, none of the xmms alternatives are up to par with xmms, with many of them having usability or stability problems. Anyone who wants to see xmms removed from Debian should step up and do whatever is required to get at least one of the alternatives in a somewhat usable shape. See? It works the other way around too :-) No. Removal of a package (that isn't part of the standard install) does *not* require adding a package to replace it. On the other hand, packages that are unmaintained, and that have dependencies also unmaintained, are cruft to be removed. -- \ As the most participatory form of mass speech yet developed, | `\the Internet deserves the highest protection from governmental | _o__) intrusion. —U.S. District Court Judge Dalzell | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Le Fri, Aug 10, 2007 at 04:00:18PM +0200, Josselin Mouette a écrit : As you don't seem to have understood at all, let me repeat it: XMMS is unmaintained. Dear Josselin, why do you write this while it has been said the contrary and that visiting www.xmms.org strongly supports the fact that it is not abandonned? http://www.xmms.org/ http://www.xmms.org/next_version.php http://havardk.xmms.org/dist/cvs/ChangeLog-20070711 There can be good reasons for removal, but adding wrong ones just suggests that the others are equally unaccurate. Have a nice weekend, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Josselin Mouette wrote: Le vendredi 10 août 2007 à 04:48 +0200, David Lopez Zajara (Er_Maqui) a écrit : I've read the complete thread, and i understand who the main reason from the mantainers are these. But, in the other hand, have the reason of gtk1.2 removal porposal. I understand this, but, i say who SAME of the given reasons are incorrect. On what grounds? As you don't seem to have understood at all, let me repeat it: XMMS is unmaintained. GTK+ 1.2 is unmaintained. Anyone who wants to see xmms remain in Debian should take over maintainership for both, including upstream maintenance and all that it implies. First: This thread is a right call for kill xmms from debian, not a thread for call for solutions because a possible unmantained upstream. Now, reading from the xmms official webpage, i've readed this: QUOTE ATTENTION DEBIAN! Hello José Miguel Parrella Romero. You're a gentoo developer. *hugs and kisses* We haven't deprecated xmms. Why would we? Jul 11, 2007 Thomas Nilsson (thomas at xmms.org) /QUOTE It isn't a depretiation for this developer, is a form to demostrate who the xmms developers are now active. And, in this thread are now a link for the 2007-07-11 changelog. This are from 1 month later. This is a unmantained upstream package? One motivation for xmms removal are the mantainer unaviability for this. Yeah, but, this have their solution on a orphan request, or request for help. GTK+ 1.2 are unmantained upstream, yes. But, now, in Debian are more than 300 packages who depends on this. Yes, there are many packages they are xmms plugins, but, many of these packages arent packages for xmms. Your right is for remove all these packages from debian? Now, these packages are on unstable, and GTK+ 1.2 too. Some of these packages are mantained now. You are saying to the mantainers who if they doesnt work on a GTK+ 1.2 - 2.0 port their packages will go out of debian now? If the GTK+ 1.2 upstream is dead from far ago, whats the reason for removal NOW and not one year ago? Or, for wait one year more? If the reason for mantain the GTK+ 1.2 packages its the developed application for this, you can wait a bit more, for upstreams work on them. In the case of xmms, i've a notice for you: - From xmms official webpage (FAQ): QUOTE Does XMMS work with GTK+ 2.x? No, XMMS 1.2.x does not work with GTK+ 2, it requires GTK+/GLIB 1.2.x. There is a project called BEEP which is a GTK+2 fork of XMMS. But your existing plugin will have to be ported to GTK+2 for this to work. We will eventually release a GTK+2 version of XMMS 1, but it still hasn't been decided when that will be. Hopefully we'll merge back the good stuff from BEEP to make the transition faster and help to convince plugin authors to port their GTK+1 versions to GTK+2. /QUOTE I doesn't have more for this, but a comment: I've read on this thread, on a critical for audacious as xmms replacement, I've pointed who audacious doesn't have many features present on xmms. I've read a reply: Contact with the main upstream and ask for these features. The same can be for application here: We can suggest to the main upstreams for all these GTK+ 1.2 application for port them to GTK+2. This work it's harder than a simple feature, but its the same, a suggestion. This are applicable for these thread, for all GTK+ 1.2 applications on the archive, and for the precipitate reaction on another distributions (mentioned on this thread). Regards. Er_Maqui. - -- [EMAIL PROTECTED] || http://maqui.darkbolt.net Linux registered user number: #363219 PGP key avaliable at KeyServ. KeyID: 0x4233E9F2 - -- Los hombres somos esclavos de la historia -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGvUHJfFjA4EIz6fIRAhLwAJkBfc5CjYfo8XGszh/l11uewHo5KgCfcRax vPYIIVhVL/aaALLX4VuKjBI= =vQpO -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On Tue, 2007-08-07 at 05:04 +0200, David Lopez Zajara (Er_Maqui) wrote: xmms have 11000+ popcon installations reported. The total reports of popcon are 57000+. This is aprox 20% of users. Now, are talking for removal an application for those users?... I've read the buglist of xmms, and i think who more than one and two bugs can be removed. Example of this can are #244984, #260754, #161702. A lot of these bugs are already opened because the version doesn't have changed (Are revised). I think who can be interesting revise the xmms buglist and close the outdated bugs, for a real information of application problems. I've read in this thread, this is for a orphan package. If this is the reason, doesnt have much more for talk, another mantainer will become. xmms its a very popular package. I think who an orphan isn't a reason at all for removal from arch. It clearly seems that you haven't read the whole thread. Your understanding of the only argument for removing xmms being that it's orphaned and your understanding of the only argument for keeping xmms being that it's popular clearly shows your misread of the whole log on the discussion. -- David Moreno Garza [EMAIL PROTECTED] | http://www.damog.net/ Le dije man, ya estás muy pasado.
Re: Considerations for 'xmms' removal from Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've read the complete thread, and i understand who the main reason from the mantainers are these. But, in the other hand, have the reason of gtk1.2 removal porposal. I understand this, but, i say who SAME of the given reasons are incorrect. Too, i say who the package are really popular, and doesnt exist an real replace for this, because the similar packages are too new packages. Simply you can read this thread and can find a report of audacious (main candidate for xmms replace) crashing on a max time of 2 minutes running. And, the another candidates, are for example, xmms2, a stream server who in debian only have a VERY simply interface (without really functionality in comparation of xmms), or the console-client, who doesn't are a replace at all. David Moreno Garza wrote: On Tue, 2007-08-07 at 05:04 +0200, David Lopez Zajara (Er_Maqui) wrote: xmms have 11000+ popcon installations reported. The total reports of popcon are 57000+. This is aprox 20% of users. Now, are talking for removal an application for those users?... I've read the buglist of xmms, and i think who more than one and two bugs can be removed. Example of this can are #244984, #260754, #161702. A lot of these bugs are already opened because the version doesn't have changed (Are revised). I think who can be interesting revise the xmms buglist and close the outdated bugs, for a real information of application problems. I've read in this thread, this is for a orphan package. If this is the reason, doesnt have much more for talk, another mantainer will become. xmms its a very popular package. I think who an orphan isn't a reason at all for removal from arch. It clearly seems that you haven't read the whole thread. Your understanding of the only argument for removing xmms being that it's orphaned and your understanding of the only argument for keeping xmms being that it's popular clearly shows your misread of the whole log on the discussion. -- David Moreno Garza [EMAIL PROTECTED] | http://www.damog.net/ Le dije man, ya estás muy pasado. - -- [EMAIL PROTECTED] || http://maqui.darkbolt.net Linux registered user number: #363219 PGP key avaliable at KeyServ. KeyID: 0x4233E9F2 - -- Los hombres somos esclavos de la historia -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGu9IHfFjA4EIz6fIRAh8fAKCQ9h7esLVSihWyePKF+fYYI0IYmwCdHBcG inOc7kCnaDr1Op/qLAGr94Q= =PoDD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On Tue, Aug 07, 2007 at 04:22:59AM +0200, David Lopez Zajara (Er_Maqui) wrote: Personally i'm an xmms user, and now, with this, i have tested other options. Audacious isn't an option at all. Yes, we have the same winamp-style, and can read winamp xmms skins, too. But, it's newer and doesn't have some options interesting (For example, add directory to playlist). It isn't a joke, this is a neccesary option. Opening the songs one-by-one or dir-by-dir without recursivety of the inside directories isn't an option at all. Did you even try adding a directory? It might even work ;) xmms2... Well, when we have a decent client, then can are an option. Now, isn't it. Same as with mpd :-/ Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: Considerations for 'xmms' removal from Debian
Hi On Tue, 7 Aug 2007 09:25:21 +0300 Andrei Popescu [EMAIL PROTECTED] wrote: On Tue, Aug 07, 2007 at 04:22:59AM +0200, David Lopez Zajara (Er_Maqui) wrote: xmms2... Well, when we have a decent client, then can are an option. Now, isn't it. Same as with mpd :-/ Have you tried to report missing features to authors of some client? Eg. Sonata upstream is usually very responsive on suggestions. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: Considerations for 'xmms' removal from Debian
David Lopez Zajara (Er_Maqui) [EMAIL PROTECTED] wrote: Hi, Personally i'm an xmms user, and now, with this, i have tested other options. Audacious isn't an option at all. Yes, we have the same I've recently tried to switch to Audacious, and man it's buggy. Way more buggy than xmms. Random segfaults during playback, random segfaults while scrolling the playlist; can't have it running for more than 2 minutes. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On Tue, Aug 07, 2007 at 11:38:33AM +0200, Julien BLACHE wrote: David Lopez Zajara (Er_Maqui) [EMAIL PROTECTED] wrote: Hi, Personally i'm an xmms user, and now, with this, i have tested other options. Audacious isn't an option at all. Yes, we have the same I've recently tried to switch to Audacious, and man it's buggy. Way more buggy than xmms. Random segfaults during playback, random segfaults while scrolling the playlist; can't have it running for more than 2 minutes. If you are using the version from Etch I would recommend upgrading/backporting to the version from unstable. It is quite usable. -- Stanislav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Stanislav Maslovski [EMAIL PROTECTED] wrote: Random segfaults during playback, random segfaults while scrolling the playlist; can't have it running for more than 2 minutes. If you are using the version from Etch I would recommend upgrading/backporting to the version from unstable. It is quite usable. I'm running unstable on all my desktops. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Julien BLACHE wrote: Stanislav Maslovski [EMAIL PROTECTED] wrote: Random segfaults during playback, random segfaults while scrolling the playlist; can't have it running for more than 2 minutes. If you are using the version from Etch I would recommend upgrading/backporting to the version from unstable. It is quite usable. I'm running unstable on all my desktops. JB. At all, xmms are an oldest package, because this, an more-tested package and more-stable. In fact, xmms was the default player on linux, or the most popular long ago. It's normal who a package with this are more tested and cleaned. - -- [EMAIL PROTECTED] || http://maqui.darkbolt.net Linux registered user number: #363219 PGP key avaliable at KeyServ. KeyID: 0x4233E9F2 - -- Los hombres somos esclavos de la historia -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGuQSTfFjA4EIz6fIRAuA+AKD9OtLb1d4YbSIWjr6+SzvhcLwb5QCfWMjX dbrail95sj0nJ9HKEyY1qNI= =MBAM -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michal Čihař wrote: Hi On Tue, 7 Aug 2007 09:25:21 +0300 Andrei Popescu [EMAIL PROTECTED] wrote: On Tue, Aug 07, 2007 at 04:22:59AM +0200, David Lopez Zajara (Er_Maqui) wrote: xmms2... Well, when we have a decent client, then can are an option. Now, isn't it. Same as with mpd :-/ Have you tried to report missing features to authors of some client? Eg. Sonata upstream is usually very responsive on suggestions. The point isn't report missing features to the main upstream, its who if you are searching for a package replace you need a real replace. Audacious have the same interface winamp-like, but, its a newer package and have some missing features. But, we can you read on this thread, the point isn't to make an remaked-xmms on audacious, its makes users switch to another player. And the main point its to deliver who client its the best for user switch, and the porposed alternatives, audacious its the client with more possibilities (because their interface, like xmms), but isn't because their missing features. At all, this is my opinion, an opinion of a not really noob, but not really advanced, too user, who are using xmms from long ago. Really i have tested some options, but this doesn't convince me. I'm an not really exigent user, but i find some functionality on a player who audacious doesn't get me. - -- [EMAIL PROTECTED] || http://maqui.darkbolt.net Linux registered user number: #363219 PGP key avaliable at KeyServ. KeyID: 0x4233E9F2 - -- Los hombres somos esclavos de la historia -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGuQYPfFjA4EIz6fIRAo0YAJ9JHDEeEKy0h/KehDLMYJkeraX03wCeKuPj PLEBpL3rYfr7V4lTwA8Eqw8= =Fa6/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On Wed, Aug 08, 2007 at 01:47:31AM +0200, David Lopez Zajara (Er_Maqui) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Julien BLACHE wrote: Stanislav Maslovski [EMAIL PROTECTED] wrote: Random segfaults during playback, random segfaults while scrolling the playlist; can't have it running for more than 2 minutes. If you are using the version from Etch I would recommend upgrading/backporting to the version from unstable. It is quite usable. I'm running unstable on all my desktops. JB. At all, xmms are an oldest package, because this, an more-tested package and more-stable. In fact, xmms was the default player on linux, or the most popular long ago. It's normal who a package with this are more tested and cleaned. old skool ;-) Regards, Paddy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On Tue, Aug 07, 2007 at 09:28:05PM +0200, Julien BLACHE wrote: Stanislav Maslovski [EMAIL PROTECTED] wrote: Random segfaults during playback, random segfaults while scrolling the playlist; can't have it running for more than 2 minutes. If you are using the version from Etch I would recommend upgrading/backporting to the version from unstable. It is quite usable. I'm running unstable on all my desktops. Hm. I am running backported audacious on etch. I admit that I have seen audacious segfaulting but not as often as you describe. Moreover, with this new version I have yet to see it... Well, anyway, reportbug is our friend ;) -- Stanislav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Kobras wrote: On Wed, Jul 04, 2007 at 01:40:05AM -0400, Jordi Gutierrez Hermoso wrote: On 03/07/07, Klaus Ethgen [EMAIL PROTECTED] wrote: I heard this crap only when using alsa. which is a problem, since OSS is deprecated in favour of ALSA. It's only OSS-the-kernel-drivers that are deprecated. OSS-the-programming-interface still works fine. Not sure, which part of ALSA actually gave rise to Klaus's problems, though. Regards, Daniel. We can't give all the problem of the OS to xmms, because in this case, the fail is from alsa system, makes and convenient bug-report to alsa and try to solvent them. But, it isn't from xmms. The old-good xmms, with our fails. Yes, it's possible if you are playing files over nfs we can lock them, and the interface its gtk1 and its outdated. But, its a consolidated program, very tested and debbuged, and works fine. We are a kind of noobs on debian using xmms, and a group of older users who uses xmms from long time ago. it's the same as winamp on windows, there have their users and this is fine. Personally i'm an xmms user, and now, with this, i have tested other options. Audacious isn't an option at all. Yes, we have the same winamp-style, and can read winamp xmms skins, too. But, it's newer and doesn't have some options interesting (For example, add directory to playlist). It isn't a joke, this is a neccesary option. Opening the songs one-by-one or dir-by-dir without recursivety of the inside directories isn't an option at all. xmms2... Well, when we have a decent client, then can are an option. Now, isn't it. I think who xmms removal its maked in another distros, and i understand who gtk1 its too outdated. But, debian its the system-for-all and if a user really likes and older application, we can have this. [QUOTE] * The BTS reports 231 bugs, most tagged 'important' or 'normal', and a couple of debugging was attempted with little success. * XMMS is broken in several aspects, one of the most important being it's dependence on GTK+ 1.2 and no UTF-8 support, which is standard in Debian Etch. * Other distributions have already discussed XMMS removal. Gentoo hardmasked the package based on the same rationale [1] * 'bmpx' and 'audacious' are in Debian, ranks 8048 and 3649 in popcon. Both are very good and development-active substitutes to xmms. * There's also in Debian the upstream-supported xmms2 package, 2598 in popcon rank. xmms is now 1069 in the overall popcon rank, with 11029 installations, not counting the plugin users. [/QUOTE] If the BTS reports more than 200 bugs, feels free to send to real-xmms mantainers (the programmers). xmms have an active development line (In their CVS the last commit was from some weeks ago). Xmms are broken in several aspects. Comment out these aspects, the solution its simply report this aspects, not makes a discursion from this without planning any solution. If these aspects are know as long ago, whats the reason for not report this? Other distros have already removal xmms. Well, other distros aren't debian. If gentoo gets the facto an hipotetic kernel on 2.7 branch... (generally, unstable branch of kernel), debian will go to make this too? bpmx and audacious are 8000+ and 3600+ reported installations, and xmms2 are 2500+ against the 11000+ of xmms. And, i can say who xmms have already much more. xmms its a oldest package, who many users can have installed and using them from potato distro or older. In this moment, popcon isnt present. The popcon information are very unusable in this case because the package can have a lot of users with this without popcon. (I have an example on me, with an installation from long ago, i have popcon because i've installed this manually). Finally: I think who xmms removal now isnt an option at all. We can have their failures, but, isn't a reason for dropping out of mirrors. Debian have a lot of packages, some of this unmantained, dead upstream and much more. And, now, we are here talking of removal from the archive a active-upstream and mantained package...? Please, consider to removal these lot-of-stuff who are really buggy and unmantained, with RC bugs and dead-upstreams. - -- Note: Please doesnt go offtopic in this thread with dependencies of audacious or another OT stuff. If we feels free to discurss these themes, open a reply of dependencies failures on sound-like programs, or so, but doesn't contamine this thread. This discursion it's important to be read with some people, and 200+ posts discursion its hard to read. And, with some OT's in this, we can have more than 200+ posts. - -- [EMAIL PROTECTED] || http://maqui.darkbolt.net Linux registered user number: #363219 PGP key avaliable at KeyServ. KeyID: 0x4233E9F2 - -- Los hombres somos esclavos de la historia -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux)
Re: Considerations for 'xmms' removal from Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I can comment out a point: xmms have 11000+ popcon installations reported. The total reports of popcon are 57000+. This is aprox 20% of users. Now, are talking for removal an application for those users?... I've read the buglist of xmms, and i think who more than one and two bugs can be removed. Example of this can are #244984, #260754, #161702. A lot of these bugs are already opened because the version doesn't have changed (Are revised). I think who can be interesting revise the xmms buglist and close the outdated bugs, for a real information of application problems. I've read in this thread, this is for a orphan package. If this is the reason, doesnt have much more for talk, another mantainer will become. xmms its a very popular package. I think who an orphan isn't a reason at all for removal from arch. - -- [EMAIL PROTECTED] || http://maqui.darkbolt.net Linux registered user number: #363219 PGP key avaliable at KeyServ. KeyID: 0x4233E9F2 - -- Los hombres somos esclavos de la historia -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGt+EufFjA4EIz6fIRAvw9AJ9ElMcjfEhMeRt6BTzcNfyIovv0JgCggpnb YQ5ETkzF03+PUlXPFzqZXmo= =LPMJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Am 2007-07-12 05:32:37, schrieb Lionel Elie Mamane: I say that, because while I really don't intend to make you angry, as a casual user of xmms, I don't see the difference. As far as I'm concerned, xmms's goal was to be a sound player. And your goal, in your FAQ is to develop a media player. But from a cursory glance I don't see audacious playing any other media than audio (no text, no hypertext, no video, no images, ...), so I see it as an audio player, not as a all-purpose all-around media player. (You handle only one medium, sound.) A while back I was realy surprised as I have downloaded some mp3 files and tried to hear them in XMMS which was wiorking fine but then, it opened a new Window to play a VIDEO! Since I have no video-plugin or such, it was realy surprising Audacious can not do this and crash without any warnings and error messages if a mp3 files is realy a video. You know why I was using xmms as opposed to any other audio player? - it takes less screen estate - it plays any sound format I have thrown at it - doesn't crash / lockup / ... - no annoying bugs *I* run in FullACK! :-) ..and I have over 58.000 WinAMP 2 skins! Thanks, Greetings and nice Day Michelle Konzack -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Considerations for 'xmms' removal from Debian
Don Armstrong don at debian.org writes: We can certainly attempt to do so; I don't think anyone in this thread is contemplanting knowingly causing audacious's upstream harm. I agree, in fact, I don't think Debian would handle such a migration in the way that Gentoo handled it. I'm just bringing forward advice that I have observed from previous migrations that have resulted in problems for us upstream and requesting that people don't move in the direction that they did. So far, things seem to be OK. So then you are saying we should reject all bugs against audacious as provided by debian which do not refer to a debian bugtracker URL anyway? I'll certainly be happy to implement that. It's entirely your decision as to what you do with your bug reports, but reporting bugs against the bts is what Debian users are encouraged to do, especially when they aren't certain whether the bug is an upstream problem or not. I'll discuss that with Adam and see what he thinks would be a good idea to do then. Since Debian users are encouraged to use sendbug(1), I have not received many support cases from Debian users. In fact, you could say that I have enjoyed the lack of support cases from Debian users in general. This is probably because Audacious in Debian does not have a gazillion insane patches on top of it, like some of the other binary packages do. Considering the fact that he would be involved in any transition, he's perfectly capable of deciding and/or recommending veribiage with which he is satisfied. Indeed, and I think he can come up with a way to handle such a migration. I was simply pointing out potential problems and how they could be avoided. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Josselin Mouette joss at debian.org writes: I think what they don't want is [4] Replace XMMS by a metapackage that installs Audacious in place This is exactly what we want, as that will cause problems for us. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Steve Greenland steveg at moregruel.net writes: On 14-Jul-07, 16:48 (CDT), William Pitcock nenolod at sacredspiral.co.uk wrote: My issue is that I find it patently offensive that people attack my work simply because they wish to regain XMMS in their distribution. Maybe I am wrong in thinking that way, but I'm pretty sure I'm not. I don't think you're wrong to be offended by jerks. However, based on 20 years of Usenet and mailling list experience, I do think you'll be happier in the long run by learning to ignore them. Steve I do ignore jerks. However, some jerks become problems for our project, and flood our bugtrackers and distro bugtrackers with inane bugs which point out some flaw in Audacious and then ask for XMMS to be restored. Which reflects poorly on our project. Luckily, I don't think Debian has so many jerks, as it's targeted at a more mature audience than those distros that I speak of were. What's funny is that some of these people who were doing this wound up switching to Debian thinking that it would always keep XMMS for some reason. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
William Pitcock nenolod at sacredspiral.co.uk writes: Josselin Mouette joss at debian.org writes: I think what they don't want is [4] Replace XMMS by a metapackage that installs Audacious in place Err to clarify, not doing [4] is exactly what we want. Sorry if anyone got confused. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Eduard Bloch edi at gmx.de writes: I disagree. As said, I dislike a simple player touching every file for no good reason, and I do not consider codec detection a such one. There is simply no important information you would gather from that. Validity of the file and the length are only interesting at play time. We've added a feature for people who feel this way which allows detection to be entirely postponed until playtime. However, that is only fully functional in 1.3 and later. I fail to see what is so broken about the XMMS way. It may be inconvinient for you when doing (re)design since you have to deal with uncerntainity. But, well, are you going to create a comfortable player or yet another piece of stupid multimedia software? Well, I guess in your opinion we are going to create 'yet another piece of stupid multimedia software.' And this is documented... where? Why not in the documentation balloons? Ever heard about ISO 9241? Please get a copy and read parts 13 and 14, I would also recommend reading VDI 3850 which is IMO a good tutorial in designing human machine interfaces. It is documented at http://audacious-media-player.org/FAQ#11.4 Oh by the way, debian users can still use XMMS. There's nothing wrong with stopping them from: 1) Doing ./configure; make; make install, or: 2) Copying the debian source archives from the previous release and using dbuild to build packages for Lenny. and odds are: 3) Somebody else will have already done this and made a repo somewhere. Rarewares comes to mind. So honestly, if Audacious is not a suitable replacement for you it does not really matter as there are ways to retain XMMS. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
#include hallo.h * William Pitcock [Sun, Jul 15 2007, 12:06:47AM]: Eduard Bloch edi at gmx.de writes: I see this in strace output with default configuration. Switching the setting between on-display and on-load makes it even worse, then it opens every file THREE times. Sorry, wtf? This is a result of codec detection, and has been improved upon in Audacious 1.3 (presently available in unstable?). XMMS does not perform codec detection, but instead guesses on how to proceed. That behaviour is broken in more than a few ways. I disagree. As said, I dislike a simple player touching every file for no good reason, and I do not consider codec detection a such one. There is simply no important information you would gather from that. Validity of the file and the length are only interesting at play time. I fail to see what is so broken about the XMMS way. It may be inconvinient for you when doing (re)design since you have to deal with uncerntainity. But, well, are you going to create a comfortable player or yet another piece of stupid multimedia software? Further, it has broken SIGTERM handling. Unless I am able to find such visible problems within minutes, this program is no replacement for the good old XMMS. It handles SIGTERM gracefully. That's not broken. SIGTERM is not Ok, I confused it with SIGINT. But let me give you a short walk-trough from the perspective of a potential user: --- $ audacious /data - a gray window appears, instead of the player. Ookay, let's wait few seconds for the app to initialize. Waiting 10 seconds. 20. 30. XMMS would be playing already (this is measured!). - Okay, examining what this stupid window is good for. Propably for error messages, but there is nothing, and the window has no title. - I change to the terminal and try to kill with with Ctrl-C. I cannot, because this window steals the WM focus every second. First WTF. Well, I manage to press Ctrl-C quickly. It says it received SIGINT and is going to terminate. Seems to have stoped stealing the focus. Great, but... - ... it does not stop scanning. The stupid window is still there and the app does not die. Second WTF. - Well, now it steals focus every 10-20 seconds, while I am typing this text. Third WTF. - Enough, doing killall audacious. The thing still does not die. Any my harddisks still suffers. Fourth WTF. - killall -9 audacious Thanks, worked. Enough of this crap. --- So, that's it. The user experience is a disaster, like it or not. It shows childhood diseases I have not expected in a serious application for daily use, not even talking about replacement for the good old XMMS. The proper way to present information to the user in a userfriendly way, this would be IMO the following: a splash screen (see Gimp as example) which has a progress bar, where the number of files is displayed, with some status messages. Something like: - Searching for files (%d found) %d runs from 0 to N while it walks through directories, and the progress bar runs slowly. I can imagine a simple algorithm to make it move and reach about 50% of the bar during the scan. - Identifying files (%d/N, %d valid) N is the number found before, %ds are updated while the identification runs, and the progress bar is complete when the process is through. Well, both steps could also be merged if you identify on the fly. And now, only after the steps above, you may display the current error message, which is designed almost well IMHO. I don't want to have it entirely deactivated, I want it to work then and only then when I need this information. Hitting F5 on your keyboard will cause metadata to be loaded manually if you have disabled automatic metadata loading. And this is documented... where? Why not in the documentation balloons? Ever heard about ISO 9241? Please get a copy and read parts 13 and 14, I would also recommend reading VDI 3850 which is IMO a good tutorial in designing human machine interfaces. Eduard. -- Die rechte unwillkürliche Originalität ärgert sich, daß nicht jeder ist wie sie -, die scheinbare will gar nicht, daß andere sind wie sie. -- Jean Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
#include hallo.h * William Pitcock [Sat, Jul 14 2007, 11:30:09PM]: As long as we don't hear about 'regressions from XMMS' as a result of a migration path provided by Debian, then you have fulfilled my request. We cannot really fulfill any such request because we are only distributors, not mind programming machines. Please realize that. This is where Gentoo initially failed to succeed in their migration. I am sorry because you have been burnt with Gentoo transition, but bitching is easy. And what do you expect us to do? [1] Forget Audacious and keep XMMS [2] Remove XMMS and let the users look for an replacement [3] Remove XMMS and suggest them Audacious as replacement For [2], they will be pissed and complain about Debian killing XMMS. Some will look for a replacement and find Audacious, so we are close to [3] anyway. And for [3], they will expect Audacious do the same things that XMMS did before. They need those features, the liked the way things worked in XMMS, and they are not going to change their habits quickly. So you will get complaints about regressions even if we put big notes into Debian.NEWS (package upgrade notes) because many people are also lazy and don't read manuals or upgrade notes. Realistically, there is no way for you to get away from those complaints, unless we go the way [1] and maintain XMMS until the end of times. Eduard. -- cpt_nemo Computer sind letztlich ein Mittel zum Zweck. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On Sun, Jul 15, 2007 at 02:14:52PM +0200, Eduard Bloch wrote: * William Pitcock [Sun, Jul 15 2007, 12:06:47AM]: Eduard Bloch edi at gmx.de writes: I see this in strace output with default configuration. Switching the setting between on-display and on-load makes it even worse, then it opens every file THREE times. Sorry, wtf? This is a result of codec detection, and has been improved upon in Audacious 1.3 (presently available in unstable?). XMMS does not perform codec detection, but instead guesses on how to proceed. That behaviour is broken in more than a few ways. I disagree. As said, I dislike a simple player touching every file for no good reason, and I do not consider codec detection a such one. There is simply no important information you would gather from that. Validity of the file and the length are only interesting at play time. I fail to see what is so broken about the XMMS way. It may be inconvinient for you when doing (re)design since you have to deal with uncerntainity. But, well, are you going to create a comfortable player or yet another piece of stupid multimedia software? I think this part of the discussion is not really on-topic for debian-devel anymore... Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Le dimanche 15 juillet 2007 à 15:56 +0200, Eduard Bloch a écrit : This is where Gentoo initially failed to succeed in their migration. I am sorry because you have been burnt with Gentoo transition, but bitching is easy. And what do you expect us to do? [1] Forget Audacious and keep XMMS [2] Remove XMMS and let the users look for an replacement [3] Remove XMMS and suggest them Audacious as replacement I think what they don't want is [4] Replace XMMS by a metapackage that installs Audacious in place -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Considerations for 'xmms' removal from Debian
On 14-Jul-07, 16:48 (CDT), William Pitcock [EMAIL PROTECTED] wrote: My issue is that I find it patently offensive that people attack my work simply because they wish to regain XMMS in their distribution. Maybe I am wrong in thinking that way, but I'm pretty sure I'm not. I don't think you're wrong to be offended by jerks. However, based on 20 years of Usenet and mailling list experience, I do think you'll be happier in the long run by learning to ignore them. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Steve Greenland steveg at moregruel.net writes: Like it or not, your software fits very much into the role played by XMMS, such that someone who likes XMMS is more likely to choose Audacious than, say, Rythymbox. That's why it's being discussed as a replacement. If we remove XMMS from the distribution, we have some obligation to point users at similar tools. Since you obviously modeled Audacious on XMMS (via BMP), I'm not sure why you find such comparisons offensive. Steve Because every time distros try to do an xmms-audacious migration on us, it causes additional load on our development effort because people file bug reports and demand that we behave exactly like XMMS. I don't find the comparison offensive, I find the result of the comparison offensive, which is people dictating to us how our project will work. I cannot work efficiently under those conditions, and I don't suspect anyone else could either. So, it becomes a PR nightmare for us. That's why I take offense and ask for very strong clarification that we are not cloning XMMS to the letter. That's what XMMS clone means to these people. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Jon Dowland lists at alcopop.org writes: Unless I've got my timeframes wrong, there were a few successful attempts too. What's objectionable about people trying to find security flaws in your software, apart from their motivation for doing so? There is nothing wrong with trying to find security flaws. However, there have been no security flaws found in audacious itself, but instead in the third party code we carry on. We have infact used these flaws to motivate distributions to keep the latest audacious always available to their userbase, e.g. hey 1.2.2 has a ton of flaws, you might want to upgrade it in your next release if you weren't doing so already. My issue is that I find it patently offensive that people attack my work simply because they wish to regain XMMS in their distribution. Maybe I am wrong in thinking that way, but I'm pretty sure I'm not. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Joseph Neal vlvtelvis at speakeasy.net writes: It's my impression that audicious is not scriptable so it can't be as easily integrated into existing applications or controlled from emacs or irssi. [EMAIL PROTECTED] ~ $ audtool current-song New Order - The Rest Of - Age of Consent [EMAIL PROTECTED] ~ $ audtool current-song-filename file:///home/nenolod/03%20Age%20of%20Consent.mp3 [EMAIL PROTECTED] ~ $ audtool current-song-length 5:13 (demonstrations of the other commands not done because there's a lot of them) Seems pretty scriptable to me. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Josselin Mouette joss at debian.org writes: Whether you like it or not, audacious is a playlist-based audio player with support for many audio formats and funny plugins. This description sounds much like XMMS, which is why it can be considered a good replacement. As a user, I don't care about the architecture being different (apart from the bugs gone away). The only thing I ask for is that you don't assert that Audacious is a 100% identical XMMS clone. Saying that Audacious is a suitable replacement is fine, saying that we are an XMMS clone in any official documentation will likely result in users harassing us. Which we don't want. After all, would you if you were in our position? Gentoo did this initially and we got hit with an onslaught of unhappy migrants. My position is to make sure that does not happen again. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Joseph Neal vlvtelvis at speakeasy.net writes: There are a number of plugins available from the rarewares repository[1] and perhaps other third party repositories which provide the only convient way I'm aware of to access a number of media formats (bonk, wavepack, lossless audio, shorten, various DVD audio formats). While I do not expect debian to support these packages, I do ask that the wider ecosystem be taken into consideration. Audacious supports wavpack out of the box. I have an unofficial port of bonk and shorten on my computer which I can package on request; and there was at one time a port of xmms-ac3dec to Audacious, but it doesn't work with the new plugin API. At any rate, the ecosystem for Audacious is pretty much the same as it is for XMMS. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On Sat, 14 Jul 2007, William Pitcock wrote: Because every time distros try to do an xmms-audacious migration on us, it causes additional load on our development effort because people file bug reports and demand that we behave exactly like XMMS. Like it or not, bug reports are a part of software development that we all have to deal with. Suggesting announcements or text for such a transition may help, but at the end of the day distributions are going to switch as projects mature or decay. Complaining about the transition occuring isn't going to resolve your concern. I don't find the comparison offensive, I find the result of the comparison offensive, which is people dictating to us how our project will work. Users shouldn't be able to dictate to you how the project works; they don't do the development. In Debian's case, refer these users to our bug tracking system (as all of our documentation refers users.) Don Armstrong -- I'm a rational being--of a sort--rational enough, at least, to see the symptoms of insanity around me. And I'm human, the same as the poeple I think of as victims when my guard drops. It's at least possible I'm even crazier than my fellows, whom I'm tempted to pity. There seems only one thing to do, and that's get drunk -- Chad C. Mulligan (John Brunner _Stand On Zanzibar p390) http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Lionel Elie Mamane lionel at mamane.lu writes: Would a mention of the different direction of audacious in the release notes of lenny, the next Debian release, fulfil your PR handling request? Something like Simply not asserting that Audacious is a fullstop XMMS clone will fulfill my request. 4.5 XMMS removal Due to concerns over its high number of bugs, unmaintained status (and hence bugs will not get fixed), usage of old, unmaintained libraries (gtk+ 1.2) and no UTF-8 support, xmms has been removed from Debian. We suggest users of xmms try 'bmpx' and/or 'audacious' for media players that may feel familiar to them. You may also want to give xmms2 a shot: it is by the same upstream than xmms, albeit feels very different. The developers of bmpx no longer have a player that is anything like Audacious or XMMS. It uses GStreamer and looks more like Amarok than XMMS. You should look at their Screenshots[1] before recommending it as an XMMS replacement. I'm not qualified to comment on XMMS2. Sure, audacious is similar to XMMS, and claiming that is fine. Claiming that we are an XMMS *clone* sends the wrong message to your user base and causes problems in upstream with bugreports like: (a) Feature X is broken in Audacious because it's not like XMMS. (b) You don't _. That's a regression from XMMS. (c) Why doesn't Audacious have _? XMMS does. As long as we don't hear about 'regressions from XMMS' as a result of a migration path provided by Debian, then you have fulfilled my request. This is where Gentoo initially failed to succeed in their migration. William [1] http://beep-media-player.org/site/Screenshots -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Don Armstrong don at debian.org writes: Like it or not, bug reports are a part of software development that we all have to deal with. Suggesting announcements or text for such a transition may help, but at the end of the day distributions are going to switch as projects mature or decay. Complaining about the transition occuring isn't going to resolve your concern. If you think I am complaining about debian transitioning from xmms to audacious, I am not. I like bug reports /that have merit/. Simple comparisons to XMMS do not provide such merit. I am complaining about developer time being wasted by xmms zealots which will likely harass us on our tracker. Users shouldn't be able to dictate to you how the project works; they don't do the development. In Debian's case, refer these users to our bug tracking system (as all of our documentation refers users.) Then debian will resolve their complaints locally using patches, which means we will likely have to adopt the position of not providing any upstream support to debian. I would like to avoid that, but if debian patches audacious to make it work like XMMS, then we would have no choice but to reject bugs reported to us using the debian patched binaries. As an example, what Debian ships as 'xmms' is quite different than what you normally get in the CVS of XMMS. I would like to see that not happen to audacious. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#431482: Considerations for 'xmms' removal from Debian
Steve Langasek vorlon at debian.org writes: I wonder why audacious and audacious-plugins should be separate packages at all instead of building them into a single binary package, given that this circular dependency relationship exists (even if not on paper currently). Because we (audacious) release the player and the plugins seperately. This allows for faster QA procedures to happen during the development workflow, as we don't have to freeze development of both the player and the plugins, we can just concentrate on one or the other. For instance, the latest audacious player is 1.3.2, and the latest plugins pack is 1.3.5. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On Sat, 14 Jul 2007, William Pitcock wrote: I am complaining about developer time being wasted by xmms zealots which will likely harass us on our tracker. There's little that can be done to educate or placate zealots; but considering that everyone is talking about transitioning to audacious, not advertising (heh; amusing that someone thinks we have PR) adacious as an xmms clone. Then debian will resolve their complaints locally using patches, which means we will likely have to adopt the position of not providing any upstream support to debian. I would like to avoid that, but if debian patches audacious to make it work like XMMS, then we would have no choice but to reject bugs reported to us using the debian patched binaries. The point isn't that the maintainers would blindly follow the user's bug reports. The point is that the maintainers will filter out inane and irrelevant bug reports before forwarding them upstream, reducing the load on upstream developers due to whatever package descriptions and transition plans that Debian implements. In general, bug reports should be filed against the Debian package. The Debian maintainer is more than capable of discerning whether the bug is due to a custom modification present in Debian only, or whether it exists upstream, and forwarding the bug appropriately. As an example, what Debian ships as 'xmms' is quite different than what you normally get in the CVS of XMMS. I would like to see that not happen to audacious. That's really a matter of maintainers working closely with upstream developers. Rather than this mailing list the person you should be coordinating with and talking to is Adam Cécile. [Hopefully you were already aware that he is the audacious maintainer.] Don Armstrong -- Our days are precious, but we gladly see them going If in their place we find a thing more precious growing A rare, exotic plant, our gardener's heart delighting A child whom we are teaching, a booklet we are writing -- Frederick Rükert _Wisdom of the Brahmans_ [Hermann Hesse _Glass Bead Game_] http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Considerations for 'xmms' removal from Debian
Eduard Bloch edi at gmx.de writes: I see this in strace output with default configuration. Switching the setting between on-display and on-load makes it even worse, then it opens every file THREE times. Sorry, wtf? This is a result of codec detection, and has been improved upon in Audacious 1.3 (presently available in unstable?). XMMS does not perform codec detection, but instead guesses on how to proceed. That behaviour is broken in more than a few ways. Further, it has broken SIGTERM handling. Unless I am able to find such visible problems within minutes, this program is no replacement for the good old XMMS. It handles SIGTERM gracefully. That's not broken. SIGTERM is not supposed to immediately kill the app, it's supposed to allow the app to shutdown gracefully, e.g. save the playlist, settings, et-cetera. I don't want to have it entirely deactivated, I want it to work then and only then when I need this information. Hitting F5 on your keyboard will cause metadata to be loaded manually if you have disabled automatic metadata loading. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Don Armstrong don at debian.org writes: There's little that can be done to educate or placate zealots; but considering that everyone is talking about transitioning to audacious, not advertising (heh; amusing that someone thinks we have PR) adacious as an xmms clone. I don't think debian has PR, however I think debian can choose how to handle a migration in a way where it's not harmful to audacious as upstream from debian. In general, bug reports should be filed against the Debian package. The Debian maintainer is more than capable of discerning whether the bug is due to a custom modification present in Debian only, or whether it exists upstream, and forwarding the bug appropriately. So then you are saying we should reject all bugs against audacious as provided by debian which do not refer to a debian bugtracker URL anyway? I'll certainly be happy to implement that. That's really a matter of maintainers working closely with upstream developers. Rather than this mailing list the person you should be coordinating with and talking to is Adam Cécile. [Hopefully you were already aware that he is the audacious maintainer.] Adam has commit access to our repository. I do indeed trust his judgement, but if he decides to orphan the package, then we have a problem. If he is put in a position where there are 11000 xmms users left without a package taking their angst out on him, he may not feel like maintaining the package anymore. That's human nature, you know. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On Sun, 15 Jul 2007, William Pitcock wrote: I don't think debian has PR, however I think debian can choose how to handle a migration in a way where it's not harmful to audacious as upstream from debian. We can certainly attempt to do so; I don't think anyone in this thread is contemplanting knowingly causing audacious's upstream harm. So then you are saying we should reject all bugs against audacious as provided by debian which do not refer to a debian bugtracker URL anyway? I'll certainly be happy to implement that. It's entirely your decision as to what you do with your bug reports, but reporting bugs against the bts is what Debian users are encouraged to do, especially when they aren't certain whether the bug is an upstream problem or not. I do indeed trust his judgement, but if he decides to orphan the package, then we have a problem. If he is put in a position where there are 11000 xmms users left without a package taking their angst out on him, he may not feel like maintaining the package anymore. Considering the fact that he would be involved in any transition, he's perfectly capable of deciding and/or recommending veribiage with which he is satisfied. Don Armstrong -- Debian's not really about the users or the software at all. It's a large flame-generating engine that the cabal uses to heat their coffee -- Andrew Suffield (#debian-devel Fri, 14 Feb 2003 14:34 -0500) http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On Wed, Jul 11, 2007 at 02:23:35PM +, William Pitcock wrote: Audacious' direction. Gentoo's (mis)handling of PR during this transitional time has resulted snip and several lame attempts to find security holes in Audacious with the explicit purpose of trying to get XMMS back. Unless I've got my timeframes wrong, there were a few successful attempts too. What's objectionable about people trying to find security flaws in your software, apart from their motivation for doing so? -- Jon Dowland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On Tue, 10 Jul 2007, Jon Dowland wrote: If a user removes the package themselves, even if they don't realise it, via a dependency chain with GTK 1.x or something similar, I don't have a great deal of sympathy. Did you ever heard about the multi-user concept? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Le mercredi 11 juillet 2007 à 14:40 +, William Pitcock a écrit : Architecturally, Audacious is much different than XMMS, it just sorta looks like XMMS, which I think sends the wrong message, but whatever. The fact is that we do not consider ourselves to be an XMMS clone or an XMMS replacement, and you should strongly consider that before removing XMMS and providing a transitive upgrade path to audacious. I'm not asking much, just some sort of notification telling users that the replacement they are installing is not really a replacement to XMMS, and as such some features are implemented in a drastically different way. Whether you like it or not, audacious is a playlist-based audio player with support for many audio formats and funny plugins. This description sounds much like XMMS, which is why it can be considered a good replacement. As a user, I don't care about the architecture being different (apart from the bugs gone away). -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Re: Considerations for 'xmms' removal from Debian
Le dimanche 08 juillet 2007 à 23:02 -0500, Joseph Neal a écrit : A substitute needs to be a simple library based player that is scriptable and provides maximum exposure to the features of the underlying libraries. If you find a piece of software that solves the eternal dilemma between features and simplicity, I'm sure this will interest thousands of software engineers in the world. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Considerations for 'xmms' removal from Debian
On Tue, Jul 10, 2007 at 07:13:03PM -0500, David Moreno Garza wrote: Daniel Jacobowitz wrote: When last I looked (some time ago), none of the different XMMS successors were ready for prime time. Are bmpx, audacious, and xmms2 all usable now? What's exactly a XMMS successor? All three of the ones I listed are descended from the XMMS code base, the XMMS developers, or both. As far as I can tell, anyway. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
José Miguel Parrella Romero joseparrella at gmail.com writes: The maintainers of the xmms package in Debian are proposing the removal of the aforementioned package. Please read on. 1. Rationale * Upstream has deprecated development and support for the current version of XMMS. * Several parts of the application are broken and no longer of Debian quality. 2. Current status * The BTS reports 231 bugs, most tagged 'important' or 'normal', and a couple of debugging was attempted with little success. * XMMS is broken in several aspects, one of the most important being it's dependence on GTK+ 1.2 and no UTF-8 support, which is standard in Debian Etch. * Other distributions have already discussed XMMS removal. Gentoo hardmasked the package based on the same rationale [1] Yes, and Gentoo's user committee fucked over the entire image and public view of Audacious' direction. Gentoo's (mis)handling of PR during this transitional time has resulted in a lot of negativity towards audacious and several lame attempts to find security holes in Audacious with the explicit purpose of trying to get XMMS back. I strongly suggest this doesn't happen in Debian, as upstream may not like the result otherwise. The general consensus of our team is that we're not going through this nightmare again. * 'bmpx' and 'audacious' are in Debian, ranks 8048 and 3649 in popcon. Both are very good and development-active substitutes to xmms. At present, the only completely successful mainstream xmms-audacious to date has been in Slackware, but that's because Pat didn't lie to the users about our goals and project direction. Please respect our project and make sure it happens this way in Debian if you provide an xmms-audacious upgrade path. * There's also in Debian the upstream-supported xmms2 package, 2598 in popcon rank. 2.1 Reverse depends The following packages depend on XMMS: snip Most of this packages are xmms plugins. Maintainers will need to port them to xmms2 or bmpx, or they should be removed. A large majority of these plugins have been ported to Audacious already. Other packages just depend on xmms as a mere multimedia player, and therefore we recommend the maintainers to adjust their dependencies to bmpx, xmms2 or audacious. That's fine as long as you respect our requests with regards to handling the PR of this. 2.2 Popcon xmms is now 1069 in the overall popcon rank, with 11029 installations, not counting the plugin users. Yours, the XMMS maintainers [1] http://www.gentoo.org/proj/en/desktop/sound/xmms.xml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Andreas Tille tillea at rki.de writes: On Sun, 8 Jul 2007, Thomas Viehmann wrote: Removing the package from Debian will not affect current users that much, While I perfectly agree that there are replacements for xmms that at first view look like a new version (for instnce audacious) many user might have links form their desktops or other hooks that just call /usr/bin/xmms. So this might affect a lot of users and especially those users that have no idea how to cope with a missing xmms in their PATH. IMHO the only way to fix this is to provide a transitional package that for instance depends from audacious (or other clones), provides xmms and conflict with older xmms versions and install a symlink to the replacement. We are not an XMMS clone. Would you like us to remove the Winamp2 UI to drive this point further? If this nonsense keeps happening, it's exactly what we will be doing. Architecturally, Audacious is much different than XMMS, it just sorta looks like XMMS, which I think sends the wrong message, but whatever. The fact is that we do not consider ourselves to be an XMMS clone or an XMMS replacement, and you should strongly consider that before removing XMMS and providing a transitive upgrade path to audacious. I'm not asking much, just some sort of notification telling users that the replacement they are installing is not really a replacement to XMMS, and as such some features are implemented in a drastically different way. Thanks, William I think xmms is to wide spread as that we just could wild guess how many users are affected and how they could cope with this. Somebody will just maintain their own repo with gtk1.2 and xmms if it's required. This already happens in gentoo. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On Wed, Jul 11, 2007 at 02:40:53PM +, William Pitcock wrote: Andreas Tille tillea at rki.de writes: I think xmms is to wide spread as that we just could wild guess how many users are affected and how they could cope with this. Somebody will just maintain their own repo with gtk1.2 and xmms if it's required. This already happens in gentoo. This is a valid solution for experienced xmms users that don't ever want to switch. But this is not Debian's concern and I think the thread is about solutions for people that primarily use Debian and just happen to have chosen xmms as their music player of choice. If xmms gets removed before lenny and they upgrade to it I guess they would welcome a hint which new program to switch to. Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On 11-Jul-07, 09:40 (CDT), William Pitcock [EMAIL PROTECTED] wrote: We are not an XMMS clone. Would you like us to remove the Winamp2 UI to drive this point further? If this nonsense keeps happening, it's exactly what we will be doing. Like it or not, your software fits very much into the role played by XMMS, such that someone who likes XMMS is more likely to choose Audacious than, say, Rythymbox. That's why it's being discussed as a replacement. If we remove XMMS from the distribution, we have some obligation to point users at similar tools. Since you obviously modeled Audacious on XMMS (via BMP), I'm not sure why you find such comparisons offensive. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On Wed, Jul 11, 2007 at 02:23:35PM +, William Pitcock wrote: José Miguel Parrella Romero joseparrella at gmail.com writes: The maintainers of the xmms package in Debian are proposing the removal of the aforementioned package. Please read on. * Other distributions have already discussed XMMS removal. Gentoo hardmasked the package based on the same rationale [1] Yes, and Gentoo's user committee fucked over the entire image and public view of Audacious' direction. Other packages just depend on xmms as a mere multimedia player, and therefore we recommend the maintainers to adjust their dependencies to bmpx, xmms2 or audacious. That's fine as long as you respect our requests with regards to handling the PR of this. Would a mention of the different direction of audacious in the release notes of lenny, the next Debian release, fulfil your PR handling request? Something like 4.5 XMMS removal Due to concerns over its high number of bugs, unmaintained status (and hence bugs will not get fixed), usage of old, unmaintained libraries (gtk+ 1.2) and no UTF-8 support, xmms has been removed from Debian. We suggest users of xmms try 'bmpx' and/or 'audacious' for media players that may feel familiar to them. You may also want to give xmms2 a shot: it is by the same upstream than xmms, albeit feels very different. The developers of audacious would like you to know that the direction of audacious is very different than the direction xmms had when actively developed. See http://audacious-media-player.org/MANIFESTO for details. This supposes you would create a manifesto on your website, I haven't found any. (Or a an explanation to how you differ from xmms's goals. All I found is a news item along the lines of people who say that audacious is just like xmms annoy us a lot, please don't do that, but no articulation of your absolutely different goals.) I say that, because while I really don't intend to make you angry, as a casual user of xmms, I don't see the difference. As far as I'm concerned, xmms's goal was to be a sound player. And your goal, in your FAQ is to develop a media player. But from a cursory glance I don't see audacious playing any other media than audio (no text, no hypertext, no video, no images, ...), so I see it as an audio player, not as a all-purpose all-around media player. (You handle only one medium, sound.) You know why I was using xmms as opposed to any other audio player? - it takes less screen estate - it plays any sound format I have thrown at it - doesn't crash / lockup / ... - no annoying bugs *I* run in And, lo and behold, I launch audacious, it takes the same screen estate. I'd be very surprised you wanted to voluntarily restrict sound formats it supports, nor make it crash or buggy, so as far as my criteria are concerned they are equivalent in their goals. I'm sorry if this annoys you. Would you like me not to use audacious because of that? I'm just a guy that wants sound-play to just work. I'm not passionate about it, I never spent a lot of thought on how an audio player should be designed to rock; for me the ideal sound player is the one I don't need to think about. It is infrastructure to me. But I'm very happy that other people are passionate about it, so that they take the effort to develop one and I can use it. Thanks for that. All this respectfully of your efforts and platform. I'm just saying that if you want people to have a new understanding of this project, you need to explain them the project. People are not all psychic or intimately familiar with the audio player developers community to just know out of the blue what your goals are. Or interested enough to analyse all features and design choices and reverse-engineer your goals from that. Best Regards, -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On 7/9/07, Matthew Johnson [EMAIL PROTECTED] wrote: If I have the time and inclination maybe I will port it to gtk2, but why should I spend that effort when it's a perfectly good working program. Sure it's not getting new features, but it gets along fine without them. Because, as it has been already said in this thread, the libraries that your package uses are deprecated, unmaintained and prone to have many undiscovered bugs. Using unmaintained software always has this risk, but using unmaintained software that uses unmaintained libraries is even worse. -- Besos, Marga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On Tue, 10 Jul 2007 11:35:09 -0300 Margarita Manterola [EMAIL PROTECTED] wrote: On 7/9/07, Matthew Johnson [EMAIL PROTECTED] wrote: If I have the time and inclination maybe I will port it to gtk2, but why should I spend that effort when it's a perfectly good working program. Sure it's not getting new features, but it gets along fine without them. Personally, I would recommend that a port is at least explored. It might not be as much work as quicklist et al. Because, as it has been already said in this thread, the libraries that your package uses are deprecated, unmaintained and prone to have many undiscovered bugs. I wouldn't call the problems undiscovered - unlikely to be fixed is much more relevant. New bugs in libglib1 and libgtk1 that affect unchanged packages could arise from toolchain issues where changes in libc or gcc expose flaws in the libraries but when the application upstream is dead, there are relatively few places for new bugs to be found. I'd expect general bitrot problems to cause FTBFS bugs due to issues in old autotools etc. before a genuinely new security bug appears in such old code. Of course, FTBFS is a prime reason for removal of the package from the archive so maintainers of packages like gaby, quicklist and gbib do need to be able to work on those. A binNMU like the one that has just taken place on libglib1.2 is one source of such problems. Example: #359299 (I'll probably NMU this one if nothing changes in the next couple of weeks. It was filed a year ago as important but it's only been RC since I bumped the severity today due to effects on gnucash after the binNMU on libglib1.2 - yes, gnucash still depends on libglib1.2, despite all the efforts upstream and it's because of this bug.) Old libraries being used by NEW applications are the big problem - especially when the application (like gnucash) ends up depending on both the old *and the new* libraries! Using unmaintained software always has this risk, but using unmaintained software that uses unmaintained libraries is even worse. To me, the worst case is the current situation with g-wrap - an old package using old libraries but used *by* packages that are linked against the NEW libraries. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpk59LGBXBz2.pgp Description: PGP signature
Re: Considerations for 'xmms' removal from Debian
On Sun, Jul 08, 2007 at 11:50:25PM +0200, Andreas Tille wrote: Perhaps not because of some dependencies (perhaps because GTK 1.x will be removed) it might be removed by aptitude / synaptics besides a lot of other stuff. If a user removes the package themselves, even if they don't realise it, via a dependency chain with GTK 1.x or something similar, I don't have a great deal of sympathy. -- Jon Dowland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Joseph Neal a écrit : On Mon, 09 Jul 2007 10:09:35 +0200 Adam Cécile (Le_Vert) [EMAIL PROTECTED] wrote: Xmms-shn was last updated March 28th 2007. I personally have about 40 hours of zappa boots in shn format that would only be playable from mplayer and perhaps vlc if xmms were removed. This is a common media format. http://en.wikipedia.org/wiki/Shorten This has been proposed to Google SoC by Audacious. xmms-shn can't be ported because their some licensing issues. Moreover audacious provies a mplayer backend in audacious-plugins-ugly package. Mplayer support in shorten is lacking. Specifically you can't seek within a file. You have to start playback and wait for it to get to the part you want. If you miss it you have to start back over at the beginning. Since it's commonly used for live audio recordings that sometimes are not always broken up into tracks. I assume you mean that it can be ported but it can't be included in debian, the same as is the case with Monkey's Audio, OptimFROG and the like? I've not tried it yet, but it looks like porting the plugins is going to be easier than actually making a deb. (I've still not got that down right). Yes, I mean you can port it, but it won't ever be available through debian (at least until we use the crap non-free bits, some people are working on a free implemenation) I'm slightly concerned that packaging all the plugins in large bundles with many dependencies makes audacious more cumbersome to use on handhelds and car computers. What about packaging the plugins individually and using metapackages to pull them in? I would do this first, but many devs told me I should't do that, because it'll lead ton much load for britney (sid-etch transition script). If it's one condition for xmms replacement, just ask it and I'll do. It's my impression that audicious is not scriptable so it can't be as easily integrated into existing applications or controlled from emacs or irssi. man audtool Kick ass, thanks. Np, Adam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Daniel Jacobowitz wrote: When last I looked (some time ago), none of the different XMMS successors were ready for prime time. Are bmpx, audacious, and xmms2 all usable now? What's exactly a XMMS successor? -- David Moreno Garza [EMAIL PROTECTED] | http://www.damog.net/ Use GPG. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Joseph Neal a écrit : Well, my reasoning was, that we just try to wild guess about user capabilities. I have just learned that user behave very unexpected and exactly these users happen to be quite vocal how broken Debian is. I just would like to give them lesser chances to be correct when they claim this. Anyone who claims Debian is broken for not shipping 6-year-old abandonware in stable is an idiot who should be refuted, not pandered to. Responding from the web because I'm lazy. Xmms-shn was last updated March 28th 2007. I personally have about 40 hours of zappa boots in shn format that would only be playable from mplayer and perhaps vlc if xmms were removed. This is a common media format. http://en.wikipedia.org/wiki/Shorten This has been proposed to Google SoC by Audacious. xmms-shn can't be ported because their some licensing issues. Moreover audacious provies a mplayer backend in audacious-plugins-ugly package. Looking at Freshmeat, 16 plugins or otherwise xmms based projects have been updated in the past year including two new ones that were introduced. It may be dead, but development on top of it is definitely ongoing. Bmpx is not really a substitute for the simple fact that it's gstreamer based. A substitute needs to be a simple library based player that is scriptable and provides maximum exposure to the features of the underlying libraries. It needs to be suitable for use in car computers, portable media devices, pro-audio applications, etc. It's my impression that audicious is not scriptable so it can't be as easily integrated into existing applications or controlled from emacs or irssi. man audtool My money is on Xmms2, but it's got a ways to go before it's usable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Roger Leigh [EMAIL PROTECTED] scribbled: GTK+ 1.2 (and GLib 1.2) were abandoned upstream over *six years* ago. It's rather probable (nay, doubtless) that there are unidentified and unfixed security problems with these libraries. Given that upstreams have had over five years to port their code, it is time to drop dead code that is not maintained, IMO. It's not like there isn't huge amounts of compatibility code in GTK, GDK and GLib to ease such porting (I've used it myself). A minimal port is often just a bunch of regex search and replace operations, with some small amount of rewriting. Note that this is irrespective of how good XMMS is or is not. The libraries it depends on are dead, and they should have upgraded years back. So, I maintain gbib. It's a gtk1.2 program which hasn't been ported upstream and upstream maintenance is basically dead. Should it be remove from the archive? I think it's really useful, I use it every day, there isn't a suitable replacement available. (kbibtex comes with lots of KDE dependencies and while being slightly more featureful is much less nice to use). Popcon lists 363 installations. If I have the time and inclination maybe I will port it to gtk2, but why should I spend that effort when it's a perfectly good working program. Sure it's not getting new features, but it gets along fine without them. If there were a drop-in replacement for gbib I wouldn't mind, but there isn't. Removing gbib from the archive would deprive any new installations of a suitable tool for doing this, something that existing Debian users also do often (Upgrading is all well and good, but for various reasons I have done numerous clean installations), and in those cases it is made a lot harder for the existing users who suddenly find gbib has disappeared. I'm not arguing against the removal of xmms, but I am arguing against the removal of perfectly good pieces of software just because the are no-longer upstream supported. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Considerations for 'xmms' removal from Debian
Kapil Hari Paranjape wrote: I do understand that an orphaned package of this kind (unmaintained upstream) puts a lot of burden on Debian QA. However, xmms appears to have a large user base and perhaps one of them will come forward to maintain the package if it is orphaned. If not, the package will be dropped eventually. I should think that the maintainers are best qualified to make the call whether to orphan or remove a package. Removing the package from Debian will not affect current users that much, it reflects that there is no ongoing development and that starting to use it now isn't a good idea. Also, the audio files can perfectly well be accessed with other programs, so users are not left without alternatives. If the maintainers think that shipping it with lenny is a bad idea, it should be removed. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Kapil Hari Paranjape wrote: Hello, Hi The maintainers of the xmms package in Debian are proposing the removal of the aforementioned package. Please read on. The rationale given does not seem to clarify why the proposal is for removal instead of the maintainers just orphaning the package? * There are a number of other GTK 1.2 packages. These packages IMHO should all be fixed or removed. * There are no security bugs at this point (though the list of bugs is large so I may have missed something). Having to support gtk1.2 security wise while almost no packages use it anymore is a real PITA. * While there are a number of alternatives there is no upgrade path for either the users or those who provide plugins. That's upstream support that is lacking, we can do our best to provide alternatives, though it's not really our job to do so... I do understand that an orphaned package of this kind (unmaintained upstream) puts a lot of burden on Debian QA. However, xmms appears to have a large user base and perhaps one of them will come forward to maintain the package if it is orphaned. If not, the package will be dropped eventually. It probably doesn't put any burden on Debian QA as we will probably just ignore it, till someone takes it over or we decide to ask for removal. The reason is that the package has no real future and we have other priorities... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Kapil Hari Paranjape [EMAIL PROTECTED] writes: The maintainers of the xmms package in Debian are proposing the removal of the aforementioned package. Please read on. The rationale given does not seem to clarify why the proposal is for removal instead of the maintainers just orphaning the package? * There are a number of other GTK 1.2 packages. GTK+ 1.2 (and GLib 1.2) were abandoned upstream over *six years* ago. It's rather probable (nay, doubtless) that there are unidentified and unfixed security problems with these libraries. Given that upstreams have had over five years to port their code, it is time to drop dead code that is not maintained, IMO. It's not like there isn't huge amounts of compatibility code in GTK, GDK and GLib to ease such porting (I've used it myself). A minimal port is often just a bunch of regex search and replace operations, with some small amount of rewriting. Note that this is irrespective of how good XMMS is or is not. The libraries it depends on are dead, and they should have upgraded years back. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpF2XGJyoCE7.pgp Description: PGP signature
Re: Considerations for 'xmms' removal from Debian
On Sun, 8 Jul 2007, Thomas Viehmann wrote: Removing the package from Debian will not affect current users that much, While I perfectly agree that there are replacements for xmms that at first view look like a new version (for instnce audacious) many user might have links form their desktops or other hooks that just call /usr/bin/xmms. So this might affect a lot of users and especially those users that have no idea how to cope with a missing xmms in their PATH. IMHO the only way to fix this is to provide a transitional package that for instance depends from audacious (or other clones), provides xmms and conflict with older xmms versions and install a symlink to the replacement. I think xmms is to wide spread as that we just could wild guess how many users are affected and how they could cope with this. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#431482: Considerations for 'xmms' removal from Debian
* Adam Cécile (Le_Vert) [Tue, 03 Jul 2007 21:57:26 +0200]: Do you mean having the right audacious-plugins dependency on audacious wouldn't be enough ? No, it would be enough. Just to be clear, I'm talking here about the dependency scheme proposed in my first message to this bug report, for *all* packages providing plugins; that is: audacious-plugins, audacious-plugins-extra, audacious-plugins-ugly, and audacious-crossfade. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org When it is not necessary to make a decision, it is necessary not to make a decision. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Andreas Tille wrote: IMHO the only way to fix this is to provide a transitional package that for instance depends from audacious (or other clones), provides xmms and conflict with older xmms versions and install a symlink to the replacement. this can and should only be done if there would be a drop in replacement for xmms available. audacious, bmpx, beeing the most close to xmms, do have partially different syntax wrt/ command line options. now, a volunteer could come up and write a little shellscript for wrapping arround that, but i don't think that someone wants to invest time into that (if not, just tell me ;). I think xmms is to wide spread as that we just could wild guess how many users are affected and how they could cope with this. i think, we can just place an appropriate note into lenny release notes about the removal of xmms, together with the list of the three most similar/popular alternatives (audacious, bmpx, and xmms2 that is). Regards, Daniel -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On Sun, 08 Jul 2007 11:48:39 +0100 Roger Leigh [EMAIL PROTECTED] wrote: Kapil Hari Paranjape [EMAIL PROTECTED] writes: * There are a number of other GTK 1.2 packages. GTK+ 1.2 (and GLib 1.2) were abandoned upstream over *six years* ago. It's rather probable (nay, doubtless) that there are unidentified and unfixed security problems with these libraries. No doubt. Given that upstreams have had over five years to port their code, it is time to drop dead code that is not maintained, IMO. I suspect that many of the packages still dependent on gtk1 now were already dead upstream before gtk2 became available. However, a dead upstream is different to being unmaintained in Debian. The Debian maintainer has the opportunity to request removal of a package if the lack of upstream development is a problem. Many do not feel that a dead upstream is actually a problem. It's not like there isn't huge amounts of compatibility code in GTK, GDK and GLib to ease such porting (I've used it myself). A minimal port is often just a bunch of regex search and replace operations, with some small amount of rewriting. Such a minimal port is hardly worth doing. It is possible to migrate from glib1 to glib2 in such a way (see #359299) but it is much harder to go from gtk1 to gtk2. I've been involved in three gtk1-gtk2 ports, one v.large (GnuCash), one v.small with a dead upstream (quicklist) and one where a minimal port (the last act of the old upstream) combined with an ill-advised RCS branch has left a horrible mess of spaghetti code. I'm not sure if the third will ever be a sane Gtk2 application. The Quicklist gtk2 port is in experimental as a pre-release but to do that I have had to refactor 75% of the codebase just to make the old gtk1 interface remotely usable with Gtk2 widgets. There is quite a lot more work to do to make the port stable. Porting from gtk1 to gtk2 is not trivial, even for small gtk applications using default gtk1 widgets. Note that this is irrespective of how good XMMS is or is not. The libraries it depends on are dead, and they should have upgraded years back. $ apt-cache rdepends libgtk1.2 | grep -c -v ^lib 316 I'm not sure Debian needs to throw out over 300 applications before Lenny. True, most of those are dead upstream - AFAICT GnuCash was the last active upstream to make it to gtk2 - but although these packages use old libraries that have an undoubted *potential* for security problems, in the absence of actual bug reports is it really worth dropping so many packages? Is a dead upstream sufficient cause to drop a package from Debian in the absence of any RC bugs? Is a dependency on libgtk1.2 going to *be* an RC bug for Lenny? It seems a very big step, IMHO. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpCUq8sYEqic.pgp Description: PGP signature
Re: Considerations for 'xmms' removal from Debian
Neil Williams wrote: On Sun, 08 Jul 2007 11:48:39 +0100 Roger Leigh [EMAIL PROTECTED] wrote: Kapil Hari Paranjape [EMAIL PROTECTED] writes: [...] Such a minimal port is hardly worth doing. It is possible to migrate from glib1 to glib2 in such a way (see #359299) but it is much harder to go from gtk1 to gtk2. I've been involved in three gtk1-gtk2 ports, one v.large (GnuCash), one v.small with a dead upstream (quicklist) and one where a minimal port (the last act of the old upstream) combined with an ill-advised RCS branch has left a horrible mess of spaghetti code. I'm not sure if the third will ever be a sane Gtk2 application. [...] $ apt-cache rdepends libgtk1.2 | grep -c -v ^lib 316 Note that about 30 of these are xmms related. Also a lot of the remaining are bindings or depending libraries. There are also some packages that are being ported anyway. I'm not sure Debian needs to throw out over 300 applications before Lenny. True, most of those are dead upstream - AFAICT GnuCash was the last active upstream to make it to gtk2 - but although these packages use old libraries that have an undoubted *potential* for security problems, in the absence of actual bug reports is it really worth dropping so many packages? It's worth trying to convince as many maintainers as possible to think about migrating to newer libraries or asking for removal of their package if it's not really usable anymore. Is a dead upstream sufficient cause to drop a package from Debian in the absence of any RC bugs? Is a dependency on libgtk1.2 going to *be* an RC bug for Lenny? It seems a very big step, IMHO. A dead upstream is not sufficient cause to drop a package perse. Though it should be sufficient to think about dropping or migrating the package... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dropped packages can be kept and even installed if so desired, eh? (was Re: Considerations for 'xmms' removal from Debian)
* Neil Williams [Sun, 08 Jul 2007 16:01:54 +0100]: $ apt-cache rdepends libgtk1.2 | grep -c -v ^lib 316 I'm not sure Debian needs to throw out over 300 applications before Lenny. True, most of those are dead upstream - AFAICT GnuCash was the last active upstream to make it to gtk2 - but although these packages use old libraries that have an undoubted *potential* for security problems, in the absence of actual bug reports is it really worth dropping so many packages? (The following paragraphs are not referred to GTK+1.2 applications in particular.) I don't see what's wrong with making a bit of cleaning in our distribution, so that what new users see available does not include software for which they have no chance to get bug fixed, and for which security issues get noticed and fixed, etc. In a nutshell, dropping a package means: hey, user, we *don't* think it's worth your time installing this package to see if it fits your needs, please look elsewhere. (Which is not the same as this package has no upstream, btw.) But in any case, users of dropped packages are free to kept them installed on their systems, together with all necessary libraries. And since our upgrade process allows that, I don't see why we should refrain from doing housekeeping in our archive. And heck, if a user knows that a certain dropped, seven year old application is exactly what they need, they can grab it from the previous distribution and install it. Chances are that it'll install without problems (together with dependencies, of course). Sure, it's not straightforward, but it'll also not be the common case. My 2¢. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Arguing with an engineer is like wrestling with a pig in mud: after a while, you realize the pig is enjoying it.
Re: Considerations for 'xmms' removal from Debian
$ apt-cache rdepends libgtk1.2 | grep -c -v ^lib 316 Is a dead upstream sufficient cause to drop a package from Debian in the absence of any RC bugs? Is a dependency on libgtk1.2 going to *be* an RC bug for Lenny? It seems a very big step, IMHO. the list includes programs like cinepaint, which is dead upstream, too, but which should not go out of Debian imho (although I'd like to see cinepaint's functions in gimp 2.3, but it doesn't look like anybody is working on that). Just an example why libgtk1.2 should stay in Debian. -- Bernd Zeimetz [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
