Like many other recent thinkpads the factory default pointingstick
sensitivity on these devices is quite low, making the pointingstick
very slow in moving the cursor.
This extends the existing hwdb rules for tweaking the sensitivity to
also apply to the X1 Tablet models.
Signed-off-by: Dennis Wassenberg <dennis.wassenberg@secunet.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1374371
When root was empty or equal to "/", chroot_symlinks_same was called with
root==NULL, and strjoina returned "", so the code thought both paths are equal
even if they were not. Fix that by always providing a non-null first argument
to strjoina.
If the unit is in the dbus queue when it is removed then the last change
signal is never sent. Fix this by checking the dbus queue and explicitly
send the change signal before sending the remove signal.
In https://github.com/systemd/systemd/pull/4004 , a runtime detection
method for seccomp was added. However, it does not detect the case
where CONFIG_SECCOMP=y but CONFIG_SECCOMP_FILTER=n. This is possible
if the architecture does not support filtering yet.
Add a check for that case too.
While at it, change get_proc_field usage to use PR_GET_SECCOMP prctl,
as that should save a few system calls and (unnecessary) allocations.
Previously, reading of /proc/self/stat was done as recommended by
prctl(2) as safer. However, given that we need to do the prctl call
anyway, lets skip opening, reading and parsing the file.
Code for checking inspired by
https://outflux.net/teach-seccomp/autodetect.html
ethtool_sset_info adding some extra space to it.
also fix valgrind warning
```
Unloaded link configuration context.
==31690==
==31690== HEAP SUMMARY:
==31690== in use at exit: 8,192 bytes in 2 blocks
==31690== total heap usage: 431 allocs, 429 frees, 321,164 bytes allocated
==31690==
==31690== 4,096 bytes in 1 blocks are still reachable in loss record 1 of 2
==31690== at 0x4C2BBAD: malloc (vg_replace_malloc.c:299)
==31690== by 0x166B32: mempool_alloc_tile (mempool.c:62)
==31690== by 0x166BBC: mempool_alloc0_tile (mempool.c:81)
==31690== by 0x15B8FC: hashmap_base_new (hashmap.c:732)
==31690== by 0x15B9F7: internal_hashmap_new (hashmap.c:766)
==31690== by 0x151291: conf_files_list_strv_internal (conf-files.c:103)
==31690== by 0x1514BA: conf_files_list_strv (conf-files.c:135)
==31690== by 0x13A1CF: link_config_load (link-config.c:227)
==31690== by 0x135B68: builtin_net_setup_link_init
(udev-builtin-net_setup_link.c:77)
==31690== by 0x1306B3: udev_builtin_init (udev-builtin.c:57)
==31690== by 0x11E984: adm_builtin (udevadm-test-builtin.c:72)
==31690== by 0x117B4D: run_command (udevadm.c:75)
```
Fixes#4080
Prior to this commit, users could be given an unusable command to run if
they attempted to stop or start special services. For example:
$ systemctl stop -- -.mount
Failed to stop -.mount: Operation refused, unit -.mount may be \
requested by dependency only.
See system logs and 'systemctl status -.mount' for details.
$ systemctl status -.mount
systemctl: invalid option -- '.'
This adds a '--' to the example command in these situations.
Let's bump it further, as this the current limit turns out to be problematic
IRL. Let's bump it to more than twice what we know of is needed.
Fixes: #4068
This splits the OS field in two : one for the distribution name
and one for the the version id.
Dashes are written for missing fields.
This also prints ip addresses of known machines. The `--max-addresses`
option specifies how much ip addresses we want to see. The default is 1.
When more than one address is written for a machine, a `,` follows it.
If there are more ips than `--max-addresses`, `...` follows the last
address.
Flushing foreign configuration for unmanaged interfaces is outright
evil, especially when it's a regular occurence with Wi-Fi.
Fixes: 3104883ddc "networkd: remove route if carrier is lost"
Ref: #3831
'continue' is a fancy no-op here – it only skips through the inner loop,
not the outer one, so entries already in BootOrder get printed twice.
This partially reverts f939cff715 "bootctl: various coding style
updates".
fileio makes use of O_TMPFILE when it is available.
We now always have O_TMPFILE, defined in missing.h if missing
from the toolchain headers.
Have fileio include missing.h and drop the guards around the
use of O_TMPFILE.
Currently, a missing __O_TMPFILE was only defined for i386 and x86_64,
leaving any other architectures with an "old" toolchain fail miserably
at build time:
src/import/export-raw.c: In function 'reflink_snapshot':
src/import/export-raw.c:271:26: error: 'O_TMPFILE' undeclared (first use in this function)
new_fd = open(d, O_TMPFILE|O_CLOEXEC|O_NOCTTY|O_RDWR, 0600);
^
__O_TMPFILE (and O_TMPFILE) are available since glibc 2.19. However, a
lot of existing toolchains are still using glibc-2.18, and some even
before that, and it is not really possible to update those toolchains.
Instead of defining it only for i386 and x86_64, define __O_TMPFILE
with the specific values for those archs where it is different from the
generic value. Use the values as found in the Linux kernel (v4.8-rc3,
current as of time of commit).
---
Note: tested on ARM (build+run), with glibc-2.18 and linux headers 3.12.
Untested on other archs, though (I have no board to test this).
Changes v1 -> v2:
- add a comment specifying some are hexa, others are octal.
