Bugzilla – Bug 1222932
power-profiles-daemon fails to build on Leap 15.6 - fail in test_dytc_performance_driver
Last modified: 2024-05-21 03:57:44 UTC
Hello package power-profiles-daemon fails to build on Leap 15.6 https://build.opensuse.org/package/live_build_log/openSUSE:Backports:SLE-15-SP6/power-profiles-daemon/standard/x86_64 [ 37s] ** (power-profiles-daemon:2094): DEBUG: 10:23:07.358: /sys/firmware/acpi/platform_profile changed (2) [ 37s] ** (power-profiles-daemon:2094): DEBUG: 10:23:07.358: Failed to get contents for '/tmp/umockdev.F1WVL2/sys/firmware/acpi/platform_profile': Failed to open file “/tmp/umockdev.F1WVL2/sys/firmware/acpi/platform_profile”: No such file or directory [ 37s] ------------------------------ [ 37s] [ 37s] ====================================================================== [ 37s] FAIL: test_dytc_performance_driver (__main__.Tests) [ 37s] Lenovo DYTC performance driver [ 37s] ---------------------------------------------------------------------- [ 37s] Traceback (most recent call last): [ 37s] File "/home/abuild/rpmbuild/BUILD/power-profiles-daemon-0.13/x86_64-suse-linux/../tests/integration-test.py", line 803, in test_dytc_performance_driver [ 37s] self.assertEventually(lambda: self.get_dbus_property('PerformanceDegraded') == 'lap-detected') [ 37s] File "/home/abuild/rpmbuild/BUILD/power-profiles-daemon-0.13/x86_64-suse-linux/../tests/integration-test.py", line 293, in assertEventually [ 37s] self.fail(message or 'timed out waiting for ' + str(condition)) [ 37s] AssertionError: timed out waiting for <function Tests.test_dytc_performance_driver.<locals>.<lambda> at 0x7fd2e27c1378> [ 37s] [ 37s] ---------------------------------------------------------------------- [ 37s] Ran 1 test in 5.437s [ 37s] [ 37s] FAILED (failures=1) [ 37s] ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― [ 37s] [ 37s] 29/31 Tests.test_trickle_charge_mode_no_change OK 0.43s [ 37s] 30/31 Tests.test_trickle_charge_system OK 0.44s [ 38s] 31/31 Tests.test_vanishing_hold OK 1.45s Could you please have a look?
This is due to some recent systemd updates to SLE-15-SP6, no doubt. Anyway, the thing that will fix this properly is an update to umockdev 0.18.1 from Factory. I already tested this theory out in my home branch where I built the SLE-15-SP6 power-profiles-daemon against Factory's umockdev: https://build.opensuse.org/project/show/home:badshah400:branches:openSUSE:Backports:SLE-15-SP6 How should I submit a new umockdev version at this stage, and is there any chance of such an update being accepted?
I guess this fixed itself? Even otherwise, it seems it is already too late now. FYI the fix is to upgrade umockdev to 0.18.1. I am sorry, I find contributing to Leap almost impossible given its Frankenstein's monster nature. Still, I tried to help as much as I could.
I don't know if this is the right target, but a potential fix is to upgrade umockdev to 0.17.18 (without jumping two minor versions to 0.18.x in Factory) which also fixed the power-profiles-daemon build. Here is the sr: https://build.opensuse.org/request/show/1170592 Raising the ship_stopper flag given that power-profiles-daemon forms a core part of the GNOME desktop env.
I've raised the issue with GNOME team. We'd have to update umockdev in SLES 15, I'd suggest SP4:Update + some sort of ECO as the SP6:GA accepts P1/P2s and this issue is basically not present in SLES (although the fix lands there). Of course we could try SP6 first ... Yi Fan what do you think?
(In reply to Lubos Kocman from comment #4) > I've raised the issue with GNOME team. > > We'd have to update umockdev in SLES 15, I'd suggest SP4:Update + some sort > of ECO as the SP6:GA accepts P1/P2s and this issue is basically not present > in SLES (although the fix lands there). Of course we could try SP6 first ... > > Yi Fan what do you think? The updating of umockdev seems nontrivial, and at least the impacted areas will be fwupd, udev, power-profiles-daemon. So for SP6, I am afraid we can't get it in GA. Just to clarify - is there any reason we need that in SP4? If it is caused by the forked systemd on SP6, shouldn't the update happens on SP6:Update through ECO?
well SP6:Update is also an option for sure. The only reason for SP4:Update was to simply update it when its forked and keep amount of forks minimal. Nothing else.
https://jira.suse.com/browse/PED-8351
MR https://build.suse.de/request/show/328919
Proposed fork for Leap 15.6 https://build.opensuse.org/request/show/1172156
(In reply to Lubos Kocman from comment #9) > Proposed fork for Leap 15.6 https://build.opensuse.org/request/show/1172156 Awesome, thanks for the help.