Package: powermgmt-base Version: 1.38 Severity: important X-Debbugs-Cc: наб <[email protected]>, [email protected]
Meow! Some time ago, nab submitted a clean-up patch. It had rotten in the BTS for a while, then got applied in a NMU _without testing_. And it turns out that the patch is incorrect, breaking `lspower` for probably all use cases. [~]$ lspower /usr/bin/lspower: 8: cannot open ./cw2015-battery/online: No such file /usr/bin/lspower: 13: cannot open ./cw2015-battery/health: No such file - cw2015-battery (84%) /usr/bin/lspower: 9: cannot open ./dc-charger/present: No such file /usr/bin/lspower: 11: cannot open ./dc-charger/status: No such file /usr/bin/lspower: 12: cannot open ./dc-charger/capacity: No such file /usr/bin/lspower: 13: cannot open ./dc-charger/health: No such file - dc-charger (84%) /usr/bin/lspower: 9: cannot open ./tcpm-source-psy-4-0022/present: No such file /usr/bin/lspower: 11: cannot open ./tcpm-source-psy-4-0022/status: No such file /usr/bin/lspower: 12: cannot open ./tcpm-source-psy-4-0022/capacity: No such file /usr/bin/lspower: 13: cannot open ./tcpm-source-psy-4-0022/health: No such file - tcpm-source-psy-4-0022 (84%) On this particular machine, the only valid bit of information is that the battery is at 84%; charger status is wrong. The power subsystem reports the kind of a device mostly by the presence or absence of a particular file. For example, defining a battery as something that has "capacity" is more reliable than trying a zoology of known "type"s. Thus, a particular file being absent is not only not an error but the primary source of information I use. The patch in question is: .-------------------------------------------------------------------- commit 2e7b352c7bac543702d221736ed251f0ecadbb68 Author: наб <[email protected]> Date: Mon Aug 22 00:54:23 2022 +0200 Don't spawn 5 cats per PSU in lspower Also shellcheck-clean diff --git a/lspower b/lspower index 2a9f68f..6299500 100755 --- a/lspower +++ b/lspower @@ -5,15 +5,15 @@ cd /sys/class/power_supply 2>/dev/null || for x in *; do [ -e "./$x/type" ] || continue - ONLINE=$(cat "./$x/online" 2>/dev/null) - PRESENT=$(cat "./$x/present" 2>/dev/null) - #TYPE=$(cat "./$x/type" 2>/dev/null) - STATUS=$(cat "./$x/status" 2>/dev/null) - CAPACITY=$(cat "./$x/capacity" 2>/dev/null) - HEALTH=$(cat "./$x/health" 2>/dev/null) + read -r ONLINE < "./$x/online" 2>/dev/null + read -r PRESENT < "./$x/present" 2>/dev/null + #read -r TYPE < "./$x/type" 2>/dev/null + read -r STATUS < "./$x/status" 2>/dev/null + read -r CAPACITY < "./$x/capacity" 2>/dev/null + read -r HEALTH < "./$x/health" 2>/dev/null ICON="?" - if [ "$ONLINE" != 1 -a "$PRESENT" != 1 ]; then + if [ "$ONLINE" != 1 ] && [ "$PRESENT" != 1 ]; then COLOR='1;30'; ICON=✗ elif [ -z "$CAPACITY" ]; then COLOR="1"; ICON=✓ `-------------------------------------------------------------------- So we have an useless binary (thus severity: important) in a high-popcon package. Thus, despite this binary in question being new and thus few people knowing about it, I'd request a stable update. For this reason, I'd make a simple revert for now, with maybe some massaging later. Thoughts, nab? Meow! -- System Information: Debian Release: 13.1 APT prefers stable-security APT policy: (666, 'stable-security'), (666, 'stable'), (250, 'unstable'), (201, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 6.12.48+deb13-arm64 (SMP w/6 CPU threads) Kernel taint flags: TAINT_CRAP Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled -- no debconf information
