IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Error, DATA expected but got 'mouse:usb:v046dpc24c:name:Logitech G400s Optical
Gaming Mouse:' in '/etc/udev/hwdb.d/70-mouse.hwdb':
Error, MATCH expected but got ' MOUSE_DPI=400@1000 *800@1000 2000@1000
4000@1000' in '/etc/udev/hwdb.d/70-mouse.hwdb':
Introduced in 6366e349
*Autocompletion for dirs, doesn't leave until you press space.
*Added tmpfs, volatile and network-macvlan options.
I tried with the SELinux options with seinfo(setools-console), but too
messy to get it right. Even Daniel Walsh haven't done it yet. :)
Imagine a kdbus peer sending a method-call without EXPECT_REPLY set
through the proxy to a dbus1 peer. The proxy turns the missing
EXPECT_REPLY flag into a dbus1 NO_REPLY_EXPECTED flag. However, if the
receipient ignores that flag (valid dbus1 behavior) and sends a reply, the
proxy will try to forward it to the original peer. This will fail with
EPERM as the kernel didn't track the reply.
We have two options now: Either we ignore EPERM for reply messages, or we
track reply-windows in the proxy so we can properly ignore replies if
EXPECT_REPLY wasn't set.
This commit chose the first option: ignore EPERM for replies. The only
down-side is that replies without matching method call will no longer be
forwarded by the proxy. This works on dbus1, though.
Nobody sane does this, so lets ignore it.
If a caller does not request a reply, dont send it. This skips message
creation and speeds up NO_REPLY_EXPECTED cases. Note that sd-bus still
handles this case internally, but if we handle it in bus-proxyd, we can
skip the whole message creation step.
dbus1 does not provide cmdline, so we have to augment our credentials from
/proc to beautify the bus-proxyd cmdline. We dont use this for anything
but beautification, so there shouldn't be any problems due to /proc
pid-recycling races.
This fixes bus-proxyd to no longer display 'xxxxxxxxxxxxxxxxxxxxxxxxxxx'
in its cmdline.
When there are a lot of split out journal files, we might run out of fds
quicker then we want. Hence: bump RLIMIT_NOFILE to 16K if possible.
Do these even for journalctl. On Fedora the soft RLIMIT_NOFILE is at 1K,
the hard at 4K by default for normal user processes, this code hence
bumps this up for users to 4K.
https://bugzilla.redhat.com/show_bug.cgi?id=1179980
Given the write patterns on disk images, we better should turn COW off
for them. In particular as the file systems used inside the disk images
should do their own data integrity checks anyway and we don't need
multiple layers of it.
btrfs' COW logic results in heavily fragment journal files, which is
detrimental for perfomance. Hence, turn off COW for journal files as we
create them.
Turning off COW comes at the cost of data integrity guarantees, but this
should be acceptable, given that we do our own checksumming, and
generally have a pretty conservative write pattern.
Also see discussion on linux-btrfs:
http://www.spinics.net/lists/linux-btrfs/msg41001.html
So far, if we had no knowledge about the correct $TERM we defaulted to
v102, as a safe, conservative choice. However, the terminfo data for
vt102 is not aware of pageup/pagedown, which makes "less" much harder
work with than necessary. Setting vt220 allows them to work correctly.
"vt220" should be a sufficiently safe choice too, given that xterm,
gnome-terminal and the linux console all strive to implement vt220 as
baseline, already to pass pageup/pagedown correctly to apps.
Effectively, with this change "journalctl -e" run inside a
"systemd-nspawn" terminal will now run a pager where pageup/pagedown
works, which is quite an improvement of usability for containers.
