Suspending (to ram) due to gnome-power-manager ordering it (either via tray icon click or lid close or whatever) has been working fine for quite a while now. Today it stopped working. Co-incident with this is that one of the many things that changed yesterday as a result of `emerge -Du world` is that gnome-power-manager was upgraded from 2.20.0-r1 to 2.20.2. Nothing to speak of in the logs. The syslog just gives: Jan 13 17:56:34 moonglow gnome-power-manager: (andrew) Suspending computer because clicked tray Jan 13 17:56:34 moonglow gnome-power-manager: (andrew) Resuming computer ie, nada other than telling me it's no-op'ing, and running in the foreground with `gnome-power-manager --no-daemon --verbose` doesn't give much else: ... [gpm_tray_icon_suspend_cb] gpm-tray-icon.c:235 (18:04:06): emitting suspend [gpm_inhibit_has_inhibit] gpm-inhibit.c:336 (18:04:06): Valid as no inhibitors Saving to syslog: Suspending computer because clicked tray[gpm_info_event_log] gpm-info.c:591 (18:04:06): Adding 5 to the event log [gpm_control_get_lock_policy] gpm-control.c:386 (18:04:06): Using ScreenSaver settings (0) [gpm_control_suspend] gpm-control.c:439 (18:04:06): emitting sleep ** (gnome-power-manager:10786): WARNING **: Method failed (No suspend method found) [gpm_control_suspend] gpm-control.c:447 (18:04:06): emitting resume [gpm_backlight_sync_policy] gpm-backlight.c:159 (18:04:06): choosing sensible default [gpm_backlight_sync_policy] gpm-backlight.c:161 (18:04:06): laptop, so use GPM_DPMS_METHOD_OFF [gpm_backlight_sync_policy] gpm-backlight.c:193 (18:04:06): BACKLIGHT parameters 0 0 1800, method '4' [x11_sync_server_dpms_settings] gpm-dpms.c:130 (18:04:06): Syncing DPMS settings enabled=1 timeouts=0 0 0 Saving to syslog: Resuming computer[gpm_info_event_log] gpm-info.c:591 (18:04:06): Adding 7 to the event log ... etc Of I could figure out where the hell the "method failed" is coming from presumably I could dig further, but not sure. Nothing in dmesg. I'll be in #gentoo-desktop as usual if someone thinks they have an idea and wants me to try something. AfC
hal-system-power-suspend-linux in /usr/lib/hal/scripts/linux contains the suspect "No suspend method found" string. Now to figure out why Gentoo's upgrade of HAL decided to stop being able to suspend to ram. A note in an Ubuntu forum indicated that this was very much a distro specific issue. AfC
Some detective work turned up that /usr/sbin/pm-suspend was what was being checked for by hal 0.5.10's scripts, and that isn't present. Thanks to Donnie, who suggested that this belonged to sys-power/pm-utils. He then noticed that hal has a USE=laptop flag that pulls this in as a dependency. USE=laptop is, I must confess, a new one on me. AfC
11:54 < EvaSDK> AfC: anyway is it working with pm-utils ? 12:10 < AfC> EvaSDK: yeah, it did 12:11 < EvaSDK> ok to close or just reassigning to compnerd/steev ? 12:11 < AfC> EvaSDK: and I agree. That USE flag (at least so far as driving the dependency on pm-utils) is a bit odd. More to the point, there needs to be an upgrade path for people who have never heard of that USE flag before and don't (yet) have it in their /etc/make.conf 12:11 < EvaSDK> it's just a bunch of scripts 12:12 < AfC> EvaSDK: I would encourage it to remain open and be reassigned to whomever might be able to work out the upgrade path. 12:12 < EvaSDK> if you have gnome, I don't see why you wouldn't want them so guys, what's your ideas on the upgrade path front ?
I see there is an einfo now. Would it make sense to make laptop an IUSE default as well or the einfo is considered enough to solved this bug ? (hint: next comment should probably be closed fixed with the answer to the previous question, don't make it wait another 4 months)
Sorry that our time schedules don't match yours. If you don't like 4 months time tough. Some of us have real jobs, we do real work, to put real food on our tables. The einfo is considered enough.
