Pass 0o666 into os.open() because we do not intend the newly created
files to be executable. NB: we do not pass 0o644 or 0o600 here because
the unwanted access mode bits will be further pruned by the umask
which can in turn be overridden by applicable default ACLs.
Fixes: d8da208c7b
1. `flags | ...` is always true (wrong bitwise operation);
2. O_* constants are not guaranteed to be non-zero (e. g. on Linux
O_RDONLY == 0), thus simply doing a `flags & ...` is also wrong.
os.O_ACCMODE is a mask of all bits that represent the access mode;
use that to extract the access mode from flags and test it using simple
equality comparisons.
Fixes: 7890b4320e
This reverts commit 14dd33acc6.
The in-tree driver allows only setting pwmX. While this works,
the value will only be applied to the fan if the channel mode
is direct PWM. As a patch for setting that mode together with
PWM value was rejected upstream, revert this commit as setting
pwmX_enable became a hard requirement for being sure that the
value is correctly applied.
A request has been made for yoda to be packaged in Arch AUR liquidctl-git.
However, on Linux (and BSD) yoda has an extra dependency of psutil,
which is used to access the system sensors.
To avoid bloating the dependency list of liquidctl as a whole, while
still not requiring separate packages, make psutil into an optional
requirement.
The primary motivation is to allow them, and any doctests contained in
them, to be discovered by pytest. The tests fixed in 31998d666ded had
been broken for for 3 years!
The change also makes sense in more general terms, as (with the
exception of prometheus-liquidctl-exporter), the scripts are
cross-platform and therefore may run in contexts (Windows) without
support for #!.
Most issues were minor changes causes by some case changes introduced by
5f3d287fa7 ("extra: yoda: fix output casing").
However, the new early ValueError message, introduced in 912dd0ad61
("msi: support Coreliquid K360 and two similar variants (#564)"), has
been changed (slightly) once again. For simplicity, the supported
profile names are no longer supported; we can bring them back later, if
really necessary.
We have a few devices that are essentially long-term broken, due to
firmware changes. Communicate that to our users in place of the old
experimental tags.
Related: #662
In the early days of the project it was important to communicate to our
users how well they could expect a device to work with liquidctl. This
was done, for new or still unstable devices, with an `e`/experimental
note (in the supported devices table) and an `(experimental)` suffix in
their description. However, it doesn't make sense to do that anymore:
- we have many more drivers, supported devices, and contributors, and so
our capability to *accurately* gauge that, across all configurations,
use cases, firmware versions, etc, has likely degraded;
- our development pace has reduced substantially, degrading the temporal
resolution (and, thus, accuracy) of any such claim;
- and, on the other hand, *most drivers* either work well from the start
or have quickly and easily been fixed.
Exceptionally, `(experimental)` suffixes have been kept for a few
untested EVGA and ASUS GPUs, since their support require the passing of
corresponding unsafe flags to be enabled.
Serphentas