Bug 310811
Summary: | sound is broken - should be f8 blocker!! | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | John Ellson <john.ellson> |
Component: | gnome-media | Assignee: | Bastien Nocera <bnocera> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | urgent | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | davidz, notting |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-09-28 15:21:57 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
John Ellson
2007-09-28 13:01:20 UTC
Is SELinux running? Do applications other than system-config-soundcard run when run as root? selinux is in permissive mode of apps as root? I've not noticed any problems. e.g. yum, yumex are ok. I meant applications that use sound. I figured the rest was working. Ah, sorry, yes OK. Running gnome-volume-control as root seems to work, enabling aux input allows sound from tvtime running as root. David, what was the bug number for the problem with not setting sound device nodes permissions properly? It seems I should have added Console-Kit* to the above list! Who knew!! Console-kit wasn't running. I'm still astounded by the complexity and the near impossibility for a regular user to debug sound problems, and by the churn in in the packages related to sound, but in this case the problem seems to be caused by me disabling Console-Kit. Sorry. re#5 #310721 perhaps? I closed that one too as not-a-bug. This bug is closed but there's an interesting bit here we may want to look at: We really need to fix the OS so users don't randomly turn off critical system services and then expect the system to work. And when it doesn't then bugs are filed and that eats up developer time. We can't really blame such users; after all we provide system-config-services and there's little or no hint that service XYZ is a critical part of the (desktop) OS or whether it's something that can be turned off. Users are left to experiment and then sometimes files bogus bugs resulting in developer time being wasted (I mean no offense John) . So perhaps we should look at starting identify what the critical services are and then moving them to rc.sysinit? Bill, what are your thoughts? Also, the error messages from programs like gnome-volume-control could be improved if an essential service is missing. It doesn't help that the <F1> key in ntsysv doesn't work as advertised. Nor that other new daemons like NetworkManager totally break previously working configurations. OK, OK, I guess this isn't the place for a general laundry list. Just add my +1 to comment #8. (In reply to comment #9) > Also, the error messages from programs like gnome-volume-control could be > improved if an essential service is missing. Feel free to file a bug, and I'll look into improving the error message for this program. A good use of your time would be to go through all the default installed programs that use sound and file bugs for those with error messages that aren't so useful. Hm, I suppose CK isn't really a good candidate for system activation, as it relies on login state that it won't have if it's activated later. Or can the PAM module activate it? If we move to system activation for some of these services, it makes it harder to fall into that trap. (In reply to comment #11) > Hm, I suppose CK isn't really a good candidate for system activation, as it > relies on login state that it won't have if it's activated later. Or can the PAM > module activate it? Possibly. > If we move to system activation for some of these services, it makes it harder > to fall into that trap. I'm saying that critical services for the desktop that can't be activated such as dbus-daemon --system ConsoleKit hald NetworkManager avahi cups ought to be started from /etc/rc.sysinit (just like udevd is). Anything else (such as Bluetooth daemon, smartd etc.) should be started only when the hardware is detected or when it's used (ideally we'd move cups to that too) using udev or hal. (As a side-effect, the set of initscripts needed for a desktop system would rapidly approach zero. We probably wouldn't boot any faster though.) |