[Touch-packages] [Bug 1706948] Re: [Ubuntu 18.04] [Feature] Inconsistent report of pm CanSuspend state by systemd and pm-utils
** Changed in: pm-utils (Ubuntu)
Assignee: (unassigned) => rahmadani (rahmadani)
** Changed in: ubuntu-power-systems
Assignee: (unassigned) => rahmadani (rahmadani)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pm-utils in Ubuntu.
https://bugs.launchpad.net/bugs/1706948
Title:
[Ubuntu 18.04] [Feature] Inconsistent report of pm CanSuspend state by
systemd and pm-utils
Status in The Ubuntu-power-systems project:
Invalid
Status in pm-utils package in Ubuntu:
Invalid
Bug description:
== Comment: #0 - Balamuruhan S <> - 2017-06-28 03:39:15 ==
systemd and pm-utils interprets CanSuspend states differently and reports it
as supported or not in a conflicting way.
# gdbus call --system --dest org.freedesktop.login1 --object-path
/org/freedesktop/login1 --method org.freedesktop.login1.Manager.CanSuspend
('yes',)
# pm-is-supported --suspend
# echo $?
1
Both systemd and pm-is-supported looks into /sys/power/state file to
check if suspend is supported.
pm-is-supported --suspend returns true if either "standby" or "mem" is
present in the file.
( /usr/lib/pm-utils/pm-functions )
systemd(Manager.CanSuspend) returns true if "standby", "freeze" or "mem" is
present in the file.
(
https://github.com/systemd/systemd/blob/dd8352659c9428b196706d04399eec106a8917ed/src/shared/sleep-config.c
)
# cat /sys/power/state
freeze
So here, pm-is-supported --suspend returns false and gdbus returns
true.
Both these utilities interpret /sys/power/state differently.
Secondly, systemd should split CanSuspend to Cansuspend+CanFreeze Or
don't report freeze as CanSuspend.
Impact of this inconsistency can be felt from Libvirt supported pm
states:
To reduce ABI dependency, libvirt queries the available states via
dbus, if not falls to pm-utils. Libvirt won't check for strings in
sys/power/state and interpret directly.
so due to this, libvirt will list that suspend_to_mem is supported
from virsh capabilities but ideally it might not.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1706948/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1669655] Re: Adapt to new Nautilus icon name
** Changed in: humanity-icon-theme (Ubuntu) Assignee: (unassigned) => rahmadani (rahmadani) ** Changed in: nautilus (Ubuntu) Assignee: (unassigned) => rahmadani (rahmadani) ** Changed in: ubuntu-themes (Ubuntu) Assignee: (unassigned) => rahmadani (rahmadani) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-themes in Ubuntu. https://bugs.launchpad.net/bugs/1669655 Title: Adapt to new Nautilus icon name Status in humanity-icon-theme package in Ubuntu: Fix Released Status in nautilus package in Ubuntu: Fix Released Status in ubuntu-themes package in Ubuntu: Fix Released Bug description: Nautilus 3.24's app icon name is org.gnome.Nautilus instead of system- file-manager for better flatpak compatibility. I have updated ubuntu-themes and humanity-icon-theme for this change (adding a new symlink pointing to system-file-manager). ubuntu-themes is handled via bileto so I'll ask the appropriate people to sponsor that separately. DONE I pushed my change to the humanity bzr branch but I don't have upload rights for it so I'll need sponsorship for this: https://code.launchpad.net/~ubuntu-art-pkg/humanity/release/ I let other Ubuntu flavors know about this change at bug 1669663. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/humanity-icon-theme/+bug/1669655/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1675163] Re: Don't attempt to create devices in LXC containers
** Changed in: makedev (Ubuntu Precise) Assignee: (unassigned) => rahmadani (rahmadani) ** Changed in: makedev (Ubuntu Trusty) Assignee: (unassigned) => rahmadani (rahmadani) ** Changed in: makedev (Ubuntu Xenial) Assignee: (unassigned) => rahmadani (rahmadani) ** Changed in: makedev (Ubuntu Yakkety) Assignee: (unassigned) => rahmadani (rahmadani) ** Changed in: makedev (Ubuntu Zesty) Assignee: (unassigned) => rahmadani (rahmadani) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to makedev in Ubuntu. https://bugs.launchpad.net/bugs/1675163 Title: Don't attempt to create devices in LXC containers Status in makedev package in Ubuntu: Fix Released Status in makedev source package in Precise: Fix Released Status in makedev source package in Trusty: Fix Released Status in makedev source package in Xenial: Fix Released Status in makedev source package in Yakkety: Fix Released Status in makedev source package in Zesty: Fix Released Bug description: Right now the "makedev" postinst script will attempt to create a number of devices in /dev, failing the package upgrade should any of those mknod calls fail. LXC containers, especially unprivileged ones do not allow the use of mknod, making it impossible to upgrade makedev in those containers and preventing Ubuntu release upgrades. The fix is quite simple, detect that we are running in an LXC container and skip the rest of the postinst script as is done in a number of other cases. = SRU == Rationale This issue prevents release to release upgrades in unprivileged LXC containers when makedev is part of the upgraded set. This is currently visible when upgrading from Ubuntu 12.04 to Ubuntu 14.04. == Testcase Install the new package in an unprivileged container. With LXD, simply use "lxc launch ubuntu: test" to create the container. Prior to this fix, the upgrade will fail on some mknod errors, after it, it'll go on after printing a message indicating that LXC was detected. == Regression potential The detection logic is based on PID 1's environment containing a container=lxc entry. If a non-LXC system somehow had that set, it'd lead to the makedev upgrade no longer creating extra devices. This is unlikely to really matter though since the system is clearly already functioning properly at that point. Similarly, some privileged LXC containers can be configured in a way where mknod is possible, this update will still disable the postinst for those cases as short of attempting every mknod ahead of time, there is no reliable way to detect any seccomp or apparmor policy in play. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedev/+bug/1675163/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
