I've heard from some KDE members on IRC it's about time to. But for clarification, can we get your statements here. Thanks.
I think I speak for gnome herd when I say we would welcome death of esound. Beside ekiga which is currently stuck at 2.0.12 with a harddep on esound (waiting for #238554), we could completely drop support for it with no problem that I can forsee. Btw, what is the "regression" keyword" for ? and why is this a qa bug ?
i dont think dropping arts makes sense until kde-4 goes stable
To be honest I'd keep USE=esd for stuff like wine until we also got PulseAudio (and the padsp/alsa-plugin) in emul-linux for amd64 builds.
(In reply to comment #1) > I think I speak for gnome herd when I say we would welcome death of esound. > Beside ekiga which is currently stuck at 2.0.12 with a harddep on esound > (waiting for #238554), we could completely drop support for it with no problem > that I can forsee. We could leave esd where e.g. alsa or something above is not optional in this round. > Btw, what is the "regression" keyword" for ? and why is this a qa bug ? - It's a regression when it wasn't bug before but is now. - Old cruft in tree is a QA issue.
(In reply to comment #2) > i dont think dropping arts makes sense until kde-4 goes stable Why? Arts isn't necessary for anything even in kde-3.
you're talking about going and modifying things directly in stable without any real testing. that sounds like a really bad idea for 0 gain at all. simply push USE="arts" down into local USE scope for KDE ebuilds and remove it from the global list. then as things stabilize, it slowly disappears.
(In reply to comment #6) > you're talking about going and modifying things directly in stable without any > real testing. that sounds like a really bad idea for 0 gain at all. I completely agree. Stable stuff should not be directly modified at all. > simply push USE="arts" down into local USE scope for KDE ebuilds and remove it > from the global list. then as things stabilize, it slowly disappears. I'm not sure about this approach, but I agree that making it (arts + esd) slowly disappear as things stabilize would be the best way.
I'm pretty sure that kde.eclass (for kde3 that is) has a way to declare that a given ebuild does not support/need arts (as well as mandating that support)... I'm sure because I wrote the code in the first place. And I also remember that back when I was a KDE team member, the idea was to disable arts wherever it did make sense to (stuff that didn't use arts but tested for it anyway because the build system is crap); stuff that mandate arts often were just using a very old admin/ directory version from when it was not possible to disable it and could be fixed by replacing the directory with a better copy. For what concern esd, I'd guess one way to handle it would be to add an ebuild that only builds the library and not the daemon or the esddsp library/script, and depend on pulseaudio instead, removing eselect-esd and fixing the esdcompat script as the esd command. And make sure there is pulseaudio in the new emul-...
So we should check if there is anything in the tree that really needs arts. If not, then I propose to drop arts from kde 3.5.10 before that goes stable.
(In reply to comment #9) > So we should check if there is anything in the tree that really needs arts. If > not, then I propose to drop arts from kde 3.5.10 before that goes stable. > So I assume KDE team is fine with me dropping arts support from all media ebuilds now?
The KDE Team will have an official answer after tonight's meeting :)
I'm sorry, what are we supposed to do here? Please do not modify our old ebuilds away from IUSE=esd, those versions still have it for a good reason. And in the course of time the revisions of packages that have USE=esd will simply be cleaned out in regular course. Nothing to do special here.
The KDE Team decided to drop arts as it is deprecated. Samuli ping me on IRC if you need anything
(In reply to comment #13) > The KDE Team decided to drop arts as it is deprecated. Samuli ping me on IRC if > you need anything > Thanks I've dropped arts from some media-sound apps, and will continue with some of the media-libs after some testing.. Some just need stabling, such as timidity++ or mpg123.. Using tinderbox as my friend
Could we at least remove esd/arts from use.defaults?
It appears the purpose of CCing gnome@ was as the primary maintainer of esound itself, not as the maintainer of packages whose old revisions might depend on esound still (which the GNOME team has been trying to get rid of for a while already and in the most part it will be resolved in due course as old revisions get removed). So I'd say that if you are a maintainer of a package that has an optional dependency on esound, please feel free to drop that in due course when no features of the application are lost. Then soon (or depending on brief research immediately) we should remove it from use.defaults too.
(In reply to comment #15) > Could we at least remove esd/arts from use.defaults? That sounds fine to me (arts).
*** Bug 286925 has been marked as a duplicate of this bug. ***
*** Bug 286953 has been marked as a duplicate of this bug. ***
no arts in main tree, kde ist fertig hier. :]
what a useless bug, closing
