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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Commit c4eb236a2c didn't take into account the situation when the user
sets e.g. PYTHON=python3 (without the full path). This value would
then be used verbatim for PYTHON_BINARY and in she-bang lines in
scripts, which is incorrect. To fix this, $PYTHON is passed through
which, which expands the path. If $PYTHON_BINARY is desired which is
not installed on the build system, then PYTHON_BINARY must be set
separately.
Python binary used in the she-bang line in installed
scripts can be set with ./configure PYTHON_BINARY=...
Defaults to the same path as python used during compilation.
Adding --version makes systemd-analyze behave consistently with the
rest of installed programs.
The lines in ./configure output are reordered to keep all yes/no lines
separate. I think that this makes the output clearer.
This also drops automatic selection of the rc local scripts
based on the local distro. Distributions now should specify the paths
of the rc-local and halt-local scripts on the configure command line.
TARGET_UBUNTU is effectively the same as TARGET_DEBIAN. Given the Ubuntu
is unlikely to use systemd anytime soon there's no point in keeping this
separate.
I'm building systemd for an embedded system and we would prefer not having
to include the entire util-linux package just to get a libblkid whose
functionality we don't need.
This is the usual setup, where pythonX.Y and pythonX.Y-config go
together. Using python-config with python3 will only lead to
confusion.
--libs is changed to --ldflags, since the latter also includes other
required flags like -L<dir>.
The tests for HAVE_PYTHON and HAVE_PYTHON_DEVEL are separated. It is
possible to have python development libraries installed without the
binary (or to want to build python modules without using python during
the build).
A line is added to the output, to show what flags will be used for
python.
Being able to be explicit about Python support (in addition to the
default of auto-detecting it) and acting upon the result, specifying
it as an option gains us more control about both dependencies and
the resulting build.
Furthermore, relying purely on auto-detection can lead to problems for
source-based distros. E. g. systemd being built before *both* 32-bit &
64-bit ABIs are installed will lead to build failures as systemd's
build system will pick up either 32-/64-bit Python, conclude both are
available and fail if that's not the case.
This minimal HTTP server can serve journal data via HTTP. Its primary
purpose is synchronization of journal data across the network. It serves
journal data in three formats:
text/plain: the text format known from /var/log/messages
application/json: the journal entries formatted as JSON
application/vnd.fdo.journal: the binary export format of the journal
The HTTP server also serves a small HTML5 app that makes use of the JSON
serialization to present the journal data to the user.
Examples:
This downloads the journal in text format:
# systemctl start systemd-journal-gatewayd.service
# wget http://localhost:19531/entries
Same for JSON:
# curl -H"Accept: application/json" http://localhost:19531/entries
Access via web browser:
$ firefox http://localhost:19531/
./.libs/libsystemd-core.a(libsystemd_core_la-selinux-access.o):
In function "selinux_access_check":
src/core/selinux-access.c:487: undefined reference to
"selinux_check_access"
This adds forward-secure authentication of journal files. This patch
includes key generation as well as tagging of journal files,
Verification of journal files will be added in a later patch.
This is useful if your keyfile is a block device, and you want to
use a specific part of it, such as an area between the MBR and the
first partition.
This feature is documented in the Arch wiki[0], and has been supported
by the Arch initscripts, so would be nice to get this into systemd.
This requires libcryptsetup >= 1.4.2 (released 12.4.2012).
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
[0]:
<https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#
Storing_the_key_between_MBR_and_1st_partition>
The MeeGo distribution is still a supported distribution, but
will probably not see an updated version of systemd anymore.
Most of the development is focussing on Tizen now, and the
generic support for building --with-distro=other is more than
adequate enough.
This patch removes the support as a custom configuration build
target in systemd. People who are still building this for
the MeeGo distribution should build as "other" distro.
On Sat, Jun 9, 2012 at 12:46 AM, Malte Starostik <lists@malte.homeip.net> wrote:
> From: Malte Starostik <m-starostik@versanet.de>
>
> Rules get installed in $(libexecdir)/udev/, so are keymaps. Helper
> binaries go to $(rootprefix)/lib/udev though. Problem is, in the code,
> both are referenced via UDEVLIBEXECDIR which is defined to the former
> location. Result: systemd-udev can't find e.g. the keymap binary to
> apply keymaps.
We finally got the OK from all contributors with non-trivial commits to
relicense systemd from GPL2+ to LGPL2.1+.
Some udev bits continue to be GPL2+ for now, but we are looking into
relicensing them too, to allow free copy/paste of all code within
systemd.
The bits that used to be MIT continue to be MIT.
The big benefit of the relicensing is that closed source code may now
link against libsystemd-login.so and friends.
This is an S/MIME signed message
The new function ima_setup() loads an IMA custom policy from a file in the
default location '/etc/ima/ima-policy', if present, and writes it to the
path 'ima/policy' in the security filesystem. This function is executed
at early stage in order to avoid that some file operations are not measured
by IMA and it is placed after the initialization of SELinux because IMA
needs the latter (or other security modules) to understand LSM-specific
rules. This feature is enabled by default and can be disabled by providing
the option '--disable-ima' to the configure script.
Signed-off-by: Roberto Sassu <roberto.sassu@polito.it>
Acked-by: Gianluca Ramunno <ramunno@polito.it>
The text mode welcome message will only show the distro name stored
in /etc/os-release and no longer read any distro-specific files. If
/etc/os-release does not exist, 'Linux' will be printed.
When the source tree is is ./configure'd, only /etc-os-release is read
to guess the distro to build for. If /etc/os-release does not exist,
--with-distro= needs to be specified.
The way the various properties[] arrays are initialized is inefficient:
- only the .data members change at runtime, yet the whole arrays of
properties with all the fields are constructed on the stack one by
one by the code.
- there's duplication, eg. the properties of "org.freedesktop.systemd1.Unit"
are repeated in several unit types.
Fix it by moving the information about properties into static const
sections. Instead of storing the .data directly in the property, store
a constant offset from a run-time base.
The small arrays of struct BusBoundProperties bind together the constant
information with the right runtime information (the base pointer).
On my system the code shrinks by 60 KB, data increases by 10 KB.
