Updating from gnome-session 2.26.2-r1 to 2.28.0 adds a new devicekit-power dependency. In turn that adds CONFIG_ACPI_SYSFS_POWER as a requirement. First observation: my desktop system is perfectly happy without CONFIG_ACPI_... Why does devicekit-power need it? Second observation; the gnome-session 2.28.0 ebuild has the following: >=x11-libs/startup-notification-0.9 || ( >=sys-apps/devicekit-power-008 sys-power/upower ) which I understand to mean that devicekit-power is needed if startup-notification is older than 0.9. I have startup-notification-0.10 installed, so why is emerge pulling in devicekit-power?
Created attachment 230093 [details] emerge --info
(In reply to comment #0) > Updating from gnome-session 2.26.2-r1 to 2.28.0 adds a new devicekit-power > dependency. In turn that adds CONFIG_ACPI_SYSFS_POWER as a requirement. I don't have it either. > First observation: my desktop system is perfectly happy without > CONFIG_ACPI_... Why does devicekit-power need it? what do you mean by needing? > Second observation; the gnome-session 2.28.0 ebuild has the following: > >=x11-libs/startup-notification-0.9 > || ( >=sys-apps/devicekit-power-008 sys-power/upower ) > which I understand to mean that devicekit-power is needed if > startup-notification is older than 0.9. I have startup-notification-0.10 > installed, so why is emerge pulling in devicekit-power? That is wrong. It needs unconditionally x11-libs/startup-notification-0.9 or newer and one of the set ("|| ( <set> )") >=sys-apps/devicekit-power-008 or sys-power/upower . Either install any version of sys-power/upower or sys-apps/devicekit-power-008 or newer. >
(In reply to comment #2) > (In reply to comment #0) > > First observation: my desktop system is perfectly happy without > > CONFIG_ACPI_... Why does devicekit-power need it? > what do you mean by needing? Does the emerge just warn or does it stop? Please see bug 263959 , the one which is mentioned in the ebuild , and post a comment if the solution causes you troubles.
Created attachment 230095 [details] output of devicekit-power emerge
Sorry. I neglected to hit "submit" for the second attachment. The emerge of devicekit-power fails, which prevents the emerging of gnome-session
(In reply to comment #5) > The emerge of devicekit-power fails, which prevents the emerging of > gnome-session Ok, a temporary fix is (better use a local overlay), would be 1) edit /usr/portage/sys-apps/devicekit-power/devicekit-power-009.ebuild and remove the "check_extra_config" 2) update the manifest with "ebuild /usr/portage/sys-apps/devicekit-power/devicekit-power-009.ebuild manifest" 3) emerge -av1 -j1 devicekit-power or just proceede with the last emerge. Note: this will be removed at next portage tree sync ("emerge --sync"). If it works, you should comment on the above bug and mention your concerns.
or do the exact same for the -014 ebuild.
Creating a local overlay for the modified 014 build allowed the building of devicekit-power. I'll add a note to bug 263959
I can sort of understand the check in devicekit-power, but does gnome-session really need to hard depend on devicekit-power then? Most users should have CONFIG_ACPI_* stuff, but I was forced to add all that ACPI support into my kernel just because of this now. I consciously avoided any form of ACPI support in kernel before - simply because my embedded BIOS doesn't support any form of ACPI, nor is it too important with the whole x86 system taking 5W max while not having a battery to benefit significantly from further decrease... Anyway, as I'm gnome@ too, I will look into this, but I hope others on the team can comment with the reasons before I get to that :)
devicekit-power is used for suspend/hibernate support. Personally, I don't ever do either, so I'd like to see the ability to conditionally build devicekit-power support. I looked at the code and it looks really easy to do... however I have no idea how to change the build system. So I'll leave it to someone who knows how. Also, if devicekit-power is made optional, an optional dependency on consolekit (used for shutdown/reboot) should probably be added, since it won't be indirectly pulled in by devicekit-power.
(In reply to comment #9) > Anyway, as I'm gnome@ too, I will look into this, but I hope others on the team > can comment with the reasons before I get to that :) > We could try to use debian patch to make it an optional requirement: http://patch-tracker.debian.org/patch/series/view/gnome-session/2.30.0-1/03_devicekit_optional.patch What do you think?
This is an even bigger problem on a Xen kernel, where you _cannot_ set CONFIG_ACPI_SYSFS_POWER, so either removing the dependency on CONFIG_ACPI_SYSFS_POWER or making devicekit-power optional for gnome-session would be fantastic.
I took a look at the Debian patch and think using it is worth a try. Ideally the patch would only make a change or two, but this seems not to be the case. Since the Debian folk have tested it and use it, it should be good for us!
(In reply to comment #12) > This is an even bigger problem on a Xen kernel, where you _cannot_ set > CONFIG_ACPI_SYSFS_POWER, so either removing the dependency on > CONFIG_ACPI_SYSFS_POWER or making devicekit-power optional for gnome-session > would be fantastic. You don't need to have a valid kernel configuration to install dk-p and co, so this argument is just not valid.
> You don't need to have a valid kernel configuration to install dk-p and co, so > this argument is just not valid. > Except having that kernel configuration does block the package installing, which in turn blocks all the new gnome stuff. What steps must I take to emerge without rebuilding the kernel ? Is there a USE flag to stop the requirement ?
(In reply to comment #15) > Except having that kernel configuration does block the package installing, > which in turn blocks all the new gnome stuff. > What steps must I take to emerge without rebuilding the kernel ? > Is there a USE flag to stop the requirement ? Afaik it only tests for a /usr/src/linux/.config file. Make that directory an copy your running config, either from `zcat /proc/config.gz > /usr/src/linux/.config` or `mount /boot ; cp /boot/config /usr/src/linux/.config`. Remember to remove that directory when you build your next kernel and want to use `eselect kernel` or the +symlink use flag.
on a personal note, i wouls add a ~ to the check argument, to make it non fatal. local CONFIG_CHECK="~ACPI_SYSFS_POWER" (line 45 in linux-info.eclass)
(In reply to comment #17) > on a personal note, i wouls add a ~ to the check argument, to make it non > fatal. > local CONFIG_CHECK="~ACPI_SYSFS_POWER" > > (line 45 in linux-info.eclass) > /usr/portage/eclass/linux-info.eclass has no mention of ACPI_SYSFS_POWER so I edited the /usr/src/linux/.config then after the emerge (which of course worked) set it back again. I feel dirty, thanks for you help.
(In reply to comment #18) > /usr/portage/eclass/linux-info.eclass > has no mention of ACPI_SYSFS_POWER No, I just referred to the `~` option to make a test failure non-fatal. The ACPI_SYSFS_POWER is inside the ebuild.
devicekit-power is just not usable if it doesn't pass the kernel check. If it is, then please file a bug report with the kernel options required for your arch (there was one, can't find it right now).
This was fixed on Apr 13.
