Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Dave Reisner
On Tue, May 26, 2015 at 04:17:07PM +0200, Lennart Poettering wrote:
 On Tue, 26.05.15 15:12, Dimitri John Ledkov (dimitri.j.led...@intel.com) 
 wrote:
 
  Or will there be a v220.1 release shortly with releasy fix-ups?
 
 Well, we don't do point releases in systemd. 

 In systemd git we already have now the change that makes sd-bus and
 sd-event public APIs, hence v221 is going to be more than just
 bugfixes. 

Is git revert not an option? Does someone depend on this already, making
a rollback impossible (and why would you allow that)? You say that
versions are just a label, but a project which adopts semver would be
able to create a branch in git and produce a dot release with backported
bugfixes. Surely you're familiar with this concept -- your colleague
Karel does this routinely with util-linux.

The fact of the matter is, the last 2 releases of systemd have been
brown bag releases. Neither 219 nor 220 are useable as the tarballs are
provided. v220 doesn't even build in a large number of configurations.
v218 wasn't quite as bad, but landed 18 patches in Arch's packaging
before v219 was released. For the average Arch package, this is unheard
of, let alone being a *necessity* in order to make software useable.

Please, let's figure out a way to lower the amount of work that gets
sharded out and duplicated by downstream packagers.

 Also, next week I'll be travelling and I doubt I will be able to
 finish a new release by then. Maybe in the middle of June we can get
 out a new release.

 Sorry,

I'm sorry to hear this too. Please find someone else who's paid to work
on systemd and teach them how to package releases. The current state of
affairs absolutely sucks for downstreams. Currently, packaging systemd
takes more of my time than all of my other packaging responsibilities
combined.

At LPC in New Orleans, you asked me how you could make systemd easier to
work with on the downstream side. I told you that I wanted more frequent
releases. You seemed amenable to this, but it really never happened.
I'm asking again: can we have more frequent releases? Can you take the
steps to actually make this happen and not gate releases on your own
personal availability?

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


Re: [systemd-devel] [PATCH] cgtop: raw output option (disable conversion to human-readable units)

2015-05-26 Thread systemd github import bot
Patchset imported to github.
Pull request:
https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1432331775-28932-2-git-send-email-charles%40dyfis.net

--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] cgtop raw output option

2015-05-26 Thread Charles Duffy
From: Charles Duffy chadu...@cisco.com

At present, systemd-cgtop converts quantities in bytes (memory and IO bandwidth
values) to human-readable form unconditionally.

Given as batch mode already exists as a supported option, there clearly is
intent for cgtop to be usable with data routed to locations other than
(directly) to human eyeballs. Given such, an option to skip this processing and
emit raw numbers (in bytes) for these values is sensible.

Charles Duffy (1):
  cgtop: raw output option (disable conversion to human-readable units)

 src/cgtop/cgtop.c | 28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

-- 
2.0.0

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


[systemd-devel] [PATCH] cgtop: raw output option (disable conversion to human-readable units)

2015-05-26 Thread Charles Duffy
From: Charles Duffy chadu...@cisco.com

---
 src/cgtop/cgtop.c | 28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/src/cgtop/cgtop.c b/src/cgtop/cgtop.c
index a390cf3..0dbac7f 100644
--- a/src/cgtop/cgtop.c
+++ b/src/cgtop/cgtop.c
@@ -62,6 +62,7 @@ typedef struct Group {
 static unsigned arg_depth = 3;
 static unsigned arg_iterations = 0;
 static bool arg_batch = false;
+static bool arg_raw = false;
 static usec_t arg_delay = 1*USEC_PER_SEC;
 
 static enum {
@@ -533,15 +534,24 @@ static int display(Hashmap *a) {
 printf( %*s, maxtcpu, format_timespan(buffer, 
sizeof(buffer), (nsec_t) (g-cpu_usage / NSEC_PER_USEC), 0));
 
 if (g-memory_valid)
-printf( %8s, format_bytes(buffer, sizeof(buffer), 
g-memory));
+if(arg_raw) {
+printf( %8ld, g-memory);
+} else {
+printf( %8s, format_bytes(buffer, 
sizeof(buffer), g-memory));
+}
 else
 fputs(-, stdout);
 
 if (g-io_valid) {
-printf( %8s,
-   format_bytes(buffer, sizeof(buffer), 
g-io_input_bps));
-printf( %8s,
-   format_bytes(buffer, sizeof(buffer), 
g-io_output_bps));
+if(arg_raw) {
+printf( %8ld, g-io_input_bps);
+printf( %8ld, g-io_output_bps);
+} else {
+printf( %8s,
+   format_bytes(buffer, sizeof(buffer), 
g-io_input_bps));
+printf( %8s,
+   format_bytes(buffer, sizeof(buffer), 
g-io_output_bps));
+}
 } else
 fputs(--, stdout);
 
@@ -561,6 +571,7 @@ static void help(void) {
  -c  Order by CPU load\n
  -m  Order by memory load\n
  -i  Order by IO load\n
+ -r  Provide raw (not human-readable) 
numbers\n
 --cpu[=TYPE] Show CPU usage as time or percentage 
(default)\n
  -d --delay=DELAYDelay between updates\n
  -n --iterations=N   Run for N iterations before exiting\n
@@ -583,6 +594,7 @@ static int parse_argv(int argc, char *argv[]) {
 { delay,  required_argument, NULL, 'd' },
 { iterations, required_argument, NULL, 'n' },
 { batch,  no_argument,   NULL, 'b' },
+{ raw,no_argument,   NULL, 'r' },
 { depth,  required_argument, NULL, ARG_DEPTH   },
 { cpu,optional_argument, NULL, ARG_CPU_TYPE},
 {}
@@ -594,7 +606,7 @@ static int parse_argv(int argc, char *argv[]) {
 assert(argc = 1);
 assert(argv);
 
-while ((c = getopt_long(argc, argv, hptcmin:bd:, options, NULL)) = 
0)
+while ((c = getopt_long(argc, argv, hptcmin:brd:, options, NULL)) = 
0)
 
 switch (c) {
 
@@ -649,6 +661,10 @@ static int parse_argv(int argc, char *argv[]) {
 arg_batch = true;
 break;
 
+case 'r':
+arg_raw = true;
+break;
+
 case 'p':
 arg_order = ORDER_PATH;
 break;
-- 
2.0.0

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


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Michael Biebl
2015-05-27 2:51 GMT+02:00 Dave Reisner d...@falconindy.com:
 The fact of the matter is, the last 2 releases of systemd have been
 brown bag releases. Neither 219 nor 220 are useable as the tarballs are
 provided. v220 doesn't even build in a large number of configurations.
 v218 wasn't quite as bad, but landed 18 patches in Arch's packaging
 before v219 was released. For the average Arch package, this is unheard
 of, let alone being a *necessity* in order to make software useable.

 Please, let's figure out a way to lower the amount of work that gets
 sharded out and duplicated by downstream packagers.

Glad to know that I'm not the only one who feels this way. Let me
quote myself from #systemd:

mbiebl_ zbyszek: looks like we want a v221 release soon
mbiebl_ fwiw, I think our QA for doing releases sucks
zbyszek mbiebl_: I'm working on the selinux bug currently...
zbyszek mbiebl_: I think the releases are possibly the point of
highest instability
mbiebl_ a bit more official planning and giving people time to test
would be a great start
zbyszek I suggested doing a week of cooling off before a release
before, but somehow that didn't stick.
mbiebl_ just telling people, when the release is planned, would help
mbiebl_ right now, that feels really amateurish
zbyszek mbiebl_: yeah, that would help. But without a rule that only
bugfix and cosmetic or documentation changes go in, it's hard to test
stuff properly.
mbiebl_ absolutely, just saying that atm we don't even have that
mbiebl_ i.e. we know when a release is planned
mbiebl_ that's imo the absolute minimum
mbiebl_ the result is broken dist tarballs
mbiebl_ and distros having to ship 50+ patches until it get's usable
mbiebl_ that sucks bigs time

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] missing: add more IFLA_VXLAN_* defines

2015-05-26 Thread systemd github import bot
Patchset imported to github.
Pull request:
https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1432619328-32030-1-git-send-email-m.olbrich%40pengutronix.de

--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Debian Bug#618862: systemd: ignores keyscript in crypttab - a possible solution

2015-05-26 Thread David Härdeman

On 2015-05-26 00:05, Alberto Bertogli wrote:
I hit this issue after upgrading a system that used keyscript to 
Jessie,

and it would no longer boot with systemd [1].

That led me to look into adding a password agent for my use case, 
and/or

creating a generic one that would invoke keyscripts as a workaround...



...

On Wed, Feb 05, 2014 at 12:16:00AM +0100, Lennart Poettering wrote:

On Thu, 30.01.14 10:40, David Härdeman (da...@hardeman.nu) wrote:
 b) the password agent implementation in systemd doesn't seem to
 handle binary strings (i.e. strings with '\0'), as can be seen by
 calls to e.g. strlen()...

 Whether making it binary safe would be a major change or not is
 something I haven't researched yet but it seems like a change that
 should be generally useful upstream...

I'd be OK with this, as discussed at FOSDEM, and I see you already
posted a ptach for this.


Has this been merged?


No, the last word was basically this thread:
http://lists.freedesktop.org/archives/systemd-devel/2014-July/021246.html

I don't have the time to implement a complete solution...


Is it safe for a password agent to write content with \0 back to the
socket?


Haven't checked but I'd be surprised if that was the case.

//David

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


[systemd-devel] inotify_add_watch() failed: Bad file descriptor

2015-05-26 Thread Christian Hesse
Hello everybody,

with systemd v220 I see inotify errors from udevd. I get this once:

systemd-udevd: inotify_add_watch(9, /dev/sr0, 10) failed: Bad file descriptor

And a lot of these:

systemd-udevd: inotify_add_watch(9, /dev/dm-[0-9]+, 10) failed: Bad file
descriptor
-- 
main(a){char*c=/*Schoene Gruesse */B?IJj;MEH
CX:;,b;for(a/*Chris   get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/*   gcc -o sig sig.c  ./sig*/b/42*2-3)*42);}


pgpbnb1NlH6bY.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] crda broken with systemd 220

2015-05-26 Thread Michał Bartoszkiewicz
Hello,

it seems that udev from systemd 220 does passes empty environment to a
process spawned by a RUN rule.
execve(/usr/sbin/crda, [/usr/sbin/crda], [/* 0 vars */]) = 0
This breaks crda, as it expects to see COUNTRY in its environment.

--
Michał Bartoszkiewicz mbartoszkiew...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Vendor default masked service

2015-05-26 Thread Umut Tezduyar Lindskog
Hi,

I was wondering if we have a way to provide vendor default masked service?

Vendor default masked service has advantages like:
 - systemctl start won't work
 - dbus activation won't work

It is common that an embedded system doesn't use packages, rather it
ships everything in monolithic image. Enabling, disabling, presetting
is great to prevent a service from starting as part of the target but
it doesn't stop anyone trying to start it with systemd (systemctl
start, or dbus activation).

I have come up with my way but obviously systemctl unmask doesn't
mean anything in this case. I was wondering if there is a way I am not
aware of.

/usr/lib/systemd/system:
aa.service: Service file implementation
a.target.wants/a.service: Start the service with a.target.
a.service: Can either be a link to aa.service (start the service) or
/dev/null (service is masked, won't start).

If the service is masked (a.service - /dev/null), to enable it we
need to create (/etc/systemd/system/a.service -
/usr/lib/systemd/system/aa.service).

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


Re: [systemd-devel] [PATCH] core: if PR_SET_CHILD_SUBREAPER fails, log_error instead of warning

2015-05-26 Thread Lennart Poettering
On Sun, 24.05.15 22:41, Tom Gundersen (t...@jklm.no) wrote:

 On Sat, May 23, 2015 at 6:04 PM, Cristian Rodríguez
 crrodrig...@opensuse.org wrote:
  It was a warning when we still supported kernel  3.4. current
  minimum version is 3.7.
 
 Hm, we don't actually fail out here, but we still try to continue.
 Isn't 'warning' more appropriate in that case?

Yes.

The warning should stay a warning, but the EINVAL check with its info
message should indeed go.

 
 Cheers,
 Tom
 
   src/core/main.c | 4 +---
   1 file changed, 1 insertion(+), 3 deletions(-)
 
  diff --git a/src/core/main.c b/src/core/main.c
  index c39815b..3bebc98 100644
  --- a/src/core/main.c
  +++ b/src/core/main.c
  @@ -1608,9 +1608,7 @@ int main(int argc, char *argv[]) {
   if (arg_running_as == MANAGER_USER) {
   /* Become reaper of our children */
   if (prctl(PR_SET_CHILD_SUBREAPER, 1)  0) {
  -log_warning_errno(errno, Failed to make us a 
  subreaper: %m);
  -if (errno == EINVAL)
  -log_info(Perhaps the kernel version is 
  too old ( 3.4?));
  +log_error_errno(errno, Failed to make us a 
  subreaper: %m);
   }
   }
 
  --
  2.4.1
 
  ___
  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


Lennart

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


[systemd-devel] how to call dbus ListUnits for user units?

2015-05-26 Thread Chris Morgan
Hello.

I'm able to use:

dbus-send --system --print-reply --reply-timeout=2000 --type=method_call \
--dest=org.freedesktop.systemd1 \
/org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.ListUnits

to list system units.

But I can't seem to figure out how to do the same for user units.
There doesn't seem to be an org.freedesktop.systemd1 interface on my
current user's session bus and I wasn't able to spot anything in the
interfaces on the system bus that had a nested interface of
org.freedesktop.system1.Manager...

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


Re: [systemd-devel] pre-release warnings?

2015-05-26 Thread Alexander E. Patrakov

26.05.2015 21:52, Martin Pitt wrote:

Lennart Poettering [2015-05-26 18:36 +0200]:

That said, I think even better would be to maybe make the support for
this generic in systemctl: instead of explicitly invoking chkconfig or
update-rcd, maybe we can just make systemctl invoke some fixed binary
/usr/lib/systemd/systemd-sysv-compat or so with a fixed set of
parameters. The distros could then make that a tool (maybe just a
shell script) that invokes chkconfig or update-rc.d This would then
allow us to remove any chkconfig-specific code from systemd, and would
allow all distros to plug-in the tool of their choice without having
to patch upstream. What do you think?


That sounds great. If chkconfig and update-r.cd are/were the only two
contenders then #ifdef sounds easier, but I don't know about other
distros like e. g. Gentoo.


With my Gentoo user hat on: Gentoo needs no support here. Their 
initscripts are based on OpenRC, which is not SysV-compatible enough for 
the fall back to the initscript logic to make sense at all (e.g., 
their initscripts have #!/sbin/runscript in the beginning, have no LSB 
header, and produce an error message if run in the system booted by 
systemd). In fact, they explicitly disable SysV compatibility in systemd:


# disable sysv compatibility
--with-sysvinit-path=
--with-sysvrcnd-path=

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


Re: [systemd-devel] [PATCH] treewide: fix typos

2015-05-26 Thread Tom Gundersen
Applied. Thanks!

Tom

On Tue, May 26, 2015 at 7:17 PM, Torstein Husebø torst...@huseboe.net wrote:
 ---
  NEWS| 4 ++--
  man/journal-remote.conf.xml | 2 +-
  src/libsystemd/sd-bus/bus-control.c | 2 +-
  src/libsystemd/sd-bus/bus-creds.c   | 6 +++---
  src/shared/architecture.c   | 2 +-
  src/shared/architecture.h   | 2 +-
  src/shared/capability.h | 2 +-
  src/shared/fdset.c  | 2 +-
  src/shared/util.c   | 2 +-
  9 files changed, 12 insertions(+), 12 deletions(-)

 diff --git a/NEWS b/NEWS
 index f72f502129..ee533b4363 100644
 --- a/NEWS
 +++ b/NEWS
 @@ -3997,7 +3997,7 @@ CHANGES WITH 191:
  * HandleSleepKey= in logind.conf has been split up into
HandleSuspendKey= and HandleHibernateKey=. The old setting
is not available anymore. X11 and the kernel are
 -  distuingishing between these keys and we should too. This
 +  distinguishing between these keys and we should too. This
also means the inhibition lock for these keys has been split
into two.

 @@ -4743,7 +4743,7 @@ CHANGES WITH 43:

  * Various functionality updates to libsystemd-login.so

 -* Track class of PAM logins to distuingish greeters from
 +* Track class of PAM logins to distinguish greeters from
normal user logins.

  Contributions from: Kay Sievers, Lennart Poettering, Michael
 diff --git a/man/journal-remote.conf.xml b/man/journal-remote.conf.xml
 index a7b2227182..fc60258d0b 100644
 --- a/man/journal-remote.conf.xml
 +++ b/man/journal-remote.conf.xml
 @@ -83,7 +83,7 @@
varlistentry
  termvarnameServerKeyFile=/varname/term

 -listitemparaSSL key in PEM format/para/listitem
 +listitemparaSSL key in PEM format./para/listitem
/varlistentry

varlistentry
 diff --git a/src/libsystemd/sd-bus/bus-control.c 
 b/src/libsystemd/sd-bus/bus-control.c
 index fa4c28174d..43ddfc651d 100644
 --- a/src/libsystemd/sd-bus/bus-control.c
 +++ b/src/libsystemd/sd-bus/bus-control.c
 @@ -429,7 +429,7 @@ static int bus_populate_creds_from_items(
  c-mask |= SD_BUS_CREDS_PPID;
  } else if (item-pids.pid == 1) {
  /* The structure doesn't
 - * really distuingish the case
 + * really distinguish the case
   * where a process has no
   * parent and where we don't
   * know it because it could
 diff --git a/src/libsystemd/sd-bus/bus-creds.c 
 b/src/libsystemd/sd-bus/bus-creds.c
 index fed66823c7..4d67619cf8 100644
 --- a/src/libsystemd/sd-bus/bus-creds.c
 +++ b/src/libsystemd/sd-bus/bus-creds.c
 @@ -303,7 +303,7 @@ _public_ int sd_bus_creds_get_ppid(sd_bus_creds *c, pid_t 
 *ppid) {
  if (!(c-mask  SD_BUS_CREDS_PPID))
  return -ENODATA;

 -/* PID 1 has no parent process. Let's distuingish the case of
 +/* PID 1 has no parent process. Let's distinguish the case of
   * not knowing and not having a parent process by the returned
   * error code. */
  if (c-ppid == 0)
 @@ -989,7 +989,7 @@ int bus_creds_add_more(sd_bus_creds *c, uint64_t mask, 
 pid_t pid, pid_t tid) {
  if (missing  SD_BUS_CREDS_EXE) {
  r = get_process_exe(pid, c-exe);
  if (r == -ESRCH) {
 -/* Unfortunately we cannot really distuingish
 +/* Unfortunately we cannot really distinguish
   * the case here where the process does not
   * exist, and /proc/$PID/exe being unreadable
   * because $PID is a kernel thread. Hence,
 @@ -1101,7 +1101,7 @@ int bus_creds_add_more(sd_bus_creds *c, uint64_t mask, 
 pid_t pid, pid_t tid) {
  }

  /* In case only the exe path was to be read we cannot
 - * distuingish the case where the exe path was unreadable
 + * distinguish the case where the exe path was unreadable
   * because the process was a kernel thread, or when the
   * process didn't exist at all. Hence, let's do a final check,
   * to be sure. */
 diff --git a/src/shared/architecture.c b/src/shared/architecture.c
 index 884abdd3ea..8e72e7a36a 100644
 --- a/src/shared/architecture.c
 +++ b/src/shared/architecture.c
 @@ -35,7 +35,7 @@ int uname_architecture(void) {
   * 1:1. Instead we try to clean it up and break down the
   * confusion on x86 and arm in particular.
   *
 - * We do not try to distuingish CPUs not CPU features, but
 + * We do not try to distinguish CPUs not CPU features, but
   * actual architectures, i.e. that 

Re: [systemd-devel] 220 udev boot regression: timeout, giving up waiting for workers to finish

2015-05-26 Thread Tom Gundersen
On Tue, May 26, 2015 at 5:11 PM, Martin Pitt martin.p...@ubuntu.com wrote:
 Hello Tom, all,

 with 220 I get a severe boot time regression:

   $ systemd-analyze
   Startup finished in 30.751s (kernel) + 11.706s (userspace) = 42.458s

 which used to be

   $ systemd-analyze
   Startup finished in 703ms (kernel) + 890ms (userspace) = 1.593s

 (this is a VM)

 It seems udevd --daemon spends 30 seconds timing out in the initramfs:

   [0.384519] systemd-udevd[55]: starting version 220
   [   30.736381] systemd-udevd[56]: timeout, giving up waiting for workers to 
 finish

 and then some more in the real root:

$ systemd-analyze blame
  10.826s dev-vda1.device
  10.067s systemd-tmpfiles-setup-dev.service
  10.031s systemd-sysctl.service
  10.019s systemd-journald.service
  10.005s sys-fs-fuse-connections.mount
  10.001s tmp.mount

 (full journal at http://paste.ubuntu.com/11372265/, but it's not very
 useful)

 I bisected this to

   http://cgit.freedesktop.org/systemd/systemd/commit/?id=e237d8c
   udevd: move file descriptors to Manager

 this is hard to revert individually as there are lots of other recent changes
 in udev around this commit, but any version before that commit is fast
 and doesn't give that timeout error.

 Current trunk as of commit 185abfc3 still has that problem, so it
 wasn't fixed by one of the recent udev commits.

 Does anyone else see this too? Any idea what causes this?

FWIW, I'm looking into this.

Cheers,

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


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Michael Biebl
2015-05-26 17:57 GMT+02:00 Reindl Harald h.rei...@thelounge.net:
 There's a stable git tree maintained by Zbigniew, Lukas and friends,
 that carries backports for the stable releases. Most vendors should
 consider following that repo I figure.

 I try to help the backporting business by tagging the commits I
 personally consider backport-worthy with git notes and the
 Backport: field


 it just works poor

 * https://bugzilla.redhat.com/show_bug.cgi?id=1185278
   never got fixed in F20 but is fixed in Fedora 21
 * https://bugzilla.redhat.com/show_bug.cgi?id=1185277 open for months

 and in general a bunch of git commits don't replace a upstream changelog of
 a minor release where as user you never have any idea what your current
 installed package really is

 with a 220.1 and a usptream download of 220.1 containing a changelog things
 are entirely different (besides that the version numbers for a project
 existing just a few years are strange to say it nicely)

Maybe we(distro maintainers included) could work together with
Zbigniew and cut releases from the stable-branches?



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Lennart Poettering
On Tue, 26.05.15 17:57, Reindl Harald (h.rei...@thelounge.net) wrote:

 
 Am 26.05.2015 um 17:29 schrieb Lennart Poettering:
 On Tue, 26.05.15 16:39, Reindl Harald (h.rei...@thelounge.net) wrote:
 which shows that a important project like systemd playing on the same level
 as the linux kernel *just needs* point releases, there is a reason that the
 kernel has point-releases and not only for the latest and greatest version,
 systemd as well as the kernel are not a random webbrowser
 
 There's a stable git tree maintained by Zbigniew, Lukas and friends,
 that carries backports for the stable releases. Most vendors should
 consider following that repo I figure.
 
 I try to help the backporting business by tagging the commits I
 personally consider backport-worthy with git notes and the
 Backport: field
 
 it just works poor
 
 * https://bugzilla.redhat.com/show_bug.cgi?id=1185278
   never got fixed in F20 but is fixed in Fedora 21

Well, it's not really a bug. We require util-linux to be around. If
you make it unavailable then you get to to keep the pieces. It's that
simple.

 * https://bugzilla.redhat.com/show_bug.cgi?id=1185277 open for
   months

I wasn't aware there was a reproducer for this issue now. Good to
know.

 and in general a bunch of git commits don't replace a upstream changelog of
 a minor release where as user you never have any idea what your current
 installed package really is.

Nah, this is not how this works. We simply do not provide turn-key
ready versions of systemd. systemd is not an app, it needs to be
integrated by the distributions, and they will have to adapt it to
their needs. Hence: if you want minor release information check the
RPM changelog, but don't expect that from us. We are not a product, we
are just a building block others may build a product from, and thus
need to polish it.

 with a 220.1 and a usptream download of 220.1 containing a changelog things
 are entirely different (besides that the version numbers for a project
 existing just a few years are strange to say it nicely)

Well, I certainly have enough things to do. We have trouble keeping up
with he amount of work that we already get, and I have no intention to
make things even more complex by maintaining multiple branches for
you, if the distros already do this anyway.

And again, there's already the stable tree maintained by Zbigniew and
friends. It comes with a change history git log and it's constantly
updated. Zbigniew doesn't tag releases in it, but if that's what you
need you can just tag it yourself and count each commit up that is
applied based on a stable branch...

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] udev now crashes in daemon mode

2015-05-26 Thread Mantas Mikulėnas
Thanks, finally got around to rebooting, and udev now starts properly.
However, when the cleanuphook calls udevadm control --exit, it takes
quite a while (though the system later boots normally). With --debug
enabled, I see:

 udevd message (EXIT) received
 [10-20 seconds pass]
 timeout, giving up waiting for workers to finish

I tried running it manually from the initramfs shell, and udev had no
workers at all at that point.

This is with the latest 185abfc3d6b build.

On Sun, May 24, 2015 at 4:30 PM, Tom Gundersen t...@jklm.no wrote:

 Hi Mantas,



 On Sun, May 24, 2015 at 11:40 AM, Mantas Mikulėnas graw...@gmail.com
 wrote:
  So, udev v220 crashes in my initramfs with the following message:
 
  starting version v220
  Assertion 'manager-pid == getpid()' failed at src/udev/udevd.c:568,
  function ev
  Aborting.
 
  It seems main calls manager_new() before forking, so the parent PID is
  stored instead of child PID.
 
  (I'm using Arch Linux with the traditional mkinitcpio-based initramfs,
 which
  starts udev using systemd-udevd --daemon --resolve-names=never.)

 Thanks for the report. This should be fixed now in git, please let me
 know if that is not the case.

 Cheers,

 Tom




-- 
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] Reduce unit-loading time

2015-05-26 Thread Filipe Brandenburger
Hi,

On Sun, May 24, 2015 at 8:41 PM, cee1 fykc...@gmail.com wrote:
 I tried ureadahead, but got following error:

 write(2, ureadahead: Error while tracing:..., 59ureadahead: Error
 while tracing: No such file or directory

 Needs an out-of-tree kernel patch?

Yes, ureadahead needs an out-of-tree kernel patch to add trace events
for open(), exec() and uselib() syscalls that take file paths.

http://bugs.launchpad.net/bugs/462111

AFAICT, this never went upstream because upstream was discussing a
generic approach of tracing any system calls, but I believe that never
really panned out...

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


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Martin Pitt
Lennart Poettering [2015-05-26 18:22 +0200]:
 Well, I certainly have enough things to do. We have trouble keeping up
 with he amount of work that we already get, and I have no intention to
 make things even more complex by maintaining multiple branches for
 you, if the distros already do this anyway.

Honestly, git format-patch (or even more convenient proper packaging
tools like Debian's git-buildpackages pq) make it a trivial
operation to get one or several upstream fixes, it's not more work
(usually less) than packaging an entire new upstream release.

Bugs that affect the tarball are a tad harder, but adding

  rm -f src/journal/audit_type-to-name.h src/udev/keyboard-keys-from-name.gperf

to the build script until we get 221 isn't rocket science either.

So I agree that maintaining more branches and upstream releases would
cause a lot of low-benefit work. I'd much rather get some distro-side
testing before we do an upstream release (see my other reply).

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] journal, coredump: allow relative values in some configuration options

2015-05-26 Thread Lennart Poettering
On Mon, 25.05.15 13:48, jsyna...@redhat.com (jsyna...@redhat.com) wrote:

 -static off_t arg_process_size_max = PROCESS_SIZE_MAX;
 -static off_t arg_external_size_max = EXTERNAL_SIZE_MAX;
 -static size_t arg_journal_size_max = JOURNAL_SIZE_MAX;
 -static off_t arg_keep_free = (off_t) -1;
 -static off_t arg_max_use = (off_t) -1;
 +static SizeParameter arg_process_size_max = {PROCESS_SIZE_MAX, false};
 +static SizeParameter arg_external_size_max = {EXTERNAL_SIZE_MAX, false};
 +static SizeParameter arg_journal_size_max = {JOURNAL_SIZE_MAX, false};
 +static SizeParameter arg_keep_free = {(uint64_t) -1, false};
 +static SizeParameter arg_max_use = {(uint64_t) -1, false};

So far we placed a space between { and the first word, and before }...

That said, I think it would make ton of sense to introduce a macro:

#define SIZE_PARAMETER_ABSOLUTE(x) { .value = (x), .relative = false }

And then use that everywhere.

  
  static int parse_config(void) {
  static const ConfigTableItem items[] = {
 @@ -109,7 +111,7 @@ static int parse_config(void) {
  { Coredump, Compress, config_parse_bool, 
  0, arg_compress  },
  { Coredump, ProcessSizeMax,   config_parse_iec_off,  
  0, arg_process_size_max  },
  { Coredump, ExternalSizeMax,  config_parse_iec_off,  
  0, arg_external_size_max },
 -{ Coredump, JournalSizeMax,   config_parse_iec_size, 
  0, arg_journal_size_max  },
 +{ Coredump, JournalSizeMax,   config_parse_iec_off,  
  0, arg_journal_size_max  },
  { Coredump, KeepFree, config_parse_iec_off,  
  0, arg_keep_free },
  { Coredump, MaxUse,   config_parse_iec_off,  
  0, arg_max_use   },
  {}

I am pretty sure config_parse_iec_off should be renamed to
config_parse_size_parameter or so if it's now parsing things into that.

 @@ -122,6 +124,15 @@ static int parse_config(void) {
   false, NULL);
  }
  
 +static uint64_t get_available(void) {
 +struct statvfs ss;
 +
 +if (statvfs(/var/lib/systemd/coredump, ss) = 0)
 +return ss.f_bsize * ss.f_bavail;
 +
 +return 0;
 +}

I'd be careful with this. Turning failure to query the disk space into
0, sounds wrong, because validly the disk space might be zero, which
cannot be distinguished then. And more importantly, if we cannot query
the disk space we should probably warn about that, and then fall back
to some constant absolute values, and not 0...

  
 +journal_size_max =
 size_parameter_evaluate(arg_journal_size_max, available);

I don't think that we should really do any such logic for the journal
size limit. This should stay an absolute value I am sure. In
particular since the journal does not store its data in
/var/lib/coredump, which you base your evaluation on.

  static int journal_file_setup_data_hash_table(JournalFile *f) {
  uint64_t s, p;
  Object *o;
 +struct statvfs ss;
  int r;
  
  assert(f);
  
 +if (fstatvfs(f-fd, ss)  0)
 +return -errno;
 +
  /* We estimate that we need 1 hash table entry per 768 of
 journal file and we want to make sure we never get beyond
 75% fill level. Calculate the hash table size for the
 maximum file size based on these metrics. */
  
 -s = (f-metrics.max_size * 4 / 768 / 3) * sizeof(HashItem);
 +s = (size_parameter_evaluate(f-metrics.max_size, ss.f_bsize * 
 ss.f_bavail) * 4 / 768 / 3) * sizeof(HashItem);
  if (s  DEFAULT_DATA_HASH_TABLE_SIZE)
  s = DEFAULT_DATA_HASH_TABLE_SIZE;

Hmm, this doesn't look right. here we choose the hash table sizes to
use for a file, and I doubt we should base this on the currently
available disk space, since sizing the hashtable will have an effect
on the entire lifetime of the file, during which the available disk
space might change wildly.

I think it would be best not to do relative sizes for the journal file
max size at all, and continue to only support and absolute value for
that. 

 +
 +uint64_t size_parameter_evaluate(const SizeParameter *sp, uint64_t 
 available) {
 +if (sp-value == (uint64_t) -1)
 +return (uint64_t) -1;
 +
 +if (sp-relative)
 +return sp-value * 0.01 * available;

Hmm, so this implements this as percentage after all. as mentioned in
my earlier mail, I think this should be normalized to 2^32 instead, so
that 2^32 maps to 100%...

Lennart

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


[systemd-devel] non-merged /usr changes [was: pre-release warnings?]

2015-05-26 Thread Martin Pitt
Hey Lennart,

Lennart Poettering [2015-05-26 17:31 +0200]:
 But note that upstream is supposed to be non-redhat centric, and is
 supposed to support non-merged /usr. If it's really about that, I#d be
 inetersted to know what these patches are about, and maybe we can move
 some upstream.

There's a bunch of different config files, such as /etc/locale.conf
and /etc/X11/xorg.conf.d/00-keyboard.conf (Fedora) vs.
/etc/default/locale and /etc/default/keyboard (Debian) (Debian uses
just one keyboard layout for both console and X), but these got
removed upstream to avoid some #ifdeffery [1]. Not much to worry
about.

More intrusive is the removal of chkconfig and addition of
update-rc.d:
  
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/Make-systemctl-enable-disable-call-update-rc.d-for-s.patch?h=experimental
  
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/systemctl-don-t-skip-native-units-when-enabling-disa.patch?h=experimental

but again moving these upstream would just mean more #ifdeffery.

Then there's the (now completely separate) fsckd which you also
already rejected:
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/fsckd-daemon-for-inter-fsckd-communication.patch?h=experimental-220
I'd be happy to put that back and maintain it upstream, perhaps with a
--configure option. But it rebases well as the changes to existing
files are minimal.

Then we have some stupid stuff like
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/buildsys-Don-t-default-to-gold-as-the-linker.patch?h=experimental-220
which got rejected, but are nevertheless still necessary on distros
(and not only for us, see responses to [2])

The single one which I'd *really* like to get rid of is this 91 kB
patch beast:
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/Fix-paths-in-man-pages.patch?h=experimental-220
This fixes the manpages to give correct paths for non-merged /usr. I
think the correct upstream fix would be to replace the hardcoded
/usr/lib/systemd/ bits with XML entities like systemunitdir; or
perhaps more generically rootlibdir; (even with --enable-split-usr
and --with-rootprefix=/ some bits still land in /usr/, like
/usr/lib/systemd/user{,-generators} and /usr/lib/systemd/catalog/. If
you'd accept a patch for that, I'll work on that.

That's just a random sample; I'm happy to go through our patches [3] in
more details if you want. The manpage one is the one that causes more
work to update than all other patches together, so getting rid of that
would be quite an improvement!

Martin


[1] http://cgit.freedesktop.org/systemd/systemd/commit/?id=46a2911bf
[2] 
http://lists.freedesktop.org/archives/systemd-devel/2015-February/028544.html
[3] 
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches?h=experimental-220
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 udev boot regression: timeout, giving up waiting for workers to finish

2015-05-26 Thread Tom Gundersen
On Tue, May 26, 2015 at 9:04 PM, Christian Hesse l...@eworm.de wrote:
 Martin Pitt martin.p...@ubuntu.com on Tue, 2015/05/26 17:11:
 Hello Tom, all,

 with 220 I get a severe boot time regression:

   $ systemd-analyze
   Startup finished in 30.751s (kernel) + 11.706s (userspace) = 42.458s

 which used to be

   $ systemd-analyze
   Startup finished in 703ms (kernel) + 890ms (userspace) = 1.593s

 (this is a VM)

 It seems udevd --daemon spends 30 seconds timing out in the initramfs:

   [0.384519] systemd-udevd[55]: starting version 220
   [   30.736381] systemd-udevd[56]: timeout, giving up waiting for workers
 to finish

 and then some more in the real root:

$ systemd-analyze blame
  10.826s dev-vda1.device
  10.067s systemd-tmpfiles-setup-dev.service
  10.031s systemd-sysctl.service
  10.019s systemd-journald.service
  10.005s sys-fs-fuse-connections.mount
  10.001s tmp.mount

 (full journal at http://paste.ubuntu.com/11372265/, but it's not very
 useful)

 I bisected this to

   http://cgit.freedesktop.org/systemd/systemd/commit/?id=e237d8c
   udevd: move file descriptors to Manager

 this is hard to revert individually as there are lots of other recent
 changes in udev around this commit, but any version before that commit is
 fast and doesn't give that timeout error.

 Current trunk as of commit 185abfc3 still has that problem, so it
 wasn't fixed by one of the recent udev commits.

 Does anyone else see this too? Any idea what causes this?

 I do see this as well. And probably we have an upstream bug [0] already.

 Wondering whether or not my report about inotify_add_watch() failed: Bad
 file descriptor [1] is related. Do you see that as well?
 BTW, is it expected to have fd_inotify in udevd.c and inotify_fd in
 udev_watch.c?

This is unrelated.

Cheers,

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


Re: [systemd-devel] 220 udev boot regression: timeout, giving up waiting for workers to finish

2015-05-26 Thread Tom Gundersen
On Tue, May 26, 2015 at 9:04 PM, Christian Hesse l...@eworm.de wrote:
 Martin Pitt martin.p...@ubuntu.com on Tue, 2015/05/26 17:11:
 Hello Tom, all,

 with 220 I get a severe boot time regression:

   $ systemd-analyze
   Startup finished in 30.751s (kernel) + 11.706s (userspace) = 42.458s

 which used to be

   $ systemd-analyze
   Startup finished in 703ms (kernel) + 890ms (userspace) = 1.593s

 (this is a VM)

 It seems udevd --daemon spends 30 seconds timing out in the initramfs:

   [0.384519] systemd-udevd[55]: starting version 220
   [   30.736381] systemd-udevd[56]: timeout, giving up waiting for workers
 to finish

 and then some more in the real root:

$ systemd-analyze blame
  10.826s dev-vda1.device
  10.067s systemd-tmpfiles-setup-dev.service
  10.031s systemd-sysctl.service
  10.019s systemd-journald.service
  10.005s sys-fs-fuse-connections.mount
  10.001s tmp.mount

 (full journal at http://paste.ubuntu.com/11372265/, but it's not very
 useful)

 I bisected this to

   http://cgit.freedesktop.org/systemd/systemd/commit/?id=e237d8c
   udevd: move file descriptors to Manager

 this is hard to revert individually as there are lots of other recent
 changes in udev around this commit, but any version before that commit is
 fast and doesn't give that timeout error.

 Current trunk as of commit 185abfc3 still has that problem, so it
 wasn't fixed by one of the recent udev commits.

 Does anyone else see this too? Any idea what causes this?

 I do see this as well. And probably we have an upstream bug [0] already.

Oh, and this bug report is probably unrelated. It is an old one (that
I could never reproduce), and the relevant parts were reworked
(probably causing the current issues).

-t

 Wondering whether or not my report about inotify_add_watch() failed: Bad
 file descriptor [1] is related. Do you see that as well?
 BTW, is it expected to have fd_inotify in udevd.c and inotify_fd in
 udev_watch.c?

 [0] https://bugs.freedesktop.org/show_bug.cgi?id=90051
 [1] http://lists.freedesktop.org/archives/systemd-devel/2015-May/032213.html
 --
 main(a){char*c=/*Schoene Gruesse */B?IJj;MEH
 CX:;,b;for(a/*Chris   get my mail address:*/=0;b=c[a++];)
 putchar(b-1/(/*   gcc -o sig sig.c  ./sig*/b/42*2-3)*42);}
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] inotify_add_watch() failed: Bad file descriptor

2015-05-26 Thread Tom Gundersen
On Tue, May 26, 2015 at 10:14 AM, Christian Hesse l...@eworm.de wrote:
 Hello everybody,

 with systemd v220 I see inotify errors from udevd. I get this once:

 systemd-udevd: inotify_add_watch(9, /dev/sr0, 10) failed: Bad file descriptor

 And a lot of these:

 systemd-udevd: inotify_add_watch(9, /dev/dm-[0-9]+, 10) failed: Bad file
 descriptor

This was fixed by David in 185abfc3d6b4e8f804a3f7216cd8b0459593af87.

Cheers,

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


Re: [systemd-devel] 220: --disable-audit broken?

2015-05-26 Thread Lennart Poettering
On Fri, 22.05.15 11:27, Marc-Antoine Perennou (marc-anto...@perennou.com) wrote:

 Hi,
 
 On 22 May 2015 at 11:16,  baldu...@units.it wrote:
  hello,
 
  while building 220 I get:
 
  In file included from src/journal/audit-type.c:32:0:
  src/journal/audit_type-to-name.h: In function 'audit_type_to_string':
  src/journal/audit_type-to-name.h:23:14: error: 'AUDIT_USER_AUTH' 
  undeclared (first use in this function)
   case AUDIT_USER_AUTH: return USER_AUTH;
^
 
 I got the same here
 
 rm src/journal/audit_type-to-name.h src/udev/keyboard-keys-from-name.gperf
 
 Solved this one and another udev-related. These generated files are in
 the tarball when they shouldn't.

I think this is now solved with Tom's commit
ee3c31bf69746c5afc764c3d0337feec1bf25f0e of your patch.

 Btw src/boot/efi is missing from the tarball, too.

I think this is now solved with Tom's commit
f80099c06fd12c87da4d2207fb2e2f31ffaec6ed of your patch.

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] Vendor default masked service

2015-05-26 Thread Lennart Poettering
On Tue, 26.05.15 11:53, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

 Hi,
 
 I was wondering if we have a way to provide vendor default masked
 service?

Well, so far our thinking was that if the vendor wants to make a unit
completely unavailable he should simply not ship it in the first
place.

What's the usecase for a vendor masking a unit, but installing it? Why
not remove it in the first place entirely?

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] how to call dbus ListUnits for user units?

2015-05-26 Thread Mantas Mikulėnas
On Tue, May 26, 2015 at 9:33 PM, Chris Morgan chmor...@gmail.com wrote:

 But I can't seem to figure out how to do the same for user units.
 There doesn't seem to be an org.freedesktop.systemd1 interface on my
 current user's session bus and I wasn't able to spot anything in the
 interfaces on the system bus that had a nested interface of
 org.freedesktop.system1.Manager...


The first org.freedesktop.systemd1 here is a /service/ name; the usual
hierarchy is bus - service - object - interface - method, no such thing as
nested interfaces.

Anyway. The user processes are not allowed to own service names on the
system bus. And `systemd --user` is a per-user service, not a per-session
one, so it cannot be on the session bus for various reasons: it doesn't
know the bus address; it needs to outlive the session bus; the user might
sometimes have multiple sessions with their own 'session bus' instances.

So the idea is that `systemd --user` would be found on the /user/ bus,
which would someday replace the 'session' bus entirely.

But right now, the 'user' bus does not exist by default. To create it, you
need either
a) enable/install/boot with kdbus,
or b) obtain the dbus.service  dbus.socket user units. (They're in
dbus-git, or various other places like 
https://wiki.archlinux.org/index.php/Systemd/User#D-Bus.)

Configured this way, the 'user' bus won't replace the session bus yet, but
you *will* be able to connect to it and reach systemd, at address
kernel:path=/dev/kdbus/$UID-user/bus;unix:path=$XDG_RUNTIME_DIR/bus.

-- 
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] nspawn: No Return key in machinectl login?

2015-05-26 Thread Tobias Hunger
This is stty -a from outside the container:

speed 38400 baud; rows 46; columns 114; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?;
eol2 = M-^?; swtch = undef; start = ^Q;
stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O;
min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl
-ixon -ixoff -iuclc ixany imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
-echoprt echoctl echoke

This is stty -a inside the nspawn-container:

speed 38400 baud; rows 46; columns 114; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = undef;
eol2 = undef; swtch = undef; start = ^Q;
stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O;
min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl
-ixon -ixoff -iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten echo echoe echok -echonl -noflsh -xcase -tostop
-echoprt -echoctl echoke

The difference is:
eol, eol2, -icrnl -ixany -imaxbel iutf8 -iexten -echoctl

stty -F /dev/ptmx is identical inside and outside of the container --
but I am not sure whether that is what you were asking in the second
part of your reply.

I tried running stty eol ^D -F /dev/pts/0 inside the container and
got a SIGSEGV. It works outside the container.

Best Regards,
Tobias


On Tue, May 26, 2015 at 4:11 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Sat, 23.05.15 00:09, Tobias Hunger (tobias.hun...@gmail.com) wrote:

 Hello,

 I am having a problem with one of my containers set up with
 systemd-nspawn. For some reason the return key will not work most of
 the time (19 out of 20 attemps) after doing machinectl login into that
 machine.

 This effects not all programs: bash works, fish-shell does not. Sudo
 password entry does not work either. Git is broken (but hardly ever
 requires user input, so that is not that tragic;-), vi works fine.

 I only have this one one container image, even though it is built
 based on an image that is also used by container images that work
 fine. So I think the image should have all the important bits and
 pieces in place.

 I am kind of lost that close to the termcap:-) Does somebody have any
 ideas on how I can debug this?

 What does stty -a say?

 Consider comparing stty on the pty master (host side) as well as the
 pty itself (container size) in the cases where this works, and where
 it does not.

 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] how to call dbus ListUnits for user units?

2015-05-26 Thread Chris Morgan
On Tue, May 26, 2015 at 3:22 PM, Mantas Mikulėnas graw...@gmail.com wrote:
 On Tue, May 26, 2015 at 9:33 PM, Chris Morgan chmor...@gmail.com wrote:

 But I can't seem to figure out how to do the same for user units.
 There doesn't seem to be an org.freedesktop.systemd1 interface on my
 current user's session bus and I wasn't able to spot anything in the
 interfaces on the system bus that had a nested interface of
 org.freedesktop.system1.Manager...


 The first org.freedesktop.systemd1 here is a /service/ name; the usual
 hierarchy is bus - service - object - interface - method, no such thing as
 nested interfaces.

 Anyway. The user processes are not allowed to own service names on the
 system bus. And `systemd --user` is a per-user service, not a per-session
 one, so it cannot be on the session bus for various reasons: it doesn't know
 the bus address; it needs to outlive the session bus; the user might
 sometimes have multiple sessions with their own 'session bus' instances.

 So the idea is that `systemd --user` would be found on the /user/ bus, which
 would someday replace the 'session' bus entirely.

 But right now, the 'user' bus does not exist by default. To create it, you
 need either
 a) enable/install/boot with kdbus,
 or b) obtain the dbus.service  dbus.socket user units. (They're in
 dbus-git, or various other places like
 https://wiki.archlinux.org/index.php/Systemd/User#D-Bus.)

 Configured this way, the 'user' bus won't replace the session bus yet, but
 you *will* be able to connect to it and reach systemd, at address
 kernel:path=/dev/kdbus/$UID-user/bus;unix:path=$XDG_RUNTIME_DIR/bus.

 --
 Mantas Mikulėnas graw...@gmail.com

Hmm. I guess user services aren't used as much as system ones are?

Is there another way to interface with systemctl like functionality
programmatically? I have a c application that today is shelling out to
systemctl to start services (which is fine for me since I'm not that
concerned if it fails but it would be nice to know right at that
time), but once everything is started I'd like to go through the
services to make sure they all got started successfully. I didn't want
to shell out to 'systemctl --user status xxx' and parse the output

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


Re: [systemd-devel] 220 udev boot regression: timeout, giving up waiting for workers to finish

2015-05-26 Thread Christian Hesse
Martin Pitt martin.p...@ubuntu.com on Tue, 2015/05/26 17:11:
 Hello Tom, all,
 
 with 220 I get a severe boot time regression:
 
   $ systemd-analyze
   Startup finished in 30.751s (kernel) + 11.706s (userspace) = 42.458s
 
 which used to be
 
   $ systemd-analyze
   Startup finished in 703ms (kernel) + 890ms (userspace) = 1.593s
 
 (this is a VM)
 
 It seems udevd --daemon spends 30 seconds timing out in the initramfs:
 
   [0.384519] systemd-udevd[55]: starting version 220
   [   30.736381] systemd-udevd[56]: timeout, giving up waiting for workers
 to finish
 
 and then some more in the real root:
 
$ systemd-analyze blame
  10.826s dev-vda1.device
  10.067s systemd-tmpfiles-setup-dev.service
  10.031s systemd-sysctl.service
  10.019s systemd-journald.service
  10.005s sys-fs-fuse-connections.mount
  10.001s tmp.mount
 
 (full journal at http://paste.ubuntu.com/11372265/, but it's not very
 useful)
 
 I bisected this to
 
   http://cgit.freedesktop.org/systemd/systemd/commit/?id=e237d8c
   udevd: move file descriptors to Manager
 
 this is hard to revert individually as there are lots of other recent
 changes in udev around this commit, but any version before that commit is
 fast and doesn't give that timeout error.
 
 Current trunk as of commit 185abfc3 still has that problem, so it
 wasn't fixed by one of the recent udev commits.
 
 Does anyone else see this too? Any idea what causes this?

I do see this as well. And probably we have an upstream bug [0] already.

Wondering whether or not my report about inotify_add_watch() failed: Bad
file descriptor [1] is related. Do you see that as well?
BTW, is it expected to have fd_inotify in udevd.c and inotify_fd in
udev_watch.c?

[0] https://bugs.freedesktop.org/show_bug.cgi?id=90051
[1] http://lists.freedesktop.org/archives/systemd-devel/2015-May/032213.html
-- 
main(a){char*c=/*Schoene Gruesse */B?IJj;MEH
CX:;,b;for(a/*Chris   get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/*   gcc -o sig sig.c  ./sig*/b/42*2-3)*42);}


pgpjACQJgD4Y4.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] ExecStart vs ExecStartPre

2015-05-26 Thread Steven Noonan
Hi there,

I'm wondering what the functional difference is between doing:

ExecStartPre=/bin/foo
ExecStart=/bin/bar

and

ExecStart=/bin/foo
ExecStart=/bin/bar

From my read of the systemd.service man page, they appear to have the
same behavior in the common use case.

The only difference I can see is that groups of ExecStartPre and
ExecStart groups can be rearranged. That is, you could have an
ExecStartPre line *after* the ExecStart line in the file, and the
ExecStartPre would still be executed first. But the ordering of
multiple ExecStart (or ExecStartPre) lines in a single systemd.service
file matters, because it has explicit ordering as written in the file.

Why would someone choose one over the other? What differences am I missing?

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


Re: [systemd-devel] how to call dbus ListUnits for user units?

2015-05-26 Thread Chris Morgan
On Tue, May 26, 2015 at 4:05 PM, Mantas Mikulėnas graw...@gmail.com wrote:
 On Tue, May 26, 2015 at 10:32 PM, Chris Morgan chmor...@gmail.com wrote:

 On Tue, May 26, 2015 at 3:22 PM, Mantas Mikulėnas graw...@gmail.com
 wrote:
  On Tue, May 26, 2015 at 9:33 PM, Chris Morgan chmor...@gmail.com
  wrote:
 
  But I can't seem to figure out how to do the same for user units.
  There doesn't seem to be an org.freedesktop.systemd1 interface on my
  current user's session bus and I wasn't able to spot anything in the
  interfaces on the system bus that had a nested interface of
  org.freedesktop.system1.Manager...
 
 
  The first org.freedesktop.systemd1 here is a /service/ name; the usual
  hierarchy is bus - service - object - interface - method, no such thing
  as
  nested interfaces.
 
  Anyway. The user processes are not allowed to own service names on the
  system bus. And `systemd --user` is a per-user service, not a
  per-session
  one, so it cannot be on the session bus for various reasons: it doesn't
  know
  the bus address; it needs to outlive the session bus; the user might
  sometimes have multiple sessions with their own 'session bus' instances.
 
  So the idea is that `systemd --user` would be found on the /user/ bus,
  which
  would someday replace the 'session' bus entirely.
 
  But right now, the 'user' bus does not exist by default. To create it,
  you
  need either
  a) enable/install/boot with kdbus,
  or b) obtain the dbus.service  dbus.socket user units. (They're in
  dbus-git, or various other places like
  https://wiki.archlinux.org/index.php/Systemd/User#D-Bus.)
 
  Configured this way, the 'user' bus won't replace the session bus yet,
  but
  you *will* be able to connect to it and reach systemd, at address
  kernel:path=/dev/kdbus/$UID-user/bus;unix:path=$XDG_RUNTIME_DIR/bus.
 
  --
  Mantas Mikulėnas graw...@gmail.com

 Hmm. I guess user services aren't used as much as system ones are?

 Is there another way to interface with systemctl like functionality
 programmatically? I have a c application that today is shelling out to
 systemctl to start services (which is fine for me since I'm not that
 concerned if it fails but it would be nice to know right at that


 Note that systemctl *does* report failure as the process exit status +
 stderr output.


Yep. But some services fall over after being started (bugs in our code etc).

Does this also apply when doing 'systemctl status blah' eg. a non-zero
exit status if the service isn't running? I'm thinking that may not be
likely.



 time), but once everything is started I'd like to go through the
 services to make sure they all got started successfully. I didn't want
 to shell out to 'systemctl --user status xxx' and parse the output


 Well, systemctl uses a private socket, at $XDG_RUNTIME_DIR/systemd/private.
 It speaks the same DBus protocol, but using a direct peer-to-peer connection
 (it's not a bus address).

 Remember that it's named private for a reason -- it's not part of the
 supported API and can go away at any time (e.g. it won't exist anymore with
 kdbus), so use it at your own risk.



Hmm. I guess I'll fall back to parsing the output of systemctl status
until there is some mechanism to interact with user services.

Is support for user dbus manager in the TODO or is that just something
that is waiting on other infrastructure before being implemented? eg.
kdbus?

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


Re: [systemd-devel] ExecStart vs ExecStartPre

2015-05-26 Thread Christian Seiler
On 05/26/2015 11:12 PM, Steven Noonan wrote:
 Hi there,
 
 I'm wondering what the functional difference is between doing:
 
 ExecStartPre=/bin/foo
 ExecStart=/bin/bar
 
 and
 
 ExecStart=/bin/foo
 ExecStart=/bin/bar
 
 From my read of the systemd.service man page, they appear to have the
 same behavior in the common use case.

Three differences come directly to mind:

 - If you have unit of type that is NOT oneshot (simple, forking,
   etc.), you can have only a single ExecStart= line, not multiple
   ones. The main service process must be started in ExecStart=
   and not ExecStartPre=.

 - Even in Type=oneshot units you must have at least one ExecStart=
   line (but can in any case have an arbitrary amount of ExecStartPre=
   lines, even zero).

 - If you set PermissionsStartOnly= or RootDirectoryStartOnly=, then
   certain settings will be applied to ExecStart= but not to
   ExecStartPre= (see manpage for details).

(There are probably more.)

Generally speaking, I follow the following guidelines when writing
units:

 - Type=oneshot: I typically use only ExecStart= and only use
   ExecStartPre= if I have to use *StartOnly=true (see above).

 - other types: ExecStart= to start the service proper, ExecStartPre=
   for preparatory things (like generating a default config if none
   is already present or something along those lines)

But it really depends on your use case and as always YMMV.

Hope that helps!

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


Re: [systemd-devel] systemd-nspawn: cannot join existing macvlan

2015-05-26 Thread Lennart Poettering
On Mon, 25.05.15 16:26, Kai Krakow (hurikha...@gmail.com) wrote:

 Lennart Poettering lenn...@poettering.net schrieb:
 
  On Fri, 08.05.15 20:53, Kai Krakow (hurikha...@gmail.com) wrote:
  
   # systemd-nspawn -b --link-journal=try-guest --network-macvlan=enp4s0
   # --
   bind=/usr/portage --bind-ro=/usr/src --machine=test
   Spawning container test on /var/lib/machines/test.
   Press ^] three times within 1s to kill container.
   Failed to add new macvlan interfaces: File exists
   
   I still don't think that systemd-nspawn should insist on creating the
   host- side macvlan bridge and fail, if it cannot. It should just accept
   that it is already there.
  
  My findings show that it actually does accept this case. But I had to
  explicitly order the machines after network.target to successfully start
  at boot time.
  
  I changed git now to order nspawn units by default after
  network.target now. In the long run we should replace this by calling
  into networkd though, without waiting for all networking, for
  whatever that means...
 
 Well, now, with v220, we are back to the original problem:
 
 machines # systemd-nspawn --boot --link-journal=try-guest --machine=test --
 network-macvlan=enp5s0
 Spawning container test on /var/lib/machines/test.
 Press ^] three times within 1s to kill container.
 Failed to add new macvlan interfaces: File exists
 
 If mv-enp5s0 is already there (maybe by means of another machine), it no 
 longer starts any other machine on the same macvlan. I don't think this is 
 how it should work.

Well, there can only be one machine with the same name, and we use
that name in the macvlan interface name. Please assign different names
to your containers so that they will also get differently named
macvlan names, and all should be good.

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] 219/Fedora22: NFS mounts do not set SELINUX label to nfs_t: errno=-22

2015-05-26 Thread Lennart Poettering
On Sun, 24.05.15 15:01, Anthony Alba (ascanio.al...@gmail.com) wrote:

 Hi,
 
 On Fedora 22, systemd 219, NFS mounts no longer acquire a default label nfs_t.
 
 mount 192.168.1.6:/var/exports/1 1 -orootcontext=system_u:object_r:nfs_t
 mount.nfs: an incorrect mount option was specified
 [ 8316.276744] SELinux:
 security_context_to_sid(system_u:object_r:nfs_t) failed for (dev 0:51,
 type nfs4) errno=-22
 
 
 To my surprise, it seems to acquire labels from the NFS server (Fedora
 22/nfs4)  - how is this possible?
 
 But..it breaks libvirtd/kvm: it sees the right label if this were a
 local filesystem but audit2allow complains:
 
 
 ls -lZ guestfs/centos7.img
 -rw-r--r--. 1 qemu qemu system_u:object_r:virt_image_t:s0 22987538432
 May 24 14:56 guestfs/centos7.img
 ## for a image in /var/lib/libvirt this is the correct label.
 ## I do not know how it figured that from the NFS server
 
 SELinux is preventing qemu-system-x86 from read access on the file
 centos7.img (on NFS share).
 
 On Fedora 21, the files acquire the label nfs_t and setsebool -P 
 virt_use_nfs=on

This is unlikely to be related to systemd, we don't really do anything
special with NFS and especially not its selinux support. We simply
invoke util-linux' mount command, which in turn calls mount.nfs of the
nfs-utils package.

Please contact the nfs-utils guys,

thank you,

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] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Lennart Poettering
On Tue, 26.05.15 15:12, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote:

 Or will there be a v220.1 release shortly with releasy fix-ups?

Well, we don't do point releases in systemd. 

In systemd git we already have now the change that makes sd-bus and
sd-event public APIs, hence v221 is going to be more than just
bugfixes. 

Also, next week I'll be travelling and I doubt I will be able to
finish a new release by then. Maybe in the middle of June we can get
out a new release.

Sorry,

Lennart

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


[systemd-devel] pre-release warnings? [was: 220 tarball erroneously ships keyboard-keys-from-name.gperf]

2015-05-26 Thread Martin Pitt
Hello all,

Dimitri John Ledkov [2015-05-26 15:12 +0100]:
 Or will there be a v220.1 release shortly with releasy fix-ups?

Can we perhaps flip that around? I did a make dist/port our
patches/build packackages/run our tests round on May 11, but that was
before most of the recent hiccups landed in master. I'd rather love
to do that once I know that a release is around the corner, but as we
don't currently have release is imminent warnings none of the
packagers can do this as a pre-release exercise.

So Lennart: WDYT about announcing your intent to do a stable release
on the ML, and then us packagers can do a make dist, test an actual
tarball, and thus find all these little tarball errors, udev
regressions and what not before the official release is cut?

At least for me, the biggest part of updating to a new release is to
rebase our ~ 50 patches; doing that against a near-release tarball
will be the same amount of work; running automatic tests is negligible
human effort, and running manual tests doesn't take that long for me
(that's the point which might vastly differ for other packagers -- but
then again, testing pre-release tarballs means that not much will
change any more until the real release, so the second time testing
will be faster).

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to wait for specific interface/IP?

2015-05-26 Thread Lennart Poettering
On Sat, 23.05.15 11:03, Ian Pilcher (arequip...@gmail.com) wrote:

 Is there a simple way to make a service require that a specific network
 interface/IP address be active?
 
 I have a manually set up bridge and dnsmasq configuration for my VM
 traffic, but dnsmasq is getting started before NetworkManager has
 configured the bridge and failing because it cannot bind to the bridge's
 IP address.

Well, for networkd, there's the systemd-networkd-wait-online tool that
allows you to wait until a specific interface is up. Maybe NM supports
something similar? Please ask NM folks for help.

Also, dnsmasq should probably use IP_FREEBIND or so (at least
optionally) so that it can work without requiring the interface to be
up.

Either way, this is something to contact the NM and dnsmasq people
about.

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] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Lennart Poettering
On Fri, 22.05.15 17:28, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Hello,
 
 while packaging 220, I got the audit related build failure that was
 already reported [1], but also another one:

I think this has been fixed now with Tom's commit
ee3c31bf69746c5afc764c3d0337feec1bf25f0e contributed my Marc-Antoine.

Please verify.

Lennart

 
 | In file included from ../src/udev/udev-builtin-keyboard.c:29:0:
 | ./src/udev/keyboard-keys-from-name.h: In function 'keyboard_lookup_key':
 | ./src/udev/keyboard-keys-from-name.h:253:21: error: 'KEY_NUMERIC_A' 
 undeclared (first use in this function)
 |{numeric_a, KEY_NUMERIC_A},
 |  ^
 | ./src/udev/keyboard-keys-from-name.h:253:21: note: each undeclared 
 identifier is reported only once for each function it appears in
 | ./src/udev/keyboard-keys-from-name.h:275:21: error: 'KEY_NUMERIC_C' 
 undeclared (first use in this function)
 |{numeric_c, KEY_NUMERIC_C},
 |  ^
 | ./src/udev/keyboard-keys-from-name.h:347:21: error: 'KEY_NUMERIC_D' 
 undeclared (first use in this function)
 |{numeric_d, KEY_NUMERIC_D},
 |  ^
 | ./src/udev/keyboard-keys-from-name.h:420:21: error: 'KEY_NUMERIC_B' 
 undeclared (first use in this function)
 |{numeric_b, KEY_NUMERIC_B},
 |  ^
 | ./src/udev/keyboard-keys-from-name.h:464:26: error: 'KEY_ROTATE_DISPLAY' 
 undeclared (first use in this function)
 |{rotate_display, KEY_ROTATE_DISPLAY},
 
 This is because unlike 219 and earlier, the 220 tarball ships a
 pregenerated src/udev/keyboard-keys-from-name.gperf. In Debian sid,
 the above constants are not defined (in the kernel headers, I
 presume). I think src/udev/keyboard-keys-from-name.gperf is supposed
 to be built during package build? I see that somewhere between 219 and
 220 this happened in Makefile.am:
 
 -CLEANFILES += \
 -   src/udev/keyboard-keys-from-name.gperf \
 -   src/udev/keyboard-keys.txt \
 -   src/udev/net/link-config-gperf.c
 
 but apparently this wasn't put back someplace else?
 
 Thanks,
 
 Martin
 
 [1] http://lists.freedesktop.org/archives/systemd-devel/2015-May/032148.html
 -- 
 Martin Pitt| http://www.piware.de
 Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel


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] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Martin Pitt
Lennart Poettering [2015-05-26 16:06 +0200]:
 I think this has been fixed now with Tom's commit
 ee3c31bf69746c5afc764c3d0337feec1bf25f0e contributed my Marc-Antoine.

Confirmed this morning. Sorry, I should have followed up to the ML
immediately. Thanks Tom!

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] pre-release warnings? [was: 220 tarball erroneously ships keyboard-keys-from-name.gperf]

2015-05-26 Thread Lennart Poettering
On Tue, 26.05.15 16:26, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Hello all,
 
 Dimitri John Ledkov [2015-05-26 15:12 +0100]:
  Or will there be a v220.1 release shortly with releasy fix-ups?
 
 Can we perhaps flip that around? I did a make dist/port our
 patches/build packackages/run our tests round on May 11, but that was
 before most of the recent hiccups landed in master. I'd rather love
 to do that once I know that a release is around the corner, but as we
 don't currently have release is imminent warnings none of the
 packagers can do this as a pre-release exercise.
 
 So Lennart: WDYT about announcing your intent to do a stable release
 on the ML, and then us packagers can do a make dist, test an actual
 tarball, and thus find all these little tarball errors, udev
 regressions and what not before the official release is cut?

Well, I had been trying to stabilize things since 3 weeks before the
release, I did mention it on IRC back then. I didn't announce this on
the ML though, but I figure I could do that too, for the next cycle...

I tend to ping some people before the release, who I know have
independent test suites or care for last-minute fixes... 

 At least for me, the biggest part of updating to a new release is to
 rebase our ~ 50 patches; doing that against a near-release tarball
 will be the same amount of work; running automatic tests is negligible
 human effort, and running manual tests doesn't take that long for me
 (that's the point which might vastly differ for other packagers -- but
 then again, testing pre-release tarballs means that not much will
 change any more until the real release, so the second time testing
 will be faster).

50 non-backport patches? That sounds like a lot...

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] pre-release warnings? [was: 220 tarball erroneously ships keyboard-keys-from-name.gperf]

2015-05-26 Thread Martin Pitt
Lennart Poettering [2015-05-26 16:43 +0200]:
 Well, I had been trying to stabilize things since 3 weeks before the
 release

Ah, that's roughly when I did my last build packages from upstream
trunk test, and indeed it looked fairly well back then.

 I didn't announce this on the ML though, but I figure I could do
 that too, for the next cycle...

That would be nice. Let's give it a try and see how it goes? From your
end it's just an extra mail when you are ready to release (and maybe
giving packagers two days or so), and from our end it's just moving
all the heavy-lifting around a bit.

 50 non-backport patches? That sounds like a lot...

It's not that bad, most of them are trivial, like tweaking tmpfiles.d
or some extra historic udev rules. We have quite a bunch of patches to
get rid of Fedora/RedHat-isms and replace them with Debianisms, and
then there's a lot for having a non-merged /usr (which Debian didn't
do yet). Aside from two or three which keep breaking most of them just
tag along, but there's always enough noise to break completely
automatically building packages from git master. Anyway, this is
completely tangential.. :-)

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Lennart Poettering
On Tue, 26.05.15 16:39, Reindl Harald (h.rei...@thelounge.net) wrote:

 
 Am 26.05.2015 um 16:17 schrieb Lennart Poettering:
 On Tue, 26.05.15 15:12, Dimitri John Ledkov (dimitri.j.led...@intel.com) 
 wrote:
 
 Or will there be a v220.1 release shortly with releasy fix-ups?
 
 Well, we don't do point releases in systemd.
 
 and why?
 
 just because don't do is not enough

it's just a label after all and I like my bikesheds green without
points.

 In systemd git we already have now the change that makes sd-bus and
 sd-event public APIs, hence v221 is going to be more than just
 bugfixes.
 
 that don't fix 220
 
 Also, next week I'll be travelling and I doubt I will be able to
 finish a new release by then. Maybe in the middle of June we can get
 out a new release
 
 which shows that a important project like systemd playing on the same level
 as the linux kernel *just needs* point releases, there is a reason that the
 kernel has point-releases and not only for the latest and greatest version,
 systemd as well as the kernel are not a random webbrowser

There's a stable git tree maintained by Zbigniew, Lukas and friends,
that carries backports for the stable releases. Most vendors should
consider following that repo I figure.

I try to help the backporting business by tagging the commits I
personally consider backport-worthy with git notes and the
Backport: field.

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] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Dimitri John Ledkov
On 26 May 2015 at 15:10, Martin Pitt martin.p...@ubuntu.com wrote:
 Lennart Poettering [2015-05-26 16:06 +0200]:
 I think this has been fixed now with Tom's commit
 ee3c31bf69746c5afc764c3d0337feec1bf25f0e contributed my Marc-Antoine.

 Confirmed this morning. Sorry, I should have followed up to the ML
 immediately. Thanks Tom!

Can stable-v220 branch be started with these please?

Or will there be a v220.1 release shortly with releasy fix-ups?
-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Reindl Harald


Am 26.05.2015 um 16:17 schrieb Lennart Poettering:

On Tue, 26.05.15 15:12, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote:


Or will there be a v220.1 release shortly with releasy fix-ups?


Well, we don't do point releases in systemd.


and why?

just because don't do is not enough


In systemd git we already have now the change that makes sd-bus and
sd-event public APIs, hence v221 is going to be more than just
bugfixes.


that don't fix 220


Also, next week I'll be travelling and I doubt I will be able to
finish a new release by then. Maybe in the middle of June we can get
out a new release


which shows that a important project like systemd playing on the same 
level as the linux kernel *just needs* point releases, there is a reason 
that the kernel has point-releases and not only for the latest and 
greatest version, systemd as well as the kernel are not a random webbrowser




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to wait for specific interface/IP?

2015-05-26 Thread Alexander E. Patrakov

26.05.2015 19:03, Lennart Poettering wrote:

On Sat, 23.05.15 11:03, Ian Pilcher (arequip...@gmail.com) wrote:


Is there a simple way to make a service require that a specific network
interface/IP address be active?

I have a manually set up bridge and dnsmasq configuration for my VM
traffic, but dnsmasq is getting started before NetworkManager has
configured the bridge and failing because it cannot bind to the bridge's
IP address.


Well, for networkd, there's the systemd-networkd-wait-online tool that
allows you to wait until a specific interface is up. Maybe NM supports
something similar? Please ask NM folks for help.

Also, dnsmasq should probably use IP_FREEBIND or so (at least
optionally) so that it can work without requiring the interface to be
up.


dnsmasq supports --bind-dynamic option, which is based not on 
IP_FREEBIND, but on notifications about new or disappearing interfaces 
and addresses.


The real problem here is with non-C languages. E.g. node.js, Java, 
Python 2.7 and even Go still have absolutely no support for IP_FREEBIND.


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


[systemd-devel] 220 udev boot regression: timeout, giving up waiting for workers to finish

2015-05-26 Thread Martin Pitt
Hello Tom, all,

with 220 I get a severe boot time regression:

  $ systemd-analyze
  Startup finished in 30.751s (kernel) + 11.706s (userspace) = 42.458s

which used to be

  $ systemd-analyze
  Startup finished in 703ms (kernel) + 890ms (userspace) = 1.593s

(this is a VM)

It seems udevd --daemon spends 30 seconds timing out in the initramfs:

  [0.384519] systemd-udevd[55]: starting version 220
  [   30.736381] systemd-udevd[56]: timeout, giving up waiting for workers to 
finish

and then some more in the real root:

   $ systemd-analyze blame
 10.826s dev-vda1.device
 10.067s systemd-tmpfiles-setup-dev.service
 10.031s systemd-sysctl.service
 10.019s systemd-journald.service
 10.005s sys-fs-fuse-connections.mount
 10.001s tmp.mount

(full journal at http://paste.ubuntu.com/11372265/, but it's not very
useful)

I bisected this to

  http://cgit.freedesktop.org/systemd/systemd/commit/?id=e237d8c
  udevd: move file descriptors to Manager

this is hard to revert individually as there are lots of other recent changes
in udev around this commit, but any version before that commit is fast
and doesn't give that timeout error.

Current trunk as of commit 185abfc3 still has that problem, so it
wasn't fixed by one of the recent udev commits.

Does anyone else see this too? Any idea what causes this?

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


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


Re: [systemd-devel] 220 regression: path_is_mount_point() for non-directories

2015-05-26 Thread Lennart Poettering
On Mon, 25.05.15 21:06, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Hello all,
 
 in 220, path_is_mount_point() now always fails with -20 ENOTDIR when
 calling it on files. This is problematic as it's perfectly valid to
 have bind-mounted files; in fact, systemd's machine_id_setup() itself
 creates a /run/machine-id → /etc/machine-id bind mount if /etc is
 read-only at that time (and systemd-machine-id-commit will write it
 once root fs becomes writable).
 
 This was first introduced here:
 
   http://cgit.freedesktop.org/systemd/systemd/commit/?id=27cc6f166
   path-util: fix path_is_mount_point() for symlinks
 
 which added O_DIRECTORY, so that openat() fails with the above error.
 It also replaced path_get_parent() (which works fine for files) with
 name_to_handle_at(fd, .., ...) which only works for directories.
 
 In fd_is_mount_point() we obviously don't have access to the file name
 any more, and presumably we do want to keep it for efficiently
 implementing the rm-rf: never cross mount points commit f25afeb.
 
 Since all possible checks in fd_is_mount_point() rely on *at(, ..)
 which doesn't work for files, one solution that I see
 is to add a fallback path_is_mountpoint() if fd_is_mount_point() fails
 with ENOTDIR; in that case, should we implement all fallbacks again
 (lots of duplicated code), or just one (st_dev comparison, which seems
 the most widely supported one)?
 
 Alternatively we could pass a parent_path to fd_is_mount_point(),
 compute that in path_is_mountpoint(), and don't specify one (or maybe
 we even can specify it easily, I didn't check) in rm_rf_children() as
 file bind mounts don't seem relevant there. This would be simpler, but
 it would technically be an API break (unless we want to add
 fd_is_mount_point_with_parent).

Not an API break. Only calls prefixed with sd_ are API, we never
export any others.

But yeah, path_is_mount_point() should be reworked to operate like
openat() and similar calls, i.e. taking an fd to a dir, plus a
filename below that dir, instead of directly and only an fd to the
file below that dir.

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] nspawn: No Return key in machinectl login?

2015-05-26 Thread Lennart Poettering
On Sat, 23.05.15 00:09, Tobias Hunger (tobias.hun...@gmail.com) wrote:

 Hello,
 
 I am having a problem with one of my containers set up with
 systemd-nspawn. For some reason the return key will not work most of
 the time (19 out of 20 attemps) after doing machinectl login into that
 machine.
 
 This effects not all programs: bash works, fish-shell does not. Sudo
 password entry does not work either. Git is broken (but hardly ever
 requires user input, so that is not that tragic;-), vi works fine.
 
 I only have this one one container image, even though it is built
 based on an image that is also used by container images that work
 fine. So I think the image should have all the important bits and
 pieces in place.
 
 I am kind of lost that close to the termcap:-) Does somebody have any
 ideas on how I can debug this?

What does stty -a say?

Consider comparing stty on the pty master (host side) as well as the
pty itself (container size) in the cases where this works, and where
it does not.

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] Reduce unit-loading time

2015-05-26 Thread Lennart Poettering
On Tue, 26.05.15 09:49, Filipe Brandenburger (filbran...@google.com) wrote:

 Hi,
 
 On Sun, May 24, 2015 at 8:41 PM, cee1 fykc...@gmail.com wrote:
  I tried ureadahead, but got following error:
 
  write(2, ureadahead: Error while tracing:..., 59ureadahead: Error
  while tracing: No such file or directory
 
  Needs an out-of-tree kernel patch?
 
 Yes, ureadahead needs an out-of-tree kernel patch to add trace events
 for open(), exec() and uselib() syscalls that take file paths.
 
 http://bugs.launchpad.net/bugs/462111
 
 AFAICT, this never went upstream because upstream was discussing a
 generic approach of tracing any system calls, but I believe that never
 really panned out...

systemd-readahead used fanotify() which requires no kernel
patching. fanotify is completely generic and perfect for this
purpose...

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] udev now crashes in daemon mode

2015-05-26 Thread Filipe Brandenburger
Hi Tom,

On Sun, May 24, 2015 at 6:30 AM, Tom Gundersen t...@jklm.no wrote:
 On Sun, May 24, 2015 at 11:40 AM, Mantas Mikulėnas graw...@gmail.com wrote:
 So, udev v220 crashes in my initramfs with the following message:

 starting version v220
 Assertion 'manager-pid == getpid()' failed at src/udev/udevd.c:568,
 function ev
 Aborting.

 It seems main calls manager_new() before forking, so the parent PID is
 stored instead of child PID.

 (I'm using Arch Linux with the traditional mkinitcpio-based initramfs, which
 starts udev using systemd-udevd --daemon --resolve-names=never.)

 Thanks for the report. This should be fixed now in git, please let me
 know if that is not the case.

I was testing the same setup (ArchLinux with mkinitcpio), seeing the
same crash in udevd from initramfs and I can confirm that
040e689654ef08 (udevd: event - fix event queue in daemenozied mode)
fixed it. Thanks!

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


Re: [systemd-devel] non-merged /usr changes [was: pre-release warnings?]

2015-05-26 Thread Martin Pitt
Lennart Poettering [2015-05-26 18:36 +0200]:
 /etc/locale.conf is not a fedoraism. It has not existed on Fedora
 before we introduced it. It's a systemd'ism if you so will: we looked
 at where the distros configured these things and came to the
 conclusion that all them were weird and nothing we wanted to
 support. We hence unified this in a new file. Except apparently that
 DEbian wasn't willing to migrate :-(

Or let's say it hasn't happened yet. This is also commonly sourced by
third-party/admin scripts, so doing that migration is the kind of
tons of work/zero visible benefit/nontrivial regression potential
thing that nobody likes to start doing.

 I really don't see how the xorg.conf.d drop-in should be
 fedora-specific. That's an upstream X11 thing, and we just picked a
 name for the file and that's it.
 
 Are you saying Debian patched out supported for /etc/X11/xorg.conf.d?

No, that of course works if it's present, but Debian wants to
configure the keyboard layout for the console and other consumers too,
and parsing Xorg config in kbd/console-setup would be rather weird. So
Debian uses Xorg's udev support by default, which is essentially

  KERNEL==event*, ENV{ID_INPUT_KEY}==?*, 
IMPORT{file}=/etc/default/keyboard

Personally I find that rather elegant as it works for the console,
Xorg, Wayland, Mir, etc, without assuming any particular configuration
format for any of those.

  More intrusive is the removal of chkconfig and addition of
  update-rc.d:

  http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/Make-systemctl-enable-disable-call-update-rc.d-for-s.patch?h=experimental

  http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/systemctl-don-t-skip-native-units-when-enabling-disa.patch?h=experimental
 
 I offered to merge a patch that adds update-rc.d support side-by-side
 with chkconfig support for this upstream, many times.

Ah, you did? I must have missed that.

 That said, I think even better would be to maybe make the support for
 this generic in systemctl: instead of explicitly invoking chkconfig or
 update-rcd, maybe we can just make systemctl invoke some fixed binary
 /usr/lib/systemd/systemd-sysv-compat or so with a fixed set of
 parameters. The distros could then make that a tool (maybe just a
 shell script) that invokes chkconfig or update-rc.d This would then
 allow us to remove any chkconfig-specific code from systemd, and would
 allow all distros to plug-in the tool of their choice without having
 to patch upstream. What do you think?

That sounds great. If chkconfig and update-r.cd are/were the only two
contenders then #ifdef sounds easier, but I don't know about other
distros like e. g. Gentoo.

  Then we have some stupid stuff like
  http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/buildsys-Don-t-default-to-gold-as-the-linker.patch?h=experimental-220
  which got rejected, but are nevertheless still necessary on distros
  (and not only for us, see responses to [2])
 
 Well, there's no need to carry a patch for that, all you need is add a
 configure cmdline param, no?

Maybe, I haven't checked. This is the kind of patch which rebases for
years without trouble :-)

 Also, this is really just working around issues with gold, and
 craziness in the suse build system. I am pretty sure bugs should be
 fixed wherever they are

Yes, agreed. TBH, I wasn't blaming you for not taking this (or the
other stuff above), just explaining what kind of nasty real-life
s*** patches distros have to deal with as you seemed surprised about
their number. It's still better to keep upstream clean of hacks.

  http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/Fix-paths-in-man-pages.patch?h=experimental-220
 
 Not enthusiastic about the idea. But the XML magic is mostly
 Zbigniew's territory (as this long got more complex than my XML-fu can
 still grasp ;-)).

Heh; I had a quick look and I'm not sure how/where to define new
entities. I'll have a closer look when I'm bored (so, maybe in 5 years
or so :-) ).

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


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


Re: [systemd-devel] non-merged /usr changes [was: pre-release warnings?]

2015-05-26 Thread Lennart Poettering
On Tue, 26.05.15 18:52, Martin Pitt (martin.p...@ubuntu.com) wrote:

  I really don't see how the xorg.conf.d drop-in should be
  fedora-specific. That's an upstream X11 thing, and we just picked a
  name for the file and that's it.
  
  Are you saying Debian patched out supported for /etc/X11/xorg.conf.d?
 
 No, that of course works if it's present, but Debian wants to
 configure the keyboard layout for the console and other consumers too,
 and parsing Xorg config in kbd/console-setup would be rather weird. So
 Debian uses Xorg's udev support by default, which is essentially
 
   KERNEL==event*, ENV{ID_INPUT_KEY}==?*,
   IMPORT{file}=/etc/default/keyboard

udev is should not be used for configuration. That's simply
wrong. 

  That said, I think even better would be to maybe make the support for
  this generic in systemctl: instead of explicitly invoking chkconfig or
  update-rcd, maybe we can just make systemctl invoke some fixed binary
  /usr/lib/systemd/systemd-sysv-compat or so with a fixed set of
  parameters. The distros could then make that a tool (maybe just a
  shell script) that invokes chkconfig or update-rc.d This would then
  allow us to remove any chkconfig-specific code from systemd, and would
  allow all distros to plug-in the tool of their choice without having
  to patch upstream. What do you think?
 
 That sounds great. If chkconfig and update-r.cd are/were the only two
 contenders then #ifdef sounds easier, but I don't know about other
 distros like e. g. Gentoo.

Well, chkconfig is the only implementation we support natively right
now. A new compat interface like I proposed would only have to replace
this hookup and all would be good.

   http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/Fix-paths-in-man-pages.patch?h=experimental-220
  
  Not enthusiastic about the idea. But the XML magic is mostly
  Zbigniew's territory (as this long got more complex than my XML-fu can
  still grasp ;-)).
 
 Heh; I had a quick look and I'm not sure how/where to define new
 entities. I'll have a closer look when I'm bored (so, maybe in 5 years
 or so :-) ).

Daniel is interested in picking this up.

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] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Lennart Poettering
On Tue, 26.05.15 19:13, Reindl Harald (h.rei...@thelounge.net) wrote:

 
 Am 26.05.2015 um 18:22 schrieb Lennart Poettering:
 On Tue, 26.05.15 17:57, Reindl Harald (h.rei...@thelounge.net) wrote:
 
 Am 26.05.2015 um 17:29 schrieb Lennart Poettering:
 On Tue, 26.05.15 16:39, Reindl Harald (h.rei...@thelounge.net) wrote:
 which shows that a important project like systemd playing on the same 
 level
 as the linux kernel *just needs* point releases, there is a reason that 
 the
 kernel has point-releases and not only for the latest and greatest 
 version,
 systemd as well as the kernel are not a random webbrowser
 
 There's a stable git tree maintained by Zbigniew, Lukas and friends,
 that carries backports for the stable releases. Most vendors should
 consider following that repo I figure.
 
 I try to help the backporting business by tagging the commits I
 personally consider backport-worthy with git notes and the
 Backport: field
 
 it just works poor
 
 * https://bugzilla.redhat.com/show_bug.cgi?id=1185278
never got fixed in F20 but is fixed in Fedora 21
 
 Well, it's not really a bug. We require util-linux to be around. If
 you make it unavailable then you get to to keep the pieces. It's that
 simple
 
 sftp-chroot worked fine until Fedora 20 and started to work again with
 Fedora 21 so please don't pretend anything else than systemd is (or was)
 responsible to fail proper shutdown and termination of the recently by
 systemd invented user-session processes

Well, we still require /usr/bin/kill from util-linux to be around. We
did not fix your bug... Maybe this doesn't trip up anymore, but we
didn't specifically fix anything...

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] pre-release warnings? [was: 220 tarball erroneously ships keyboard-keys-from-name.gperf]

2015-05-26 Thread Lennart Poettering
BOn Tue, 26.05.15 16:58, Martin Pitt (martin.p...@ubuntu.com) wrote:

  50 non-backport patches? That sounds like a lot...
 
 It's not that bad, most of them are trivial, like tweaking tmpfiles.d
 or some extra historic udev rules. We have quite a bunch of patches to
 get rid of Fedora/RedHat-isms and replace them with Debianisms, and
 then there's a lot for having a non-merged /usr (which Debian didn't
 do yet). Aside from two or three which keep breaking most of them just
 tag along, but there's always enough noise to break completely
 automatically building packages from git master. Anyway, this is
 completely tangential.. :-)

But note that upstream is supposed to be non-redhat centric, and is
supposed to support non-merged /usr. If it's really about that, I#d be
inetersted to know what these patches are about, and maybe we can move
some upstream.

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] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Reindl Harald


Am 26.05.2015 um 17:29 schrieb Lennart Poettering:

On Tue, 26.05.15 16:39, Reindl Harald (h.rei...@thelounge.net) wrote:

which shows that a important project like systemd playing on the same level
as the linux kernel *just needs* point releases, there is a reason that the
kernel has point-releases and not only for the latest and greatest version,
systemd as well as the kernel are not a random webbrowser


There's a stable git tree maintained by Zbigniew, Lukas and friends,
that carries backports for the stable releases. Most vendors should
consider following that repo I figure.

I try to help the backporting business by tagging the commits I
personally consider backport-worthy with git notes and the
Backport: field


it just works poor

* https://bugzilla.redhat.com/show_bug.cgi?id=1185278
  never got fixed in F20 but is fixed in Fedora 21
* https://bugzilla.redhat.com/show_bug.cgi?id=1185277 open for months

and in general a bunch of git commits don't replace a upstream changelog 
of a minor release where as user you never have any idea what your 
current installed package really is


with a 220.1 and a usptream download of 220.1 containing a changelog 
things are entirely different (besides that the version numbers for a 
project existing just a few years are strange to say it nicely)




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Reindl Harald


Am 26.05.2015 um 18:22 schrieb Lennart Poettering:

On Tue, 26.05.15 17:57, Reindl Harald (h.rei...@thelounge.net) wrote:


Am 26.05.2015 um 17:29 schrieb Lennart Poettering:

On Tue, 26.05.15 16:39, Reindl Harald (h.rei...@thelounge.net) wrote:

which shows that a important project like systemd playing on the same level
as the linux kernel *just needs* point releases, there is a reason that the
kernel has point-releases and not only for the latest and greatest version,
systemd as well as the kernel are not a random webbrowser


There's a stable git tree maintained by Zbigniew, Lukas and friends,
that carries backports for the stable releases. Most vendors should
consider following that repo I figure.

I try to help the backporting business by tagging the commits I
personally consider backport-worthy with git notes and the
Backport: field


it just works poor

* https://bugzilla.redhat.com/show_bug.cgi?id=1185278
   never got fixed in F20 but is fixed in Fedora 21


Well, it's not really a bug. We require util-linux to be around. If
you make it unavailable then you get to to keep the pieces. It's that
simple


sftp-chroot worked fine until Fedora 20 and started to work again with 
Fedora 21 so please don't pretend anything else than systemd is (or was) 
responsible to fail proper shutdown and termination of the recently by 
systemd invented user-session processes




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] treewide: fix typos

2015-05-26 Thread Torstein Husebø
---
 NEWS| 4 ++--
 man/journal-remote.conf.xml | 2 +-
 src/libsystemd/sd-bus/bus-control.c | 2 +-
 src/libsystemd/sd-bus/bus-creds.c   | 6 +++---
 src/shared/architecture.c   | 2 +-
 src/shared/architecture.h   | 2 +-
 src/shared/capability.h | 2 +-
 src/shared/fdset.c  | 2 +-
 src/shared/util.c   | 2 +-
 9 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/NEWS b/NEWS
index f72f502129..ee533b4363 100644
--- a/NEWS
+++ b/NEWS
@@ -3997,7 +3997,7 @@ CHANGES WITH 191:
 * HandleSleepKey= in logind.conf has been split up into
   HandleSuspendKey= and HandleHibernateKey=. The old setting
   is not available anymore. X11 and the kernel are
-  distuingishing between these keys and we should too. This
+  distinguishing between these keys and we should too. This
   also means the inhibition lock for these keys has been split
   into two.
 
@@ -4743,7 +4743,7 @@ CHANGES WITH 43:
 
 * Various functionality updates to libsystemd-login.so
 
-* Track class of PAM logins to distuingish greeters from
+* Track class of PAM logins to distinguish greeters from
   normal user logins.
 
 Contributions from: Kay Sievers, Lennart Poettering, Michael
diff --git a/man/journal-remote.conf.xml b/man/journal-remote.conf.xml
index a7b2227182..fc60258d0b 100644
--- a/man/journal-remote.conf.xml
+++ b/man/journal-remote.conf.xml
@@ -83,7 +83,7 @@
   varlistentry
 termvarnameServerKeyFile=/varname/term
 
-listitemparaSSL key in PEM format/para/listitem
+listitemparaSSL key in PEM format./para/listitem
   /varlistentry
 
   varlistentry
diff --git a/src/libsystemd/sd-bus/bus-control.c 
b/src/libsystemd/sd-bus/bus-control.c
index fa4c28174d..43ddfc651d 100644
--- a/src/libsystemd/sd-bus/bus-control.c
+++ b/src/libsystemd/sd-bus/bus-control.c
@@ -429,7 +429,7 @@ static int bus_populate_creds_from_items(
 c-mask |= SD_BUS_CREDS_PPID;
 } else if (item-pids.pid == 1) {
 /* The structure doesn't
- * really distuingish the case
+ * really distinguish the case
  * where a process has no
  * parent and where we don't
  * know it because it could
diff --git a/src/libsystemd/sd-bus/bus-creds.c 
b/src/libsystemd/sd-bus/bus-creds.c
index fed66823c7..4d67619cf8 100644
--- a/src/libsystemd/sd-bus/bus-creds.c
+++ b/src/libsystemd/sd-bus/bus-creds.c
@@ -303,7 +303,7 @@ _public_ int sd_bus_creds_get_ppid(sd_bus_creds *c, pid_t 
*ppid) {
 if (!(c-mask  SD_BUS_CREDS_PPID))
 return -ENODATA;
 
-/* PID 1 has no parent process. Let's distuingish the case of
+/* PID 1 has no parent process. Let's distinguish the case of
  * not knowing and not having a parent process by the returned
  * error code. */
 if (c-ppid == 0)
@@ -989,7 +989,7 @@ int bus_creds_add_more(sd_bus_creds *c, uint64_t mask, 
pid_t pid, pid_t tid) {
 if (missing  SD_BUS_CREDS_EXE) {
 r = get_process_exe(pid, c-exe);
 if (r == -ESRCH) {
-/* Unfortunately we cannot really distuingish
+/* Unfortunately we cannot really distinguish
  * the case here where the process does not
  * exist, and /proc/$PID/exe being unreadable
  * because $PID is a kernel thread. Hence,
@@ -1101,7 +1101,7 @@ int bus_creds_add_more(sd_bus_creds *c, uint64_t mask, 
pid_t pid, pid_t tid) {
 }
 
 /* In case only the exe path was to be read we cannot
- * distuingish the case where the exe path was unreadable
+ * distinguish the case where the exe path was unreadable
  * because the process was a kernel thread, or when the
  * process didn't exist at all. Hence, let's do a final check,
  * to be sure. */
diff --git a/src/shared/architecture.c b/src/shared/architecture.c
index 884abdd3ea..8e72e7a36a 100644
--- a/src/shared/architecture.c
+++ b/src/shared/architecture.c
@@ -35,7 +35,7 @@ int uname_architecture(void) {
  * 1:1. Instead we try to clean it up and break down the
  * confusion on x86 and arm in particular.
  *
- * We do not try to distuingish CPUs not CPU features, but
+ * We do not try to distinguish CPUs not CPU features, but
  * actual architectures, i.e. that have genuinely different
  * code. */
 
diff --git a/src/shared/architecture.h b/src/shared/architecture.h
index cb82418a5e..f5bbf65a90 100644
--- a/src/shared/architecture.h
+++ 

Re: [systemd-devel] non-merged /usr changes [was: pre-release warnings?]

2015-05-26 Thread Michael Biebl
2015-05-26 19:08 GMT+02:00 Lennart Poettering lenn...@poettering.net:
 On Tue, 26.05.15 18:52, Martin Pitt (martin.p...@ubuntu.com) wrote:

   http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/Fix-paths-in-man-pages.patch?h=experimental-220
 
  Not enthusiastic about the idea. But the XML magic is mostly
  Zbigniew's territory (as this long got more complex than my XML-fu can
  still grasp ;-)).

 Heh; I had a quick look and I'm not sure how/where to define new
 entities. I'll have a closer look when I'm bored (so, maybe in 5 years
 or so :-) ).

 Daniel is interested in picking this up.

Zbyszek was sympathetic to this idea, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717491#10

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel