[opensuse-factory] dropping of pm-utils + suspend
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
-----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
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
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
В Fri, 26 Jun 2015 20:46:30 +0200 Takashi Iwai <tiwai@suse.de> пишет:
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
At Fri, 26 Jun 2015 22:01:27 +0300, Andrei Borzenkov wrote:
В Fri, 26 Jun 2015 20:46:30 +0200 Takashi Iwai <tiwai@suse.de> пишет:
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
-----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
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
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
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
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
-----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
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
-----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
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
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
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
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
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
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
-----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
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
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 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
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
On 26 June 2015 at 18:11, Stanislav Brabec <sbrabec@suse.com> 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
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
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
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
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
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
On Mon, 29 Jun 2015 21:12, Stanislav Brabec <sbrabec@...> 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
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
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
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
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