date:20131101

Re: [systemd-devel] [PATCH] SMACK: assign * label to /tmp when using SMACK.

2013-11-01 Thread Karel Zak

On Thu, Oct 31, 2013 at 01:20:18PM -0700, Kok, Auke-jan H wrote:
   BTW, for SELinux we remove selinux specific mount options in
   userspace (in mount(8)) if the kernel does not support selinux.
 
   It help us to make command line or fstab setting independent on the
   current kernel features.
 
   Maybe we can use the same for SMACK, is there any way how to
   determine that the system uses SMACK? (/proc/something or so...).
   -- for selinux we check for /sys/fs/selinux or /selinux.
 
 Ohh yes that would be so nice.
 
 You've got your choice for detecting smack, but I like
 stat(/sys/fs/smackfs) == 0 the best so far. You can parse
 /proc/filesystems for smackfs too, but that's obviously more complex.
 This method works with 3.9 and above, as that's when we made sysfs
 hold the mount point for smackfs.
 
 I assume we're talking about this code here:
 
 https://github.com/karelzak/util-linux/blob/master/libmount/src/context_mount.c#L181

 Yes, the se_rem code (with SELinux is it tricky, because old
 kernels don't support selinux options remount, options duplication is
 problem etc.. I guess that for SMACK it will be less complex :-). 
 
 Do you have somewhere list of the smack mount options? I'll prepare
 the patch.
 
 BTW, the options should be also documented in mount.8 man page :-)

Karel


-- 
 Karel Zak  k...@redhat.com
 http://karelzak.blogspot.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] .libs/test-sched-prio failed

2013-11-01 Thread Rongqing Li




On 10/31/2013 11:44 AM, Zbigniew Jędrzejewski-Szmek wrote:

On Thu, Oct 31, 2013 at 08:05:18AM +0800, Rongqing Li wrote:



On 10/30/2013 07:10 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Wed, Oct 30, 2013 at 10:02:33AM +0800, Rongqing Li wrote:

Hi:

I am running the systemd test cases, but .libs/test-sched-prio always
failed, whether I put sched_idle_ok.service to anywhere, who can help
me? thanks

.libs/test-sched-prio
Assertion 'idle_ok-load_state == UNIT_LOADED' failed at
src/test/test-sched-prio.c:47, function main(). Aborting.
Aborted

That's interesting. *What* systemd version are you running, and *how*
exactly are you running the tests?



Thanks for your reply, I run it on a embedded linux.
and run it directly .libs/test-sched-prio, but I try to put
sched_idle_ok.service
to /lib/systemd/system/, and other places, it always failed.

The test loads the file from $(abs_top_srcdir)/test/.
Maybe try changing the assert to a printf, to see what is returned.
If it is something like -ENOENT, then maybe strace the test to see
where it is trying to load the unit from.

Zbyszek



I did not see the file is read,

open(/proc/self/mountinfo, O_RDONLY|O_CLOEXEC) = 9
epoll_ctl(3, EPOLL_CTL_ADD, 9, {EPOLLPRI, {u32=7197784, u64=7197784}}) = 0
fstat(9, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7fa0ca7b3000

lseek(9, 0, SEEK_SET)   = 0
read(9, 14 1 0:13 / / rw,relatime shared..., 1024) = 1024
read(9, ,noexec,relatime shared:10 - cgr..., 1024) = 1024
read(9, s/binfmt_misc rw,relatime shared..., 1024) = 1024
read(9, tc/localtime rw,relatime shared:..., 1024) = 692
read(9, , 1024)   = 0
open(/proc/swaps, O_RDONLY|O_CLOEXEC) = 10
epoll_ctl(3, EPOLL_CTL_ADD, 10, {EPOLLPRI, {u32=7197832, u64=7197832}}) = 0
fstat(10, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7fa0ca7b2000

lseek(10, 0, SEEK_SET)  = 0
read(10, Filename\t\t\t\tType\t\tSize\tUsed\tPrio..., 1024) = 37
read(10, , 1024)  = 0
read(10, , 1024)  = 0
writev(2, [{Assertion 'idle_ok-load_state =..., 114}, {\n, 1}], 2) 
= 115

rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(383, 383, SIGABRT)   = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=383, si_uid=0} ---
+++ killed by SIGABRT +++



more detailed
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7fa0ca7b3000

read(9, MAJOR=3\nMINOR=155\nDEVNAME=ttyyb\n, 4096) = 32
read(9, , 4096)   = 0
close(9)= 0
munmap(0x7fa0ca7b3000, 4096)= 0
readlink(/sys/devices/virtual/tty/ttyyb/subsystem, 
../../../../class/tty, 1024) = 21

open(/run/udev/data/c3:155, O_RDONLY|O_CLOEXEC) = 9
fstat(9, {st_mode=S_IFREG|0644, st_size=19, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7fa0ca7b3000

read(9, I:304731\nG:systemd\n, 4096)  = 19
read(9, , 4096)   = 0
close(9)= 0
munmap(0x7fa0ca7b3000, 4096)= 0
readlink(/sys/devices/virtual/tty/ttyyc, 0x7fffecf31360, 1024) = -1 
EINVAL (Invalid argument)
stat(/sys/devices/virtual/tty/ttyyc/uevent, {st_mode=S_IFREG|0644, 
st_size=4096, ...}) = 0

open(/sys/devices/virtual/tty/ttyyc/uevent, O_RDONLY|O_CLOEXEC) = 9
fstat(9, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7fa0ca7b3000

read(9, MAJOR=3\nMINOR=156\nDEVNAME=ttyyc\n, 4096) = 32
read(9, , 4096)   = 0
close(9)= 0
munmap(0x7fa0ca7b3000, 4096)= 0
readlink(/sys/devices/virtual/tty/ttyyc/subsystem, 
../../../../class/tty, 1024) = 21

open(/run/udev/data/c3:156, O_RDONLY|O_CLOEXEC) = 9
fstat(9, {st_mode=S_IFREG|0644, st_size=19, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7fa0ca7b3000

read(9, I:313540\nG:systemd\n, 4096)  = 19
read(9, , 4096)   = 0
close(9)= 0
munmap(0x7fa0ca7b3000, 4096)= 0
readlink(/sys/devices/virtual/tty/ttyyd, 0x7fffecf31360, 1024) = -1 
EINVAL (Invalid argument)
stat(/sys/devices/virtual/tty/ttyyd/uevent, {st_mode=S_IFREG|0644, 
st_size=4096, ...}) = 0

open(/sys/devices/virtual/tty/ttyyd/uevent, O_RDONLY|O_CLOEXEC) = 9
fstat(9, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7fa0ca7b3000

read(9, MAJOR=3\nMINOR=157\nDEVNAME=ttyyd\n, 4096) = 32
read(9, , 4096)   = 0
close(9)= 0
munmap(0x7fa0ca7b3000, 4096)= 0
readlink(/sys/devices/virtual/tty/ttyyd/subsystem, 
../../../../class/tty, 1024) = 21

open(/run/udev/data/c3:157,

Re: [systemd-devel] [PATCH] fix compiler warnings

2013-11-01 Thread Markus Mayer


On 10/31/2013 07:26 PM, Ronny Chevalier wrote:

multiple warnings like

src/socket-proxy/socket-proxyd.c: In function ‘transfer_data_cb’:
src/socket-proxy/socket-proxyd.c:237:25: warning: format ‘%ld’ expects argument 
of type ‘long int’, but argument 6 has type ‘size_t’ [-Wformat=]
  log_debug(Buffer now has %ld bytes full., 
c-buffer_filled_len);
---
  src/socket-proxy/socket-proxyd.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/socket-proxy/socket-proxyd.c b/src/socket-proxy/socket-proxyd.c
index 054a27a..34b1c15 100644
--- a/src/socket-proxy/socket-proxyd.c
+++ b/src/socket-proxy/socket-proxyd.c
@@ -129,7 +129,7 @@ static int send_buffer(struct connection *sender) {
   * it does. */
  while (sender-buffer_filled_len  sender-buffer_sent_len) {
  len = send(receiver-fd, sender-buffer + sender-buffer_sent_len, 
sender-buffer_filled_len - sender-buffer_sent_len, 0);
-log_debug(send(%d, ...)=%ld, receiver-fd, len);
+log_debug(send(%d, ...)=%zd, receiver-fd, len);
  if (len  0) {
  if (errno != EWOULDBLOCK  errno != EAGAIN) {
  log_error(Error %d in send to fd=%d: %m, 
errno, receiver-fd);
@@ -147,7 +147,7 @@ static int send_buffer(struct connection *sender) {
  sender-buffer_sent_len += len;
  }

-log_debug(send(%d, ...) completed with %lu bytes still buffered., 
receiver-fd, sender-buffer_filled_len - sender-buffer_sent_len);
+log_debug(send(%d, ...) completed with %zd bytes still buffered., 
receiver-fd, sender-buffer_filled_len - sender-buffer_sent_len);

  /* Detect a would-block state or partial send. */
  if (sender-buffer_filled_len  sender-buffer_sent_len) {
@@ -206,13 +206,13 @@ static int transfer_data_cb(sd_event_source *s, int fd, 
uint32_t revents, void *
  log_debug(Got event revents=%d from fd=%d (conn %p)., revents, fd, 
c);

  if (revents  EPOLLIN) {
-log_debug(About to recv up to %lu bytes from fd=%d 
(%lu/BUFFER_SIZE)., BUFFER_SIZE - c-buffer_filled_len, fd, c-buffer_filled_len);
+log_debug(About to recv up to %zd bytes from fd=%d 
(%zd/BUFFER_SIZE)., BUFFER_SIZE - c-buffer_filled_len, fd, c-buffer_filled_len);

  /* Receive until the buffer's full, there's no more data,
   * or the client/server disconnects. */
  while (c-buffer_filled_len  BUFFER_SIZE) {
  len = recv(fd, c-buffer + c-buffer_filled_len, 
BUFFER_SIZE - c-buffer_filled_len, 0);
-log_debug(recv(%d, ...)=%ld, fd, len);
+log_debug(recv(%d, ...)=%zd, fd, len);
  if (len  0) {
  if (errno != EWOULDBLOCK  errno != EAGAIN) {
  log_error(Error %d in recv from fd=%d: 
%m, errno, fd);
@@ -232,9 +232,9 @@ static int transfer_data_cb(sd_event_source *s, int fd, 
uint32_t revents, void *
  }

  assert(len  0);
-log_debug(Recording that the buffer got %ld more bytes 
full., len);
+log_debug(Recording that the buffer got %zd more bytes 
full., len);
  c-buffer_filled_len += len;
-log_debug(Buffer now has %ld bytes full., 
c-buffer_filled_len);
+log_debug(Buffer now has %zd bytes full., 
c-buffer_filled_len);
  }

  /* Try sending the data immediately. */



According to the 'man 3 printf' %zd refers to ssize_t to print out 
size_t you should use %zu.



Regards

Markus
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] fix compiler warnings

2013-11-01 Thread Ronny Chevalier

Yes, already fixed by David

2013/11/1 Markus Mayer lotharl...@gmx.de:
 On 10/31/2013 07:26 PM, Ronny Chevalier wrote:

 multiple warnings like

 src/socket-proxy/socket-proxyd.c: In function ‘transfer_data_cb’:
 src/socket-proxy/socket-proxyd.c:237:25: warning: format ‘%ld’ expects
 argument of type ‘long int’, but argument 6 has type ‘size_t’ [-Wformat=]
   log_debug(Buffer now has %ld bytes full.,
 c-buffer_filled_len);
 ---
   src/socket-proxy/socket-proxyd.c | 12 ++--
   1 file changed, 6 insertions(+), 6 deletions(-)

 diff --git a/src/socket-proxy/socket-proxyd.c
 b/src/socket-proxy/socket-proxyd.c
 index 054a27a..34b1c15 100644
 --- a/src/socket-proxy/socket-proxyd.c
 +++ b/src/socket-proxy/socket-proxyd.c
 @@ -129,7 +129,7 @@ static int send_buffer(struct connection *sender) {
* it does. */
   while (sender-buffer_filled_len  sender-buffer_sent_len) {
   len = send(receiver-fd, sender-buffer +
 sender-buffer_sent_len, sender-buffer_filled_len -
 sender-buffer_sent_len, 0);
 -log_debug(send(%d, ...)=%ld, receiver-fd, len);
 +log_debug(send(%d, ...)=%zd, receiver-fd, len);
   if (len  0) {
   if (errno != EWOULDBLOCK  errno != EAGAIN) {
   log_error(Error %d in send to fd=%d:
 %m, errno, receiver-fd);
 @@ -147,7 +147,7 @@ static int send_buffer(struct connection *sender) {
   sender-buffer_sent_len += len;
   }

 -log_debug(send(%d, ...) completed with %lu bytes still
 buffered., receiver-fd, sender-buffer_filled_len -
 sender-buffer_sent_len);
 +log_debug(send(%d, ...) completed with %zd bytes still
 buffered., receiver-fd, sender-buffer_filled_len -
 sender-buffer_sent_len);

   /* Detect a would-block state or partial send. */
   if (sender-buffer_filled_len  sender-buffer_sent_len) {
 @@ -206,13 +206,13 @@ static int transfer_data_cb(sd_event_source *s, int
 fd, uint32_t revents, void *
   log_debug(Got event revents=%d from fd=%d (conn %p)., revents,
 fd, c);

   if (revents  EPOLLIN) {
 -log_debug(About to recv up to %lu bytes from fd=%d
 (%lu/BUFFER_SIZE)., BUFFER_SIZE - c-buffer_filled_len, fd,
 c-buffer_filled_len);
 +log_debug(About to recv up to %zd bytes from fd=%d
 (%zd/BUFFER_SIZE)., BUFFER_SIZE - c-buffer_filled_len, fd,
 c-buffer_filled_len);

   /* Receive until the buffer's full, there's no more
 data,
* or the client/server disconnects. */
   while (c-buffer_filled_len  BUFFER_SIZE) {
   len = recv(fd, c-buffer + c-buffer_filled_len,
 BUFFER_SIZE - c-buffer_filled_len, 0);
 -log_debug(recv(%d, ...)=%ld, fd, len);
 +log_debug(recv(%d, ...)=%zd, fd, len);
   if (len  0) {
   if (errno != EWOULDBLOCK  errno !=
 EAGAIN) {
   log_error(Error %d in recv from
 fd=%d: %m, errno, fd);
 @@ -232,9 +232,9 @@ static int transfer_data_cb(sd_event_source *s, int
 fd, uint32_t revents, void *
   }

   assert(len  0);
 -log_debug(Recording that the buffer got %ld more
 bytes full., len);
 +log_debug(Recording that the buffer got %zd more
 bytes full., len);
   c-buffer_filled_len += len;
 -log_debug(Buffer now has %ld bytes full.,
 c-buffer_filled_len);
 +log_debug(Buffer now has %zd bytes full.,
 c-buffer_filled_len);
   }

   /* Try sending the data immediately. */


 According to the 'man 3 printf' %zd refers to ssize_t to print out size_t
 you should use %zu.


 Regards

 Markus

 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Xorg+logind+DM issue: inactive graphical session for seat0

2013-11-01 Thread David Herrmann

Hi

On Tue, Oct 29, 2013 at 4:44 PM, Laércio de Sousa lbsous...@gmail.com wrote:
 I would append another approach to the list:

 * For non-seat0 seats, X server should open no VT at all. Currently, even
 with -sharevts option, it seems Xorg does open a VT, although it can't
 control this.

Yes, please! We shouldn't touch VTs at all if we're not on seat0. I
never understood why we have -sharedvt.. It doesn't make any sense.
Furthermore, if we remove -sharedvt we could also run the xserver with
CONFIG_VT=n.

Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] tree-wide conversion from libdbus to libsystemd-bus

2013-11-01 Thread Lennart Poettering

On Wed, 30.10.13 23:08, Kay Sievers (k...@vrfy.org) wrote:

 
 On Wed, Oct 30, 2013 at 3:48 AM, Kay Sievers k...@vrfy.org wrote:
 
  [update]
 
  To avoid any duplication of work, here are the tools which still need
  conversion. Please reply to this mail, in case you decide to work on
  anything in that area.
 
 - systemd-logind

I am knee-deep in converting logind now.

 - loginctl
 Peeters Simon: I'll take ... (probably loginctl afterwards)
 
 - hostnamectl
Peeters Simon's (patch on the list, needs rebase)
 
 - pam_systemd
Zbigniew: I'll do pam_systemd
 
 - systemctl
 
 - systemd

And then I am going to work on systemd itself.

systemctl is still up for grabs!

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] tree-wide conversion from libdbus to libsystemd-bus

2013-11-01 Thread Kay Sievers

On Fri, Nov 1, 2013 at 4:44 PM, Lennart Poettering
lenn...@poettering.net wrote:

[update]

- systemd-logind
   Lennart: I am knee-deep in converting logind now.

- loginctl
  Peeters Simon: I'll take ... (probably loginctl afterwards)

- hostnamectl
   Peeters Simon's (patch on the list, needs rebase)

 - pam_systemd
   Zbigniew: I'll do pam_systemd

 - systemctl
   Marc-Antoine Perennou: I'll do systemctl if noone else wants to.

- systemd
   Lennart: And then I am going to work on systemd itself.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] SMACK: assign * label to /tmp when using SMACK.

2013-11-01 Thread Kok, Auke-jan H

On Fri, Nov 1, 2013 at 12:57 AM, Karel Zak k...@redhat.com wrote:
On Thu, Oct 31, 2013 at 01:20:18PM -0700, Kok, Auke-jan H wrote:
BTW, for SELinux we remove selinux specific mount options in
userspace (in mount(8)) if the kernel does not support selinux.

It help us to make command line or fstab setting independent on the
current kernel features.

Maybe we can use the same for SMACK, is there any way how to
determine that the system uses SMACK? (/proc/something or so...).
-- for selinux we check for /sys/fs/selinux or /selinux.

Ohh yes that would be so nice.

You've got your choice for detecting smack, but I like
stat(/sys/fs/smackfs) == 0 the best so far. You can parse
/proc/filesystems for smackfs too, but that's obviously more complex.
This method works with 3.9 and above, as that's when we made sysfs
hold the mount point for smackfs.

I assume we're talking about this code here:

https://github.com/karelzak/util-linux/blob/master/libmount/src/context_mount.c#L181

Yes, the se_rem code (with SELinux is it tricky, because old
kernels don't support selinux options remount, options duplication is
problem etc.. I guess that for SMACK it will be less complex :-).

Do you have somewhere list of the smack mount options? I'll prepare
the patch.

Yes, the authoritative documentation is the code:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/security/smack/smack.h#n143

/*
* Mount options
*/
#define SMK_FSDEFAULT smackfsdef=
#define SMK_FSFLOOR smackfsfloor=
#define SMK_FSHAT smackfshat=
#define SMK_FSROOT smackfsroot=
#define SMK_FSTRANS smackfstransmute=

BTW, the options should be also documented in mount.8 man page :-)

nod

Thanks,

Auke
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Linux kernel API

2013-11-01 Thread ScotXW


Hi,

systemd is written exclusively for the Linux kernel because this offers 
advantages over the POSIX API. To illustrate the difference between 
Linux kernel API and POSIX API I created a diagram, see [1].


On topic: It could be used to illustrate the reasons for this decision.
1. Could you have a look and check whether it is correct?
2. Ideas?

Off topic:
Do you know more programs that are Linux kernel-only?

Thank you,
ScotXW

[1] https://commons.wikimedia.org/wiki/File:Linux_kernel_API.svg
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Linux kernel API

2013-11-01 Thread Greg KH

On Fri, Nov 01, 2013 at 06:47:00PM +0100, ScotXW wrote:
 Hi,
 
 systemd is written exclusively for the Linux kernel because this
 offers advantages over the POSIX API. To illustrate the difference
 between Linux kernel API and POSIX API I created a diagram, see [1].

Linux doesn't implement all of the POSIX api in the kernel, other
portions of it are in other userspace pieces.

Linux, like all other Unix-like operating systems, also includes some
apis that are not in POSIX, which is nothing new.

 On topic: It could be used to illustrate the reasons for this decision.
 1. Could you have a look and check whether it is correct?

It isn't.

 2. Ideas?

What are you trying to show, and why?

 Off topic:
 Do you know more programs that are Linux kernel-only?

Lots of them are, but again, why does this matter?

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Linux kernel API

2013-11-01 Thread ScotXW


On 11/01/2013 06:51 PM, Greg KH wrote:

On Fri, Nov 01, 2013 at 06:47:00PM +0100, ScotXW wrote:

Hi,

systemd is written exclusively for the Linux kernel because this
offers advantages over the POSIX API. To illustrate the difference
between Linux kernel API and POSIX API I created a diagram, see [1].


Linux doesn't implement all of the POSIX api in the kernel, other
portions of it are in other userspace pieces.


Would you please name a couple beside the libc?


Linux, like all other Unix-like operating systems, also includes some
apis that are not in POSIX, which is nothing new.


DRI1? DRI2? What else, what is of advantage to usage on the typical 
home computer?



On topic: It could be used to illustrate the reasons for this decision.
1. Could you have a look and check whether it is correct?


It isn't.


Any hints?


2. Ideas?


What are you trying to show, and why?


1. I do not program.
2. I use Linux on my home computer, that means, that besides office 
and browsing I play computer games, watch videos and listen to music. 
I can already do all of those things, but it could always be better. I 
like Wayland, so I created this [1]. I like playing video games and 
watching videos, so I created this [2].


I would like to play Rigs of Rods [3] (on Fedora or on Debian), and I 
cannot simply do that. On Windows I could __simply__ download, install 
and play it. On Linux I cannot! I would like to contribute to solve this 
issue **at its root.** The Debian Way (=adapt and maintain 37.500 
packages) failed for RoR because it is not (yet) in the Debian repos. 
Actually it is not even packaged for any Linux distro.


I would like to watch videos by using the silicon decoder in the GPU I 
bought, rather then utilizing 90% CPU. I have enough CPU-power, but 
since I paid for the GPU, why not put it to good use?


Since I do not write code, I thought I could help a very little bit with 
the documentation. Make Linux kernel-based OSes easier understandable 
for simple users, like me. Make them see, where the strong points are, 
where the problems are.
Maybe if people would have donated 10% of the entire donations to the 
Mozilla Project, to some other projects, we now would have better sound 
drivers, or multi-touch in evdev, or better you name it, rather then 
Firefox OS.


I'd prefer a fully FOSS core operaring system, but I want to __simply__ 
install and effectively run proprietary software on it. Steam is fine, 
but I want Rigs of Rods. ;-)


I do not bash against the other Unix OSes, but POSIX is rather thin 
and the last version is from 2008. IRIX is retired, Tru64 UNIX is for 
DEC Alpha only, etc.


Question is: In the year 2014 (Linux kernel 3.13, Mesa 10.0, DRI3, 
cgroups, etc.) how big would the advantages regarding amount of glue 
code, efficiency and fun to program, be, if a program would use the 
Linux-API instead of being cross-platform? Or instead of using the 
POSIX-API?


Its a bit tough to create a useful scheme about something you do not 
fully comprehend. I am not even sure the benefits of programming for the 
Linux API instead of cross-platform/POSIX can be easily illustrated. I 
tried, you say, the scheme is wrong. What to change about it?




Off topic:
Do you know more programs that are Linux kernel-only?


Lots of them are, but again, why does this matter?


The more people focus on the matter, the quicker I can play Rigs of 
Rods on Linux like on Windows: download, install, play, whether some 
ancient version is in the repos or not.


Oh, I also wanted to have Wayland 5 years ago. Was it technically not 
feasible? A failure to communicate?


If Sony would have adopted Linux instead of FreeBSD 9.0 for the 
PlayStation 4, we would have better hardware support (with HSA), so 
working on that stuff could do other things, and people doing other 
things would do other things, etc., and I could finally play Rigs of 
Rods: download, install, play. No compilation. No reading up on nothing. 
Because that is what I actually want. ;-)


I do not insist on playing it on GNU Hurd, and I accept a little detour, 
some plumbing, better drivers, some streamlining the Linux kernel-based 
OS for the home computer, etc. Eventually I want to play Rigs of Rods 
(or any other game that is not in the Debian/Fedora repos).




greg k-h


[1] 
https://commons.wikimedia.org/wiki/File:Wayland_display_server_protocol.svg

[2] https://commons.wikimedia.org/wiki/File:Linux_Graphics_Stack_2013.svg
[3] http://en.wikipedia.org/wiki/Rigs_Of_Rods
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Help on Automatic Symlink XDG_DATA_HOME

2013-11-01 Thread systemdkiosk

Might some expert address:

https://bbs.archlinux.org/viewtopic.php?id=172220

It seems systemd pushes hard-wired paths irrespective of XDG vars, a
possible bug.

On this box XDG_DATA_HOME and XDG_CACHE_HOME point outside $HOME, while
XDG_CONFIG_HOME is the default ~/.config folder. XDG_DATA_DIRS is the
default,
/usr/local/share/:/usr/share/

No file ~/.config/systemd/user exists. Still systemd insists on its
symlink in .local and will manufacture all the parent dirs just to
create that broken symlink to a nonexistent file.

I'd like reliable ways to tell systemd how to use, or not use $HOME. If
another way than XDG vars wil serve pray tell.

Thanks
Dave

-- 
http://www.fastmail.fm - A no graphics, no pop-ups email service

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Linux kernel API

2013-11-01 Thread Greg KH

On Sat, Nov 02, 2013 at 12:05:23AM +0100, ScotXW wrote:
 On 11/01/2013 06:51 PM, Greg KH wrote:
  On Fri, Nov 01, 2013 at 06:47:00PM +0100, ScotXW wrote:
  Hi,
 
  systemd is written exclusively for the Linux kernel because this
  offers advantages over the POSIX API. To illustrate the difference
  between Linux kernel API and POSIX API I created a diagram, see [1].
 
  Linux doesn't implement all of the POSIX api in the kernel, other
  portions of it are in other userspace pieces.
 
 Would you please name a couple beside the libc?

Why, this is your research, not mine :)

  Linux, like all other Unix-like operating systems, also includes some
  apis that are not in POSIX, which is nothing new.
 
 DRI1? DRI2? What else, what is of advantage to usage on the typical 
 home computer?

That sentance doesn't make much sense.

  On topic: It could be used to illustrate the reasons for this decision.
  1. Could you have a look and check whether it is correct?
 
  It isn't.
 
 Any hints?

snip

This is all _way_ off-topic for this mailing list, sorry.

Best of luck with your research.

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 2/2] hostnamectl: port to sd-bus

2013-11-01 Thread Kay Sievers

On Wed, Oct 30, 2013 at 6:55 AM, Simon Peeters peeters.si...@gmail.com wrote:

 +#define foreach_dbus_property(r, bus, dest, object, error, reply, name, 
 contents) \
 +for (int _i = 0; _i  3; _i++) \
 +if (_i == 0) { \
 +r = sd_bus_call_method(bus, dest, object,\
 +org.freedesktop.DBus.Properties,\
 +GetAll, error, reply, s, );\
 +if (r  0) {\
 +log_error(Could not get properties: %s, 
 bus_error_message(error, -r));\
 +break;\
 +}\
 +r = sd_bus_message_enter_container(reply, 
 SD_BUS_TYPE_ARRAY, {sv});\
 +if (r  0) goto CATENATE(fail,__LINE__); \
 +} else if (_i == 2) { \
 +r = sd_bus_message_exit_container(reply);\
 +if (r  0) goto CATENATE(fail,__LINE__); \
 +break;\
 +CATENATE(fail,__LINE__):\
 +log_error(Failed to parse reply: %s, 
 strerror(-r)); \
 +r = -EIO;\
 +break;\
 +} else \
 +while ((r = sd_bus_message_enter_container(reply,\
 +SD_BUS_TYPE_DICT_ENTRY, sv))  0)\
 +for (int _j = 0; _j  3; _j++) \
 +if (_j == 0) {\
 +if (r  0) goto 
 CATENATE(fail,__LINE__);\
 +r = 
 sd_bus_message_read(reply, s, (name));\
 +if (r  0) goto 
 CATENATE(fail,__LINE__);\
 +r = 
 sd_bus_message_peek_type(reply, NULL, (contents));\
 +if (r  0) goto 
 CATENATE(fail,__LINE__);\
 +r = 
 sd_bus_message_enter_container(reply,\
 +
 SD_BUS_TYPE_VARIANT, contents);\
 +if (r  0) goto 
 CATENATE(fail,__LINE__);\
 +} else if (_j ==2) {\
 +r = 
 sd_bus_message_exit_container(reply);\
 +if (r  0) goto 
 CATENATE(fail,__LINE__);\
 +r = 
 sd_bus_message_exit_container(reply);\
 +if (r  0) goto 
 CATENATE(fail,__LINE__);\
 +} else
 +

Cool, but it's quite a bit too magical, I think. :)

But yeah, we should have something which makes GetAll easier. Now
about something like the attached patch?

Thanks,
Kay
From c0dc3f5ed3838d909b9a46d4e3b8e9de0b6cd3e2 Mon Sep 17 00:00:00 2001
From: Kay Sievers k...@vrfy.org
Date: Sat, 2 Nov 2013 00:10:12 +0100
Subject: [PATCH] bus: use internal helper to read
 org.freedesktop.DBus.Properties::GetAll variables

---
 src/libsystemd-bus/bus-util.c | 165 +-
 src/libsystemd-bus/bus-util.h |  11 +++
 src/locale/localectl.c| 134 +-
 src/timedate/timedatectl.c| 107 +--
 4 files changed, 211 insertions(+), 206 deletions(-)

diff --git a/src/libsystemd-bus/bus-util.c b/src/libsystemd-bus/bus-util.c
index 0632288..c05a3f6 100644
--- a/src/libsystemd-bus/bus-util.c
+++ b/src/libsystemd-bus/bus-util.c
@@ -21,13 +21,16 @@
 
 #include sys/socket.h
 
-#include sd-event.h
-#include sd-bus.h
-
 #include util.h
+#include strv.h
 #include macro.h
 #include def.h
 
+#include sd-event.h
+#include sd-bus.h
+#include bus-error.h
+#include bus-message.h
+
 #include bus-util.h
 
 static int quit_callback(sd_bus *bus, sd_bus_message *m, void *userdata) {
@@ -595,6 +598,162 @@ int bus_generic_print_property(const char *name, sd_bus_message *property, bool
 return 0;
 }
 
+int bus_map_all_properties(sd_bus *bus,
+   const char *destination,
+   const char *path,
+   struct bus_properties_map *map) {
+_cleanup_bus_message_unref_ sd_bus_message *m = NULL;
+_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
+int r;
+
+r = sd_bus_call_method( bus,
+destination,
+path,
+org.freedesktop.DBus.Properties,
+GetAll,
+error,
+m,
+s, );
+if (r  0) {
+log_error(Could not get properties: %s, bus_error_message(error, -r));
+return r;
+}
+
+

Re: [systemd-devel] Help on Automatic Symlink XDG_DATA_HOME

2013-11-01 Thread Zbigniew Jędrzejewski-Szmek

On Fri, Nov 01, 2013 at 11:02:30PM +, systemdki...@yopmail.com wrote:
 Might some expert address:
 
 https://bbs.archlinux.org/viewtopic.php?id=172220
 
 It seems systemd pushes hard-wired paths irrespective of XDG vars, a
 possible bug.
 
 On this box XDG_DATA_HOME and XDG_CACHE_HOME point outside $HOME, while
 XDG_CONFIG_HOME is the default ~/.config folder. XDG_DATA_DIRS is the
 default,
 /usr/local/share/:/usr/share/
Looking at the code, it seems that systemd will create the symlink
in ~/.local/share/systemd/user only if $XDG_DATA_HOME is not set.
Are you sure that systemd is actually running with this variable set?

 No file ~/.config/systemd/user exists. Still systemd insists on its
 symlink in .local and will manufacture all the parent dirs just to
 create that broken symlink to a nonexistent file.
Hm, this might be an actual bug. I guess that systemd should not create
the link if the destination doesn't exist.

 I'd like reliable ways to tell systemd how to use, or not use $HOME. If
 another way than XDG vars wil serve pray tell.
This should work.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Help on Automatic Symlink XDG_DATA_HOME

2013-11-01 Thread Mantas Mikulėnas

On Sat, Nov 2, 2013 at 1:37 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Fri, Nov 01, 2013 at 11:02:30PM +, systemdki...@yopmail.com wrote:
 Might some expert address:

 https://bbs.archlinux.org/viewtopic.php?id=172220

 It seems systemd pushes hard-wired paths irrespective of XDG vars, a
 possible bug.

 On this box XDG_DATA_HOME and XDG_CACHE_HOME point outside $HOME, while
 XDG_CONFIG_HOME is the default ~/.config folder. XDG_DATA_DIRS is the
 default,
 /usr/local/share/:/usr/share/
 Looking at the code, it seems that systemd will create the symlink
 in ~/.local/share/systemd/user only if $XDG_DATA_HOME is not set.
 Are you sure that systemd is actually running with this variable set?

 No file ~/.config/systemd/user exists. Still systemd insists on its
 symlink in .local and will manufacture all the parent dirs just to
 create that broken symlink to a nonexistent file.
 Hm, this might be an actual bug. I guess that systemd should not create
 the link if the destination doesn't exist.

 I'd like reliable ways to tell systemd how to use, or not use $HOME. If
 another way than XDG vars wil serve pray tell.
 This should work.

I'm curious why the symlink is created at all... or in other words,
why systemd looks in /usr/share and ~/.local/share for user units in
the first place? It is neither documented in systemd.unit(5), nor
consistent with the system unit paths, nor makes much sense since
AFAIK the units are configuration, not data?

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Help on Automatic Symlink XDG_DATA_HOME

2013-11-01 Thread systemdkiosk

Zbigniew Jędrzejewski-Szmek wrote:

 Are you sure that systemd is actually running
 with this variable set?

Excellent question, and no, I'm not sure.
If you can tell me how to determine the
answer, please do.

What I can say is that

1) XDG_DATA_HOME is set in /etc/profile.d on
Arch Linux, the first script that runs
from that folder. The same script sets all
the other XDG vars too.

2) To my knowledge this arrangement works
fine in every other respect. All the apps,
and Arch as well, use XDG vars as intended.
In other words, systemd is the ONLY thing
that (creates, and then,) uses ~/.local.

-- 
http://www.fastmail.fm - Email service worth paying for. Try it for free

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Help on Automatic Symlink XDG_DATA_HOME

2013-11-01 Thread systemdkiosk

Zbigniew Jędrzejewski-Szmek wrote:
 I guess that systemd should not create
 the link if the destination doesn't exist.
+1

Mantas Mikulėnas wrote:
 I'm curious why the symlink is created at all...

I know not why, but I do know that:
If a symlink is made, the C code should use $XDG_CONFIG_HOME to make it,
not the presently hard-wired path ../../../.config/systemd/user

-- 
http://www.fastmail.fm - IMAP accessible web-mail

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH 0/1] systemd will fail to compile if libgcrypt is missing

2013-11-01 Thread Djalal Harouni

Hi list,

I'm doing some systemd testing on clean machines. I'm building from git
tree, and I've noticed that systemd autogen.sh will fail if the
libgcrypt and its headers are missing, this will produce a buggy
configure script.

The error messages were not clear, I did lost time debugging... :-/

The libtool and libgcrypt were missing, perhaps others packages too, but
I was trying to get it compile without all the features. The readme file
states clearly that libtool is needed and libgcrypt is optional, so lets
see:

(Libtool and libgcrypt were not installed)

The autogen.sh output:
configure.ac:547: warning: macro 'AM_PATH_LIBGCRYPT' not found in
library
configure.ac:47: error: possibly undefined macro: AC_MSG_ERROR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:547: error: possibly undefined macro: AM_PATH_LIBGCRYPT
autoreconf: /usr/bin/autoconf failed with exit status: 1

The produced configure.ac script will fail with:
./configure: line 5123: syntax error near unexpected token `2.2'
./configure: line 5123: `LT_PREREQ(2.2)'

So, I know LT_PREREQ(2.2) is from libtool, lets get it. After that I
re-run autogen.sh:

./autogen.sh 
configure.ac:547: warning: macro 'AM_PATH_LIBGCRYPT' not found in
library
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build-aux'.
libtoolize: linking file `build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: linking file `m4/libtool.m4'
libtoolize: linking file `m4/ltoptions.m4'
libtoolize: linking file `m4/ltsugar.m4'
libtoolize: linking file `m4/ltversion.m4'
libtoolize: linking file `m4/lt~obsolete.m4'
configure.ac:547: warning: macro 'AM_PATH_LIBGCRYPT' not found in library
configure.ac:47: error: possibly undefined macro: AC_MSG_ERROR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:547: error: possibly undefined macro: AM_PATH_LIBGCRYPT
autoreconf: /usr/bin/autoconf failed with exit status: 1


I still have the AM_PATH_LIBGCRYPT report, but I did install libtool
so why I'm getting that 'AC_MSG_ERROR'?, hmm ok perhaps other errors
got autoreconf produce this output? I don't know, all of this is set to
confuse my poor debugging skills... but running the autotools manually
will produce a better output.


Anyway, running the generated configure script will produce:

checking for fsetxattr in -lattr... yes
./configure: line 17100: syntax error near unexpected token `newline'
./configure: line 17100: `AM_PATH_LIBGCRYPT('


So systemd clearly needs libgcrypt to compile since it makes use of
the AM_PATH_LIBGCRYPT macro. It's not optional as stated in the README
file.

There was a patch to test if AM_PATH_LIBGCRYPT is defined:
http://lists.freedesktop.org/archives/systemd-devel/2013-May/010885.html

The discussion ended by: libgcrypt should not use its own macro, yes
that's true, but in the end systemd is also using this same macro and
will fail to build...


What do you think of the following:
1) The following patch removes the AM_PATH_LIBGCRYPT macro use. It
makes the libgcrypt check consistent with the other library checks.

However by doing this we remove the version check from configure.ac, we
can still call gcry_version_check() inside AC_COMPILE_IFELSE to check
the minimal required version, but I don't like it.

It seems that the code that makes use of libgcrypt tries to check the
minimal version during initialization.

Please see the patch change log.


2) merge the patch:
http://lists.freedesktop.org/archives/systemd-devel/2013-May/010885.html


3) Edit the README file to state that systemd needs libgcrypt


BTW it would be nice if we can add a check like the following for
libtool:
m4_ifdef([LT_PREREQ],
 [LT_PREREQ(...)],
 [m4_fatal([Libtool version X not found])])

To improve error messages.


Thanks!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH 1/1] configure.ac: make libgcrypt dependency optional

2013-11-01 Thread Djalal Harouni

Currently systemd will fail to build if libgcrypt headers are not
installed:

autoge.sh output:
...
libtoolize: linking file `m4/lt~obsolete.m4'
configure.ac:547: warning: macro 'AM_PATH_LIBGCRYPT' not found in library
configure.ac:47: error: possibly undefined macro: AC_MSG_ERROR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:547: error: possibly undefined macro: AM_PATH_LIBGCRYPT
autoreconf: /usr/bin/autoconf failed with exit status: 1

configure output:
...
checking for fsetxattr in -lattr... yes
./configure: line 17100: syntax error near unexpected token `newline'
./configure: line 17100: `AM_PATH_LIBGCRYPT('

The macro AM_PATH_LIBGCRYPT is used to check if libgcrypt support is
present, but if libgcrypt headers are missing then this macro is
undefined and the build process will fail.

Fix this by removing the AM_PATH_LIBGCRYPT macro and convert the
libgcrypt headers check to be consistent with other systemd library
checks.

This will remove the libgcrypt version check from configure.ac and
delay it to be done during runtime, precisely during libgcrypt
intialization by the gcry_check_version() function. The manuals of
libgcrypt suggest this which is already done by systemd.

All the calls to this function are followed by an assert() check to
make sure that we are using the required version.
---
 configure.ac | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 7e41d57..ade172d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -544,13 +544,21 @@ AC_ARG_ENABLE([gcrypt],
 [have_gcrypt=auto])
 
 if test x${have_gcrypt} != xno ; then
-AM_PATH_LIBGCRYPT(
-[1.4.5],
+AC_CHECK_HEADER(
+[gcrypt.h],
 [have_gcrypt=yes],
 [if test x$have_gcrypt = xyes ; then
 AC_MSG_ERROR([*** GCRYPT headers not found.])
 fi])
 
+AC_CHECK_LIB(
+[gcrypt],
+[gcry_check_version],
+[have_gcrypt=yes],
+[if test x$have_gcrypt = xyes ; then
+AC_MSG_ERROR([*** libgcrypt not found.])
+fi])
+
 if test x$have_gcrypt = xyes ; then
 GCRYPT_LIBS=$LIBGCRYPT_LIBS
 GCRYPT_CFLAGS=$LIBGCRYPT_CFLAGS
-- 
1.7.11.7

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 0/1] systemd will fail to compile if libgcrypt is missing

2013-11-01 Thread Djalal Harouni

List please hold on these patch!

It seems that AM_PATH_LIBGCRYPT will also define LIBGCRYPT_LIBS
which is used to link again libgcrypt and other libraries related to
libgcrypt.

My bad, this current patch will not fix the problem!

I guess that we are stuck with this :-/ until gcrypt converts to
pkg-config...

On Sat, Nov 02, 2013 at 02:11:48AM +0100, Djalal Harouni wrote:
 Hi list,
 
 I'm doing some systemd testing on clean machines. I'm building from git
 tree, and I've noticed that systemd autogen.sh will fail if the
 libgcrypt and its headers are missing, this will produce a buggy
 configure script.
 
 The error messages were not clear, I did lost time debugging... :-/
 
 The libtool and libgcrypt were missing, perhaps others packages too, but
 I was trying to get it compile without all the features. The readme file
 states clearly that libtool is needed and libgcrypt is optional, so lets
 see:
 
 (Libtool and libgcrypt were not installed)
 
 The autogen.sh output:
 configure.ac:547: warning: macro 'AM_PATH_LIBGCRYPT' not found in
 library
 configure.ac:47: error: possibly undefined macro: AC_MSG_ERROR
 If this token and others are legitimate, please use m4_pattern_allow.
 See the Autoconf documentation.
 configure.ac:547: error: possibly undefined macro: AM_PATH_LIBGCRYPT
 autoreconf: /usr/bin/autoconf failed with exit status: 1
 
 The produced configure.ac script will fail with:
 ./configure: line 5123: syntax error near unexpected token `2.2'
 ./configure: line 5123: `LT_PREREQ(2.2)'
 
 So, I know LT_PREREQ(2.2) is from libtool, lets get it. After that I
 re-run autogen.sh:
 
 ./autogen.sh 
 configure.ac:547: warning: macro 'AM_PATH_LIBGCRYPT' not found in
 library
 libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build-aux'.
 libtoolize: linking file `build-aux/ltmain.sh'
 libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
 libtoolize: linking file `m4/libtool.m4'
 libtoolize: linking file `m4/ltoptions.m4'
 libtoolize: linking file `m4/ltsugar.m4'
 libtoolize: linking file `m4/ltversion.m4'
 libtoolize: linking file `m4/lt~obsolete.m4'
 configure.ac:547: warning: macro 'AM_PATH_LIBGCRYPT' not found in library
 configure.ac:47: error: possibly undefined macro: AC_MSG_ERROR
 If this token and others are legitimate, please use m4_pattern_allow.
 See the Autoconf documentation.
 configure.ac:547: error: possibly undefined macro: AM_PATH_LIBGCRYPT
 autoreconf: /usr/bin/autoconf failed with exit status: 1
 
 
 I still have the AM_PATH_LIBGCRYPT report, but I did install libtool
 so why I'm getting that 'AC_MSG_ERROR'?, hmm ok perhaps other errors
 got autoreconf produce this output? I don't know, all of this is set to
 confuse my poor debugging skills... but running the autotools manually
 will produce a better output.
 
 
 Anyway, running the generated configure script will produce:
 
 checking for fsetxattr in -lattr... yes
 ./configure: line 17100: syntax error near unexpected token `newline'
 ./configure: line 17100: `AM_PATH_LIBGCRYPT('
 
 
 So systemd clearly needs libgcrypt to compile since it makes use of
 the AM_PATH_LIBGCRYPT macro. It's not optional as stated in the README
 file.
 
 There was a patch to test if AM_PATH_LIBGCRYPT is defined:
 http://lists.freedesktop.org/archives/systemd-devel/2013-May/010885.html
 
 The discussion ended by: libgcrypt should not use its own macro, yes
 that's true, but in the end systemd is also using this same macro and
 will fail to build...
 
 
 What do you think of the following:
 1) The following patch removes the AM_PATH_LIBGCRYPT macro use. It
 makes the libgcrypt check consistent with the other library checks.
 
 However by doing this we remove the version check from configure.ac, we
 can still call gcry_version_check() inside AC_COMPILE_IFELSE to check
 the minimal required version, but I don't like it.
 
 It seems that the code that makes use of libgcrypt tries to check the
 minimal version during initialization.
 
 Please see the patch change log.
 
 
 2) merge the patch:
 http://lists.freedesktop.org/archives/systemd-devel/2013-May/010885.html
 
 
 3) Edit the README file to state that systemd needs libgcrypt
 
 
 BTW it would be nice if we can add a check like the following for
 libtool:
 m4_ifdef([LT_PREREQ],
  [LT_PREREQ(...)],
  [m4_fatal([Libtool version X not found])])
 
 To improve error messages.
 
 
 Thanks!
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel

-- 
Djalal Harouni
http://opendz.org
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Help on Automatic Symlink XDG_DATA_HOME

2013-11-01 Thread systemdkiosk

Zbigniew Jędrzejewski-Szmek wrote:

 'systemctl --user show-environment' will show what's set

I get errors as normal user and root.

$ systemctl --user show-environment 
Failed to issue method call: Process /bin/false exited with status 1
$ su -
Password:
# systemctl --user show-environment 
Failed to get D-Bus connection: Unable to autolaunch a dbus-daemon
without a $DISPLAY for X11



 systemd is executed by systemd
 with a standard set of variables

Might sysd avoid/defer possibly wrong values until they are reliable?
Might it offer a config file for admins to override assumptions? Note my
XDG vars need $USER, so:
export XDG_DATA_HOME=/tmp/user_data_for_$USER

 /etc/profile* is unfortunately shell-only, so it's not something
 that systemd can use directly. I think that adding a custom pam
 module would be a better option here (c.f. pam_env(8)).

Everything else works swell with /etc/profile* values, and, for that
matter, even systemd does after login. KDE works in its entirety. Read
on XDG_RUNTIME_DIR. tightly bound to login.
http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html

If I need PAM trickery then I'd rather drop a one-line script into
/etc/profile.d to delete the symlink and call it a wrap.

But philosophically, would it be fair to say:

All vars can, and should, be set or changed in /etc/profile.d, except
XDG vars, which only for the sake of systemd should be set elsewhere.

Is that idea documented or proposed anywhere, or desirable design? Isn't
the issue more about sysd bootstrapping glitches?

Thanks for the feedback in any case. Sounds like a cleanup script is the
fast answer. Maybe in future sysd can offer an admin config file for XDG
vars.

Glad I asked, help was appreciated and very rapid.

Best
Dave

-- 
http://www.fastmail.fm - IMAP accessible web-mail

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] SMACK: assign * label to /tmp when using SMACK.

Re: [systemd-devel] .libs/test-sched-prio failed

Re: [systemd-devel] [PATCH] fix compiler warnings

Re: [systemd-devel] [PATCH] fix compiler warnings

Re: [systemd-devel] Xorg+logind+DM issue: inactive graphical session for seat0

Re: [systemd-devel] tree-wide conversion from libdbus to libsystemd-bus

Re: [systemd-devel] tree-wide conversion from libdbus to libsystemd-bus

Re: [systemd-devel] [PATCH] SMACK: assign * label to /tmp when using SMACK.

[systemd-devel] Linux kernel API

Re: [systemd-devel] Linux kernel API

Re: [systemd-devel] Linux kernel API

[systemd-devel] Help on Automatic Symlink XDG_DATA_HOME

Re: [systemd-devel] Linux kernel API

Re: [systemd-devel] [PATCH 2/2] hostnamectl: port to sd-bus

Re: [systemd-devel] Help on Automatic Symlink XDG_DATA_HOME

Re: [systemd-devel] Help on Automatic Symlink XDG_DATA_HOME

Re: [systemd-devel] Help on Automatic Symlink XDG_DATA_HOME

Re: [systemd-devel] Help on Automatic Symlink XDG_DATA_HOME

[systemd-devel] [PATCH 0/1] systemd will fail to compile if libgcrypt is missing

[systemd-devel] [PATCH 1/1] configure.ac: make libgcrypt dependency optional

Re: [systemd-devel] [PATCH 0/1] systemd will fail to compile if libgcrypt is missing

Re: [systemd-devel] Help on Automatic Symlink XDG_DATA_HOME

22 matches

Site Navigation

Mail list logo

Footer information