Mantas Mikulėnas schreef op 30-12-2013 13:36:
On Mon, Dec 30, 2013 at 1:06 PM, Roelof Wobben wrote:
hello,
Im trying to port Cinnamon to porteus.
Porteus is a slackware based distro which work with modules.
The problem is that Cinnamon works the best with systemd and slackware
refuses to use
On Thu, Dec 19, 2013 at 5:34 PM, Umut Tezduyar Lindskog
wrote:
> It is broken when bindir is /usr/bin and /lib is not symbolic link to
> /usr/lib.
>
> bus-proxyd-install-hook:
> $(AM_V_LN)$(LN_S) -f ../../lib/systemd/systemd-bus-proxyd
> $(DESTDIR)$(bindir)/systemd-stdio-bridge
>
> Maybe
On Tue, Dec 31, 2013 at 10:11 AM, Roelof Wobben wrote:
> Mantas Mikulėnas schreef op 30-12-2013 13:36:
>>
>> On Mon, Dec 30, 2013 at 1:06 PM, Roelof Wobben wrote:
>>
>>> hello,
>>>
>>> Im trying to port Cinnamon to porteus.
>>> Porteus is a slackware based distro which work with modules.
>>>
>>>
Le lundi 30 décembre 2013 à 03:14 -0600, David Timothy Strauss a écrit :
> On Sat, Dec 28, 2013 at 10:47 AM, Michael Scherer wrote:
> > So using templated units, we could do for example :
> > SELinuxContext=staff_u:staff_r:%s_t:s0-s0:c0.c1023
>
> In the spirit of making isolation easy, it would b
В Вс, 29/12/2013 в 18:57 +0100, Zbigniew Jędrzejewski-Szmek пишет:
> Hi,
> I'd like to reopen this thread.
>
> I have been looking at our bugs [1-10, there are others too] related to
> enabling/disabling of units and following of symlinks. Currently this
> is an unintuitive mess and some changes w
On Tue, Dec 31, 2013 at 06:40:47PM +0400, Andrey Borzenkov wrote:
> В Вс, 29/12/2013 в 18:57 +0100, Zbigniew Jędrzejewski-Szmek пишет:
> > Hi,
> > I'd like to reopen this thread.
> >
> > I have been looking at our bugs [1-10, there are others too] related to
> > enabling/disabling of units and fol
On Mon, Dec 30, 2013 at 11:32 PM, Stefan Beller
wrote:
> 2 lines after the changed line we assign err to efi_get_variable(...)
> unconditionally, so it makes no sense to initialize it to some value.
> ---
> src/boot/boot-efi.c | 2 +-
Applied.
Thanks,
Kay
First of all, thank you for advice you said.
You are right, I am a novice on TCP/IP, so I had studied that for a few
days.
Now, I understand that UDS Protocol and the difference between
"Accept=true" and "Accept=false".
But What I really want to know is why the server process always waited in
the a
Convert entry_array.items[0] to host byte order prior to passing it to
chain_cache_put().
Signed-off-by: George McCollister
---
src/journal/journal-file.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
index 121b40a
struct sd_rtnl_message would keep two additional pointers into the hdr
field. Every time hdr was realloced, those pointers should be adjusted,
but weren't. It seems less error-prone to keep offsets instead.
---
Hi Tom,
this fixes errors reported by valgrind and should make the code more
robust, imo
On Tue, Dec 31, 2013 at 9:20 AM, Tony Seo wrote:
> But What I really want to know is why the server process always waited in
> the accept stage, when I executed client process for the first after system
> boot.
It may hang in accept() if the service is Accept=true and the daemon
still tries to ac
struct sd_rtnl_message would keep two additional pointers into the hdr
field. Every time hdr was realloced, those pointers should be adjusted,
but weren't. It seems less error-prone to keep offsets instead.
---
Previous version was missing some hunks...
Zbyszek
src/libsystemd-rtnl/rtnl-message.c
On Tue, Dec 31, 2013 at 3:33 AM, Michael Scherer wrote:
> I am not sure of the value of having 2 configuration file doing the same
> thing. What about
> SELinuxContext=auto , and so replace auto by some default configuration
> in that case ?
That works for me. I just like the idea of naming that
13 matches
Mail list logo
