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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Using the DIR macro breaks caching and has no benefit as it only offers
performance improvements when AS_FOR is used with a single element list.
Also --with-lds-dir= was broken as we never set have_efi_lds in this case.
Fix this and check if PATH actually contains the efi-lds file.
The build would fail later anyway, so it is better to bail
out early.
Also check for the second bios file only if the first one was not
found. I'm not sure which one is preferred. If the other one, the
order should be flipped.
gcc5 introduced this option (gcc4 silently ignores it, which is fine).
Given that gcc5 thinks 'unsigned char'/'unsigned short' is promoted to
'int' for var-args, stuff like this spits out warnings:
uint8_t x;
printf("%" PRIu8", x);
gcc5 promots 'x' to 'int', instead of 'unsigned int' and thus gets a
signedness-warnings as it expects an 'unsigned int'.
glibc states otherwise: unsigneds are always promoted to 'unsigned int'.
Until gcc and glibc figure this out, lets just ignore that warning (which
is totally useless in its current form).
We should prefer the unifont.hex file from the system, instead of our
own. Upstream has made a few releases since our version was included,
and we should follow upstream changes. But adding 2.6MB to our source
repo every time upstream releases is not nice.
The old "systemd-import" binary is now an internal tool. We still use it
as asynchronous backend for systemd-importd. Since the import tool might
require some IO and CPU resources (due to qcow2 explosion, and
decompression), and because we might want to run it with more minimal
priviliges we still keep it around as the worker binary to execute as
child process of importd.
machinectl now has verbs for pulling down images, cancelling them and
listing them.
We use PY_LOG_COMPILER in Makefile.am for running *.py tests, which requires
automake's parallel test runner. This has only been the default from 1.13 on.
As we only require automake 1.11, add it as an option explicitly.
With this change the import tool will now unpack qcow2 images into
normal raw disk images, suitable for usage with nspawn.
This allows has the benefit of also allowing importing Ubuntu Cloud
images for usage with nspawn.
This directory is not used by systemd.
Tested by running a full build, running `make install` and comparing the file
list in the target trees and making sure that `make distcheck` still works.
Do not use the dbus-1.pc pkgconfig settings to determine dbus directories. Use
directories relative to ${sysconfdir} and ${datadir} instead.
This approach was suggested by Simon McVittie in:
http://lists.freedesktop.org/archives/systemd-devel/2014-October/024388.html
Tested by building and installing systemd without the dbus-devel installed.
Without this patch, the dbus files and directories end up in the root of the
filesystem. With this patch, they end up in the same locations as previously
(assuming default ${sysconfdir} and ${datadir}) whether dbus-devel is present
or not. Also made sure that `make check` works without dbus-devel installed.
I figure "pull-dck" is not a good name, given that one could certainly
read the verb in a way that might be funny for 16year-olds. ;-)
Also, don't hardcode the index URL to use, make it runtime and configure
time configurable instead.
This is useful for exposing unsafe access to mmapped objects after
the context that they were mapped in was already moved.
For example:
journal_file_move_to_object(f1, OBJECT_DATA, p1, &o1);
journal_file_move_to_object(f2, OBJECT_DATA, p2, &o2);
t = o1->object.type; /* this usually works, but is unsafe */
There will be more debugging options later.
--enable-debug will enable them all.
--enable-debug=hashmap will enable only hashmap debugging.
Also rename the C #define to ENABLE_DEBUG_* pattern.
When dbus client connects to systemd-bus-proxyd through
Unix domain socket proxy takes client's smack label and sets for itself.
It is done before and independent of dropping privileges.
The reason of such soluton is fact that tests of access rights
performed by lsm may take place inside kernel, not only
in userspace of recipient of message.
The bus-proxyd needs CAP_MAC_ADMIN to manipulate its label.
In case of systemd running in system mode, CAP_MAC_ADMIN
should be added to CapabilityBoundingSet in service file of bus-proxyd.
In case of systemd running in user mode ('systemd --user')
it can be achieved by addition
Capabilities=cap_mac_admin=i and SecureBits=keep-caps
to user@.service file
and setting cap_mac_admin+ei on bus-proxyd binary.
Choose which system users defined in sysusers.d/systemd.conf and files
or directories in tmpfiles.d/systemd.conf, should be provided depending
on comile-time configuration.
Add support for compose files to idev-keyboard. This requires
libxkbcommon-0.5.0, which is pretty new, but should be fine.
We don't use the compose-files, yet. Further commits will put life into
them.
Introduce a new optional dependency on libxkbcommon for systemd-localed.
Whenever the x11 keymap settings are changed, use libxkbcommon to compile
the keymap. If the compilation fails, print a warning so users will get
notified.
On compilation failure, we still update the keymap settings for now. This
patch just introduces the xkbcommon infrastructure to have keymap
validation in place. We can later decide if/how we want to enforce this.
The option simply enables hashmap debugging by defining
ENABLE_HASHMAP_DEBUG.
I suggest developing new code with it enabled, to have the iterator checks.
linux/memfd.h was added linux 3.17, so it might not be widely
available for a while.
Also, check if memfd_create is defined, for the HAVE_LINUX_MEMFD_H
check to have a chance of succeeding.
Also, collapse all ifdefs for memfd-related stuff, because they
were all added together so there's no need to check separately.
The grdev layer provides graphics-device access via the
libsystemd-terminal library. It will be used by all terminal helpers to
actually access display hardware.
Like idev, the grdev layer is built around session objects. On each
session object you add/remove graphics devices as they appear and vanish.
Any device type can be supported via specific card-backends. The exported
grdev API hides any device details.
Graphics devices are represented by "cards". Those are hidden in the
session and any pipe-configuration is automatically applied. Out of those,
we configure displays which are then exported to the API user. Displays
are meant as lowest hardware entity available outside of grdev. The
underlying pipe configuration is fully hidden and not accessible from the
outside. The grdev tiling layer allows almost arbitrary setups out of
multiple pipes, but so far we only use a small subset of this. More will
follow.
A grdev-display is meant to represent real connected displays/monitors.
The upper level screen arrangements are user policy and not controlled by
grdev. Applications are free to apply any policy they want.
Real card-backends will follow in later patches.
Rather than forcing gcc to always produce colorized error messages
whether on tty or not, enable automatic colorization by ensuring
GCC_COLORS is set to a non-empty string.
Doing it this way removes the need for workarounds in ~/.emacs or
~/.vimrc for "M-x compile" or ":make", respectively, to work.
