[opensuse-factory] dropping of pm-utils + suspend

older
[opensuse-factory] New packages:...

Stanislav Brabec

26 Jun 2015 26 Jun '15

16:11

After getting many bug reports on a strange suspend or hibernate behavior, and two years after last discussion on dropping pm-utils[1], I think that there is a time to make a step further, and drop pm-utils for real. What changed over in last two years: - many bugs were fixed - really needed quirks were ported to systemd - SUSE Linux Enterprise was released without pm-utils and suspend packages - Fedora has no pm-utils as well How suspend/hibernate works in openSUSE now: - systemd gets a request to hibernate. - systemd executes its quirks. - if pm-utils are not present, systemd asks kernel for hibernation. - if pm-utils are present but suspend is not present, hibernate. continues with pm-utils quirks, then pm-hibernate asks kernel for hibernation. - if pm-utils and suspend are present, hibernate continues with pm-utils quirks, but skips video quirks, then pm-hibernate converts list of skipped video quirks to command line arguments of s2disk, and then it calls s2disk. s2disk calls selected video quirks and does hibernation on its own. - If you call pm-hibernate or s2disk, things are going differently and some quirks can be skipped. Your machine may start or stop hibernate. As you see, it's a nightmare to debug stuff like that. My proposal: - drop both pm-utils and suspend. See the discussion in BugZilla[2]. - Remove support for pm-utils from systemd. See the discussion in BugZilla[3]. - Create sysconfig for hwclock. - If it will be needed, create systemd-video-quirks-legacy. How suspend/hibernate will work then: - systemd gets a request to hibernate - systemd executes its quirks - systemd asks kernel for hibernation What will we lose: - pm-utils quirks. Nobody knows, what is still needed. Quirks were added to work-around kernel bugs, kernel was fixes, quirks left intact. Most quirks are > 5 years old, there are no quirks for new hardware. See a long discussion about these quirks in the BugZilla[2] - Serial execution of quirks. Not a big problem, as (even the old) pm-utils quirks are independent on on other. - s2disk multithread compression and hibernation to file until kernel gets these features. But it seems, that there are many machines, where s2disk breaks the suspend completely. Which are the risks: - That some pm-utils video quirks are still needed. But it is not a reason to re-introduce pm-utils. We can easily port pm-utils video quirk wrapper to systemd, and create a systemd-video-quirks-legacy package for them. - That some kernel drivers still need reload. Fill a bug against kernel instead of adding them to SUSPEND_MODULES in /etc/pm/config.d. - That network software will not re-initiate connection. Fill a bug against your network management software. Proposed change in systemd.spec for Factory [4]: +Obsoletes: pm-utils <= 1.4.1 +Obsoletes: suspend <= 1.0 -# PATCH-FIX-OPENSUSE forward to pm-utils -- until boo#904828 is addressed -Patch25: Forward-suspend-hibernate-calls-to-pm-utils.patch -%patch25 -p1 References: [1] http://lists.opensuse.org/opensuse-factory/2013-11/msg00911.html [2] bugzilla.opensuse.org/show_bug.cgi?id=925873 [3] bugzilla.opensuse.org/show_bug.cgi?id=904828 [4] https://build.opensuse.org/package/show/home:sbrabec:branches:systemd-drop-p... -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Show replies by date

Carlos E. R.

26 Jun 26 Jun

16:39

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-06-26 18:11, Stanislav Brabec wrote:

...

Which are the risks: - That some pm-utils video quirks are still needed. But it is not a reason to re-introduce pm-utils. We can easily port pm-utils video quirk wrapper to systemd, and create a systemd-video-quirks-legacy package for them. - That some kernel drivers still need reload. Fill a bug against kernel instead of adding them to SUSPEND_MODULES in /etc/pm/config.d. - That network software will not re-initiate connection. Fill a bug against your network management software.

Please allow for local script on each action, where we can still add our own actions. In pm-utils, this means directory "/etc/pm/sleep.d/". It doesn't need to be the exact same syntax, but if it is that would allow us (users) to just drop our scripts into the new location. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWNgEYACgkQja8UbcUWM1zaQAD+OaKrzUZUhEwGnys4M972E5p4 TAmIsdvf6rG2e+T4tvAA/iWJEYVlZL1aUtT0qLC+jPQA8EX21SL6QA1srAUOlVYK =Owcm -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Wolfgang Bauer

17:49

Am Freitag, 26. Juni 2015, 18:39:34 schrieb Carlos E. R.:

...

Please allow for local script on each action, where we can still add our own actions. In pm-utils, this means directory "/etc/pm/sleep.d/". It doesn't need to be the exact same syntax, but if it is that would allow us (users) to just drop our scripts into the new location.

Systemd does allow this, see "man systemd-sleep": Immediately before entering system suspend and/or hibernation systemd-suspend.service (and the other mentioned units, respectively) will run all executables in /usr/lib/systemd/system-sleep/ and pass two arguments to them. The first argument will be "pre", the second either "suspend", "hibernate", or "hybrid-sleep" depending on the chosen action. Immediately after leaving system suspend and/or hibernation the same executables are run, but the first argument is now "post". All executables in this directory are executed in parallel, and execution of the action is not continued until all executables have finished. Note that scripts or binaries dropped in /usr/lib/systemd/system-sleep/ are intended for local use only and should be considered hacks. If applications want to be notified of system suspend/hibernation and resume, there are much nicer interfaces available. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Takashi Iwai

18:46

At Fri, 26 Jun 2015 19:49:05 +0200, Wolfgang Bauer wrote:

...

Am Freitag, 26. Juni 2015, 18:39:34 schrieb Carlos E. R.:

...
Please allow for local script on each action, where we can still add our own actions. In pm-utils, this means directory "/etc/pm/sleep.d/". It doesn't need to be the exact same syntax, but if it is that would allow us (users) to just drop our scripts into the new location.

Systemd does allow this, see "man systemd-sleep": Immediately before entering system suspend and/or hibernation systemd-suspend.service (and the other mentioned units, respectively) will run all executables in /usr/lib/systemd/system-sleep/ and pass two arguments to them. The first argument will be "pre", the second either "suspend", "hibernate", or "hybrid-sleep" depending on the chosen action. Immediately after leaving system suspend and/or hibernation the same executables are run, but the first argument is now "post". All executables in this directory are executed in parallel, and execution of the action is not continued until all executables have finished.

Note that scripts or binaries dropped in /usr/lib/systemd/system-sleep/ are intended for local use only and should be considered hacks. If applications want to be notified of system suspend/hibernation and resume, there are much nicer interfaces available.

I think a few things missing there. 1. Serialized execution of scripts 2. Some easy interface for common workarounds such as unloading / reloading modules. This is still needed occasionally, and writing the full unit file from scratch at each time is a waste of man hours. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andrei Borzenkov

19:01

В Fri, 26 Jun 2015 20:46:30 +0200 Takashi Iwai пишет:

...

At Fri, 26 Jun 2015 19:49:05 +0200, Wolfgang Bauer wrote:

...
Am Freitag, 26. Juni 2015, 18:39:34 schrieb Carlos E. R.:

...
Please allow for local script on each action, where we can still add our own actions. In pm-utils, this means directory "/etc/pm/sleep.d/". It doesn't need to be the exact same syntax, but if it is that would allow us (users) to just drop our scripts into the new location.

Systemd does allow this, see "man systemd-sleep": Immediately before entering system suspend and/or hibernation systemd-suspend.service (and the other mentioned units, respectively) will run all executables in /usr/lib/systemd/system-sleep/ and pass two arguments to them. The first argument will be "pre", the second either "suspend", "hibernate", or "hybrid-sleep" depending on the chosen action. Immediately after leaving system suspend and/or hibernation the same executables are run, but the first argument is now "post". All executables in this directory are executed in parallel, and execution of the action is not continued until all executables have finished.

Note that scripts or binaries dropped in /usr/lib/systemd/system-sleep/ are intended for local use only and should be considered hacks. If applications want to be notified of system suspend/hibernation and resume, there are much nicer interfaces available.

I think a few things missing there.

1. Serialized execution of scripts

Yes, that needs some driver which is called from systemd and controls further script execution. Sounds suspiciously familiar to what pm-utils does :)

...

2. Some easy interface for common workarounds such as unloading / reloading modules. This is still needed occasionally, and writing the full unit file from scratch at each time is a waste of man hours.

Programs under systemd-sleep are not units, they are just arbitrary executables. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Takashi Iwai

19:42

At Fri, 26 Jun 2015 22:01:27 +0300, Andrei Borzenkov wrote:

...

В Fri, 26 Jun 2015 20:46:30 +0200 Takashi Iwai пишет:

...
At Fri, 26 Jun 2015 19:49:05 +0200, Wolfgang Bauer wrote:

...
Am Freitag, 26. Juni 2015, 18:39:34 schrieb Carlos E. R.:

...
Please allow for local script on each action, where we can still add our own actions. In pm-utils, this means directory "/etc/pm/sleep.d/". It doesn't need to be the exact same syntax, but if it is that would allow us (users) to just drop our scripts into the new location.

Systemd does allow this, see "man systemd-sleep": Immediately before entering system suspend and/or hibernation systemd-suspend.service (and the other mentioned units, respectively) will run all executables in /usr/lib/systemd/system-sleep/ and pass two arguments to them. The first argument will be "pre", the second either "suspend", "hibernate", or "hybrid-sleep" depending on the chosen action. Immediately after leaving system suspend and/or hibernation the same executables are run, but the first argument is now "post". All executables in this directory are executed in parallel, and execution of the action is not continued until all executables have finished.

Note that scripts or binaries dropped in /usr/lib/systemd/system-sleep/ are intended for local use only and should be considered hacks. If applications want to be notified of system suspend/hibernation and resume, there are much nicer interfaces available.

I think a few things missing there.

1. Serialized execution of scripts

Yes, that needs some driver which is called from systemd and controls further script execution. Sounds suspiciously familiar to what pm-utils does :)

...
2. Some easy interface for common workarounds such as unloading / reloading modules. This is still needed occasionally, and writing the full unit file from scratch at each time is a waste of man hours.

Programs under systemd-sleep are not units, they are just arbitrary executables.

Ah right. But the argument is same. If we have something like $SUSPEND_MODULE in /etc/sysconfig/suspend, it's easier to manage, for example. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R.

21:01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-06-26 21:42, Takashi Iwai wrote:

...

Ah right. But the argument is same. If we have something like $SUSPEND_MODULE in /etc/sysconfig/suspend, it's easier to manage, for example.

The OP said that these should be reported in bugzillas against the kernel. But this can take weeks, months, even years! Thus, till whatever kernel piece is corrected, we, as users, still need (temporary) hacks. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWNvacACgkQja8UbcUWM1yqWAD/edja1NXqm5OiGoO2ny5oU5Xo bmIvSzIJFXHcEsxzckABAIsqrXUoEs6TSvyqkgdFgKGD11PGqm+nKqXDQrj+7IQE =VYpL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Takashi Iwai

27 Jun 27 Jun

08:09

At Fri, 26 Jun 2015 23:01:27 +0200, Carlos E. R. wrote:

...

On 2015-06-26 21:42, Takashi Iwai wrote:

...
Ah right. But the argument is same. If we have something like $SUSPEND_MODULE in /etc/sysconfig/suspend, it's easier to manage, for example.

The OP said that these should be reported in bugzillas against the kernel. But this can take weeks, months, even years! Thus, till whatever kernel piece is corrected, we, as users, still need (temporary) hacks.

Yes, that's exactly my intention, too. As a long time person who has been involved with kernel development, I highly appreciate bug reports. It's the first thing we care. OTOH, I see no big reason to make workarounds difficult. A possible compromise would be to let the script give some warning if it actually unloads/reloads the module. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stanislav Brabec

29 Jun 29 Jun

13:54

Takashi Iwai wrote:

...

At Fri, 26 Jun 2015 23:01:27 +0200, Carlos E. R. wrote:

...
On 2015-06-26 21:42, Takashi Iwai wrote:

...
Ah right. But the argument is same. If we have something like $SUSPEND_MODULE in /etc/sysconfig/suspend, it's easier to manage, for example.

The OP said that these should be reported in bugzillas against the kernel. But this can take weeks, months, even years! Thus, till whatever kernel piece is corrected, we, as users, still need (temporary) hacks.

Yes, that's exactly my intention, too.

As a long time person who has been involved with kernel development, I highly appreciate bug reports. It's the first thing we care. OTOH, I see no big reason to make workarounds difficult.

A possible compromise would be to let the script give some warning if it actually unloads/reloads the module.

Following work-around will not work? /usr/lib/systemd/system-sleep/broken-modules.sh #!/bin/bash . /etc/sysconfig/suspend if [ "$1" = pre ] && ( [ "$2" = hibernate ] || [ "$2" = hybrid-sleep ] ) ; then for MODULE in $SUSPEND_MODULE ; do rmmod $MODULE done fi if [ "$1" = post ] && ( [ "$2" = hibernate ] || [ "$2" = hybrid-sleep ] ) ; then for MODULE in $SUSPEND_MODULE ; do modprobe $MODULE done fi -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stefan Seyfried

17:58

Am 29.06.2015 um 15:54 schrieb Stanislav Brabec:

...

Following work-around will not work?

/usr/lib/systemd/system-sleep/broken-modules.sh

#!/bin/bash

. /etc/sysconfig/suspend

if [ "$1" = pre ] && ( [ "$2" = hibernate ] || [ "$2" = hybrid-sleep ] ) ; then

why only suspend-to-disk?

...

for MODULE in $SUSPEND_MODULE ; do rmmod $MODULE done fi if [ "$1" = post ] && ( [ "$2" = hibernate ] || [ "$2" = hybrid-sleep ] ) ; then for MODULE in $SUSPEND_MODULE ; do modprobe $MODULE done fi

I think you should actually note somewhere which modules had been unloaded and only reload those on resume. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stanislav Brabec

19:19

Stefan Seyfried wrote:

...

Am 29.06.2015 um 15:54 schrieb Stanislav Brabec:

...
Following work-around will not work?

/usr/lib/systemd/system-sleep/broken-modules.sh

#!/bin/bash

. /etc/sysconfig/suspend

if [ "$1" = pre ] && ( [ "$2" = hibernate ] || [ "$2" = hybrid-sleep ] ) ; then

why only suspend-to-disk?

Does this problem affect suspend to RAM as well? If yes, it is easy to add it there.

...

...
for MODULE in $SUSPEND_MODULE ; do rmmod $MODULE done fi if [ "$1" = post ] && ( [ "$2" = hibernate ] || [ "$2" = hybrid-sleep ] ) ; then for MODULE in $SUSPEND_MODULE ; do modprobe $MODULE done fi

I think you should actually note somewhere which modules had been unloaded and only reload those on resume.

Probably yes. The easiest way would be just porting of pm-utils script. But I am not sure, whether we should add it to systemd. I would create a new package: systemd-quirks-legacy with sub-packages like systemd-quirks-legacy-modules and maybe later (if required) systemd-quirks-legacy-video systemd-quirks-legacy-rtc -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R.

20:49

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-06-29 21:19, Stanislav Brabec wrote:

...

Stefan Seyfried wrote:

...

...
why only suspend-to-disk?

Does this problem affect suspend to RAM as well? If yes, it is easy to add it there.

Not always, I think. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWRr3YACgkQja8UbcUWM1y7AgD+Ppkd+0DSM+4qeGX4fAsGDvKJ wj4SJd77ezdcaDl4y5oA/A3/6A8Cnlb12b+4vWydBjwkgg+VatuZxqroh1iZ3LSJ =gKQi -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Takashi Iwai

30 Jun 30 Jun

05:10

At Mon, 29 Jun 2015 22:49:58 +0200, Carlos E. R. wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 2015-06-29 21:19, Stanislav Brabec wrote:

...
Stefan Seyfried wrote:

...
...
why only suspend-to-disk?

Does this problem affect suspend to RAM as well? If yes, it is easy to add it there.

Not always, I think.

... when you're lucky :) In most cases the workaround is needed for both. Typically a problem is a bug (or a lack) of the suspend/resume code, and most kernel drivers use the same function for S3 and S4 in some level. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R.

10:32

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-06-30 07:10, Takashi Iwai wrote:

...

At Mon, 29 Jun 2015 22:49:58 +0200, Carlos E. R. wrote:

...

...
Not always, I think.

... when you're lucky :) In most cases the workaround is needed for both.

Typically a problem is a bug (or a lack) of the suspend/resume code, and most kernel drivers use the same function for S3 and S4 in some level.

I know that some machines work fine on hibernate but fail on suspend. And I have seen machines with totally broken suspend; my old desktop stopped the internal fan and the cpu went terribly hot, because it remained powered. In that machine I had to disable suspend to ram. It was a bios bug, I found out later. On a laptop, the USB sockets may remain powered during suspend to ram, so that hacks needed to restart a certain device on wake up might not be not needed on suspend, but it would be on hibernate. However, loading/unloading whatever module on all cases, works always. It just makes things a bit slower. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWScEEACgkQja8UbcUWM1xcVAD/bDiLFomQB8eC3N2ewuK0fPB6 +XtwB4EYKd9YPM5elIUA/2M3d7LwP3saBfIWe2qyDk/a9t1wa2JmTwQ0eGSYnxO7 =KEC1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt

26 Jun 26 Jun

19:17

On Friday 2015-06-26 18:11, Stanislav Brabec wrote:

...

Proposed change in systemd.spec for Factory [4]: +Obsoletes: pm-utils <= 1.4.1 +Obsoletes: suspend <= 1.0

Well, systemd is not really obsoleting it in a packaging sense. We should probably seek to introduce a weakremover(pm-utils) in the factory package list…thing. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Cristian Rodríguez

20:16

...

On Friday 2015-06-26 18:11, Stanislav Brabec wrote:

...
Proposed change in systemd.spec for Factory [4]: +Obsoletes: pm-utils <= 1.4.1 +Obsoletes: suspend <= 1.0

Nope, it is the kernel that obsoletes pm-utils (99% of the hacks that once lived there, were to workaround long gone kernel issues) and suspend is provided by the kernel.. ;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Thomas Vatter

22:23

New subject: [opensuse-factory] mouse-setting not persistent

The mouse setting to left-handed is lost after reboot. (Also initialization of the GUI takes longer then usual.) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

mh＠mike.franken.de

27 Jun 27 Jun

08:28

New subject: [opensuse-factory] mouse-setting not persistent

Hi Thomas,

...

The mouse setting to left-handed is lost after reboot. (Also initialization of the GUI takes longer then usual.)

that's correct, but it has nothing to do with pm-utils or suspend. At least for me it doesn't happen after suspend/hibernate and resume, but after a complete reboot of the machine. Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Thomas Vatter

14:48

New subject: [opensuse-factory] mouse-setting not persistent

Hi Michael, Am 27.06.2015 um 10:28 schrieb Michael Hirmke:

...

Hi Thomas,

...
The mouse setting to left-handed is lost after reboot. (Also initialization of the GUI takes longer then usual.) that's correct, but it has nothing to do with pm-utils or suspend. At least for me it doesn't happen after suspend/hibernate and resume, but after a complete reboot of the machine. yes, after complete reboot. I'm new to tumbleweed and the list, is there a possiblity to report a bug?

Bye Thomas

...

Bye. Michael.

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

mh＠mike.franken.de

15:14

New subject: [opensuse-factory] mouse-setting not persistent

Hi Thomas,

...

Hi Michael,

...

Am 27.06.2015 um 10:28 schrieb Michael Hirmke:

...
Hi Thomas,

...
The mouse setting to left-handed is lost after reboot. (Also initialization of the GUI takes longer then usual.) that's correct, but it has nothing to do with pm-utils or suspend. At least for me it doesn't happen after suspend/hibernate and resume, but after a complete reboot of the machine. yes, after complete reboot. I'm new to tumbleweed and the list, is there a possiblity to report a bug?

as the Tumbleweed portal states: How can I contribute? You can test the Tumbleweed distribution and give feedback, share experience and report issues. To do so, send your mail to the list address, opensuse-factory@opensuse.org. So it is already done, I guess :)

...

Bye Thomas

Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R.

16:55

New subject: [opensuse-factory] mouse-setting not persistent

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-06-27 16:48, Thomas Vatter wrote:

...

I'm new to tumbleweed and the list, is there a possiblity to report a bug?

https://en.opensuse.org/Bugzilla - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWO1YwACgkQja8UbcUWM1w+fwD/fVujc3g9zB1jqVkVVxIkqgg0 i5x/dFTL8N7CbmBVMFEA/Ryt0NsbD5PBs4y0m85O6KuLt/xPe/8mJ2iGFz5s9Ik6 =WruN -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Thomas Vatter

18:18

New subject: [opensuse-factory] mouse-setting not persistent

Hi Carlos, Am 27.06.2015 um 18:55 schrieb Carlos E. R.:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 2015-06-27 16:48, Thomas Vatter wrote:

...
I'm new to tumbleweed and the list, is there a possiblity to report a bug? https://en.opensuse.org/Bugzilla looks like "KDE Plasma 5" and "openSUSE tumbleweed" are not in the bugzilla lists.

Saludos Thomas

...

- -- Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlWO1YwACgkQja8UbcUWM1w+fwD/fVujc3g9zB1jqVkVVxIkqgg0 i5x/dFTL8N7CbmBVMFEA/Ryt0NsbD5PBs4y0m85O6KuLt/xPe/8mJ2iGFz5s9Ik6 =WruN -----END PGP SIGNATURE-----

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Felix Miata

20:19

New subject: [opensuse-factory] mouse-setting not persistent

Thomas Vatter composed on 2015-06-27 20:18 (UTC+0200):

...

looks like "KDE Plasma 5" and "openSUSE tumbleweed" are not in the bugzilla lists.

"open" SUSE people don't control Bugzilla configuration. Until somebody get a round tuit, the following will get your report where it needs to go: Tumbleweed -> openSUSE Factory KDE Plasma 5 -> KDE4 Workspace -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Thomas Vatter

22:47

New subject: [opensuse-factory] mouse-setting not persistent

...

Thomas Vatter composed on 2015-06-27 20:18 (UTC+0200):

...
looks like "KDE Plasma 5" and "openSUSE tumbleweed" are not in the bugzilla lists. "open" SUSE people don't control Bugzilla configuration. Until somebody get a round tuit, the following will get your report where it needs to go:

Tumbleweed -> openSUSE Factory

KDE Plasma 5 -> KDE4 Workspace

Am 27.06.2015 um 22:19 schrieb Felix Miata: thx. For "Product" I had chosen "openSUSE Factory", for OS there are the openSUSE released versions till 13.2, or "SUSE other" and "Other". Product version seems to be fixed to 201505, so this might be the factory release and OS selection might be not of interest? Thomas -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stanislav Brabec

29 Jun 29 Jun

13:41

Dne 26.6.2015 v 21:17 Jan Engelhardt napsal(a):

...

On Friday 2015-06-26 18:11, Stanislav Brabec wrote:

...
Proposed change in systemd.spec for Factory [4]: +Obsoletes: pm-utils <= 1.4.1 +Obsoletes: suspend <= 1.0

Well, systemd is not really obsoleting it in a packaging sense. We should probably seek to introduce a weakremover(pm-utils) in the factory package list…thing.

I was not aware that something like weakremover exists in ZYPP? Provides: weakremover(pm-utils) Provides: weakremover(suspend) Does it support versions? Is there any documentation of this feature? What is difference between Obsoletes and weakremover? -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Richard Brown

26 Jun 26 Jun

19:35

On 26 June 2015 at 18:11, Stanislav Brabec wrote:

...

My proposal: - drop both pm-utils and suspend. See the discussion in BugZilla[2]. - Remove support for pm-utils from systemd. See the discussion in BugZilla[3]. - Create sysconfig for hwclock. - If it will be needed, create systemd-video-quirks-legacy.

How suspend/hibernate will work then: - systemd gets a request to hibernate - systemd executes its quirks - systemd asks kernel for hibernation

+1 Please do it, it's my experience that pm-utils is now causing more problems than it's solving and it's removal is overdue. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

mh＠mike.franken.de

21:07

Hi Stanislav,

...

After getting many bug reports on a strange suspend or hibernate behavior, and two years after last discussion on dropping pm-utils[1], I think that there is a time to make a step further, and drop pm-utils for real.

I second this! [...] Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stefan Seyfried

27 Jun 27 Jun

13:24

Am 26.06.2015 um 18:11 schrieb Stanislav Brabec:

...

Proposed change in systemd.spec for Factory [4]: +Obsoletes: pm-utils <= 1.4.1 +Obsoletes: suspend <= 1.0

If systemd obsoletes it, can I still install it or will that obsoletes: make that impossible? (Not that I would want to have it installed, but if someone were to work on improving userspace suspend to bring back the advanced features, it would be nice if he actually could install it without uninstalling systemd). -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stanislav Brabec

29 Jun 29 Jun

13:46

Stefan Seyfried wrote:

...

Am 26.06.2015 um 18:11 schrieb Stanislav Brabec:

...
Proposed change in systemd.spec for Factory [4]: +Obsoletes: pm-utils <= 1.4.1 +Obsoletes: suspend <= 1.0

If systemd obsoletes it, can I still install it or will that obsoletes: make that impossible?

I am not sure, but it for sure goes away on any update. There is a discussion about weakremover in other part of this thread.

...

(Not that I would want to have it installed, but if someone were to work on improving userspace suspend to bring back the advanced features, it would be nice if he actually could install it without uninstalling systemd).

That is why openSUSE policy says: Every Obsoletes has to be versioned. It makes an easy work-around possible: Increment version of obsoleted package above the latest obsolete version. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stefan Seyfried

18:01

Am 29.06.2015 um 15:46 schrieb Stanislav Brabec:

...

Stefan Seyfried wrote:

...
Am 26.06.2015 um 18:11 schrieb Stanislav Brabec:

...
Proposed change in systemd.spec for Factory [4]: +Obsoletes: pm-utils <= 1.4.1 +Obsoletes: suspend <= 1.0

If systemd obsoletes it, can I still install it or will that obsoletes: make that impossible?

I am not sure, but it for sure goes away on any update.

There is a discussion about weakremover in other part of this thread.

I understood that does not yet exist but Jan suggests to introduce it in ZYPP.

...

...
(Not that I would want to have it installed, but if someone were to work on improving userspace suspend to bring back the advanced features, it would be nice if he actually could install it without uninstalling systemd).

That is why openSUSE policy says: Every Obsoletes has to be versioned.

It makes an easy work-around possible: Increment version of obsoleted package above the latest obsolete version.

Ok, that's good enough then. -- Stefan Seyfried Linux Consultant & Developer Tel.: +49-173-2158643 Mail: seyfried@b1-systems.de GPG Key: 0x731B665B B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stanislav Brabec

19:12

Stefan Seyfried wrote:

...

Am 29.06.2015 um 15:46 schrieb Stanislav Brabec:

...

...
There is a discussion about weakremover in other part of this thread.

I understood that does not yet exist but Jan suggests to introduce it in ZYPP.

It apparently already exists: grep weakremover /usr/lib64/libzypp.so.1503 Binary file /usr/lib64/libzypp.so.1503 matches But I just tested that it does not work as simple as I expected. Zypper in, up nor dup does not remove pm-utils, if systemd contains Provides: weakremover(pm-utils) I found no documentation except source code comment in zypp/solver/detail/SATResolver.cc: Dropped packages: look for 'weakremover()' provides in dup candidates of installed products. => I'll submit a version with Obsoletes. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Yamaban

19:19

New subject: [opensuse-factory] Re: dropping of pm-utils + suspend

On Mon, 29 Jun 2015 21:12, Stanislav Brabec wrote:

...

Stefan Seyfried wrote:

...
Am 29.06.2015 um 15:46 schrieb Stanislav Brabec:

...
...
There is a discussion about weakremover in other part of this thread.

I understood that does not yet exist but Jan suggests to introduce it in ZYPP.

It apparently already exists: grep weakremover /usr/lib64/libzypp.so.1503 Binary file /usr/lib64/libzypp.so.1503 matches

But I just tested that it does not work as simple as I expected.

Zypper in, up nor dup does not remove pm-utils, if systemd contains Provides: weakremover(pm-utils)

I found no documentation except source code comment in zypp/solver/detail/SATResolver.cc:

Dropped packages: look for 'weakremover()' provides in dup candidates of installed products.

=> I'll submit a version with Obsoletes.

That was already in /usr/lib64/libzypp.so.1200 from OSS 12.3. IMHO, the Obsoletes + a grep through the *pattern* packages to make sure that neither pm-utils nor suspend are in any of them with a Require, Recommend, or Suggest should be the way to go. - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stanislav Brabec

19:36

New subject: [opensuse-factory] Re: dropping of pm-utils + suspend

Yamaban wrote:

...

make sure that neither pm-utils nor suspend are in any of them with a Require, Recommend, or Suggest should be the way to go.

It was done more than year ago to make possible to release SLE12 without pm-utils and suspend. I hope that nobody re-introduced this requirement in time between. I just made three simple requests: https://build.opensuse.org/request/show/314429 https://build.opensuse.org/request/show/314430 https://build.opensuse.org/request/show/314431 -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stefan Seyfried

18:03

Am 29.06.2015 um 15:46 schrieb Stanislav Brabec:

...

Stefan Seyfried wrote:

...
Am 26.06.2015 um 18:11 schrieb Stanislav Brabec:

...
Proposed change in systemd.spec for Factory [4]: +Obsoletes: pm-utils <= 1.4.1 +Obsoletes: suspend <= 1.0

If systemd obsoletes it, can I still install it or will that obsoletes: make that impossible?

I am not sure, but it for sure goes away on any update.

There is a discussion about weakremover in other part of this thread.

I understood that does not yet exist but Jan suggests to introduce it in ZYPP.

...

...
(Not that I would want to have it installed, but if someone were to work on improving userspace suspend to bring back the advanced features, it would be nice if he actually could install it without uninstalling systemd).

That is why openSUSE policy says: Every Obsoletes has to be versioned.

It makes an easy work-around possible: Increment version of obsoleted package above the latest obsolete version.

Ok, that's good enough then. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman "Your mail is 7 pages of printout. Do you seriously expect people that do openSUSE in their free time to read that? Little less Castro, little more JFK..." -- coolo -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt

19:54

On Monday 2015-06-29 15:46, Stanislav Brabec wrote:

...

Stefan Seyfried wrote:

...
Am 26.06.2015 um 18:11 schrieb Stanislav Brabec:

...
Proposed change in systemd.spec for Factory [4]: +Obsoletes: pm-utils <= 1.4.1 +Obsoletes: suspend <= 1.0

If systemd obsoletes it, can I still install it or will that obsoletes: make that impossible?

I am not sure, but it for sure goes away on any update.

weakremover() is present in openSUSE-release.spec, and flags packages for possible removal (if nothing blocks them, transitively) on `zypper dup` (not sure about `zypper up`). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

3224

Age (days ago)

3228

Last active (days ago)

List overview

Download

34 comments

15 participants

participants (15)

Andrei Borzenkov
Carlos E. R.
Carlos E. R.
Cristian Rodríguez
Felix Miata
Jan Engelhardt
mh＠mike.franken.de
Richard Brown
Stanislav Brabec
Stefan Seyfried
Stefan Seyfried
Takashi Iwai
Thomas Vatter
Wolfgang Bauer
Yamaban