Hi,
On Tue, Nov 1, 2011 at 4:39 PM, Lennart Poettering
wrote:
> Hmm, let me see if I get this right: with this patch applied we'd build
> cap and selinux support into libsystemd-basic.la, but we wouldn't link
> against the respective libraries but instead do that in the binaries
> which pull in t
On Wed, Apr 4, 2012 at 10:36 AM, Daniel Drake wrote:
> But with selinux included, the task is more complicated. For example,
> label.c (part of libsystemd-basic) also uses libselinux, so we need to
> move it out somewhere else (lets say we put it in a new library:
> libsystemd-extra). But the labe
On Wed, Apr 4, 2012 at 10:53 AM, Daniel Drake wrote:
> However, dropping the link against libcap (which also includes
> libattr) would be nice. Here is a patch to do that.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.fr
On Wed, Apr 4, 2012 at 1:53 PM, Daniel Drake wrote:
>
> On Wed, Apr 4, 2012 at 10:36 AM, Daniel Drake wrote:
> > But with selinux included, the task is more complicated. For example,
> > label.c (part of libsystemd-basic) also uses libselinux, so we need to
> > move it out somewhere else (lets sa
On Wed, Apr 4, 2012 at 18:53, Daniel Drake wrote:
> On Wed, Apr 4, 2012 at 10:36 AM, Daniel Drake wrote:
>> But with selinux included, the task is more complicated. For example,
>> label.c (part of libsystemd-basic) also uses libselinux, so we need to
>> move it out somewhere else (lets say we pu
On Wed, Apr 4, 2012 at 4:52 PM, Kay Sievers wrote:
> On Wed, Apr 4, 2012 at 18:53, Daniel Drake wrote:
>> On Wed, Apr 4, 2012 at 10:36 AM, Daniel Drake wrote:
>>> But with selinux included, the task is more complicated. For example,
>>> label.c (part of libsystemd-basic) also uses libselinux, so
On Wed, Apr 4, 2012 at 21:59, Gustavo Sverzut Barbieri
wrote:
> On Wed, Apr 4, 2012 at 4:52 PM, Kay Sievers wrote:
>> It should be possible: selinux, lzma, z should not be needed. I think
>> they just appeared in the systemd tree, and did not in the udev tree.
>> There will be a lot of turnaroun
On Wed, Apr 4, 2012 at 2:02 PM, Kay Sievers wrote:
> Right, when udevadm is there, then there is udevd, which definitely
> needs all of them.
Thats a good point - and if udevd really needs them, then there's no escaping.
So I guess there is nothing to gain here :(
Daniel
Hi,
While playing with a little round-robin unit setup (two units that
conflict with each other but enable themselves by installing the same
alias), I stumbled across this assertion in pid 1.
Apr 4 22:10:06 jimmy systemd[1]: Assertion 'f =
hashmap_get(b->unit->manager->cgroup_bondings, b->path)'