| Age | Commit message (Collapse) | Author |
|---|
|
In case of scripts, _EXE is set to the interpreter name, and
_COMM is set based on the file name. Add a match for _COMM,
and _EXE if the interpreter is not a link (e.g. for yum,
the interpreter is /usr/bin/python, but it is a link to
/usr/bin/python2, which in turn is a link to /usr/bin/python2.7,
at least on Fedora, so we end up with _EXE=/usr/bin/python2.7).
I don't think that such link chasing makes sense, because
the final _EXE name is more likely to change.
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=67273
|
|
src/python-systemd/_reader.c: In function Reader_get_catalog:
src/python-systemd/_reader.c:912:53: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
assert(mid_len > l);
^
|
|
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
|
|
|
|
|
|
"systemctl load" has always been racy since the GC could hit any time,
before making use of the loaded unit. Very recent systemd will run GC
immeidately after all unit state changes which has the effect that the
the effect of "systemctl load" is completely gone now, so let's remove
the support for it in "systemctl" for good.
|
|
"systemctl set-log-level" is a command for analysis and tracing hence
"systemd-analyze" should be the better home for it, thus allowing us to
make the overly large "systemctl" a bit smaller.
|
|
It's an analysis command and its format is explicitly not covered by any
stability guarantees, hence move away from systemctl and into
systemd-analyze, minimizing the already large interface of systemctl a
bit.
This patch also adds auto-paging to the various systemd-analyze commands
where that makes sense
|
|
|
|
Avoid pulling-in selinux for tools which just create directories
but not need to fix the selinux label.
|
|
|
|
Fixes Arch Linux bug: https://bugs.archlinux.org/task/36259
|
|
The opposite of --prefix, allows specifying path prefixes which should
be skipped when processing rules.
|
|
|
|
Don't set default permissions if only TAGS were specified in a rule.
|
|
|
|
|
|
Spotted by uau in #systemd.
|
|
Support for writing to cgroup.procs was introduced in 3.0
|
|
message
|
|
Previously, the logging sockets were asynchronous and if clogged we'd
lose messages. We did this to be extra careful given that PID 1 might
need to spawn the logging daemon as response to PID 1's own log messages
and we really should avoid a deadlock in that case.
As it turns out this causes loss of too many messages, hence make the
socket blocking again, however put a time limit on it to avoid unbounded
deadlocks in the unlikely case they happen.
https://bugs.freedesktop.org/show_bug.cgi?id=66664
|
|
No sense in keeping this around if support for reading RD_TIMESTAMP has
been removed.
|
|
|
|
|
|
See edeb68c53f1cdc452016b4c8512586a70b1262e3.
|
|
|
|
|
|
|
|
|
|
|
|
Without this, tmpfiles-setpu-dev would be re-run if any other service,
which pulls in basic.target, was started after setup-dev was finished
and before basic.target was active.
|
|
|
|
This includes regularly-submitted corrections to comma setting and
orthographical mishaps that appeared in man/ in recent commits.
|
|
|
|
|
|
|
|
|
|
On Sat, Jul 20, 2013 at 12:56 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> After a recent change present in 3.11-rc1 there is a driver, called processor,
> that can be bound to the CPU devices whose sysfs directories are located under
> /sys/devices/system/cpu/. A side effect of this is that, after the driver has
> been bound to those devices, the kernel adds DRIVER=processor to ENV for CPU
> uevents and they don't match the default rule for autoloading modules matching
> MODALIAS:
>
> DRIVER!="?*", ENV{MODALIAS}=="?*", IMPORT{builtin}="kmod load $env{MODALIAS}"
>
> any more. However, there are some modules whose module aliases match specific
> CPU features through the modalias string and those modules should be loaded
> automatically if a compatible CPU is present. Yet, with the processor driver
> bound to the CPU devices the above rule is not sufficient for that, so we need
> a new default udev rule allowing those modules to be autoloaded even if the
> CPU devices have drivers.
|
|
Yesterday I added test-suite.log as dependency to the .PRECIOUS
target. Automake is warning about this target being redefined
and from what I see there is no way I can stop the warning but
I can add the %MAKEFILE% as dependency.
automake warning:
Makefile.am:35: warning: user target '.PRECIOUS' defined here ...
/usr/share/automake-1.13/am/configure.am: ... overrides Automake target '.PRECIOUS' defined here
[zj: s/%MAKEFILE%/Makefile/ because %MAKEFILE% wasn't actually substituted properly.]
|
|
|
|
units at the same time
|
|
|
|
|
|
|
|
|
|
--dump-configuration-items" shows
|
|
|
|
|
|
|
