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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
The idev-keyboard object provides keyboard devices to the idev interface.
It uses libxkbcommon to provide proper keymap support.
So far, the keyboard implementation is pretty straightforward with one
keyboard device per matching evdev element. We feed everything into the
system keymap and provide proper high-level keyboard events to the
application. Compose-features and IM need to be added later.
The evdev-element provides linux evdev interfaces as idev-elements. This
way, all real input hardware devices on linux can be used with the idev
interface.
We use libevdev to interface with the kernel. It's a simple wrapper
library around the kernel evdev API that takes care to resync devices
after kernel-queue overflows, which is a rather non-trivial task.
Furthermore, it's a well tested interface used by all other major input
users (Xorg, weston, libinput, ...).
Last but not least, it provides nice keycode to keyname lookup tables (and
vice versa), which is really nice for debugging input problems.
Make sure we format UTF-8 labels as IDNA when writing them to DNS
packets, and as native UTF-8 when writing them to mDNS or LLMNR packets.
When comparing or processing labels always consider native UTF-8 and
IDNA formats equivalent.
intltool is needed for nls _and_ polkit, thus the check needs to be
changed to do the test whenever one of them is enables.
Without this build fails when configured with
--disable-nls --enable-polkit
This commit introduces libsystemd-ui, a systemd-internal helper library
that will contain all the UI related functionality. It is going to be used
by systemd-welcomed, systemd-consoled, systemd-greeter and systemd-er.
Further use-cases may follow.
For now, this commit only adds terminal-page handling based on lines only.
Follow-up commits will add more functionality.
A new tool "systemd-firstboot" can be used either interactively on boot,
where it will query basic locale, timezone, hostname, root password
information and set it. Or it can be used non-interactively from the
command line when prepareing disk images for booting. When used
non-inertactively the tool can either copy settings from the host, or
take settings on the command line.
$ systemd-firstboot --root=/path/to/my/new/root --copy-locale --copy-root-password --hostname=waldi
The tool will be automatically invoked (interactively) now on first boot
if /etc is found unpopulated.
This also creates the infrastructure for generators to be notified via
an environment variable whether they are running on the first boot, or
not.
Add liblz4 as an optional dependency when requested with --enable-lz4,
and use it in preference to liblzma for journal blob and coredump
compression. To retain backwards compatibility, XZ is used to
decompress old blobs.
Things will function correctly only with lz4-119.
Based on the benchmarks found on the web, lz4 seems to be the best
choice for "quick" compressors atm.
For pkg-config status, see http://code.google.com/p/lz4/issues/detail?id=135.
IT_PROG_INTLTOOL makes configure fail if intltool is not present. If we can
not find intltool, then disable NLS (otherwise make in po/ fails since MSGFMT
will not be defined.)
Tested: Built it on a host without intltool.
$ ./configure --enable-nls
...
checking for intltool-merge... no
configure: error: --enable-nls requested but intltool not found
$ ./configure --disable-polkit
...
checking for intltool-merge... no
configure: WARNING: *** Disabling NLS support because intltool was not found
checking whether NLS is requested... no
...
$ make
https://bugs.freedesktop.org/show_bug.cgi?id=79692
In particular, disable intltool when --disable-nls is passed to configure.
Tested: Built it on a host without intltool or gettext.
$ ./configure --disable-nls --disable-polkit
$ make
The recently added stacktrace support in 8d4e028f uses functions added
in elfutils 158. Check for one of the new functions to avoid attempting
to build against older versions.
We used to check if e.g. IFLA_BOND_MAX is defined and provide fallback
values in missing.h is it wasn't. But over time, various kernel
versions added IFLA_* defines, so checking for IFLA_BOND_MAX is not
enough if the kernel is new enough to have some of them but too old to
have all. In case we detect that the latest known enum value is
missing, #define most of them.
https://bugs.freedesktop.org/show_bug.cgi?id=80095
Be verbose when checking if Python module lxml is available. Also warn that
Python support will be disabled when the lxml module is not present.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=80005
Tested:
- Without python-lxml package installed:
$ ./configure
checking for python extension module directory... ${exec_prefix}/lib64/python2.7/site-packages
checking for python lxml module... no
configure: WARNING: *** python support requires python-xml module installed
- With python-lxml package installed:
$ ./configure
checking for python extension module directory... ${exec_prefix}/lib64/python2.7/site-packages
checking for python lxml module... yes
checking for PYTHON_DEVEL... yes
...
Python: yes
Python Headers: yes
systemd-sysusers is a tool to reconstruct /etc/passwd and /etc/group
from static definition files that take a lot of inspiration from
tmpfiles snippets. These snippets should carry information about system
users only. To make sure it is not misused for normal users these
snippets only allow configuring UID and gecos field for each user, but
do not allow configuration of the home directory or shell, which is
necessary for real login users.
The purpose of this tool is to enable state-less systems that can
populate /etc with the minimal files necessary, solely from static data
in /usr. systemd-sysuser is additive only, and will never override
existing users.
This tool will create these files directly, and not via some user
database abtsraction layer. This is appropriate as this tool is supposed
to run really early at boot, and is only useful for creating system
users, and system users cannot be stored in remote databases anyway.
The tool is also useful to be invoked from RPM scriptlets, instead of
useradd. This allows moving from imperative user descriptions in RPM to
declarative descriptions.
The UID/GID for a user/group to be created can either be chosen dynamic,
or fixed, or be read from the owner of a file in the file system, in
order to support reconstructing the correct IDs for files that shall be
owned by them.
This also adds a minimal user definition file, that should be
sufficient for most basic systems. Distributions are expected to patch
these files and augment the contents, for example with fixed UIDs for
the users where that's necessary.
systemd fails to build (symbols not found/resolved during cgls link step)
under gcc-4.9.0 due to link-time optimization (lto) changes, in particular
from gcc-4.9.0/NEWS:
+ When using a linker plugin, compiling with the -flto option
now generates slim objects files (.o) which only contain
intermediate language representation for LTO. Use
-ffat-lto-objects to create files which contain additionally
the object code. To generate static libraries suitable for LTO
processing, use gcc-ar and gcc-ranlib; to list symbols from a
slim object file use gcc-nm. (Requires that ar, ranlib and nm
have been compiled with plugin support.)
Both -flto and -ffat-lto-objects are now needed when building and linking
against static libs w/LTO.
Instead of accessing /proc/1/environ directly, trying to read the
$container variable from it, let's make PID 1 save the contents of that
variable to /run/systemd/container. This allows us to detect containers
without the need for CAP_SYS_PTRACE, which allows us to drop it from a
number of daemons and from the file capabilities of systemd-detect-virt.
Also, don't consider chroot a container technology anymore. After all,
we don't consider file system namespaces container technology anymore,
and hence chroot() should be considered a container even less.
We shouldn't destroy IPC objects of system users on logout.
http://lists.freedesktop.org/archives/systemd-devel/2014-April/018373.html
This introduces SYSTEM_UID_MAX defined to the maximum UID of system
users. This value is determined compile-time, either as configure switch
or from /etc/login.defs. (We don't read that file at runtime, since this
is really a choice for a system builder, not the end user.)
While we are at it we then also update journald to use SYSTEM_UID_MAX
when we decide whether to split out log data for a specific client.
tcpwrap is legacy code, that is barely maintained upstream. It's APIs
are awful, and the feature set it exposes (such as DNS and IDENT
access control) questionnable. We should not support this natively in
systemd.
Hence, let's remove the code. If people want to continue making use of
this, they can do so by plugging in "tcpd" for the processes they start.
With that scheme things are as well or badly supported as they were from
traditional inetd, hence no functionality is really lost.
If --trust=ca.crt is used, only clients presenting certificates signed
by the ca will be allowed to proceed. No hostname matching is
performed, so any client wielding a signed certificate will be
authorized.
Error functions are moved from journal-gateway to microhttp-util and
made non-static, since now they are used in two source files.
This way each user allocates from his own pool, with its own size limit.
This puts the size limit by default to 10% of the physical RAM size but
makes it configurable in logind.conf.
The release tarballs ship with pre-generated man pages, so we do not
need xsltproc for a typical end-user build.
Developers will probably have xsltproc anyway, but if not they will now
encounter a build-time failure instead of an error in configure.
This permit to switch to a specific apparmor profile when starting a daemon. This
will result in a non operation if apparmor is disabled.
It also add a new build requirement on libapparmor for using this feature.
Debian Stable is still using glibc 2.13, which doesn't provide the setns().
So we detect this and provide a tiny wrapper that issues the setns syscall
towards the kernel.
- Allow configuration of an errno error to return from blacklisted
syscalls, instead of immediately terminating a process.
- Fix parsing logic when libseccomp support is turned off
- Only keep the actual syscall set in the ExecContext, and generate the
string version only on demand.
gold doesn't exhibit the problems with linking of compatibility
libraries.
It is also slightly faster:
make clean && make -j5 bfd gold
real 34.885s 33.707s
user 34.486s 32.189s
sys 9.929s 10.845s
real 35.128s 33.508s
user 34.660s 31.858s
sys 10.798s 10.341s
real 35.405s 33.748s
user 34.765s 32.384s
sys 11.635s 10.998s
real 35.250s 33.795s
user 34.704s 32.253s
sys 11.220s 11.469s
touch src/libsystemd/sd-bus.c && make -j5
bfd gold
real 10.224s 9.030s
user 11.664s 9.877s
sys 3.431s 2.878s
real 10.021s 9.165s
user 11.526s 9.990s
sys 3.061s 3.015s
real 10.233s 8.961s
user 11.657s 9.973s
sys 3.467s 2.202s
real 10.160s 9.086s
user 11.637s 9.950s
sys 3.188s 2.859s
It is nicer to predefine patterns using configure time check instead of
using casts everywhere.
Since we do not need to use any flags, include "%" in the format instead
of excluding it like PRI* macros.
Even if the lower-leveld dbus1 protocol calls it "serial", let's expose
the word "cookie" for this instead, as this is what kdbus uses and since
it doesn't imply monotonicity the same way "serial" does.
systemd-bus-driverd is a small daemon that connects to kdbus and
implements the org.freedesktop.DBus interface. IOW, it provides the bus
functions traditionally taken care for by dbus-daemon.
Calls are proxied to kdbus, either via libsystemd-bus (were applicable)
or with the open-coded use of ioctl().
Note that the implementation is not yet finished as the functions to
add and remove matches and to start services by name are still missing.
Since we want to retain the ability to break kernel ←→ userspace ABI
after the next release, let's not make use by default of kdbus, so that
people with future kernels will not suddenly break with current systemd
versions.
kdbus support is left in all builds but must now be explicitly requested
at runtime (for example via setting $DBUS_SESSION_BUS). Via a configure
switch the old behaviour can be restored. In fact, we change autogen.sh
to do this, so that git builds (which run autogen.sh) get kdbus by
default, but tarball builds (which ue the configure defaults) do not get
it, and hence this stays out of the distros by default.
This reverts commit f1a1264d13.
We can turn this off with a pragma only on old gcc. Newer gcc doesn't
need this, so let's not turn this off for everybody.
This allows make rules for generated build files (i.e. configure,
Makefile.in, ... ) to be skipped. This is useful when
the source is stored without timestamps (for example in CVS or GIT).
When the build rules trigger to regenerate the build files, it tries to
use the same autotools version (currently 1.14) as was originally used
for the release. Since many of our build machines run Debian Squeeze,
they only have autotools 1.11 available and the build fails.
Currently, we have to work around this by touching all the generated
files before building to avoid triggering the make rule. With this
patch, we would be able to just run configure with
--disable-maintainer-mode instead. The patch sets the default to enable
to not change the default behavior.
Ref: http://git.kernel.org/cgit/utils/kernel/kmod/kmod.git/commit/
?id=f5cc26c77d2f332a9b40f51f0ec72e95711edf1e
For GNOME (Continuous), we are unlikely to require or want
systemd-networkd in the near term future; all of the tools and code
are targeting NetworkManager.
The long term story is still an open question of course, but for now,
there's no reason for gnome-continuous to build or ship this.
Older gcc versions throw things like:
In file included from /usr/include/fcntl.h:302:0,
from ../src/core/execute.c:25:
In function 'open',
inlined from 'open_null_as' at ../src/core/execute.c:196:12:
/usr/include/bits/fcntl2.h:50:24: error: call to '__open_missing_mode'
declared with attribute error: open with O_CREAT in second argument needs 3 arguments
__open_missing_mode ();
Allows the systemd --system process to change its current
SMACK label to a predefined custom label (usually "system")
at boot time.
This is needed to have a few system-generated folders and
sockets automatically be created with the right SMACK
label. Without that, processes either cannot communicate with
systemd or systemd fails to perform some actions.
Enabling address sanitizer seems like a useful thing, but is quite
tricky. Proper flags have to be passed to CPPFLAGS, CFLAGS and
LDFLAGS, but passing them on the commandline doesn't work because
we tests are done with ld directly, and not with libtool like in
real linking. We might want to fix this, but let's add a handy
way to enable address checking anyway.
The modules should build just fine, but AM_PATH_PYTHON sets
pkgpyexecdir for us. Without that variable we don't know where to
install modules. In addition libtool tries an empty rpath, breaking
the build. Those issues could be fixed or worked around, but we
probably don't have many people who want to avoid using python binary,
but want to compile python modules. If such uses ever come up, this
issue should be revisited.
systemd-logind will start user@.service. user@.service unit uses
PAM with service name 'systemd-user' to perform account and session
managment tasks. Previously, the name was 'systemd-shared', it is
now changed to 'systemd-user'.
Most PAM installations use one common setup for different callers.
Based on a quick poll, distributions fall into two camps: those that
have system-auth (Redhat, Fedora, CentOS, Arch, Gentoo, Mageia,
Mandriva), and those that have common-auth (Debian, Ubuntu, OpenSUSE).
Distributions that have system-auth have just one configuration file
that contains auth, password, account, and session blocks, and
distributions that have common-auth also have common-session,
common-password, and common-account. It is thus impossible to use one
configuration file which would work for everybody. systemd-user now
refers to system-auth, because it seems that the approach with one
file is more popular and also easier, so let's follow that.
As many laptops don't save/restore screen brightness across reboots,
let's do this in systemd with a minimal tool, that restores the
brightness as early as possible, and saves it as late as possible. This
will cover consoles and graphical logins, but graphical desktops should
do their own per-user stuff probably.
This only touches firmware brightness controls for now.
Moved zsh shell completion to shell-completion/zsh/_systemd for
automake's sake. Also allow users to specify where the files should go
with::
./configure --with-zshcompletiondir=/path/to/some/where
and by default going to `$datadir/zsh/site-functions`
Python 2.7, and 3.2 and higher support querying compilation
flags through pkg-config. This makes python support follow
rules similar to various other optional compilation-time
libraries. New flags are called PYTHON_DEVEL_CFLAGS and
PYTHON_DEVEL_LIBS, because PYTHON (without _DEVEL), is
already used for the python binary name, and things would
be confusing if the same prefix was used for two things.
configure has --disable-python-devel to disable python modules.
One advantage is that CFLAGS for modules gets smaller:
- -I/usr/include/python3.3m -I/usr/include/python3.3m -Wno-unused-result -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv
+ -I/usr/include/python3.3m
as does LIBS:
- -lpthread -ldl -lutil -lm -lpython3.3m
+ -lpython3.3m
Support for Python 2.6 is removed, but can be easily
restored by using
PYTHON_DEVEL_CFLAGS="$(python2.6-config --cflags)",
etc., as ./configure parameters.
https://bugs.freedesktop.org/show_bug.cgi?id=57800
Tcrypt uses a different approach to passphrases/key files. The
passphrase and all key files are incorporated into the "password"
to open the volume. So, the idea of slots that provide a way to
open the volume with different passphrases/key files that are
independent from each other like with LUKS does not apply.
Therefore, we use the key file from /etc/crypttab as the source
for the passphrase. The actual key files that are combined with
the passphrase into a password are provided as a new option in
/etc/crypttab and can be given multiple times if more than one
key file is used by a volume.
Enable coverage with --enable-coverage.
"make coverage" will create the report locally,
"make coverage-sync" will upload the report to
http://www.freedesktop.org/software/systemd/coverage/.
Requires lcov version 1.10 to handle naming in systemd and to
use the --no-external option.
[zj: make the coverage at least generate something with
separate build dir, simplify rules a bit: all errors
are mine. ]
This reverts commit cd3069559a.
Emacs compilation can be fixed by putting
(custom-set-variables
'(compilation-environment (quote ("GCC_COLORS="))))
in ~/.emacs.
Guys, we know that emacs is the best editor on earth, but unfortunately
its "M-x compile" terminal cannot do colors (well, it does its own
highlighting of the output anyway), and it will inform the programs it
calls about this with TERM=dumb, and gcc should check for that. But you
guys turned that off. Not cool. Let's turn it on again.
PKG_CHECK_EXISTS won't created a cached variable that later messes with
our PKG_CHECK_MODULES check for an explicit version. Unfortunately,
nesting these checks as the code existed lead to an odd error. Rather,
split the checks apart.
This also improves to the error message when the requisite version
isn't found, and supplies the literal version systemd needs.
Almost everyone wants kmod support, so don't fail silently if the libs are
out-of-date.
kmod can still be explicitly disabled and if it is not found at all, we still
default to disabling it.
As of kmod v14, it is possible to export the static node information from
/lib/modules/`uname -r`/modules.devname in tmpfiles.d(5) format.
Use this functionality to let systemd-tmpfilesd create the static device nodes
at boot, and drop the functionality from systemd-udevd.
As an effect of this we can move from systemd-udevd to systemd-tmpfiles-setup-dev:
* the conditional CAP_MKNOD (replaced by checking if /sys is mounted rw)
* ordering before local-fs-pre.target (see 89d09e1b5c)
Embedded folks don't need the machine registration stuff, hence it's
nice to make this optional. Also, I'd expect that machinectl will grow
additional commands quickly, for example to join existing containers and
suchlike, hence it's better keeping that separate from loginctl.
This brings the check for ENABLE_GTK_DOC in line with
HAVE_INTROSPECTION and other similar checks. Only
the status line that is printed with uninstalled
gtk-doc is changed.
https://bugs.freedesktop.org/show_bug.cgi?id=63108
Distributions may have selinux but not sushell or might
need to set a custom debug shell.
Defaults to /sbin/sushell if selinux is enabled, /bin/sh if not.
[zj: Renamed --with-debugshelltty to --with-debug-tty, and
added a line in output showing DEBUGSHELL and DEBUGTTY.
I figure that debug shell is pretty useful, and I hope
the extra line in configure status will draw attention
to it.]
This patch adds --disable-tests to configure. It is based on a patch
posted by Thierry Reding in 2010. The motivation for adding it is that
some tests fail link-time when cross-compiling.
The patch adds a new Makefile variable -- manual_tests -- and uses
that instead of noinst_PROGRAMS. However, if ENABLE_TESTS is true,
the former is added to the latter. It also renames noinst_tests to
simply tests.
* using AC_PATH_TOOL does not allow to override it from shell environment
which is useful when cross-compiling
* with external toolchain I have different HOST_PREFIX and HOST_SYS
AC_PATH_TOOL is using HOST_SYS as prefix and fails to find objcopy
which is available only as ${TARGET_PREFIX}-objcopy then it tries
objcopy without prefix which is found on host, but that objcopy
does not work for !host (e.g. arm when building on x86) libs
Distributions that never shipped upstart do not have
"telinit" in /lib/upstart/..
Defaults to /lib/upstart/telinit so there is no change
for systems existing installs.
use readlink -m instead of -f since we might be building in a minimal
chroot where those directories do not actually exist and readlink -f
would return an empty string.
* python-systemd-reader:
python-systemd: rename Journal to Reader
build-sys: upload python documentation to freedesktop.org
systemd-python: add Journal class for reading journal
python: build html docs using sphinx
journalct: also print Python code in --new-id
python: utilize uuid.UUID in logging
python: add systemd.id128 module
... and 34 other commits
In short: python module systemd.id128 is added, and existing
systemd.journal gains a new class systemd.journal.Reader, which can be
used to iterate over journal entries. Documentation is provided, and
accessible under e.g.
pydoc3 systemd.journal.Reader
or
firefox http://www.freedesktop.org/software/systemd/man/python-systemd/
Both gtk-doc and intltoolize have problems with VPATH builds.
"Creatively" disable tests when configuring from outside the
source directory.
This more-or-less reverts 9795da43c.
This patch only adds one line, but moves python detection
after cflags detection, so the result of the latter can
be used in the former.
$PYTHON_CFLAGS usually includes -D_FORTIFY_SOURCE, which will generate
a warning when compiling without optimization. Avoid by undefining
_FORTIFY_SOURCE.
Rather then force the user to undefine _FORTIFY_SOURCE,
don't define it in the first place if it cannot be used.
I'm assuming that -O* can only be sensibly specified in $CFLAGS.
Bootchart is renamed to 'systemd-bootchart' and installed as
/usr/lib/systemd/systemd-bootchart. The configuration file
will reside in /etc/systemd/bootchart.conf.
Note that there are still some rome for cleanups. In particular,
the .la files are now installed, which we probably don't want; and
some of the macros in Makefile.am are likely redundan.
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.
