Current state of gnome volume control/manager seems completely problematic in Gnome. Non-super-user login (with superuser privs). 1) Click on old Gnome "Volume Control" panel applet ==> ERROR 1. 2) gnome-control-center -> Volume Control ==> ERROR 2. ERROR 1: The volume control did not find any elements and/or devices to control. This means either that you don't have the right GStreamer plugins installed, or that you don't have a sound card configured. ERROR 2: No volume control GStreamer plugins and/or devices found. Reproducible: Always Steps to Reproduce: 1. Try to change the volume as a non-SU user. Actual Results: All sorts of errors suggesting things are not configured correctly. Expected Results: Volume control should work as well or better than in the past. gnome-volume-manager 2.24.1 USE: consolekit debug gnome-control-center 2.30.1 USE: debug policykit -eds gnome-media 2.30.0-r1 USE: -pulseaudio
Created attachment 244419 [details] Entire .gnomerc-errors file from session Critical ".gnomerc-errors" involving "volume": (gnome-settings-daemon:3092): GVFS-RemoteVolumeMonitor-WARNING **: invoking IsSupported() failed for remote volume monitor with dbus name org.gtk.Private.GduVolumeMonitor: org.freedesktop.DBus.Error.Spawn.ChildSignaled: Process /usr/libexec/gvfs-gdu-volume-monitor received signal 6 (gnome-panel:3098): GVFS-RemoteVolumeMonitor-WARNING **: invoking IsSupported() failed for remote volume monitor with dbus name org.gtk.Private.GduVolumeMonitor: org.freedesktop.DBus.Error.Spawn.ChildSignaled: Process /usr/libexec/gvfs-gdu-volume-monitor received signal 6 (nautilus:3104): GVFS-RemoteVolumeMonitor-WARNING **: invoking IsSupported() failed for remote volume monitor with dbus name org.gtk.Private.GduVolumeMonitor: org.freedesktop.DBus.Error.Spawn.ChildSignaled: Process /usr/libexec/gvfs-gdu-volume-monitor received signal 6
Created attachment 244421 [details] emerge --info
Same operations as "root" DO work. I.e. the gnome-panel volume control gives you a "master volume" slider and the gnome-control-center -> Volume Control gives you an standard alsamixer window. So the sound devices and drivers are properly configured. What doesn't work is the same configuration for non-root. (The configurations for root and non-root are identical as problems involving the Multiload applet and reconfiguring the gnome-panel [to-be-filed] forced me to copy the root .gconf to the non-root .gconf this morning.) The only "caveat" is that this is a multi-year old configuration and if 2.30 isn't handling reconfiguring it properly problems may be present.
I don't understand why are you getting so many errors and problems :-/, I can also see dbus, policykit, seamonkey errors...
Pacho, I think part of the problem is that this is a *very* old Gentoo installation (5 years this October). My newer Gentoo installation (< 6mo) seems much less problematic -- though its on AMD64 and doesn't have anywhere near the number of packages installed that the older X86 does. The Gnome profiles for the two primary users (root & bradbury) are also old (though they have been deleted/modified it may be reasonable to assume they have elements predating Gnome 2.28 or even 2.26). I think a primary source of the problem may be the development and installation of both "dbus" and "policykit". These took place on top of systems which never had these "features/handicaps". So one is fighting a battle where the added features may serve some population subset -- but are not needed/wanted in single machine/manager/owner - multiple ID situation [1] (i.e. most desktops / laptops). Years ago (circa 2005-2007) I believe I had many fewer problems with Gnome and its related functions. So I would think that the problem is a failure of gnome upgrades to retrofit both the system and or individual user configurations to function properly. But I know from experience that the current gnome upgrade path (esp. gnome-panel) are going to be problematic when switching from the "classical" top/bottom panels to the side panels (or multiple panels) being driven by wide screens and indirectly by Mark/Ubuntu. It is very easy to drive gnome-panel into heavy CPU use and unresponsiveness simply by adding panels or configuring them "non-classically" --- but that is a separate bug. [But I have watched a valid Gnome-panel addition [the panel multiload-applet-2] "disappear" from the panel (while I have been entering this bug report). So I've got the gnome panel upon which id did appear. I've got the multiload-applet-2 for root running (as evidenced by ps and accumulating CPU time). But I *do* not have that output appearing on the top of the screen as was the case 30+ minutes ago. And the only core in "/" is for "gvfs-gdu-volume-monitor") Note that this is not a "strange" PC. Its a pretty standard HP PC with some added memory and some added drives. And unusual behaviour of software didn't generally exist before Linux 2.6.34 (though I am not blaming Linux) 1. The only reason for multiple IDs on this machine is to a) potentially test multiple session types (e.g. Gnome vs. OpenStep vs. FVWM [Gnome is getting very "top-heavy"]) -- something I've never (in 5 years) been able to configure for testing even though the software is installed. b) Maintain multiple "work instance environments" -- generally for when a desktop manager (e.g. Gnome/KDE) + a browser (Firefox/Seamonkey/Opera/Chrome -- which are all "desktop/session clueless") cannot be guaranteed to always return one to a "former state" (e.g. completely separate but functional "Professional/Personal/Research/Whatever" states. One of course has session aware browsers like epiphany but they don't offer the functionality/plugins that Firefox/Seamonkey/Chrome offer [NoScript & AdBlock are non-negotiables IMO]. c) Protection from oneself -- any user can sometimes make mistakes and it is desirable to have User-ID firewalls to prevent "rm -fr *" from spreading too far. For example I don't want a mistake in the
Well, my development system is from 2005 July and works ok, I would suggest you to do the following: 1. Switch to gnome profile, default/linux/amd64/10.0/desktop/gnome will get you the safest defaults 2. Get rid of cruft in /etc/portage/package.use and leave profile choose default USE flags when possible. 3. Check you are not mixing testing with stable packages minimizing entries in /etc/portage/package.keywords 4. Run stable gclibc and basesystem (Really, really important if you don't want to suffer strange issues. 5. Check -march=prescott is the proper setting for your pentium 4 machine (maybe you could consider -march=native usage) 6. Be sure elog messages are being saved in a place you can read easily after installing, for example, I have the following lines on my /etc/make.conf: PORTAGE_ELOG_CLASSES="warn error log qa" PORTAGE_ELOG_SYSTEM="save_summary" 7. Rebuild your system: emerge -e world && emerge -a --depclean (remember to review the list) && lafilefixer --justfixit && revdep-rebuild && dispatch-conf 8. And probably the most important step: Read *all* messages recorded in /var/log/portage/elog/summary.log following its instructions to properly update your system (for example, you will need to run some "specific" revdep-rebuild commands to properly update gnome-desktop and others) 9. Create a new and fresh user account that you will be able to use for checking when you are suffering a "configuration" problem or not (it will also help you yo isolate the wrong config) Good luck!
Feel free to reopen if still valid after following that recommendations. Good luck!
See Bug #331543 Comment #8 and Bug #334321 Comment #5.
