-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
upower: Upgrade to 1.90.6 and extend CriticalPowerActions #341086
base: master
Are you sure you want to change the base?
Conversation
When I build locally, the compilation succeeds, but I run into test failures. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Skimming the upstream diff, looks okay:
https://gitlab.freedesktop.org/upower/upower/-/compare/v1.90.4...v1.90.5
@@ -218,6 +246,7 @@ in | |||
TimeLow = cfg.timeLow; | |||
TimeCritical = cfg.timeCritical; | |||
TimeAction = cfg.timeAction; | |||
AllowRiskyCriticalPowerAction = cfg.allowRiskyCriticalPowerAction; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ugh, we should really switch to RFC 42-style settings so that we do not need to keep adding the options forever like this. Opened #341107 for now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That does indeed seem like better way of doing things.
@@ -80,6 +81,7 @@ stdenv.mkDerivation (finalAttrs: { | |||
buildInputs = [ | |||
libgudev | |||
libusb1 | |||
polkit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at the diff, https://gitlab.freedesktop.org/upower/upower/-/commit/0c9ba8048fd38567aa1292f3760fbff48904c3ca sets POLKIT_ACTIONDIR
define but it does not look like it is currently used? If not, that should not be an issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, it doesn't look like it's used.
8c1e1f5
to
ad1a29d
Compare
9a67952
to
508db42
Compare
@jtojnar I've bumped up to 1.90.6, which avoids the need for patching the tests. |
@jtojnar Don't suppose you have time for another review pass? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for this change! I just had my laptop die on my for the upteenth time, and decided to finally set up upower.
I don't have hibernation support enabled on my machine, so I want this Sleep
functionality!
assertions = [ | ||
{ | ||
assertion = | ||
with builtins; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit, feel free to ignore: what is builtins
used for here? Is it just elem
? I think this would be nicer as just a inherit (builtins) elem;
in the let block instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
]; | ||
riskyActionEnabled = elem cfg.criticalPowerAction riskyActions; | ||
in | ||
!cfg.allowRiskyCriticalPowerAction && riskyActionEnabled; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit, feel free to ignore: would this be cleaner written as riskyActionEnabled -> cfg.allowRiskyCriticalPowerAction
? I think it's the same boolean logic, and reads a bit more nicely ("if a risky action is enabled, then we must allow risky actions").
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, is the current assertion correct? I'm trying out this patch locally, and I've set services.upower.criticalPowerAction = "Suspend"
, so riskyActionEnabled = true
. I have not yet set services.upower.allowRiskyCriticalPowerAction
to anything, so it's just the default value of false
.
Plugging that into this expression, I get:
!cfg.allowRiskyCriticalPowerAction && riskyActionEnabled
=> !false && true
=> true && true
=> true
That's wrong, right? Don't we want this configuration to trigger the assertion (i.e., evaluate to false
)?
I think the riskyActionEnabled -> cfg.allowRiskyCriticalPowerAction
I suggested above is correct. Or perhaps !riskyActionEnabled or cfg.allowRiskyCriticalPowerAction
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TIL ->
.
Quite right. I was treating that as an expression that when evaluated as true
would trigger an error, rather than (what should have been clear to me) when the assertion condition is not met.
Good spot!
(UPS or laptop batteries) supplying the computer | ||
(UPS or laptop batteries) supplying the computer. | ||
|
||
When set to `Suspend` or `Ignore`, `allowRiskyCriticalPowerAction` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I recently learned there's special syntax for referencing options. See https://github.com/NixOS/nixpkgs/tree/master/doc#roles
When set to `Suspend` or `Ignore`, `allowRiskyCriticalPowerAction` | |
When set to `Suspend` or `Ignore`, {option}`services.upower.allowRiskyCriticalPowerAction` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good to know! Done.
508db42
to
57077af
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Latest changes LGTM
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/prs-already-reviewed/2617/2062 |
I've been using this for a couple weeks and it's working great for me. I've added a link to this PR in https://discourse.nixos.org/t/prs-already-reviewed/2617/2062. |
@benjamb, do you have time to rebase this branchb and address the conflicts? If it's helpful, I'm maintaining a branch here with your changes: https://github.com/jfly/nixpkgs/tree/upower-critical-actions |
57077af
to
789bb45
Compare
Done! |
@jtojnar, any chance of getting this merged? |
Description of changes
Things done
nix.conf
? (See Nix manual)sandbox = relaxed
sandbox = true
nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)Add a 👍 reaction to pull requests you find important.