Heya,
since a while now logind has replaced CK in Fedora. I'd like to retire it entirely from the distribution now.
Most deps on CK are gone. Holdouts are "cdm", "lightdm", "lxsession", "lxdm".
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
This page doesn't say anything about retiring packages other still depend on...
I am tempted to just retire CK ignoring the remaining dependencies, in the hope this will put the pressure on the folks involved to update their stuff...
Getting rid of CK in those packages is dead simple BTW. Just disable it in the packages, but make sure pam_systemd is in the PAM stack for your greeter tool. It's basically about removing code, not about adding new code -- adding new code is only necessary if you want to improve your DM to handle multi-seat setups, too (which is a new feature of logind, not available in CK[1]). For details, see:
http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers
I'd also like to retire "esound" finally. Currently, adplay, ayttm, dopewars, e16, gnome-libs, gnubg, lxdream, moon-buggy, spacechart, xarchon, xmms-esd still use it. esd of course has been deprecated and dead since many years, the packages which still use it really should wake up one day. So here, too, I'd just like to retire the package...
Alternatively, somebody else can take these over, but honstely I'd rather see them removed than continue to bitrot in our repository...
Lennart
Footnotes:
[1] If you are interested in adding proper multi-seat support to the DM of your choice, then we might be able to supply you with a free set of multi-seat hardware so that you can actually make it work. Ping me.
On Tue, Feb 12, 2013 at 12:34 PM, Lennart Poettering mzerqung@0pointer.dewrote:
Heya,
since a while now logind has replaced CK in Fedora. I'd like to retire it entirely from the distribution now.
Most deps on CK are gone. Holdouts are "cdm", "lightdm", "lxsession", "lxdm".
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
This page doesn't say anything about retiring packages other still depend on...
I am tempted to just retire CK ignoring the remaining dependencies, in the hope this will put the pressure on the folks involved to update their stuff...
Getting rid of CK in those packages is dead simple BTW. Just disable it in the packages, but make sure pam_systemd is in the PAM stack for your greeter tool. It's basically about removing code, not about adding new code -- adding new code is only necessary if you want to improve your DM to handle multi-seat setups, too (which is a new feature of logind, not available in CK[1]). For details, see:
http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers
I'd also like to retire "esound" finally. Currently, adplay, ayttm, dopewars, e16, gnome-libs, gnubg, lxdream, moon-buggy, spacechart, xarchon, xmms-esd still use it. esd of course has been deprecated and dead since many years, the packages which still use it really should wake up one day. So here, too, I'd just like to retire the package...
Alternatively, somebody else can take these over, but honstely I'd rather see them removed than continue to bitrot in our repository...
So to clarify, you're not actually retiring anything currently, just expressing to the community that you'd like to and that we should work toward making that possible?
If so, do you have any guidelines on getting rid of esound requirements?
-J
Lennart
Footnotes:
[1] If you are interested in adding proper multi-seat support to the DM of your choice, then we might be able to supply you with a free set of multi-seat hardware so that you can actually make it work. Ping me.
-- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, 12.02.13 12:38, Jon Ciesla (limburgher@gmail.com) wrote:
On Tue, Feb 12, 2013 at 12:34 PM, Lennart Poettering mzerqung@0pointer.dewrote:
Heya,
since a while now logind has replaced CK in Fedora. I'd like to retire it entirely from the distribution now.
Most deps on CK are gone. Holdouts are "cdm", "lightdm", "lxsession", "lxdm".
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
This page doesn't say anything about retiring packages other still depend on...
I am tempted to just retire CK ignoring the remaining dependencies, in the hope this will put the pressure on the folks involved to update their stuff...
Getting rid of CK in those packages is dead simple BTW. Just disable it in the packages, but make sure pam_systemd is in the PAM stack for your greeter tool. It's basically about removing code, not about adding new code -- adding new code is only necessary if you want to improve your DM to handle multi-seat setups, too (which is a new feature of logind, not available in CK[1]). For details, see:
http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers
I'd also like to retire "esound" finally. Currently, adplay, ayttm, dopewars, e16, gnome-libs, gnubg, lxdream, moon-buggy, spacechart, xarchon, xmms-esd still use it. esd of course has been deprecated and dead since many years, the packages which still use it really should wake up one day. So here, too, I'd just like to retire the package...
Alternatively, somebody else can take these over, but honstely I'd rather see them removed than continue to bitrot in our repository...
So to clarify, you're not actually retiring anything currently, just expressing to the community that you'd like to and that we should work toward making that possible?
Well, I am just checking before I do something whether I can actually do it. That's all. By next week or so I will either have retired the packages (which I'd prefer) or somebody else took them over (which I'd prefer not to do, but which we can do too, if the retro-computing folks step up...)
If so, do you have any guidelines on getting rid of esound requirements?
Dunno really. My suspicion is that the packages in question are either obsolete on their own, or should just be compiled with --disable-esd or so. These packages all look pretty much esoteric or obsolete to me, so I am not really that curious what precisely packagers would need to do...
Lennart
On Tue, Feb 12, 2013 at 1:12 PM, Lennart Poettering mzerqung@0pointer.dewrote:
On Tue, 12.02.13 12:38, Jon Ciesla (limburgher@gmail.com) wrote:
On Tue, Feb 12, 2013 at 12:34 PM, Lennart Poettering mzerqung@0pointer.dewrote:
Heya,
since a while now logind has replaced CK in Fedora. I'd like to retire it entirely from the distribution now.
Most deps on CK are gone. Holdouts are "cdm", "lightdm", "lxsession", "lxdm".
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
This page doesn't say anything about retiring packages other still depend on...
I am tempted to just retire CK ignoring the remaining dependencies, in the hope this will put the pressure on the folks involved to update their stuff...
Getting rid of CK in those packages is dead simple BTW. Just disable it in the packages, but make sure pam_systemd is in the PAM stack for your greeter tool. It's basically about removing code, not about adding new code -- adding new code is only necessary if you want to improve your DM to handle multi-seat setups, too (which is a new feature of logind, not available in CK[1]). For details, see:
http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers
I'd also like to retire "esound" finally. Currently, adplay, ayttm, dopewars, e16, gnome-libs, gnubg, lxdream, moon-buggy, spacechart, xarchon, xmms-esd still use it. esd of course has been deprecated and dead since many years, the packages which still use it really should wake up one day. So here, too, I'd just like to retire the package...
Alternatively, somebody else can take these over, but honstely I'd rather see them removed than continue to bitrot in our repository...
So to clarify, you're not actually retiring anything currently, just expressing to the community that you'd like to and that we should work toward making that possible?
Well, I am just checking before I do something whether I can actually do it. That's all. By next week or so I will either have retired the packages (which I'd prefer) or somebody else took them over (which I'd prefer not to do, but which we can do too, if the retro-computing folks step up...)
I'd prefer that you orphan them, and mail the list, ccing <foo>-owner for
each dependency, that you're doing so. That said, I maintain gnugb, and was able to easily remove the esound requirement. If no one else wants to maintain esound, I will, even if only long enough to excise it from the packages that need it.
If so, do you have any guidelines on getting rid of esound requirements?
Dunno really. My suspicion is that the packages in question are either obsolete on their own, or should just be compiled with --disable-esd or so. These packages all look pretty much esoteric or obsolete to me, so I am not really that curious what precisely packagers would need to do...
Obsolete is in the eye of the beholder. I don't think games ever truly are. ;)
-J
Lennart
-- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 12 Feb 2013 19:53, "Jon Ciesla" limburgher@gmail.com wrote:
On Tue, Feb 12, 2013 at 1:12 PM, Lennart Poettering mzerqung@0pointer.de
wrote:
On Tue, 12.02.13 12:38, Jon Ciesla (limburgher@gmail.com) wrote:
On Tue, Feb 12, 2013 at 12:34 PM, Lennart Poettering mzerqung@0pointer.dewrote:
Heya,
since a while now logind has replaced CK in Fedora. I'd like to
retire
it entirely from the distribution now.
Most deps on CK are gone. Holdouts are "cdm", "lightdm", "lxsession", "lxdm".
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
This page doesn't say anything about retiring packages other still depend on...
I am tempted to just retire CK ignoring the remaining dependencies,
in
the hope this will put the pressure on the folks involved to update their stuff...
Getting rid of CK in those packages is dead simple BTW. Just disable
it
in the packages, but make sure pam_systemd is in the PAM stack for
your
greeter tool. It's basically about removing code, not about adding new code -- adding new code is only necessary if you want to improve your DM to handle multi-seat setups, too (which is a new feature of logind, not available in CK[1]). For details, see:
http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers
I'd also like to retire "esound" finally. Currently, adplay, ayttm, dopewars, e16, gnome-libs, gnubg, lxdream, moon-buggy, spacechart, xarchon, xmms-esd still use it. esd of course has been deprecated and dead since many years, the packages which still use it really should wake up one day. So here, too, I'd just like to retire the package...
Alternatively, somebody else can take these over, but honstely I'd rather see them removed than continue to bitrot in our repository...
So to clarify, you're not actually retiring anything currently, just expressing to the community that you'd like to and that we should work toward making that possible?
Well, I am just checking before I do something whether I can actually do it. That's all. By next week or so I will either have retired the packages (which I'd prefer) or somebody else took them over (which I'd prefer not to do, but which we can do too, if the retro-computing folks step up...)
I'd prefer that you orphan them, and mail the list, ccing <foo>-owner for
each dependency, that you're doing so. That said, I maintain gnugb, and was able to easily remove the esound requirement. If no one else wants to maintain esound, I will, even if only long enough to excise it from the packages that need it.
In the case of esound I think we're better killing them because I suspect in all cases the packages are either: - optional packages better served by either native PA or alsa support in other sub/related packages - disable the esd support and just use the native alsa/oss in the package
In all cases I strongly doubt the user will lose functionality and we should just get on with it.
If so, do you have any guidelines on getting rid of esound
requirements?
Dunno really. My suspicion is that the packages in question are either obsolete on their own, or should just be compiled with --disable-esd or so. These packages all look pretty much esoteric or obsolete to me, so I am not really that curious what precisely packagers would need to do...
Obsolete is in the eye of the beholder. I don't think games ever truly
are. ;)
-J
Lennart
-- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
-- http://cecinestpasunefromage.wordpress.com/
in your fear, seek only peace in your fear, seek only love
-d. bowie
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
xfce4-session still wants to use ConsoleKit, however, there are upstream patches to fix that. I was waiting for a release to happen with them, but I can pick them in before them if need be.
kevin
Peter Robinson wrote:
In the case of esound I think we're better killing them because I suspect in all cases the packages are either:
- optional packages better served by either native PA or alsa support in
other sub/related packages
- disable the esd support and just use the native alsa/oss in the package
Actually, several of those games support ONLY esd for sound. Disabling esd = disabling sound in those games. Not so nice, considering that PulseAudio still supports the ESD protocol just fine. Now if Lennart is going to drop the protocol support from PulseAudio, then libesd will have to go away as well, but if it's just about Fedora maintainership, then the maintainer(s) of one or more of the affected packages should just take it over.
Kevin Kofler
On Tue, 12.02.13 13:52, Jon Ciesla (limburgher@gmail.com) wrote:
So to clarify, you're not actually retiring anything currently, just expressing to the community that you'd like to and that we should work toward making that possible?
Well, I am just checking before I do something whether I can actually do it. That's all. By next week or so I will either have retired the packages (which I'd prefer) or somebody else took them over (which I'd prefer not to do, but which we can do too, if the retro-computing folks step up...)
I'd prefer that you orphan them, and mail the list, ccing <foo>-owner for each dependency, that you're doing so. That said, I maintain gnugb, and was able to easily remove the esound requirement. If no one else wants to maintain esound, I will, even if only long enough to excise it from the packages that need it.
OK, if that's what you want. I have now orphaned esound. Please take it over.
Lennart
Hi
On Tue, Feb 12, 2013 at 5:51 PM, Lennart Poettering mzerqung@0pointer.dewrote:
OK, if that's what you want. I have now orphaned esound. Please take it over.
https://bugzilla.redhat.com/show_bug.cgi?id=910600 spacechart https://bugzilla.redhat.com/show_bug.cgi?id=910601 xmms
It is not clear why spacechart is picking up esound but it in any case, xmms could disable it easily. Couple of games look they need to be ported over and their needs usually are simple enough
Rahul
On Tue, 12.02.13 18:22, Rahul Sundaram (metherid@gmail.com) wrote:
OK, if that's what you want. I have now orphaned esound. Please take it over.
https://bugzilla.redhat.com/show_bug.cgi?id=910600 spacechart https://bugzilla.redhat.com/show_bug.cgi?id=910601 xmms
It is not clear why spacechart is picking up esound but it in any case, xmms could disable it easily. Couple of games look they need to be ported over and their needs usually are simple enough
Hmm, we still have xmms in the repo? Both Debian and Gentoo killed it years ago... And I though those were the conservative distributions...
Lennart
On Wed, Feb 13, 2013 at 00:26:28 +0100, Lennart Poettering mzerqung@0pointer.de wrote:
Hmm, we still have xmms in the repo? Both Debian and Gentoo killed it years ago... And I though those were the conservative distributions...
I wanted to keep it in Fedora a little bit longer since I have been using it. But if it is causing problems, I won't stand in the way of dropping it.
On Tue, 12 Feb 2013 20:47:50 -0600, Bruno Wolff III wrote:
On Wed, Feb 13, 2013 at 00:26:28 +0100, Lennart Poettering wrote:
Hmm, we still have xmms in the repo? Both Debian and Gentoo killed it years ago... And I though those were the conservative distributions...
I wanted to keep it in Fedora a little bit longer since I have been using it. But if it is causing problems, I won't stand in the way of dropping it.
It is causing problems: http://bugz.fedoraproject.org Plus the several closed tickets (for xmms and xmms-pulse) that have not been responded to by any package maintainer at all.
On Wed, Feb 13, 2013 at 16:10:58 +0100, Michael Schwendt mschwendt@gmail.com wrote:
On Tue, 12 Feb 2013 20:47:50 -0600, Bruno Wolff III wrote:
On Wed, Feb 13, 2013 at 00:26:28 +0100, Lennart Poettering wrote:
Hmm, we still have xmms in the repo? Both Debian and Gentoo killed it years ago... And I though those were the conservative distributions...
I wanted to keep it in Fedora a little bit longer since I have been using it. But if it is causing problems, I won't stand in the way of dropping it.
It is causing problems: http://bugz.fedoraproject.org Plus the several closed tickets (for xmms and xmms-pulse) that have not been responded to by any package maintainer at all.
I'll retire it before F20 is branched.
Hi,
On 02/13/2013 04:26 AM, DJ Delorie wrote:
Hmm, we still have xmms in the repo?
/me is very glad we still have xmms in the repo
Have you tried using Audacious ? You can set it to classic mode, at which point it user experience is identical to xmms.
With the advantage that it uses a modern toolkit, more modern plumbing in various places, and it is actively maintained both in Fedora and upstream.
Regards,
Hans
On 13 February 2013 09:21, Hans de Goede hdegoede@redhat.com wrote:
Hi,
Have you tried using Audacious ? You can set it to classic mode, at which point it user experience is identical to xmms.
With the advantage that it uses a modern toolkit, more modern plumbing in various places, and it is actively maintained both in Fedora and upstream.
That seems like exactly what should go in the dead.package file :-)
On Wed, 13 Feb 2013 10:21:35 +0100, Hans de Goede wrote:
Hi,
On 02/13/2013 04:26 AM, DJ Delorie wrote:
Hmm, we still have xmms in the repo?
/me is very glad we still have xmms in the repo
Have you tried using Audacious ? You can set it to classic mode, at which point it user experience is identical to xmms.
Except for the double-sized skinned mode, which is no longer available, because nobody has interest in maintaining it. Occasionally, a user notices that it's missing, but most users seem to like the GTK+ mode better anyway. And for the future that could mean the Winamp classic mode will be removed eventually, too.
If it must be a skinned interface like Winamp, there are other players that support such skins, such as "qmmp": yum info qmmp
Have you tried using Audacious ?
Just did. No thanks. /me uninstalls those five RPMs...
You can set it to classic mode, at which point it user experience is identical to xmms.
No, it's not. It's close enough to fool someone who doesn't use xmms regularly, but it's different enough to really annoy those of us who do.
Reminds me of a friend who hates anything gtk-on-windows because it looks enough like windows that your instinct is to use your windows techniques, but it's different enough to burn you every time you try that.
With the advantage that it uses a modern toolkit,
Disadvantage, if you ask me. First thing audacious did was spew random errors to the screen and change my Firefox and emacs cursors. Then it ask which of the most recent minecraft jar files I wanted to listen to. When I finally located my *music* folder in its playlist chooser, it refused to play my shoutcast streams, instead filling the log window with more useless errors. I managed to find one .wav it would play, and it defaulted to 120% volume which made it sound like crap (well, more like crap, since I still haven't figured out how to get pulseaudio to use my digital audio outputs).
All this was before I figured out how to switch it to Winamp mode (not xmms mode) but it doesn't support all the customization options that xmms does, so it didn't look or act like xmms. Plus, the playlist management system is completely different.
On Wed, 13 Feb 2013 13:15:07 -0500, DJ Delorie wrote:
First thing audacious did was spew random errors to the screen and change my Firefox and emacs cursors.
Interesting, but here it has never done that before.
Then it ask which of the most recent minecraft jar files I wanted to listen to. When I finally located my *music* folder in its playlist chooser, it refused to play my shoutcast streams, instead filling the log window with more useless errors. I managed to find one .wav it would play,
Odd. It can certainly play a lot more formats than just WAV, though for MP3'n'stuff you need plug-in packages from RPM Fusion.
and it defaulted to 120% volume which made it sound like crap (well, more like crap, since I still haven't figured out how to get pulseaudio to use my digital audio outputs).
It includes an ALSA output plug-in, too, but defaults to Pulse Audio. Apparently, you've not used XMMS with "xmms-pulse" either (because that one suffers from several volume related issues).
You have other serious system issues not affiliated with Audacious if this is the case.
If "I don't run gnome" is considered "other serious system issues", I suppose so.
Restarting didn't help, I still had the wrong cursor in emacs and firefox, but only the emacs and firefox run remotely back to my display, the local emacs and firefox had the right cursors. I still can't figure out how to get rid of the wrong cursor without also getting rid of the right cursors, so I'm currently *not* using Xcursor because the theme stuff is so confusing.
DJ Delorie wrote:
Disadvantage, if you ask me. First thing audacious did was spew random errors to the screen and change my Firefox and emacs cursors.
So I suspect that Audacious started gnome-settings-daemon. In the past, some GNOME apps kept doing that under KDE Plasma sessions as well, until we started installing xsettings-kde by default, which claims XSettings ownership and thus prevents gnome-settings-daemon from running.
If "I don't run gnome" is considered "other serious system issues", I suppose so.
Well, it looks like you aren't running ANY desktop environment, or at least one that doesn't provide an XSettings manager.
Unfortunately, gnome-settings-daemon is a real annoyance, you cannot rely on it running when you don't use GNOME, because it's autostarted only in GNOME, but then some stuff ends up starting it for whatever reason. GNOME developers say it should only ever run in GNOME sessions, but somehow it still gets autospawned by some stuff, and only having some other software claim XSettings ownership (as xsettings-kde does in KDE Plasma sessions) will stop it from applying GNOME settings in the middle of your session.
Restarting didn't help, I still had the wrong cursor in emacs and firefox, but only the emacs and firefox run remotely back to my display, the local emacs and firefox had the right cursors. I still can't figure out how to get rid of the wrong cursor without also getting rid of the right cursors, so I'm currently *not* using Xcursor because the theme stuff is so confusing.
Did the evil gnome-settings-daemon even get autospawned? Try "killall gnome-settings-daemon".
Kevin Kofler
I wrote:
DJ Delorie wrote:
Restarting didn't help, I still had the wrong cursor in emacs and firefox, but only the emacs and firefox run remotely back to my display, the local emacs and firefox had the right cursors. I still can't figure out how to get rid of the wrong cursor without also getting rid of the right cursors, so I'm currently *not* using Xcursor because the theme stuff is so confusing.
Did the evil gnome-settings-daemon even get autospawned? Try "killall gnome-settings-daemon".
Oops, I mean, did it even get saved in the session and auto-REspawned? (That used not to be the case.)
Kevin Kofler
Well, it looks like you aren't running ANY desktop environment,
fvwm2, emacs, firefox, xterm. Plus a few other things as needed. This is for two computers running four monitors (one computer is the local one with the monitors, the other is strictly ssh and remote X, each computer has its own desktop I switch between). It's a horror show each time I upgrade, usually takes a few days to get everything "settled" again.
or at least one that doesn't provide an XSettings manager.
This is the first time I've *heard* of an "XSettings manager".
Did the evil gnome-settings-daemon even get autospawned? Try "killall gnome-settings-daemon".
I did kill it. It was running again anyway. I killed it again and replaced it with a script that just calls /bin/true :-)
Some of the appearance changed back when I killed the daemon, but I'll have to reinstall the theme to see if the cursor is fixed.
I have a hard time keeping programs from running xrdb too, I usually end up renaming that too.
On Thu, 14 Feb 2013 03:49:23 +0100, Kevin Kofler wrote:
DJ Delorie wrote:
Disadvantage, if you ask me. First thing audacious did was spew random errors to the screen and change my Firefox and emacs cursors.
So I suspect that Audacious started gnome-settings-daemon.
It doesn't do that when I use OpenBox instead of GNOME, so OpenBox does not auto-spawn g-s-d.
However, one of its plug-ins talks to DBus (org.gnome.SettingsDaemon) for GNOME media player keyboard shortcuts. That plug-in is enabled by default and by request, and anyone not running a compatible environment can easily switch it off in the preferences.
On Thu, 2013-02-14 at 10:53 +0100, Michael Schwendt wrote:
On Thu, 14 Feb 2013 03:49:23 +0100, Kevin Kofler wrote:
DJ Delorie wrote:
Disadvantage, if you ask me. First thing audacious did was spew random errors to the screen and change my Firefox and emacs cursors.
So I suspect that Audacious started gnome-settings-daemon.
It doesn't do that when I use OpenBox instead of GNOME, so OpenBox does not auto-spawn g-s-d.
However, one of its plug-ins talks to DBus (org.gnome.SettingsDaemon) for GNOME media player keyboard shortcuts. That plug-in is enabled by default and by request, and anyone not running a compatible environment can easily switch it off in the preferences.
Or you could fix the plugin to not auto-start the daemon so we don't get blamed for Audacious bugs...
Hi,
On 02/14/2013 01:28 PM, Bastien Nocera wrote:
On Thu, 2013-02-14 at 10:53 +0100, Michael Schwendt wrote:
On Thu, 14 Feb 2013 03:49:23 +0100, Kevin Kofler wrote:
DJ Delorie wrote:
Disadvantage, if you ask me. First thing audacious did was spew random errors to the screen and change my Firefox and emacs cursors.
So I suspect that Audacious started gnome-settings-daemon.
It doesn't do that when I use OpenBox instead of GNOME, so OpenBox does not auto-spawn g-s-d.
However, one of its plug-ins talks to DBus (org.gnome.SettingsDaemon) for GNOME media player keyboard shortcuts. That plug-in is enabled by default and by request, and anyone not running a compatible environment can easily switch it off in the preferences.
Or you could fix the plugin to not auto-start the daemon so we don't get blamed for Audacious bugs...
Actually after seeing this thread I was planning on sending a mail to ask people how to fix this. I guess that dbus-activation causes g-s-d to start when the audacious tries to talk to it.
Rather then a less the friendly worded reply, it would be actually helpful if you could tell us (pointer to a code example would be a bonus) how to talk to a dbus interface without causing dbus-activation to trigger.
Regards,
Hans
On 02/14/2013 06:35 PM, Hans de Goede wrote:
Hi,
On 02/14/2013 01:28 PM, Bastien Nocera wrote:
On Thu, 2013-02-14 at 10:53 +0100, Michael Schwendt wrote:
On Thu, 14 Feb 2013 03:49:23 +0100, Kevin Kofler wrote:
DJ Delorie wrote:
Disadvantage, if you ask me. First thing audacious did was spew random errors to the screen and change my Firefox and emacs cursors.
So I suspect that Audacious started gnome-settings-daemon.
It doesn't do that when I use OpenBox instead of GNOME, so OpenBox does not auto-spawn g-s-d.
However, one of its plug-ins talks to DBus (org.gnome.SettingsDaemon) for GNOME media player keyboard shortcuts. That plug-in is enabled by default and by request, and anyone not running a compatible environment can easily switch it off in the preferences.
Or you could fix the plugin to not auto-start the daemon so we don't get blamed for Audacious bugs...
Actually after seeing this thread I was planning on sending a mail to ask people how to fix this. I guess that dbus-activation causes g-s-d to start when the audacious tries to talk to it.
Rather then a less the friendly worded reply, it would be actually helpful if you could tell us (pointer to a code example would be a bonus) how to talk to a dbus interface without causing dbus-activation to trigger.
Nothing fancy:
http://developer.gnome.org/gio/unstable/GDBusConnection.html#GDBusCallFlags
or
http://dbus.freedesktop.org/doc/api/html/group__DBusMessage.html#ga1596d92a8...
Obviously I can't list every single language or binding here.
Cheers,
Stef
Hi,
On 02/15/2013 07:57 AM, Stef Walter wrote:
On 02/14/2013 06:35 PM, Hans de Goede wrote:
Hi,
On 02/14/2013 01:28 PM, Bastien Nocera wrote:
On Thu, 2013-02-14 at 10:53 +0100, Michael Schwendt wrote:
On Thu, 14 Feb 2013 03:49:23 +0100, Kevin Kofler wrote:
DJ Delorie wrote:
Disadvantage, if you ask me. First thing audacious did was spew random errors to the screen and change my Firefox and emacs cursors.
So I suspect that Audacious started gnome-settings-daemon.
It doesn't do that when I use OpenBox instead of GNOME, so OpenBox does not auto-spawn g-s-d.
However, one of its plug-ins talks to DBus (org.gnome.SettingsDaemon) for GNOME media player keyboard shortcuts. That plug-in is enabled by default and by request, and anyone not running a compatible environment can easily switch it off in the preferences.
Or you could fix the plugin to not auto-start the daemon so we don't get blamed for Audacious bugs...
Actually after seeing this thread I was planning on sending a mail to ask people how to fix this. I guess that dbus-activation causes g-s-d to start when the audacious tries to talk to it.
Rather then a less the friendly worded reply, it would be actually helpful if you could tell us (pointer to a code example would be a bonus) how to talk to a dbus interface without causing dbus-activation to trigger.
Nothing fancy:
http://developer.gnome.org/gio/unstable/GDBusConnection.html#GDBusCallFlags
or
http://dbus.freedesktop.org/doc/api/html/group__DBusMessage.html#ga1596d92a8...
Thanks, that is likely / hopefully exactly what we're looking for.
Regards,
Hans
On Thu, 14 Feb 2013 18:35:23 +0100, Hans de Goede wrote:
On Thu, 14 Feb 2013 03:49:23 +0100, Kevin Kofler wrote:
DJ Delorie wrote:
Disadvantage, if you ask me. First thing audacious did was spew random errors to the screen and change my Firefox and emacs cursors.
So I suspect that Audacious started gnome-settings-daemon.
It doesn't do that when I use OpenBox instead of GNOME, so OpenBox does not auto-spawn g-s-d.
However, one of its plug-ins talks to DBus (org.gnome.SettingsDaemon) for GNOME media player keyboard shortcuts. That plug-in is enabled by default and by request, and anyone not running a compatible environment can easily switch it off in the preferences.
Or you could fix the plugin to not auto-start the daemon so we don't get blamed for Audacious bugs...
Actually after seeing this thread I was planning on sending a mail to ask people how to fix this. I guess that dbus-activation causes g-s-d to start when the audacious tries to talk to it.
Rather then a less the friendly worded reply, it would be actually helpful if you could tell us (pointer to a code example would be a bonus) how to talk to a dbus interface without causing dbus-activation to trigger.
What I checked in ~13 hours ago is this:
http://pkgs.fedoraproject.org/cgit/audacious-plugins.git/commit/?id=55972c07...
Reviews/feedback appreciated. Preferably, I'd still like to see a test-case where g-s-d would be started automatically. Chasing ghosts is not so funny.
On Thu, 14 Feb 2013 13:28:57 +0100, Bastien Nocera wrote:
On Thu, 2013-02-14 at 10:53 +0100, Michael Schwendt wrote:
On Thu, 14 Feb 2013 03:49:23 +0100, Kevin Kofler wrote:
DJ Delorie wrote:
Disadvantage, if you ask me. First thing audacious did was spew random errors to the screen and change my Firefox and emacs cursors.
So I suspect that Audacious started gnome-settings-daemon.
It doesn't do that when I use OpenBox instead of GNOME, so OpenBox does not auto-spawn g-s-d.
However, one of its plug-ins talks to DBus (org.gnome.SettingsDaemon) for GNOME media player keyboard shortcuts. That plug-in is enabled by default and by request, and anyone not running a compatible environment can easily switch it off in the preferences.
Or you could fix the plugin to not auto-start the daemon so we don't get blamed for Audacious bugs...
Could you tell me a test environment where auto-starting the daemon is reproducible? Then I might take a look at trying to avoid it. As pointed out above, with Openbox the daemon is not started automatically when starting Audacious. I'm stuck there. The puzzle is incomplete.
The implementation of the plugin looks dubious in the bottom half of gnome_remote_init() -- I dunno why it does the 2nd dbus_g_proxy_call -- https://github.com/audacious-media-player/audacious-plugins/blob/master/src/... but other than that the only thing I could think of is dbus system activation as there's nothing else that would start the daemon automatically.
$ ps ax|grep dbus 646 ? Ssl 0:01 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation 20236 ? S 0:00 dbus-launch --sh-syntax --exit-with-session 20237 ? Ssl 0:00 /bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session 20443 ? Sl 0:00 /bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3 20900 pts/0 S+ 0:00 grep --color=auto dbus
On Thu, 2013-02-14 at 20:39 +0100, Michael Schwendt wrote:
On Thu, 14 Feb 2013 13:28:57 +0100, Bastien Nocera wrote:
On Thu, 2013-02-14 at 10:53 +0100, Michael Schwendt wrote:
On Thu, 14 Feb 2013 03:49:23 +0100, Kevin Kofler wrote:
DJ Delorie wrote:
Disadvantage, if you ask me. First thing audacious did was spew random errors to the screen and change my Firefox and emacs cursors.
So I suspect that Audacious started gnome-settings-daemon.
It doesn't do that when I use OpenBox instead of GNOME, so OpenBox does not auto-spawn g-s-d.
However, one of its plug-ins talks to DBus (org.gnome.SettingsDaemon) for GNOME media player keyboard shortcuts. That plug-in is enabled by default and by request, and anyone not running a compatible environment can easily switch it off in the preferences.
Or you could fix the plugin to not auto-start the daemon so we don't get blamed for Audacious bugs...
Could you tell me a test environment where auto-starting the daemon is reproducible? Then I might take a look at trying to avoid it.
It should be auto-started when your app pokes at the not-yet-spawned well-known D-Bus name.
As pointed out above, with Openbox the daemon is not started automatically when starting Audacious. I'm stuck there. The puzzle is incomplete.
Is there a session D-Bus running in your session? I don't know how it could not start.
The implementation of the plugin looks dubious in the bottom half of gnome_remote_init() -- I dunno why it does the 2nd dbus_g_proxy_call -- https://github.com/audacious-media-player/audacious-plugins/blob/master/src/... but other than that the only thing I could think of is dbus system activation as there's nothing else that would start the daemon automatically.
You make a call to GrabMediaPlayerKeys() on a well-known D-Bus name that isn't spawned. D-Bus will gladly allow you to make the call and spawn the service for you.
You should use dbus_g_proxy_new_for_name_owner() instead, which will round-trip and check whether the service exists. Hopefully it should stop it from auto-spawning.
GDBus has the separate and more practical G_DBUS_CALL_FLAGS_NO_AUTO_START flag to be used.
Cheers
On Fri, 15 Feb 2013 08:13:32 +0100, Bastien Nocera wrote:
Could you tell me a test environment where auto-starting the daemon is reproducible? Then I might take a look at trying to avoid it.
It should be auto-started when your app pokes at the not-yet-spawned well-known D-Bus name.
There's an error upon trying to talk to it:
The name org.gnome.SettingsDaemon was not provided by any .service files
It seems something wants to start it but couldn't without the .service file.
I've also tried Fedora 17 where g-s-d is not auto-started either. I've also tried Fedora 18 _without_ GDM but with startx and fvwm. Always the same error message.
As pointed out above, with Openbox the daemon is not started automatically when starting Audacious. I'm stuck there. The puzzle is incomplete.
Is there a session D-Bus running in your session? I don't know how it could not start.
At the bottom of the message you replied to: http://lists.fedoraproject.org/pipermail/devel/2013-February/178617.html
$ ps ax|grep dbus 646 ? Ssl 0:01 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation 20236 ? S 0:00 dbus-launch --sh-syntax --exit-with-session 20237 ? Ssl 0:00 /bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session 20443 ? Sl 0:00 /bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3 20900 pts/0 S+ 0:00 grep --color=auto dbus
You should use dbus_g_proxy_new_for_name_owner() instead, which will round-trip and check whether the service exists.
Then my (preliminary) solution from yesterday can't be too bad, since if there's no owner the plugin refuses to talk to dbus.
Hopefully it should stop it from auto-spawning.
You said "hopefully". ;-) Yeah, a test environment would be good.
Yeah, a test environment would be good.
Found a first one! EL6 with Openbox from EPEL. That one auto-spawns g-s-d when running Audacious unpatched.
$ find /usr/share/dbus-1|grep Sett /usr/share/dbus-1/services/org.gnome.SettingsDaemon.service
On Wed, 13 Feb 2013 12:59:46 -0600, Michael Cronenworth wrote:
DJ Delorie wrote:
And now I have to restart my entire session to reset my gtk themes, because of one rogue app. Thanks.
You have other serious system issues not affiliated with Audacious if this is the case.
Hmmm, Audacious uses GTK+ v3, whereas XMMS uses GTK+ v1. We haven't heard what desktop environment (or plain window manager) is being used. Perhaps it can be disturbed by gtk3? It wouldn't be the first time that a modern application exposes a bug/deficiency in a window manger.
Anyway, I do use Emacs, too, and my customized cursor doesn't get disturbed by Audacious. ;)
On 13/02/13 10:15 AM, DJ Delorie wrote:
(well, more like crap, since I still haven't figured out how to
get pulseaudio to use my digital audio outputs).
Really? It's not that hard. It's either a device or a profile right on the very first tab of GNOME sound properties. If you're using pavucontrol, devices are on the 'Output Devices' tab, profiles are on the 'Configuration' tab. It's rather easier than doing the same thing with ALSA, really.
(subject changed, please strip the [was...] when replying)
On 13/02/13 10:15 AM, DJ Delorie wrote:
(well, more like crap, since I still haven't figured out how to get pulseaudio to use my digital audio outputs).
Really? It's not that hard. It's either a device or a profile right on the very first tab of GNOME sound properties. If you're using pavucontrol, devices are on the 'Output Devices' tab, profiles are on the 'Configuration' tab. It's rather easier than doing the same thing with ALSA, really.
I know all about those. I've tried them all. I've gone through all the online discussions about how to get digital outputs to work with pulseaudio. I've hacked at the config files and tried to trace the operation. I've been doing this with every update since pulseaudio was introduced, and they're all clean installs, not upgrades. It worked just fine with ALSA. I've even run GNOME sound properties, despite not running a GNOME desktop. I haven't yet tried F18 though, because I don't yet have the spare days it takes to do that.
It just doesn't work.
I know the hardware works, because XBMC uses the digital output just fine (and sounds seriously better). The motherboard is a Gigabyte GA-X58A-UD3R although I do have an HDMI-compatible video card (and yes, I know you have to disable audio on that, the video card is much more recent than my PA woes).
00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller 03:00.1 Audio device: ATI Technologies Inc Barts HDMI Audio [Radeon HD 6800 Series] 07:00.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 02)
On 15/02/13 10:22 AM, DJ Delorie wrote:
(subject changed, please strip the [was...] when replying)
On 13/02/13 10:15 AM, DJ Delorie wrote:
(well, more like crap, since I still haven't figured out how to get pulseaudio to use my digital audio outputs).
Really? It's not that hard. It's either a device or a profile right on the very first tab of GNOME sound properties. If you're using pavucontrol, devices are on the 'Output Devices' tab, profiles are on the 'Configuration' tab. It's rather easier than doing the same thing with ALSA, really.
I know all about those. I've tried them all. I've gone through all the online discussions about how to get digital outputs to work with pulseaudio. I've hacked at the config files and tried to trace the operation. I've been doing this with every update since pulseaudio was introduced, and they're all clean installs, not upgrades. It worked just fine with ALSA. I've even run GNOME sound properties, despite not running a GNOME desktop. I haven't yet tried F18 though, because I don't yet have the spare days it takes to do that.
It just doesn't work.
I know the hardware works, because XBMC uses the digital output just fine (and sounds seriously better). The motherboard is a Gigabyte GA-X58A-UD3R although I do have an HDMI-compatible video card (and yes, I know you have to disable audio on that, the video card is much more recent than my PA woes).
00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller 03:00.1 Audio device: ATI Technologies Inc Barts HDMI Audio [Radeon HD 6800 Series] 07:00.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 02)
That's weird. Definitely just some kind of bug specific to your system, though, the normal PA experience with digital output is pretty simple. I've had no problem with it. You don't really need to disable any output sources in most cases, either (I haven't bothered disabling any of the umpteen sources that appear to exist on my system, I just pick the one I actually want to use, and it works, no problems at all). Do you have a bug report in?
On Fri, Feb 15, 2013 at 6:22 PM, DJ Delorie dj@redhat.com wrote:
(subject changed, please strip the [was...] when replying)
On 13/02/13 10:15 AM, DJ Delorie wrote:
(well, more like crap, since I still haven't figured out how to get pulseaudio to use my digital audio outputs).
Really? It's not that hard. It's either a device or a profile right on the very first tab of GNOME sound properties. If you're using pavucontrol, devices are on the 'Output Devices' tab, profiles are on the 'Configuration' tab. It's rather easier than doing the same thing with ALSA, really.
I know all about those. I've tried them all. I've gone through all the online discussions about how to get digital outputs to work with pulseaudio. I've hacked at the config files and tried to trace the operation. I've been doing this with every update since pulseaudio was introduced, and they're all clean installs, not upgrades. It worked just fine with ALSA. I've even run GNOME sound properties, despite not running a GNOME desktop. I haven't yet tried F18 though, because I don't yet have the spare days it takes to do that.
It just doesn't work.
It works just fine for me on F18 on media center box using a standard optical cable.
Peter
On Wed, Feb 13, 2013 at 4:21 AM, Hans de Goede wrote:
Hi,
On 02/13/2013 04:26 AM, DJ Delorie wrote:
Hmm, we still have xmms in the repo?
/me is very glad we still have xmms in the repo
Have you tried using Audacious ? You can set it to classic mode, at which point it user experience is identical to xmms.
With the advantage that it uses a modern toolkit, more modern plumbing in various places, and it is actively maintained both in Fedora and upstream.
While audacious can be made to look similar to xmms, it is not xmms, and indeed they are very different from each other. xmms (with ALSA) is the only player that consistently worked for me with no problems for the last 11 years. Moreover it uses the best (in my opinion) GTK version out there.
If the esound or pulseaudio plugins are problematic, let us retire them. I don't think xmms will be used by other people than us fanboys, and I feel that we are fine with the ALSA output.
Anyhow it looks like spot was kind enough to pick it up, so no worries :)
Best, Orcan
On Wed, Feb 13, 2013 at 21:21:41 -0500, Orcan Ogetbil oget.fedora@gmail.com wrote:
If the esound or pulseaudio plugins are problematic, let us retire them. I don't think xmms will be used by other people than us fanboys, and I feel that we are fine with the ALSA output.
Anyhow it looks like spot was kind enough to pick it up, so no worries :)
I was still planning on retiring xmms. It has no upstream support. The volume control has issues that I don't have time to figure out.
On Wed, Feb 13, 2013 at 7:26 PM, Bruno Wolff III bruno@wolff.to wrote:
On Wed, Feb 13, 2013 at 21:21:41 -0500, Orcan Ogetbil oget.fedora@gmail.com wrote:
If the esound or pulseaudio plugins are problematic, let us retire them. I don't think xmms will be used by other people than us fanboys, and I feel that we are fine with the ALSA output.
Anyhow it looks like spot was kind enough to pick it up, so no worries :)
I was still planning on retiring xmms. It has no upstream support. The volume control has issues that I don't have time to figure out.
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
I found pavucontrol very useful to deal with the volume control issue. Thanks to rdieter for the help on that.
Thanks, Dan
On 02/14/2013 04:26 AM, Bruno Wolff III wrote:
On Wed, Feb 13, 2013 at 21:21:41 -0500, Orcan Ogetbil oget.fedora@gmail.com wrote:
If the esound or pulseaudio plugins are problematic, let us retire them. I don't think xmms will be used by other people than us fanboys, and I feel that we are fine with the ALSA output.
Anyhow it looks like spot was kind enough to pick it up, so no worries :)
I was still planning on retiring xmms. It has no upstream support. The volume control has issues that I don't have time to figure out.
esound can be disabled at build time - please do not retire it just yet. I can take it on if need be.
Orcan, can you confirm that it still works? This is not working for me here. http://koji.fedoraproject.org/koji/taskinfo?taskID=4971729
--- xmms.spec 2013-02-14 11:40:18.021243517 +0100 +++ /home/bsjones/rpmbuild/SPECS/xmms.spec 2013-02-14 11:39:42.377244852 +0100 @@ -1,6 +1,6 @@ Name: xmms Version: 1.2.11 -Release: 17.20071117cvs%{?dist} +Release: 18.20071117cvs%{?dist} Epoch: 1 Summary: The X MultiMedia System, a media player
@@ -70,14 +70,6 @@ Group: System Environment/Libra %description libs The X MultiMedia System player engine and core plugins.
-%package esd -Summary: EsounD output plugin for XMMS -Group: System Environment/Libraries -Requires: %{name}-libs = %{epoch}:%{version}-%{release} - -%description esd -EsounD output plugin for the X MultiMedia System. - %package devel Summary: Files required for XMMS plug-in development Group: Development/Libraries @@ -130,7 +122,8 @@ done --enable-texthack \ --enable-ipv6 \ --with-pic \ - --disable-static + --disable-static \ + --disable-esd # causes problems with dso linking #find . -name Makefile | xargs sed -i -e s/-lpthread//g # old libtool, x86_64 make @@ -212,10 +205,6 @@ update-desktop-database &>/dev/null || : %{_libdir}/xmms/Output/libdisk_writer.so %{_libdir}/xmms/Visualization/
-%files esd -%defattr(-,root,root,-) -%{_libdir}/xmms/Output/libesdout.so - %files devel %defattr(-,root,root,-) %{_bindir}/xmms-config @@ -226,6 +215,9 @@ update-desktop-database &>/dev/null || :
%changelog +* Thu Feb 14 2013 Brendan Jones brendan.jones.it@gmail.com 1.2.11-18.20071117cvs +- Disable esound plugin + * Sun Jul 22 2012 Fedora Release Engineering rel-eng@lists.fedoraproject.org - 1:1.2.11-17.20071117cvs - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
On Thu, Feb 14, 2013 at 13:33:27 +0100, Brendan Jones brendan.jones.it@gmail.com wrote:
On 02/14/2013 04:26 AM, Bruno Wolff III wrote:
I was still planning on retiring xmms. It has no upstream support. The volume control has issues that I don't have time to figure out.
esound can be disabled at build time - please do not retire it just yet. I can take it on if need be.
Do you want to apply as a co-maintainer to try it out?
On Thu, Feb 14, 2013 at 7:33 AM, Brendan Jones wrote:
On 02/14/2013 04:26 AM, Bruno Wolff III wrote:
I was still planning on retiring xmms. It has no upstream support. The volume control has issues that I don't have time to figure out.
esound can be disabled at build time - please do not retire it just yet. I can take it on if need be.
Orcan, can you confirm that it still works? This is not working for me here. http://koji.fedoraproject.org/koji/taskinfo?taskID=4971729
It works here. I can play my OGG files. What doesn't work there?
Orcan
On Wed, 13 Feb 2013 21:21:41 -0500, Orcan Ogetbil wrote:
While audacious can be made to look similar to xmms, it is not xmms,
True, and it doesn't try to duplicate XMMS anyway. It had only started as a fork of BMP. From its description:
| Historically, it started as a fork of Beep Media Player (BMP), which | itself forked from XMMS.
With emphasis on "historically" -- so much has been rewritten. That's good, because some of the inherited visualization code (especially for the scaled skinned mode) was really ugly with lots of stack-smashing and other forms of memory corruption.
and indeed they are very different from each other. xmms (with ALSA) is the only player that consistently worked for me with no problems for the last 11 years.
Consider yourself lucky. ;)
Moreover it uses the best (in my opinion) GTK version out there.
If the esound or pulseaudio plugins are problematic, let us retire them. I don't think xmms will be used by other people than us fanboys, and I feel that we are fine with the ALSA output.
The xmms-pulse tickets are all closed/wontfix. It might still be possible to copy fixes from Audacious' Pulse Audio output plugin (which had started with the same code base), but it could be that touching XMMS will also be necessary (with regard to saving/restoring volume levels).
If anyone thinks xmms-pulse works, oh well, keep it, but don't just keep it because it still builds. I assume that Lennart Poettering, the (original) author of that plug-in, could tell what's wrong with it nowadays.
Anyhow it looks like spot was kind enough to pick it up, so no worries :)
Already long ago.
On Tue, Feb 12, 2013 at 4:51 PM, Lennart Poettering mzerqung@0pointer.dewrote:
On Tue, 12.02.13 13:52, Jon Ciesla (limburgher@gmail.com) wrote:
So to clarify, you're not actually retiring anything currently, just expressing to the community that you'd like to and that we should
work
toward making that possible?
Well, I am just checking before I do something whether I can actually
do
it. That's all. By next week or so I will either have retired the packages (which I'd prefer) or somebody else took them over (which I'd prefer not to do, but which we can do too, if the retro-computing folks step up...)
I'd prefer that you orphan them, and mail the list, ccing <foo>-owner for each dependency, that you're doing so. That said, I maintain gnugb, and was able to easily remove the esound requirement. If no one else wants
to
maintain esound, I will, even if only long enough to excise it from the packages that need it.
OK, if that's what you want. I have now orphaned esound. Please take it over.
Thanks, but it looks like someone beat me to it.
-J
Lennart
-- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Jon Ciesla wrote:
That said, I maintain gnugb, and was able to easily remove the esound requirement.
What sound output options does that leave? I see only arts-devel in the BuildRequires list, and that's actually worse than esound, because it requires running another sound server from KDE 3 era on top of PulseAudio (which gets autospawned, but it unnecessarily eats resources), whereas the ESD protocol is emulated by PulseAudio.
I'd suggest dropping arts support (to squelch dependency bloat) and reenabling esound now that it got picked up (unless there's ALSA support which works with the PulseAudio ALSA plugin, then you can drop both arts and esound).
Kevin Kofler
On Tue, Feb 12, 2013 at 1:34 PM, Lennart Poettering wrote:
I'd also like to retire "esound" finally. Currently, adplay, ayttm, dopewars, e16, gnome-libs, gnubg, lxdream, moon-buggy, spacechart, xarchon, xmms-esd still use it.
Most of these projects if not all are dead upstream but for now, I have disabled esd support in ayttm and adplay. I will take a look at others when I find time.
Rahul
Please can we test this on rawhide first if anything? I'm pretty sure a lot of thing are still ck dependant. We are still trying to catch up to systemd.
Just because some other distro did it doesn't mean we should do it too.
Dan
On Tuesday, February 12, 2013, Lennart Poettering wrote:
Heya,
since a while now logind has replaced CK in Fedora. I'd like to retire it entirely from the distribution now.
Most deps on CK are gone. Holdouts are "cdm", "lightdm", "lxsession", "lxdm".
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
This page doesn't say anything about retiring packages other still depend on...
I am tempted to just retire CK ignoring the remaining dependencies, in the hope this will put the pressure on the folks involved to update their stuff...
Getting rid of CK in those packages is dead simple BTW. Just disable it in the packages, but make sure pam_systemd is in the PAM stack for your greeter tool. It's basically about removing code, not about adding new code -- adding new code is only necessary if you want to improve your DM to handle multi-seat setups, too (which is a new feature of logind, not available in CK[1]). For details, see:
http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers
I'd also like to retire "esound" finally. Currently, adplay, ayttm, dopewars, e16, gnome-libs, gnubg, lxdream, moon-buggy, spacechart, xarchon, xmms-esd still use it. esd of course has been deprecated and dead since many years, the packages which still use it really should wake up one day. So here, too, I'd just like to retire the package...
Alternatively, somebody else can take these over, but honstely I'd rather see them removed than continue to bitrot in our repository...
Lennart
Footnotes:
[1] If you are interested in adding proper multi-seat support to the DM of your choice, then we might be able to supply you with a free set of multi-seat hardware so that you can actually make it work. Ping me.
-- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org javascript:; https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, Feb 13, 2013 at 10:44 AM, Dan Mashal dan.mashal@gmail.com wrote:
Please can we test this on rawhide first if anything? I'm pretty sure a lot of thing are still ck dependant. We are still trying to catch up to systemd.
Just because some other distro did it doesn't mean we should do it too.
Retirement of packages really only should ever happen on rawhide and I believe that's what is being discussed.
Peter
On Wed, 13.02.13 02:44, Dan Mashal (dan.mashal@gmail.com) wrote:
Please can we test this on rawhide first if anything? I'm pretty sure a lot of thing are still ck dependant. We are still trying to catch up to systemd.
So, in contrast to the esound discussion I do not sense too much opposition to me just retiring CK. So I'd probably do that in Rawhide next week or so. CK would hence disappear in F19, but would give everybody time until the branch or freeze or so to fix their packages...
Lennart
On Feb 13, 2013 10:58 AM, "Lennart Poettering" mzerqung@0pointer.de wrote:
On Wed, 13.02.13 02:44, Dan Mashal (dan.mashal@gmail.com) wrote:
Please can we test this on rawhide first if anything? I'm pretty sure a
lot
of thing are still ck dependant. We are still trying to catch up to
systemd.
So, in contrast to the esound discussion I do not sense too much opposition to me just retiring CK. So I'd probably do that in Rawhide next week or so. CK would hence disappear in F19, but would give everybody time until the branch or freeze or so to fix their packages...
Lennart
-- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Sorry if I sound ignorant but:
No. I meant fedora 20 rawhide. What is the problem with keeping it?
Are we just trying to break something different every time we release a new version of Fedora?
Regardless, do you know exactly what depends on consolekit and what doesn't? Have you gone through every package?
If so, great but my main question is who is it hurting right now? Let's spend some more time to plan doing something like this. Again, just because other distros do it is not a good enough reason.
Dan
On Wed, 13.02.13 12:58, Dan Mashal (dan.mashal@gmail.com) wrote:
Sorry if I sound ignorant but:
No. I meant fedora 20 rawhide. What is the problem with keeping it?
There is no Fedora 20 rawhide.
I don't want to maintain it, and I want to put the pressure on the few holdouts to finally port things over.
Are we just trying to break something different every time we release a new version of Fedora?
Yes, of course. We are inherently evil people, who just hate other people. We have no interest in making Fedora better, and are exclusively lead by our deepest interest to make everybody's lifes as miserable as we can.
Regardless, do you know exactly what depends on consolekit and what doesn't? Have you gone through every package?
Please go back to mail #1 of this thread, thank you.
If so, great but my main question is who is it hurting right now? Let's spend some more time to plan doing something like this. Again, just because other distros do it is not a good enough reason.
What do other distros have to do with this? It's *my* intention to get rid of CK, I am upstream of it, and downstream too.
I will retire this next week, unless somebody steps up to take it over pretty soon who really thinks his time is better spent on CK rather then just fixing the remaining packages which use it (and as mentioned, exorcising CK from packages is rather simple usually, as in most cases you will just delete code, not add new code).
Lennart
Lennart Poettering wrote:
There is no Fedora 20 rawhide.
There will be one in less than 4 weeks.
(and as mentioned, exorcising CK from packages is rather simple usually, as in most cases you will just delete code, not add new code).
I don't think that's true. As far as I know, LightDM relies on ConsoleKit for some essential functionality, and upstream has zero interest in systemd given that they're Ubuntu. So there is one person at Fedora / Red Hat who is trying to port it to systemd all alone, he's not done yet. I don't know what the state of the other affected packages is, but I assume there's also more to do than just disabling ConsoleKit support or it would have been already done (as we did for KDM long ago). For example, if a desktop (or even a display manager, like LightDM) wants to use ConsoleKit for shutdown/restart or, worse (in terms of porting effort), user switching, this all has to be ported to systemd, not just disabled.
I agree that ConsoleKit needs to go away, but FIRST all packages using it must be ported away from it, THEN it can be retired.
Kevin Kofler
On Thu, 14.02.13 04:02, Kevin Kofler (kevin.kofler@chello.at) wrote:
(and as mentioned, exorcising CK from packages is rather simple usually, as in most cases you will just delete code, not add new code).
I don't think that's true. As far as I know, LightDM relies on ConsoleKit for some essential functionality, and upstream has zero interest in systemd given that they're Ubuntu.
Well, subscribing to systemd-devel for a while and asking a number of questions (which the lightdm upstream did) is hardly "zero interest".
So there is one person at Fedora / Red Hat who is trying to port it to systemd all alone, he's not done yet. I don't know what the state of the other affected packages is, but I assume there's also more to do than just disabling ConsoleKit support or it would have been already done (as we did for KDM long ago). For example, if a desktop (or even a display manager, like LightDM) wants to use ConsoleKit for shutdown/restart or, worse (in terms of porting effort), user switching, this all has to be ported to systemd, not just disabled.
I agree that ConsoleKit needs to go away, but FIRST all packages using it must be ported away from it, THEN it can be retired.
Well, that's a pity, but I guess the burden for this really should be carried by the lightdm folks then. So, lightdm folks, if you want to keep CK around, then you need to step up, and take it over.
If I hear nothing but "oh, oh, i think, oh, i think", then I will retire it next week.
Lennart
On Wed, Feb 13, 2013 at 8:09 PM, Lennart Poettering mzerqung@0pointer.de wrote:
On Thu, 14.02.13 04:02, Kevin Kofler (kevin.kofler@chello.at) wrote:
(and as mentioned, exorcising CK from packages is rather simple usually, as in most cases you will just delete code, not add new code).
I don't think that's true. As far as I know, LightDM relies on ConsoleKit for some essential functionality, and upstream has zero interest in systemd given that they're Ubuntu.
Well, subscribing to systemd-devel for a while and asking a number of questions (which the lightdm upstream did) is hardly "zero interest".
So there is one person at Fedora / Red Hat who is trying to port it to systemd all alone, he's not done yet. I don't know what the state of the other affected packages is, but I assume there's also more to do than just disabling ConsoleKit support or it would have been already done (as we did for KDM long ago). For example, if a desktop (or even a display manager, like LightDM) wants to use ConsoleKit for shutdown/restart or, worse (in terms of porting effort), user switching, this all has to be ported to systemd, not just disabled.
I agree that ConsoleKit needs to go away, but FIRST all packages using it must be ported away from it, THEN it can be retired.
Well, that's a pity, but I guess the burden for this really should be carried by the lightdm folks then. So, lightdm folks, if you want to keep CK around, then you need to step up, and take it over.
If I hear nothing but "oh, oh, i think, oh, i think", then I will retire it next week.
Lennart
-- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Lennart,
Not knowing too much about CK itself but out of concern for anyone that uses CK (including myself) I will be happy to take over ConsoleKit as the package maintainer for F19 if it means keeping it in for 1 more release to maintain compatibility. F19 will be branched shortly and we will have F20 rawhide shortly which we can completely retire ConsoleKit with plenty of notice to package maintainers and upstream developers.
If all goes well we might even be able to completely retire it in 19.
What you are saying is true. There is interest from LightDM folks to support systemd. However, as you know we move very fast here.
I will look at switching MATE Desktop to KDM or MDM if necessary (which I kind of wanted to do from the start, not the hugest fan of LightDM as a user personally).
I have already done work on looking in to packaging MDM (formerly known as mate-display-manager). MDM is maintained by the folks at Linux Mint and is a fork of GDM 2.3 (surprise!).
https://github.com/linuxmint/mdm
Thanks, Dan
On Thu, 14.02.13 03:26, Dan Mashal (dan.mashal@gmail.com) wrote:
Not knowing too much about CK itself but out of concern for anyone that uses CK (including myself) I will be happy to take over ConsoleKit as the package maintainer for F19 if it means keeping it in for 1 more release to maintain compatibility.
That's the spirit! "I don't know too much about it, but I want to maintain it"...
But anyway, if that is indeed your wish, then I can hand it over. But please, don't let this stuff bitrot forever. That would help nobody. If you want to take care of it, fine, but please make sure the remaining packages using it get their stuff updated and fixed...
What I want is that "yum distro-sync" removes the package eventually.
Anyway, I will release the Rawhide/F19 version now in pkgdb, please take possession of it. It's yours now.
Lennart
On 02/14/2013 06:16 PM, Lennart Poettering wrote:
On Thu, 14.02.13 03:26, Dan Mashal (dan.mashal@gmail.com) wrote:
Not knowing too much about CK itself but out of concern for anyone that uses CK (including myself) I will be happy to take over ConsoleKit as the package maintainer for F19 if it means keeping it in for 1 more release to maintain compatibility.
That's the spirit! "I don't know too much about it, but I want to maintain it"...
Your arrogance never ceases to amaze.
But anyway, if that is indeed your wish, then I can hand it over. But please, don't let this stuff bitrot forever. That would help nobody. If you want to take care of it, fine, but please make sure the remaining packages using it get their stuff updated and fixed...
I'm sure the new maintainer can handle the dependencies
On Thu, Feb 14, 2013 at 9:16 AM, Lennart Poettering mzerqung@0pointer.de wrote:
On Thu, 14.02.13 03:26, Dan Mashal (dan.mashal@gmail.com) wrote:
Not knowing too much about CK itself but out of concern for anyone that uses CK (including myself) I will be happy to take over ConsoleKit as the package maintainer for F19 if it means keeping it in for 1 more release to maintain compatibility.
That's the spirit! "I don't know too much about it, but I want to maintain it"...
But anyway, if that is indeed your wish, then I can hand it over. But please, don't let this stuff bitrot forever. That would help nobody. If you want to take care of it, fine, but please make sure the remaining packages using it get their stuff updated and fixed...
What I want is that "yum distro-sync" removes the package eventually.
Anyway, I will release the Rawhide/F19 version now in pkgdb, please take possession of it. It's yours now.
Lennart
-- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
I have taken ownership of ConsoleKit for Fedora 19.
Thanks, Dan
On Thu, 14 Feb 2013 18:16:56 +0100, Lennart Poettering wrote:
What I want is that "yum distro-sync" removes the package eventually.
Then it will need an "Obsoletes" tag somewhere else to get rid of any installed CK packages.
"yum distro-sync" doesn't remove orphans. It only upgrades/downgrades packages as necessary to match what's in the repos.
For an up-to-date installation, "package-cleanup --orphans" and "yum list extras" show which installed packages are not available in any repo. Users would need to uninstall them manually.
On Fri, Feb 15, 2013 at 11:27 AM, Michael Schwendt mschwendt@gmail.com wrote:
On Thu, 14 Feb 2013 18:16:56 +0100, Lennart Poettering wrote:
What I want is that "yum distro-sync" removes the package eventually.
Then it will need an "Obsoletes" tag somewhere else to get rid of any installed CK packages.
We could / should add one to systemd.
drago01 wrote:
On Fri, Feb 15, 2013 at 11:27 AM, Michael Schwendt mschwendt@gmail.com wrote:
On Thu, 14 Feb 2013 18:16:56 +0100, Lennart Poettering wrote:
What I want is that "yum distro-sync" removes the package eventually.
Then it will need an "Obsoletes" tag somewhere else to get rid of any installed CK packages.
We could / should add one to systemd.
We should only do that when ConsoleKit actually gets retired! As long as something still needs it, please DON'T Obsolete it!
Kevin Kofler
Dan Mashal wrote:
I will look at switching MATE Desktop to KDM or MDM if necessary (which I kind of wanted to do from the start, not the hugest fan of LightDM as a user personally).
As much as I like KDM, I don't think it'd be the optimal choice for the MATE spin due to its dependencies (Qt and kdelibs).
Kevin Kofler
On Thu, Feb 14, 2013 at 7:06 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Dan Mashal wrote:
I will look at switching MATE Desktop to KDM or MDM if necessary (which I kind of wanted to do from the start, not the hugest fan of LightDM as a user personally).
As much as I like KDM, I don't think it'd be the optimal choice for the MATE spin due to its dependencies (Qt and kdelibs).
Kevin Kofler
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Rex said the same thing, but I don't really care. It pulls in a few extra KDE packages but it works like a charm.
Either way It's not that big of a deal, let's see what happens with LightDM or MDM first. KDM would be a last resort.
Thanks, Dan
On Wed, Feb 13, 2013 at 7:02 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Lennart Poettering wrote:
There is no Fedora 20 rawhide.
There will be one in less than 4 weeks.
(and as mentioned, exorcising CK from packages is rather simple usually, as in most cases you will just delete code, not add new code).
I don't think that's true. As far as I know, LightDM relies on ConsoleKit for some essential functionality, and upstream has zero interest in systemd given that they're Ubuntu. So there is one person at Fedora / Red Hat who is trying to port it to systemd all alone, he's not done yet. I don't know what the state of the other affected packages is, but I assume there's also more to do than just disabling ConsoleKit support or it would have been already done (as we did for KDM long ago). For example, if a desktop (or even a display manager, like LightDM) wants to use ConsoleKit for shutdown/restart or, worse (in terms of porting effort), user switching, this all has to be ported to systemd, not just disabled.
I agree that ConsoleKit needs to go away, but FIRST all packages using it must be ported away from it, THEN it can be retired.
Kevin Kofler
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
This was exactly my point.
MATE Desktop being dependent on LightDM in Fedora (that can possibly be changed).
However if LightDM had full systemd/logind support then I'm all for it.
Correct me if I'm wrong, but I believe XFCE, LXDE and MATE all use LightDM and I think there were plans to get rid of KDM on KDE in favor of LightDM as well.
Thanks, Dan
Le mercredi 13 février 2013 à 12:58 -0800, Dan Mashal a écrit :
On Feb 13, 2013 10:58 AM, "Lennart Poettering" mzerqung@0pointer.de wrote:
On Wed, 13.02.13 02:44, Dan Mashal (dan.mashal@gmail.com) wrote:
Please can we test this on rawhide first if anything? I'm pretty
sure a lot
of thing are still ck dependant. We are still trying to catch up
to systemd.
So, in contrast to the esound discussion I do not sense too much opposition to me just retiring CK. So I'd probably do that in
Rawhide
next week or so. CK would hence disappear in F19, but would give everybody time until the branch or freeze or so to fix their
packages...
Lennart
-- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Sorry if I sound ignorant but:
No. I meant fedora 20 rawhide. What is the problem with keeping it?
Are we just trying to break something different every time we release a new version of Fedora?
Regardless, do you know exactly what depends on consolekit and what doesn't? Have you gone through every package?
That's a valid concern. While the list of packages requiring consolekit are quite small ( ie, 3 packages, 1 being a shell script with support to disable ck ), we cannot really check those using the dbus interface in a exhaustive way.
However, I have already removed consolekit on my F18 without any notable issue, so I do not think any breakage would be blocking. We have the whole F19 cycle to find and detect the few packages needing fix.
On Wed, Feb 13, 2013 at 11:38:42PM +0100, Michael Scherer wrote:
However, I have already removed consolekit on my F18 without any notable issue, so I do not think any breakage would be blocking. We have the whole F19 cycle to find and detect the few packages needing fix.
Is this the kind of thing that would have been better done as a feature, similar to the Usermode Migration feature?
----- Original Message -----
On Wed, Feb 13, 2013 at 11:38:42PM +0100, Michael Scherer wrote:
However, I have already removed consolekit on my F18 without any notable issue, so I do not think any breakage would be blocking. We have the whole F19 cycle to find and detect the few packages needing fix.
Is this the kind of thing that would have been better done as a feature, similar to the Usermode Migration feature?
This is really just the tail end of a migration that has largely already happened. Writing a feature for it now would be a little late, imo.
But what I really wanted to say is: thanks for seeing this through to the end, Lennart. Too often we don't complete these transitions, and then the remnants of old, half-broken infrastructure linger forever... In the place of ConsoleKit, /etc/X11/xinitrc-common is such a place - we should remove the mentions of ck-xinit-session from there for F19.
Matthias
On Wed, 13.02.13 17:50, Matthew Miller (mattdm@fedoraproject.org) wrote:
On Wed, Feb 13, 2013 at 11:38:42PM +0100, Michael Scherer wrote:
However, I have already removed consolekit on my F18 without any notable issue, so I do not think any breakage would be blocking. We have the whole F19 cycle to find and detect the few packages needing fix.
Is this the kind of thing that would have been better done as a feature, similar to the Usermode Migration feature?
It is an (accepted) feature:
https://fedoraproject.org/wiki/Features/ckremoval
I am just looking to do the final step, to kill the beast entirely.
Lennart
On Thu, Feb 14, 2013 at 12:34:35AM +0100, Lennart Poettering wrote:
It is an (accepted) feature: https://fedoraproject.org/wiki/Features/ckremoval
Huh. That (Fedora 17 feature) says 100% complete.
I am just looking to do the final step, to kill the beast entirely.
So, 110%. :)
Mind you, I have no attachment to ConsoleKit. I'd just like to see changes with the potential for end-user impact go through some low-barrier form of change management. I don't know if this reasonably rises to that level or not; my origial question was (and remains) serious, not rhetorical.
In reading the F17 feature and the associated discussion page, it looks like the actual final state of that was that the multi-seat portion was implemented but the "ckremoval" portion wasn't completed, and that there was no particular effort around non-Gnome desktops except documentation. So, it's that last bit you're completing now, as I understand it.
I notice that there's a lot of documentation at user forums around using ck-launch-session in ~/.xinitrc. We should probably at least release-notes that.
On Wed, 13.02.13 19:13, Matthew Miller (mattdm@fedoraproject.org) wrote:
On Thu, Feb 14, 2013 at 12:34:35AM +0100, Lennart Poettering wrote:
It is an (accepted) feature: https://fedoraproject.org/wiki/Features/ckremoval
Huh. That (Fedora 17 feature) says 100% complete.
I am just looking to do the final step, to kill the beast entirely.
So, 110%. :)
Mind you, I have no attachment to ConsoleKit. I'd just like to see changes with the potential for end-user impact go through some low-barrier form of change management. I don't know if this reasonably rises to that level or not; my origial question was (and remains) serious, not rhetorical.
In reading the F17 feature and the associated discussion page, it looks like the actual final state of that was that the multi-seat portion was implemented but the "ckremoval" portion wasn't completed, and that there was no particular effort around non-Gnome desktops except documentation. So, it's that last bit you're completing now, as I understand it.
Well, the goal of the feature was just getting it out of the default install, and that we completed. Now I am building on that and want to remove it entirely. This is then more than one year after we implemented the original feature. I think that should be enough time for the packagers to wake up under their rocks...
I notice that there's a lot of documentation at user forums around using ck-launch-session in ~/.xinitrc. We should probably at least release-notes that.
Well, sure, if that's what it takes...
Lennart
Matthew Miller wrote:
In reading the F17 feature and the associated discussion page, it looks like the actual final state of that was that the multi-seat portion was implemented but the "ckremoval" portion wasn't completed, and that there was no particular effort around non-Gnome desktops except documentation.
There was work done by KDE SIG too. No KDE stuff depends on ConsoleKit anymore (I wrote the patch to port kde-workspace's support for shutdown, restart and user switching without KDM from ConsoleKit to systemd), and ConsoleKit is not on the KDE spin.
Kevin Kofler
On Wed, Feb 13, 2013 at 11:50 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Feb 13, 2013 at 11:38:42PM +0100, Michael Scherer wrote:
However, I have already removed consolekit on my F18 without any notable issue, so I do not think any breakage would be blocking. We have the whole F19 cycle to find and detect the few packages needing fix.
Is this the kind of thing that would have been better done as a feature, similar to the Usermode Migration feature?
Per https://fedoraproject.org/wiki/Features/Policy/Definitions#Definition_of_a_F... item #2, I think so. It would also have ensured that the release note won't be forgotten about.
(I can't really buy that https://fedoraproject.org/wiki/Features/ckremoval automatically applies to F19 - and the feature page is rather unclear on whether ConsoleKit was actually planned to be removed in F17. It's really not obvious from the feature page that it was "only" not installed by default.) Mirek
On 13 Feb 2013 22:50, "Matthew Miller" mattdm@fedoraproject.org wrote:
On Wed, Feb 13, 2013 at 11:38:42PM +0100, Michael Scherer wrote:
However, I have already removed consolekit on my F18 without any notable issue, so I do not think any breakage would be blocking. We have the whole F19 cycle to find and detect the few packages needing fix.
Is this the kind of thing that would have been better done as a feature, similar to the Usermode Migration feature?
It was a feature back about f17 (search for ckremoval) and the remaining are the packages are ones that didn't adhere. This has been planned and discussed for a number of releases maybe as far back as f15 so maintainers need to step up and deal with it.
Peter