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/
