and use dedicated knobs for every option used in
former SimpleConnectProperties.
New section is [MobileNetwork] with the following configuration options:
APN=
AllowedAuthenticationMechanisms==
User=
Password=
IPFamily=
AllowRoaming=
PIN=
OperatorId=
Closes#40877. As requested, --extra-drive=path[:format] is changed
to --extra-drive=[format:]path, so that the parsing is less ambiguous.
(In the original request, it was requested that the empty format can be
used also, but that was dropped in the second version of the patch.)
Closes#40883. As described in the issue, it's not "jobs" that are
marked, and also the name is unnecessarilly long.
I think we don't need any compatibility measures here. At least in the
rpm world, package upgrade scripts go through the helper which is part
of the package so the new systemctl and the new helper are upgraded
together.
Follow-up for 93d768e0f3. The commit with
the fix didn't mention this, but the reported reproducer was:
> Install openSUSE Tumbleweed with account-utils and systemd v258.
> Compile and install systemd v260. Run "varlinkctl list-methods
> /run/account/newidmapd-socket" -> the newidmap service crashes in
> varlink_idl_format_all_fields(). Recompile newidmap with systemd v260
> headers -> varlinkctl list-methods works again.
Other people might hit the same issue, so let's mention that this was
fixed.
Could ask to Bastien Nocera who originally commited the joysticks hwdb
integration
https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1429#note_3338386
and stated that was for use in iio-sensor but later anything was done.
As the variable was never used replace it with the new variable actually
in the process to be use in libinput. Even more at least some of the
idea that was planed for ID_INPUT_JOYSTICK_INTEGRATION could be done in
libinput.
Actually ID_INPUT_JOYSTICK_INTEGRATION was never used anywhere, replace
it with ID_INTEGRATION.
Follow up: a4381cae8b.
We've changed them to return additional values, which may be a breaking
change for desktop environments. In practice, it doesn't seem to be a
major issue. However, let's make sure to document the changes in the
NEWS anyway!
xfsprogs 6.17.0 added support for populating xfs filesystems from
directories. As this supports extended attributes unlike our current
hack with protofiles. Let's make use of the new feature in mkfs-util.c
As there's no clean way to do feature detection on the mkfs.xfs binary,
we drop support for the old hack with protofiles that we had before.
Change the default udev rule for /dev/ptp* from 0660 to 0664,
allowing unprivileged users read-only access.
NIC telemetry and hardware logs often use device timestamps that must
be correlated with host time via read-only PTP ioctls (e.g.
cross-timestamp queries). Requiring privileged access makes these
workflows unnecessarily restrictive.
Older kernels lacked proper permission checks in some PTP ioctls.
Kernel commit b4e53b15c04e3852949003752f48f7a14ae39e86 ("ptp: Add PHC
file mode checks. Allow RO adjtime() without FMODE_WRITE.") introduces
the necessary file mode validation, ensuring that read access does not
permit clock modification or configuration changes, which still require
write permissions.
This commit has been backported to all actively maintained stable
kernel branches.
Related to #31034
In 5c05a339c6 I retroactively changed the NEWS
entry for v259. But this is very confusing, because it looks like the original
change never happened and it's not clear what is being reverted.
Let's restore the original text, and just add a short note, but then move
the new text to the section for v260.
Actually GNOME sets a clamp of 1% and divides in 20 steps the brightness
control. Using 5% clamp makes things like in a device with max value 640
to always be in the first brightness step in GNOME and we can't leave in
the minimum.
GNOME set steps of 640/20 = 32 with the zero step 640 * 1% = 6. When we
restart the device with the lowest bright systemd sees 6 but sets
640 * 5% = 32, so we get the brightness in the first step.
Tests in IPS and OLED panels have been done and 1% still seems a
comprensive minimun usable value so use that to allow all environments
to be able to set lower brightness values that won't be raised by
systemd at boot.
If your user enviroment allow to set excesive lower unusable values you
should blame it or yourself if you directle changes it through sysfs but
not systemd.
This reverts (in spirit) "network/tuntap: deny from owning Tun/Tap interfaces",
commit 940441b44c.
Justification similar as in the previous commit. The check is only
partially connected to the intended purpose and breaks backwards compat
without a sufficient reason.
Alternative fix for #37279.
This reverts (in sprit) commit f5cdf9515a,
"udev-rules: ignore non-system user/group in OWNER=/GROUP=".
The original change was done to clean up a situation where we added a
new group, but the group could already have been used for some other
purposes, and now the some unexpected entity would own the device.
Unfortunately, this check doesn't really address the issue, since the
existing account might as well be a system account, which might be
equally bad. In addition, this change is a big compatiblity break,
causing existing rules to stop working. Since quite a lot of systems
have local configuration to assign devices to users for various
purposes, this is very noticable to users. In a way, the original change
to add a new group was the compat break, and follow-up patch to cahnge
the rule parsing evolved a small compat break into a much bigger one.
There is merit to the change though, since device nodes shouldn't be
owned by users and groups and different mechanisms should be used
instead. To avoid breaking users systems, and since the original goal
cannot be achieved by this patch, let's downgrade this to a warning
to guide users towards different solutions.
Luca Boccassi
Oleksandr Andrushchenko
Lennart Poettering
Zbigniew Jędrzejewski-Szmek
Christopher Cooper
Adrian Vovk
Daan De Meyer
Yu Watanabe
DaanDeMeyer
David Santamaría Rogado
Carolina Jubran
Mike Yuan
Jörg Behrmann