Re: [systemd-devel] [PATCH v3 2/4] udev: Update pointingstick rules to allow setting ibm trackpoint sensitivity

[David Herrmann]

Hi

On Tue, Apr 7, 2015 at 12:09 PM, Hans de Goede hdego...@redhat.com wrote:
 IBM / Lenovo trackpoints allow specifying a sensitivity setting through a
 ps/2 command, which changes the range of the deltas sent when using the
 trackpoint. On some models with normal usage only deltas of 1 or 2 are send,
 resulting in there only being 2 mouse cursor movement speeds, rather than
 the expected fluid scale.

 Changing the sensitivity to a higher level than the bootup default fixes this,
 the rule additions in this commit allows specifying a new sensitivity default
 through hwdb giving a better ootb experience.
 ---
  hwdb/70-pointingstick.hwdb   | 12 
  rules/70-pointingstick.rules |  9 +++--
  2 files changed, 19 insertions(+), 2 deletions(-)

 diff --git a/hwdb/70-pointingstick.hwdb b/hwdb/70-pointingstick.hwdb
 index a893da6..89f4b8a 100644
 --- a/hwdb/70-pointingstick.hwdb
 +++ b/hwdb/70-pointingstick.hwdb
 @@ -42,6 +42,7 @@
  #
  # Allowed properties are:
  #   POINTINGSTICK_CONST_ACCEL
 +#   POINTINGSTICK_SENSITIVITY
  #
  #
  #  POINTINGSTICK_CONST_ACCEL#
 @@ -54,6 +55,17 @@
  # by how much to multiply deltas generated by the pointingstick to get
  # normalized deltas.
  #
 +#
 +#  POINTINGSTICK_SENSITIVITY#
 +#
 +#
 +# TPPS/2 IBM TrackPoint driver sensitivity sysfs setting
 +#POINTINGSTICK_SENSITIVITY=sensitivity
 +#
 +# Where sensitivity is a number between 0 and 255, note this property
 +# only applies to TPPS/2 IBM TrackPoint devices, see
 +# drivers/input/mouse/trackpoint.c in the Linux kernel sources.
 +#

  #
  # Sort by by brand, model
 diff --git a/rules/70-pointingstick.rules b/rules/70-pointingstick.rules
 index 5a853f3..15e34a0 100644
 --- a/rules/70-pointingstick.rules
 +++ b/rules/70-pointingstick.rules
 @@ -6,11 +6,16 @@ ENV{ID_INPUT_POINTINGSTICK}==, GOTO=pointingstick_end

  # skip later rules when we find something for this input device
  IMPORT{builtin}=hwdb --subsystem=input --lookup-prefix=pointingstick:, \
 -  GOTO=pointingstick_end
 +  GOTO=pointingstick_apply_settings

  # device matching the input device name and the machine's DMI data
  KERNELS==input*, \
IMPORT{builtin}=hwdb 
 'pointingstick:name:$attr{device/name}:$attr{[dmi/id]modalias}', \
 -  GOTO=pointingstick_end
 +  GOTO=pointingstick_apply_settings
 +
 +LABEL=pointingstick_apply_settings
 +
 +TEST==../../../sensitivity, ENV{POINTINGSTICK_SENSITIVITY}!=, \
 +  ATTR{../../../sensitivity}=$env{POINTINGSTICK_SENSITIVITY}

You can read attributes of parents, but writing to them is not that
easy. _Writing_ to ATTR always affects the event-device, not the
matched parent.

The series looks reasonable, but I wonder why we cannot merge it into
60-keyboard.rule (60-evdev.rule now) like Peter's series does? In that
case, please make this a builtin of input_id which uses
udev_device_get_parent_subsystem_devtype() and look for the
serio/atkbd (?) parent device, instead of hard-coding the path.

Thanks
David

  LABEL=pointingstick_end
 --
 2.3.4

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

Re: [systemd-devel] systemd-resolved service ignores UseDNS=false

[David Herrmann]

Hi

On Wed, Mar 25, 2015 at 4:20 AM, Mikhail Morfikov mmorfi...@gmail.com wrote:
 In the systemd-resolved manual we can read something like this:

   The DNS servers contacted are determined from the global settings in
   resolved.conf(5), the per-link static settings in .network files, and
   the per-link dynamic settings received over DHCP.

 1. Let's say that I have set all the three settings, which one will be
 applied?

 2. If I set the global settings via the /etc/systemd/resolved.conf file,
 for instance:

 [Resolve]
 DNS=127.0.2.1
 FallbackDNS=208.67.222.222 208.67.220.220

 will this local resolver be used all the time, even when dhcp
 server sends an ip address of other resolver in the network to
 the client?

 I don't know how that is supposed to work, but it looks like it doesn't
 work in the way I thought it would. So I added some entries to this
 /etc/systemd/network/50-bond0-dhcp.network file:

 [Match]
 Name=bond0

 [Network]
 Description=Bonded network
 DHCP=ipv4
 LinkLocalAddressing=no
 DNS=127.0.2.1
 IPForward=true

 [DHCP]
 UseDNS=false
 UseMTU=false
 SendHostname=true
 UseHostname=false
 UseDomains=true
 UseRoutes=true
 CriticalConnection=true
 RequestBroadcast=true

 And according to the systemd-networkd manual:

   DNS -- a DNS server address, which must be in the format described
   in inet_pton(3). This option may be specified more than once.

   UseDNS -- when true (the default), the DNS servers received from the
   DHCP server will be used and take precedence over any statically
   configured ones.

 (btw, the link to inet_pton is dead)

 So UseDNS is set to false, and I thought the system will be using
 the local resolver, but it sometimes uses the local settings and
 sometimes not -- it depends on restarting the systemd-resolved
 service, for example:

 # ls -al /etc/resolv.conf
 lrwxrwxrwx 1 root root 32 2015-02-27 23:52:39 /etc/resolv.conf - 
 /run/systemd/resolve/resolv.conf

 # cat /etc/resolv.conf
 nameserver 127.0.2.1
 nameserver 192.168.1.1
 search mhouse.lh

 # systemctl restart systemd-resolved.service
 # cat /etc/resolv.conf
 nameserver 192.168.1.1
 nameserver 127.0.2.1
 search mhouse.lh

 (I've cut the comments for readability)

 As you can see, the two resolvers just switched, and it seems that my
 system tries to use the 192.168.1.1 , but I disabled it for testing on
 my router. After I ping a domain, I have 10s lag, and then ping go there
 and back, so it falls back to the local resolver.

 3. Shouldn't there be just one resolver in the /etc/resolv.conf file?

I'm not 100% sure, but reading networkd-code I'd say there's something
going wrong. It should never store the DHCP DNS servers if UseDNS is
false. Therefore, resolved should never see them.

Cat you look into /run/systemd/netif/links/* and paste the content?

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

Re: [systemd-devel] [PATCH v3 2/4] udev: Update pointingstick rules to allow setting ibm trackpoint sensitivity

[David Herrmann]

Hi

On Tue, Apr 7, 2015 at 1:52 PM, Hans de Goede hdego...@redhat.com wrote:
 Hi,


 On 07-04-15 13:46, David Herrmann wrote:

 Hi

 On Tue, Apr 7, 2015 at 1:40 PM, Hans de Goede hdego...@redhat.com wrote:

 The series looks reasonable, but I wonder why we cannot merge it into
 60-keyboard.rule (60-evdev.rule now) like Peter's series does? In that
 case, please make this a builtin of input_id which uses
 udev_device_get_parent_subsystem_devtype() and look for the
 serio/atkbd (?) parent device, instead of hard-coding the path.



 Why would we want to merge this into keyboard rules/hwdb? Trackpoints
 always have a separate driver, input device and event node.


 Right now, we do hwdb lookups for keyboard:foobar, evdev:foobar and
 now trackpoint:foobar, instead of a single lookup for evdev:foobar.

 To me, it looks much easier if we have one generic evdev rule, which
 searches the hwdb based on the input-modalias via
 evdev:input:modalias and the legacy fallback,
 evdev:name:name:dmi

 Depending on what properties where found, we simply apply them to the
 evdev node.


 Ah, I see so what you're suggesting is in essence dropping the

 ENV{ID_INPUT_KEY}==, GOTO=keyboard_end

 Rule from rules/60-keyboard.rules

 And s/keyboard/evdev/ as one of Peter's updated patches is already doing,
 while keeping the hwdb bits the same, except that the prefix for the
 matches would be evdev instead of pointingstick ?

 And teaching the keyboard^Wevdev builtin to handle
 POINTINGSTICK_SENSITIVITY and write the sysfs attribute ?

Exactly. Peter already did most of this in his series, so we might
wanna wait for him to push it.
I'm actually only waiting for Kay to ACK the prefix 'evdev', then I'd
push it myself and we can rebase your series.

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

Re: [systemd-devel] [PATCH v3 2/4] udev: Update pointingstick rules to allow setting ibm trackpoint sensitivity

[David Herrmann]

Hi

On Tue, Apr 7, 2015 at 1:40 PM, Hans de Goede hdego...@redhat.com wrote:
 The series looks reasonable, but I wonder why we cannot merge it into
 60-keyboard.rule (60-evdev.rule now) like Peter's series does? In that
 case, please make this a builtin of input_id which uses
 udev_device_get_parent_subsystem_devtype() and look for the
 serio/atkbd (?) parent device, instead of hard-coding the path.


 Why would we want to merge this into keyboard rules/hwdb? Trackpoints
 always have a separate driver, input device and event node.

Right now, we do hwdb lookups for keyboard:foobar, evdev:foobar and
now trackpoint:foobar, instead of a single lookup for evdev:foobar.

To me, it looks much easier if we have one generic evdev rule, which
searches the hwdb based on the input-modalias via
evdev:input:modalias and the legacy fallback,
evdev:name:name:dmi

Depending on what properties where found, we simply apply them to the
evdev node.

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

Re: [systemd-devel] [PATCH] udev: input_id: tag accelerometers as ID_INPUT_ACCELEROMETER

[David Herrmann]

Hi

On Fri, Apr 3, 2015 at 8:55 PM, Hans de Goede hdego...@redhat.com wrote:
[...]
 I don't think we should return when we see INPUT_PROP_ACCEL. If a
 keyboard embeds an accelerometer, we will miss it. I think I went too
 deep in detail for Wacoms/tablets devices and it confused you. Those
 don't need much processing in udev, we can mostly control everything
 out the tree.


 Ok, I'll respin my patch to not have the return then.

What's the plan? Use INPUT_PROP_ACCEL as negative check (necessary
negative condition) for touchpads and mice? And as fallback hint for
accelerometer if nothing else matched?

I guess I'll see in v2 then.

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

Re: [systemd-devel] [PATCH 1/6] udev: builtin-keyboard: move fetching the device node up

[David Herrmann]

Hi

On Wed, Apr 8, 2015 at 7:41 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Mon, 23.03.15 11:30, Peter Hutterer (peter.hutte...@who-t.net) wrote:

 No point parsing the properties if we can't get the devnode to apply them
 later. Plus, this makes future additions easier to slot in.

 Hmm, Peter, this series was never pushed?

 (Just making sure this is not forgotten...)

There's still discussion on patches 5 and 6 (and cross-discussion with
Hans' series). Kay and me discussed the hwdb modalias namespace mess
and need to push the changes before we can apply these. We're on it.

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

Re: [systemd-devel] [PATCH] udev: input_id: tag accelerometers as ID_INPUT_ACCELEROMETER

[David Herrmann]

Hi

On Fri, Apr 3, 2015 at 12:07 PM, Hans de Goede hdego...@redhat.com wrote:
 input_id already (tries to) tag accelerometers as such, but this only works
 for absolute accelerometers. Recent kernels mark accelerometers through an
 input prop. Trust that prop and always tag devices with it with
 ID_INPUT_ACCELEROMETER.

 Note that detection by the prop bit works the same as the existing detection
 and will ensure that no other tags get set on the device.

 Signed-off-by: Hans de Goede hdego...@redhat.com
 ---
  src/shared/missing.h | 4 
  src/udev/udev-builtin-input_id.c | 5 +
  2 files changed, 9 insertions(+)

 diff --git a/src/shared/missing.h b/src/shared/missing.h
 index 3bdfd8f..4464e35 100644
 --- a/src/shared/missing.h
 +++ b/src/shared/missing.h
 @@ -944,3 +944,7 @@ static inline int kcmp(pid_t pid1, pid_t pid2, int type, 
 unsigned long idx1, uns
  #ifndef INPUT_PROP_POINTING_STICK
  #define INPUT_PROP_POINTING_STICK 0x05
  #endif
 +
 +#ifndef INPUT_PROP_ACCELEROMETER
 +#define INPUT_PROP_ACCELEROMETER  0x06
 +#endif
 diff --git a/src/udev/udev-builtin-input_id.c 
 b/src/udev/udev-builtin-input_id.c
 index d4c38ca..ecfc447 100644
 --- a/src/udev/udev-builtin-input_id.c
 +++ b/src/udev/udev-builtin-input_id.c
 @@ -136,6 +136,11 @@ static void test_pointers (struct udev_device *dev,
  int is_mouse = 0;
  int is_touchpad = 0;

 +if (test_bit (INPUT_PROP_ACCELEROMETER, bitmask_props)) {
 +udev_builtin_add_property(dev, test, 
 ID_INPUT_ACCELEROMETER, 1);
 +return;
 +}
 +

So this property is only set for accelerometer-only devices? I didn't
follow the kernel discussion, sorry.. I just wonder what happens if we
report accelerometer + keys on the same device. But I guess that's
broken, anyway, as we don't have ABS_ACCEL_*. Just thinking out loud..

But generally looks good to me!

Thanks
David

  if (!test_bit (EV_KEY, bitmask_ev)) {
  if (test_bit (EV_ABS, bitmask_ev) 
  test_bit (ABS_X, bitmask_abs) 
 --
 2.3.4

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

Re: [systemd-devel] [ANNOUNCE] Separating gudev from systemd

[David Herrmann]

Hi

On Wed, May 20, 2015 at 8:46 AM, Tom Gundersen t...@jklm.no wrote:
 On Wed, May 20, 2015 at 8:24 AM, Martin Pitt martin.p...@ubuntu.com wrote:
 Hey David,

 David Herrmann [2015-05-19 17:06 +0200]:
 We're about to remove gudev from the systemd repository, as it is in
 no way related to the systemd code-base, nor used by the systemd
 project.

 This makes sense indeed. gudev used to be a standalone project before
 it was merged into udev, so the circle is complete now :-)

 For those of us who already packaged gudev from systemd 219, would it
 be possible to bump the current release to 220, so that gudev can be
 packaged without renaming the tarball and doing ugly version numbers?
 Monotonously increasing version numbers and all.. (Yes, there are
 epochs in Debian, and I'm sure RPM has these too, but they might not
 be available everywhere and are generally frowned upon)

 While you are at it, why not bump it to 225 or something (just to
 guarantee that the last systemd release with gudev has a lower version
 number than gudev at that time, so people can switch over whenever
 they want without having to worry about going backwards).

I intend to apply patches to systemd-git until we finally removed it
there. Given that we had 0 patches so far this year, it'll probably
stay that way. Hence, there's no hurry in replacing gudev from systemd
with libgudev. It'd be enough to just drop the systemd sub-package and
provide a new libgudev package, even if that might not forcefully
update the package.

However, I see no reason not to bump it, so I'll gladly follow the
packager's demands:

https://github.com/systemd-devs/libgudev/commit/f6203336e5b1ccf896acc506b54ec895fdae98b4

@Bastien: At your convenience, can you cherry-pick this and do another
release? Should have done this right away, sorry!

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

[systemd-devel] [ANNOUNCE] Separating gudev from systemd

[David Herrmann]

Hi

We're about to remove gudev from the systemd repository, as it is in
no way related to the systemd code-base, nor used by the systemd
project. To preserve backwards compatibility, gudev was extracted into
a separate repository and is now managed on gnome.org:

Homepage: https://wiki.gnome.org/Projects/libgudev
Bugtracker: http://bugzilla.gnome.org/browse.cgi?product=libgudev
Releases: http://download.gnome.org/sources/libgudev/
Repository: http://git.gnome.org/browse/libgudev/

ArchLinux: https://aur.archlinux.org/packages/li/libgudev/PKGBUILD
Others: TBD

The new libgudev project is binary-compatible to gudev as provided by
systemd-219. Distributions are encouraged to pass --disable-gudev to
systemd and provide gudev via the libgudev project. We haven't decided
at which point gudev will be dropped from the systemd repository, but
chances are systemd-221 will not include it, anymore.

If there are any issues, please let me know.

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

Re: [systemd-devel] [PATCH] util: fix typo

[David Herrmann]

Hi

On Tue, May 19, 2015 at 2:26 PM,  jsyna...@redhat.com wrote:
 From: Jan Synacek jsyna...@redhat.com

 ---
  src/shared/util.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Applied!

Thanks
David

 diff --git a/src/shared/util.c b/src/shared/util.c
 index da6343f..fd837d9 100644
 --- a/src/shared/util.c
 +++ b/src/shared/util.c
 @@ -1697,7 +1697,7 @@ int loop_write(int fd, const void *buf, size_t nbytes, 
 bool do_poll) {

  int parse_size(const char *t, off_t base, off_t *size) {

 -/* Soo, sometimes we want to parse IEC binary suffxies, and
 +/* Soo, sometimes we want to parse IEC binary suffixes, and
   * sometimes SI decimal suffixes. This function can parse
   * both. Which one is the right way depends on the
   * context. Wikipedia suggests that SI is customary for
 --
 2.1.0

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

Re: [systemd-devel] Alienware graphics amplifier scancodes

[David Herrmann]

Hi

On Thu, Jun 4, 2015 at 9:31 PM, Mario Limonciello
mario_limoncie...@dell.com wrote:
 On 06/04/2015 01:31 AM, David Herrmann wrote:

 Last but not least: Did you try fixing the alienware x86-platform
 driver to provide the correct mappings instead of adding a user-space
 fixup?

 I'm unsure what is a correct mapping.  These scancodes are what we have
 specc'ed out the hardware to interpret.  The Windows userspace app we use
 does pick up these scancodes to do the right user notification event and I'm
 looking to bring parity for that on the Linux side.

As it turns out, the i8042 subsystem does not allow to easily hook
into the key-mapping. Can you provide your hwdb entry via
github.com/systemd/systemd please?

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

Re: [systemd-devel] [ANNOUNCE] Git development moved to github

[David Herrmann]

Hi

On Wed, Jun 3, 2015 at 7:48 PM, Lucas De Marchi
lucas.de.mar...@gmail.com wrote:
 Of course this is a non-issue for several projects in github which
 don't have proper commit
 review. It's not the case of systemd and it seems it's even the reason
 why you are moving
 to github.  So I'm just curious if anything changed in this regard or
 you solved it in another
 way.

github attaches code-reviews to the actual git commits. The PR
displays all comments on the commits in the given branch. As long as
those commits stay part of the PR, the comments will remain. However,
if people force-push corrected commits, the old commits are no longer
linked in any way to the PR and thus will not be shown. You can still
access them by directly looking at the old commit, though.

With their model, I understand why old reviews are lost on force-push.
You can work around this, by including the sha256 in your PR comments
after a review. Those comments remain and you can look at the old
reviews this way. They'll not be linked in a shiny way (but that's the
same if you resend your mails on an ML..).

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

Re: [systemd-devel] siphash24 gives unmatched bloom_mask and bloom_filter?

[David Herrmann]

Hi

On Thu, Jun 4, 2015 at 2:07 PM,  eshar...@163.com wrote:
 Hi, All,
  I use libsystemd.so for the kdbus protocol layer, and  I met a
 question that I added a signal matching rule by sd_bus_add_match() , then I
 sent signal by sd_bus_send().
 But I couldn't receive this signal  because its bloom_filter  caculated by
 siphash24()  NOT match the bloom_mask which was also caculated by
 siphash24().

  For example ,  when adding matching rule for 
 type='signal',interface='service.a.interface',path='/service/a',member='com_0yunos_0spms_0uninstall',arg0path='/p1/p2/p3'
  by sd_bus_add_match(),

Can you provide a real C-code example so we can reproduce this?

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

Re: [systemd-devel] How to get all PIDs in a service

[David Herrmann]

Hi

On Thu, Jun 4, 2015 at 6:31 PM, Andrei Borzenkov arvidj...@gmail.com wrote:
 В Thu, 04 Jun 2015 10:08:52 +0200
 Sébastien Luttringer se...@seblu.net пишет:
 What's the right way to get all pid belonging to a service? How can I
 unescape strings from systemctl?


 Well, you can use systemd-escape -u, but real question is why it gets
 escaped twice and is it intentional.

We escape all strings we write to a TTY to make sure we don't
accidentally write control-chars. However, we also don't know whether
the data we print was already escaped or not (as we just call a
generic handler on the dbus property).

In short: double-escape is on purpose.

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

Re: [systemd-devel] siphash24 gives unmatched bloom_mask and bloom_filter?

[David Herrmann]

Hi

On Mon, Jun 8, 2015 at 3:26 PM,  eshar...@163.com wrote:
 Hi, David
I just modified the  src/libsystemd/sd-bus/test-bus-match.c.
 And you could add the following two lines in the bloom_add_data() in
 bus-bloom.c
  for (i = 0; i  size/sizeof(uint64_t); i++)
 log_info(bloom: filter[%d] = 0x%llx,i, filter[i]);

Can you please try with systemd-220? The diff against 220 is 83 lines
and it doesn't even compile. If there is a bloom-bug, it should be
possible to show this with a much shorter example. I'm having a hard
time understanding what you changed there, sorry.

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

Re: [systemd-devel] Alienware graphics amplifier scancodes

[David Herrmann]

Hi

On Thu, Jun 4, 2015 at 12:50 AM, Mario Limonciello
mario_limoncie...@dell.com wrote:


 On 05/29/2015 04:22 AM, Lennart Poettering wrote:

 On Thu, 28.05.15 13:53, Mario Limonciello (mario_limoncie...@dell.com)
 wrote:


 On 05/28/2015 01:46 PM, Greg KH wrote:

 You

 can't guarantee that there is another GPU to display things on.

 Yes you can.

 Wait, what?  No, you can't.

 1) Not everyone has multiple monitors plugged into multiple GPU's.

 2) The system ships with a dGPU and supports an xGPU.  If you remove the
 dGPU from the chassis, all you have is the xGPU.  If you unplug xGPU,
 there's nothing left..

 gdm has multi seat support btw: it will spawn X servers on all seats
 capable of graphics. if you unplug all graphics cards than this simply
 means that your number of graphics-capable seats went from  0 to
 0. That's all. And if you plug in a graphics card then, then it goes
 from 0 to 1 again and you get a fresh new login prompt on it.

 Lennart

 Lennart,

 The kernel bits and discussion around hot unplug aside, can you please add
 support to systemd to map the scan codes?  For the other scenarios such as
 the cable being connected and the disconnect button being pressed userspace
 will need to provide a notification to the user what to do next.  I've added
 the details (and a proposed patch) to bug 90689.  If these are also
 controversial, I'd like to know what else you have in mind.

systemd is not really in the business of remapping scancodes. Sure,
the hwdb provides remappings, but this is only to fixup devices that
the kernel cannot fix (usually devices which are handled by generic
drivers).

In your case, you use the serio-input driver, which is also a generic
driver so I wouldn't oppose adding your proposed mappings. However, I
cannot see why your mapping provides any value. You remap F21 / F23 /
F24 to PROG1 / PROG2 / POWER. The only added value is F24 to POWER
mapping, which might even break systems as KEY_POWER is marked as SC
System Power Down. Hence, it might get assigned the same behavior as
the system power key.

Regarding the PROG1 and PROG2 mappings I cannot see how they are any
better than F21 and F23? Can you elaborate?

Last but not least: Did you try fixing the alienware x86-platform
driver to provide the correct mappings instead of adding a user-space
fixup?

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

Re: [systemd-devel] Bind key combination to isolate emergency mode

[David Herrmann]

Hi

On Sat, Jun 20, 2015 at 4:26 PM, Thomas Meyer tho...@m3y3r.de wrote:
 Hi,

 Is it possible to bind a key combination in systemd to perform a switch into 
 emergency mode or another target?

 And would this key binding also work in situations where the system is under 
 heavy cpu load and heavy swapping?

That's not implemented, no. You'd have to write a daemon which does
this yourself.

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

Re: [systemd-devel] sd-bus object manager question

[David Herrmann]

Hi

On Tue, Jun 23, 2015 at 2:41 PM, David Härdeman da...@hardeman.nu wrote:
 Hi,

 as an experiment I've tried porting a toy dbus daemon over to sd-bus. It
 seems to be working well so far and I have to say I really like the sd-bus
 API over the gdbus one (sd-bus feels like I'm still writing C...can't say
 the same thing about gdbus).

 Now, a question...how is an object manager supposed to be implemented in
 sd-bus?

 I've seen that there's a sd_bus_add_object_manager() function in sd-bus.h,
 but how would I notify the object manager when objects are added and
 removed?

 Two likely candidates seemed to be:
 sd_bus_emit_object_added()
 sd_bus_emit_object_removed()

 But calling them did not seem to do the right thing. And there seems to be
 zero usage of sd_bus_add_object_manager() in the systemd tree itself (though
 plenty of calls to sd_bus_add_node_enumerator() which might be related?).

Not sure where the confusion is. Those calls generate the
InterfacesAdded/Removed signals that the objectmanager API specifies.
They collect the interfaces based on the vtables you registered on a
given path. have a look at test-bus-objects.c which uses these
interfaces.

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

Re: [systemd-devel] Can kdbus send signal to the source connection?

[David Herrmann]

Hi

On Mon, Jun 15, 2015 at 4:43 PM, Simon McVittie
simon.mcvit...@collabora.co.uk wrote:
 On 15/06/15 15:32, Lennart Poettering wrote:
 Did I get this right, you have one bus connection per thread, but
 possibly both a kdbus client and its service run from the server, and
 you want broadcast msgs sent out from one to then also be matchable by
 the other?

 If this is indeed what eshark means, then talking to yourself like
 this is something that always used to work with traditional D-Bus (as
 long as you make sure to never block waiting for a reply!), so it's a
 regression if it doesn't work with kdbus.

 In traditional D-Bus, broadcasts go to any connection that has
 registered its interest in the broadcast via AddMatch. dbus-daemon does
 not discriminate between the sender of a message, and other connections
 - in particular, it will send a copy of a broadcast back to its sender,
 if that's what the sender asked for.

 Various projects' regression tests work like this: they run the
 client-side and service-side code in the same GLib main loop and do
 everything asynchronously, and it works. Ideally, the only processes
 involved are the test and the dbus-daemon (and under kdbus the
 dbus-daemon would not be needed either).

Didn't know traditional DBus allows this. The kdbus fix should be as
simple as removing the condition in kdbus_bus_broadcast(). Dead-lock
detection for src==dst is already in place, as we allow unicasts to
oneself.

I'll look into this.

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

Re: [systemd-devel] machinectl status vs show

[David Herrmann]

Hi

On Wed, Jun 17, 2015 at 5:53 AM, Johannes Ernst
johannes.er...@gmail.com wrote:
 Are those supposed to produce the same information, just formatted 
 differently (man vs machine per man page)?

 I’m failing to convince ‘show’ to give me the container’s IP address, while 
 ‘status’ has all of them.

As with almost all *ctl tools in systemd, 'show' is used to print DBus
properties of the object in question. 'status' on the other hand
prints a human-readable, pre-selected set of attributes of an object.

With machinectl, the 'show' command must be used with a parameter. So
`machinectl --all show $machine` should contain the same information
as `machinectl status $machine`, and even more. If that's not the
case, please post an example.

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

Re: [systemd-devel] sd-bus vs glib object path node hierarchy

[David Herrmann]

Hi

On Tue, Jun 16, 2015 at 11:32 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Tue, 16.06.15 22:54, Krzesimir Nowak (krzesi...@endocode.com) wrote:
 That reminds me of a bug (or not-a-bug) in go-dbus [1] - it also generates
 flat hierarchy. This is a problem for tools like d-feet - they fail to
 introspect services with flat hierarchy. Of course, it might be a bug in
 d-feet itself.

 [1] https://github.com/godbus/dbus/issues/14

 Unless I misunderstand this sd-bus and go-dbus actually work very
 differently here: sd-bus actually synthesizes an object and suppresses
 it in the introspection. go-dbus doesn't even synthesize it. That
 means that if d-feet asks the intermediary objects on an sd-bus server
 all is good even if the service will never announce it voluntarily...

 I also just verified that d-feet works fine with sd-bus services.

Maybe someone can fix d-feet to do what `busctl tree` does? That is,
if introspection for '/' returns a node at '/foo/bar' then better
continue at '/foo/bar' instead of '/foo'. Not sure why d-feet chops
those paths off?

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

Re: [systemd-devel] /etc/resolv.conf link in container

[David Herrmann]

Hi

On Tue, Jun 16, 2015 at 11:39 PM, Johannes Ernst
johannes.er...@gmail.com wrote:
 I have a root filesystem in directory foo/
 It has symlink
 foo/etc/resolv.conf - /run/systemd/resolve/resolv.conf

 When I’m booting the container:
 sudo systemd-nspawn --directory foo --boot

 I’m getting:
 Failed to copy /etc/resolv.conf to /home/…./foo/etc/resolv.conf: Too many 
 levels of symbolic links

 This message makes very little sense to me. Why is a copy necessary? and is 
 that indeed /etc/resolv.conf or foo/etc/resolv.conf?

 If I boot with -n, I don’t seem to get the error.

If you pass --private-network / -n, then we never touch resolv.conf.
In all other cases, we copy resolv.conf from the host into the
container. We usually assume that if your container runs in the same
network as the host, then the container must also use the DNS features
of the host.

The error code of Too many levels of symbolic links is ELOOP. This
is returned by open() in many cases. In this example, it is returned
because we passed O_NOFOLLOW to open(), but the final part of the path
is a symlink. In that case, the kernel returns ELOOP to tell us that
we're dealing with a symlink.

Maybe Lennart or Tom have some comments on that? Your example use-case
(resolved in the container, even with shared network namespace) looks
valid, though odd. I mean, what's the reason not to use -n? Anyway,
maybe we can deal with ELOOP in setup_resolv_conf() and just print a
big fat warning?
But lets people who know that stuff comment first..

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

Re: [systemd-devel] Can kdbus send signal to the source connection?

[David Herrmann]

Hi

On Tue, Jun 16, 2015 at 9:35 AM, eshark eshar...@163.com wrote:
 Hi,


 At 2015-06-15 22:32:27, Lennart Poettering lenn...@poettering.net wrote:
On Mon, 15.06.15 19:05, eshark (eshar...@163.com) wrote:

 Hi, All,
If I post this email to the wrong mail-list, please tell me, thank
 you.

Now many JS applications implement the client and service in the
 same thread, so they share the same connection too.

 However when the client or the service want to send signal to the other,
 the receiver cannot get the signal because the kdbus driver

 won't broadcast the signal to the source connection.

   I've tried to simply allow the kdbus driver to send signal to all
 the connections including the source , but it seems not work OK.

 I wonder that how I can make kdbus send signal to the source connection,
 or that this is impossible ?

I am not dure I follow. Are you developing a native kdbus client
library for JS?
 Yes, we already have a library based on DBus, and I'm migrating it to KDBus.


Did I get this right, you have one bus connection per thread, but
possibly both a kdbus client and its service run from the server, and
you want broadcast msgs sent out from one to then also be matchable by
the other?
 Yes.  And I've tried removing the condition in kdbus_bus_broadcast(), as
 David  said.
 But this modification caused that the network module of our system cannot
 work OK,  it's very strange ,
 and I'm not familiar with the network module, so I  haven't find the root
 cause.
 Maybe it has nothing to do with KDBus? I am not sure.

Can you be more specific, please? What do you mean by network module
of our systemd cannot work OK?

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

Re: [systemd-devel] Can kdbus send signal to the source connection?

[David Herrmann]

Hi

On Tue, Jun 16, 2015 at 12:07 PM, eshark eshar...@163.com wrote:
 At 2015-06-16 15:54:10, David Herrmann dh.herrm...@gmail.com wrote:
Can you be more specific, please? What do you mean by network module
of our systemd cannot work OK?

 Sorry.  Acctually  our network module cannot get ip by DHCP.  Our network
 module is
 connman, which depends on libdbus.And the connman will connect to KDBus
 through the bus-proxyd, which is implemented in the libsystemd.

Can you please be more specific!

Does this only happen with kdbus?
Does this only happen with you kdbus-patch to make broadcasts being
sent to oneself?
Or does it happen with unmodified kdbus, too?
What exactly changes?
Does everything work perfectly well without kdbus?
Is the missing DHCP connectivity the only difference you see with kdbus?
What kdbus version do you run?
What kdbus tree do you use?
What systemd version do you use? (in case of git: which commit?)
Did you pass --enable-kdbus to systemd?
What upstream kernel version do you use?
Any obscure messages in the system-log that you didn't see before?
...

Please try to paste as much information as possible. Otherwise, it's
really a hassle to ask for each piece of information separately.

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

[systemd-devel] [ANNOUNCE] Git development moved to github

[David Herrmann]

Hi

As of today we've disabled git-push to fd.o. The official development
git repository is now at github [1]. The old repository will still be
back-synced, but we had to disable push-access to avoid getting
out-of-sync with github.

In recent months, keeping up with the mailing-list has become more and
more cumbersome, with many of us missing mails or unable to keep up
with the traffic. To make sure all community requests and patches will
get handled in time, we're now trying out the github infrastructure.
We encourage everyone in the development community to switch over now,
even though the old fd.o infrastructure will still be maintained.
Distributions are free to wait until the next release announcement
before updating anything.

If github does not work out, we will see what else we can try out. But
lets give it at least a try.

Thanks
David

[1] https://github.com/systemd-devs/systemd
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] Separating gudev from systemd

[David Herrmann]

Hi

On Mon, Jun 1, 2015 at 6:51 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Mon, Jun 01, 2015 at 05:48:15PM +0100, Bastien Nocera wrote:
 On Sun, 2015-05-31 at 02:24 +, Zbigniew Jędrzejewski-Szmek wrote:
  Hi Bastien,
 
  do you have any plans for the package in Fedora?

 I don't plan on packaging it in the short term, so if there are
 volunteers, go right ahead.
 OK, I'll prepare a review request.

Thanks a lot!

 @David: could you make a release of gudev 230? There's a few patches
 on top gudev 219 currently, and I think it would be less error-prone
 to package the released version with the bumped version number.

I only found a typo-fix on top of 219. Now backported to libgudev and
pushed into the gnome bugzilla. Same for the 230 version bump. If
anything else is missing, please let me know.

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

Re: [systemd-devel] [ANNOUNCE] Git development moved to github

[David Herrmann]

Hi

On Mon, Jun 1, 2015 at 8:12 PM, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 As of today we've disabled git-push to fd.o. The official development
 git repository is now at github [1]. The old repository will still be
 back-synced, but we had to disable push-access to avoid getting
 out-of-sync with github.

 In recent months, keeping up with the mailing-list has become more and
 more cumbersome, with many of us missing mails or unable to keep up
 with the traffic. To make sure all community requests and patches will
 get handled in time, we're now trying out the github infrastructure.
 We encourage everyone in the development community to switch over now,
 even though the old fd.o infrastructure will still be maintained.
 Distributions are free to wait until the next release announcement
 before updating anything.

 If github does not work out, we will see what else we can try out. But
 lets give it at least a try.

Short update trying to answer all the questions:

Our preferred way to send future patches is the github way. This
means sending pull-requests to the github repo. Furthermore, all
feature patches should go through pull-requests and should get
reviewed pre-commit. This applies to everyone. Exceptions are
non-controversial patches like typos and obvious bug-fixes.
The exact 'rules' on when to merge a pull-request need to be figured
out once we get going. Ideas welcome! Until then, just apply common
sense. Push-access can be granted to contributors like before.
However, given that we want a pre-commit review model, it will not
make much of a difference which person eventually merges the patches.
We still highly appreciate the effort spent by many commiters to
review and apply trivial changes up to critical bugfixes. This worked
well and we want to keep this model, but avoid it for any feature
development.

The mailing-list will still be used for non-code related discussions,
and I think (?) patches from new contributors on the ML might still be
handled as before. But I guess this is mostly limited to trivial
patches. Bigger patchsets should really go through github to avoid
them getting lost on mailing-lists.
Regarding the bug-tracker, I honestly don't know what the plan is. I
think the plan is to stick to everything github provides us, to make
sure we don't spread our tools across multiple hosts. However, I
personally would prefer to discuss this in the community and see what
issues come up. Anyone?

The reason behind this move is that our current post-commit model
places a high burden on anyone doing a release. It really does not
scale and requires often more than a month to review everything. It is
hard to distribute the workload as the infrastructure doesn't provide
any help here. The result could be seen with the several hiccups
during the 220 release.
Furthermore, we want to avoid miscommunications on bigger feature
patches that might not make it into upstream. With a pre-commit
review, we hope to settle discussions before any code makes it into
git, and save everyone the hassle of reverting patches which maybe
other projects already relied on.

Regarding the final github address: David Strauss kindly offered the
'systemd' user to us. Hence, we hope to move the repository to
github.com/systemd/systemd this week. Sorry for the confusion, I hope
we can settle all this this week.

Finally, please speak up if there are any issues. I will do my best to
address them. We want to tryout github to reduce the burden on the
maintainers, but to also improve the interactions with outside
contributions. Feedback is welcome! And to everyone not happy with
that move, we'd appreciate if you could still give it a try. Lets see
how it works out!

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

Re: [systemd-devel] [ANNOUNCE] Git development moved to github

[David Herrmann]

Hi

On Tue, Jun 2, 2015 at 3:58 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Tue, Jun 02, 2015 at 03:31:19PM +0200, Daniel Mack wrote:
 On 06/02/2015 02:19 PM, Jason A. Donenfeld wrote:
  On Tue, Jun 2, 2015 at 1:06 PM, David Herrmann dh.herrm...@gmail.com 
  wrote:
  Regarding the final github address: David Strauss kindly offered the
  'systemd' user to us. Hence, we hope to move the repository to
  github.com/systemd/systemd this week. Sorry for the confusion, I hope
  we can settle all this this week.
 
  I recommend you get this sorted out as soon as possible and not wait
  another moment. People have already submitted pull requests to both
  repos, and things are going to get quite confusing if you don't move
  fast on this.

 It's sorted out now. https://github.com/systemd/systemd is now the
 official upstream. The old repo from systemd-devs was transferred
 withing GitHub, which means that the old web and ssh URLs are currently
 redirected automatically. However, we will remove the systemd-devs
 organization any time soon to avoid further confusion.
 Who has write access to the repository? If you could add me (keszybz @ 
 github),
 that would be nice. What about the rest of people from annarchy.fd.o: 
 david,walters,kay,harald,tfheen,lennart,whot,mbiebl,holtmann,alban,martin,colin,bor,michich,zbyszek,dreisner,straussd,tomegun,phomes,auke,dvdhrm,zonque,bphilips,msekleta,lnykryn,pflykt,rchevalier?

Daniel added them all. We just had to figure out the github
user-names. You should have an invitation in your inbox.

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

Re: [systemd-devel] [PATCH] loginctl: add rule for qemu's pci-bridge-seat

[David Herrmann]

Hi

On Mon, Jun 29, 2015 at 9:42 AM, Gerd Hoffmann kra...@redhat.com wrote:
 Signed-off-by: Gerd Hoffmann kra...@redhat.com
 ---
  src/login/71-seat.rules.in | 6 ++
  1 file changed, 6 insertions(+)

 diff --git a/src/login/71-seat.rules.in b/src/login/71-seat.rules.in
 index ab7b66f..270da71 100644
 --- a/src/login/71-seat.rules.in
 +++ b/src/login/71-seat.rules.in
 @@ -17,6 +17,12 @@ SUBSYSTEM==usb, ATTR{bDeviceClass}==09, TAG+=seat
  # 'Plugable' USB hub, sound, network, graphics adapter
  SUBSYSTEM==usb, ATTR{idVendor}==2230, ATTR{idProduct}==000[13], 
 ENV{ID_AUTOSEAT}=1

 +# qemu (version 2.4+) has a PCI-PCI bridge (-device pci-bridge-seat)
 +# to group devices belonging to one seat.
 +# see http://git.qemu.org/?p=qemu.git;a=blob;f=docs/multiseat.txt
 +SUBSYSTEM==pci, ATTR{vendor}==0x1b36, ATTR{device}==0x000a, \
 +   TAG+=seat, ENV{ID_AUTOSEAT}=1
 +

I have no idea why this is correct. Could you provide a proper commit-message?

Is this specific VID/PID match exclusively used for seat'ing? Or might
other pci-bridges use the same (without any intention to get different
seats?). Even if that's the case, I'm still fine with you default, but
please describe this properly so we can understand the implications
later on.

Thanks!
David

  # Mimo 720, with integrated USB hub, displaylink graphics, and e2i
  # touchscreen. This device carries no proper VID/PID in the USB hub,
  # but it does carry good ID data in the graphics component, hence we
 --
 1.8.3.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

Re: [systemd-devel] [PATCH] loginctl: add rule for qemu's pci-bridge-seat

[David Herrmann]

Hi

On Wed, Jul 1, 2015 at 4:25 PM, Gerd Hoffmann kra...@redhat.com wrote:
 On Mi, 2015-07-01 at 13:10 +0200, David Herrmann wrote:
 Hi

 On Mon, Jun 29, 2015 at 9:42 AM, Gerd Hoffmann kra...@redhat.com wrote:
  Signed-off-by: Gerd Hoffmann kra...@redhat.com
  ---
   src/login/71-seat.rules.in | 6 ++
   1 file changed, 6 insertions(+)
 
  diff --git a/src/login/71-seat.rules.in b/src/login/71-seat.rules.in
  index ab7b66f..270da71 100644
  --- a/src/login/71-seat.rules.in
  +++ b/src/login/71-seat.rules.in
  @@ -17,6 +17,12 @@ SUBSYSTEM==usb, ATTR{bDeviceClass}==09, TAG+=seat
   # 'Plugable' USB hub, sound, network, graphics adapter
   SUBSYSTEM==usb, ATTR{idVendor}==2230, ATTR{idProduct}==000[13], 
  ENV{ID_AUTOSEAT}=1
 
  +# qemu (version 2.4+) has a PCI-PCI bridge (-device pci-bridge-seat)
  +# to group devices belonging to one seat.
  +# see http://git.qemu.org/?p=qemu.git;a=blob;f=docs/multiseat.txt
  +SUBSYSTEM==pci, ATTR{vendor}==0x1b36, ATTR{device}==0x000a, \
  +   TAG+=seat, ENV{ID_AUTOSEAT}=1
  +

 I have no idea why this is correct. Could you provide a proper 
 commit-message?

 Is this specific VID/PID match exclusively used for seat'ing?

 Yes.  The normal pci-pci bridge (-device pci-bridge) has 1b36:0001.
 The new pci-bridge-seat was specifically added to simplify guest-side
 multiseat configuration.  It is identical to the normal pci-pci bridge,
 except that it has a different id (1b36:000a) so we can match it and
 configure multiseating automatically.

Ok, then this looks fine.

 The documentation linked in the comment has all the details.  /me
 through this would be more useful as it is visible on the installed
 system (unlike the git commit message).

 But I can cut  paste the paragraph above into the commit message and
 resend.  Or should I redo the github pull-request instead?

I can amend this information.

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

Re: [systemd-devel] Testing kdbus and bus-proxy

[David Herrmann]

Hi

On Wed, Jul 1, 2015 at 10:38 PM, Daniel Buch boogiewasth...@gmail.com wrote:
 Alright, i just updated kdbus branch, and these issues is solved..

We haven't broken ABI for quite some time (and are now committed to
the ABI!). But still, thanks for the report!

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

Re: [systemd-devel] [PATCH] Remove accelerometer helper

[David Herrmann]

Hi

On Fri, Jul 3, 2015 at 1:25 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Mon, 29.06.15 16:03, Tom Gundersen (t...@jklm.no) wrote:

 On Sat, Jun 27, 2015 at 10:02 PM, Kay Sievers k...@vrfy.org wrote:
  On Fri, May 22, 2015 at 3:42 PM, Bastien Nocera had...@hadess.net wrote:
  It's moved to the iio-sensor-proxy D-Bus service.
  ---
   .gitignore |   1 -
   Makefile.am|  15 --
   rules/61-accelerometer.rules   |   3 -
   src/udev/accelerometer/Makefile|   1 -
   src/udev/accelerometer/accelerometer.c | 303 
 
  https://github.com/systemd/systemd/pull/387

 This was now merged, so distros should be aware that they need to pick
 up iio-sensor-proxy with the next systemd release.

 Could you please add a note with the details regarding this to NEWS
 for v222 already, so that we don't forget this?

Done.

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

Re: [systemd-devel] Can kdbus send signal to the source connection?

[David Herrmann]

Hi

On Sun, Jun 21, 2015 at 4:28 AM, eshark eshar...@163.com wrote:
 Hi,
 After removing /usr/lib/systemd/systemd-cgroups-agent,  all seems to
 work OK.

cgroups-agent is now fixed in -git:
https://github.com/systemd/systemd/commit/0a069ce62de904ae9cbaf23d026ac380b02e50e4

I also fixed kdbus, but haven't pushed it out, yet. It will be
included in the next merge.

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

Re: [systemd-devel] What kdbus Version for systemd 220 ?

[David Herrmann]

Hi

On Sun, May 24, 2015 at 3:00 PM, Thomas Ritter th.rit...@gmx.at wrote:
 Dear group,

 Since a while I am experimenting with systemd and kdbus, till now with
 excellent results.
 Recently I tried to bump all versions to LATEST/HEAD, and ran into some
 issues.

 My short question:
 Is there a recommendation what kdbus version fits to the current systemd
 V220?

 Till now I was using kdbus from https://github.com/gregkh/kdbus, but the
 latest commit there is from Mar 6th  ?
 And with this version kdbus seems not working properly with V220 here (
 is_kdbus_available() in bus-util.c fails with ioctl KDBUS_CMD_BUS_MAKE).

There's an out-of-tree repository with an v4.0 and v4.1 branch (you
must pick a branch matching your kernel!):
https://github.com/systemd-devs/kdbus

The official kdbus branch is in Greg's kernel.org tree. However, due
to vacation it hasn't been updated, yet.

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

Re: [systemd-devel] [PATCH] fix typos in systemd-nspawn man page

[David Herrmann]

Hi

On Sat, May 23, 2015 at 5:11 AM, Jonathan Boulle
jonathan.bou...@coreos.com wrote:
 ---
  man/systemd-nspawn.xml | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

Applied!

Thanks
David

 diff --git a/man/systemd-nspawn.xml b/man/systemd-nspawn.xml
 index 6a5db86cec3c..06285edc0bb3 100644
 --- a/man/systemd-nspawn.xml
 +++ b/man/systemd-nspawn.xml
 @@ -330,7 +330,7 @@
  first host UID to assign to the container, the second
  parameter specifies the number of host UIDs to assign to the
  container. If the second parameter is omitted, 65536 UIDs are
 -assigned. If the first parameter is also ommitted (and hence
 +assigned. If the first parameter is also omitted (and hence
  no parameter passed at all), the first UID assigned to the
  container is read from the owner of the root directory of the
  container's directory tree. By default no user namespacing is
 @@ -454,7 +454,7 @@
  container port number in the range from 1 to 65535. The
  protocol specifier and its separating colon may be omitted, in
  which case literaltcp/literal is assumed. The container
 -port number and its colon may be ommitted, in which case the
 +port number and its colon may be omitted, in which case the
  same port as the host port is implied. This option is only
  supported if private networking is used, such as
  option--network-veth/option or
 --
 1.9.3

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

Re: [systemd-devel] [PATCH] Remove accelerometer helper

[David Herrmann]

Hi

On Fri, May 22, 2015 at 5:10 PM, Bastien Nocera had...@hadess.net wrote:
 On Fri, 2015-05-22 at 17:00 +0200, Tom Gundersen wrote:
 On Fri, May 22, 2015 at 3:42 PM, Bastien Nocera had...@hadess.net
 wrote:
  It's moved to the iio-sensor-proxy D-Bus service.

 Nice! When was this released? Should we expect all distros to have
 picked up this yet?

 It was released as 1.0 today, so, no, I don't expect all distros to
 have it, in fact, I don't expect any to have it ;)

Awesome! Much appreciated! I think we wanna do another systemd release
soon (with the sd-bus/event exports), we can apply this patch
afterwards then (with the gudev removal, too).

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

Re: [systemd-devel] Failed to run test-bus-zero-copy on ARM platform

[David Herrmann]

Hi

On Mon, Jul 6, 2015 at 3:43 PM, eshark eshar...@163.com wrote:
  Hi, All,
 My Software environment is : systemd v219 +  kdbus-4.1-rc1 + 
 kernel_3.10
 and my hardware platform is ARM CA9 quad core.

 I failed to run the test-bus-zero-copy on my platform,  and then I 
 traced into the issue ,
 and found that the reason is that the padding  KDBU_ITEM_PAYLOAD_VEC will  
 fail to pass the
 access_ok() in kdbus_pool_slice_copy_iovec().

  In detail,in kdbus_msg_scan_items() , there is
iov-iov_base = (char  __user *)zeros == for example, the 
 iov_base is 0xc0b1794c  on my platform
   and
static const char * const zeros = \0\0\0\0\0\0\0;

 But in slice-pool-f-f_op-aio_write() , that is 
 generic_file_aio_write() , which calls  access_ok(access_flags, iv-iov_base, 
 iv-iov_len);
 And this will fail.

However,  I can run test-bus-zero-copy successfully  in Fedora21 
 Virtual Machine which runs on x86-64 platform.
 And  I run  systemd v219 +  kdbus-4.1-rc1 + kernel_3.18 in Fedora21 VM.

 Could anyone give me some suggestion?

Your kdbus-module version must match your kernel version. If you use
the out-of-tree repository, use the v4.1 branch for your 4.1 kernel,
the v4.0 branch for your 4.0 kernel. No other combinations are
supported.

I also highly recommend to use the in-tree version of kdbus from Greg's tree:
http://git.kernel.org/cgit/linux/kernel/git/gregkh/char-misc.git/log/?h=kdbus
This is the officially supported version. The out-of-tree module is
just for development.

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

Re: [systemd-devel] sd 221 regression: login - nonexistent sessions via lightdm

[David Herrmann]

Hi

On Tue, Jul 7, 2015 at 6:55 PM, Martin Pitt martin.p...@ubuntu.com wrote:
 Hey David,

 David Herrmann [2015-07-07 18:31 +0200]:
  Revert login: re-use VT-sessions if they already exist - commit 0204c4b
  http://cgit.freedesktop.org/systemd/systemd/commit/?id=0204c4b

 Can someone elaborate what exactly lightdm does here? We really want
 to prevent multiple sessions on the same VT. This is just nasty and
 never made any sense. So I'm really interested why lightdm doesn't
 kill it's manager-session before it starts the new session. Any
 particular reason here?

 I'll let Robert answer with the details, but something I noticed:

 It's not that simple to reproduce, but sometimes it seems the lightdm
 greeter session (running as user lightdm, where you select user/type
 password and so on) doesn't completely terminate, but some processes
 stay around in it. Thus the greeter session stays around in state
 Closing, and then the real session starts on the same VT.

 I asked the reporter of https://launchpad.net/bugs/1472259 to attach
 systemd-cgls, so that we can see what's running in the session.

So it might indeed just be a race in lightdm. Hmm..
Anyway, this patch here should also fix the issue (if it does, I'll
commit something proper).

Thanks
David

diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
index 0cc2cdf..bced693 100644
--- a/src/login/logind-dbus.c
+++ b/src/login/logind-dbus.c
@@ -690,8 +690,11 @@ static int method_create_session
 }

 manager_get_session_by_pid(m, leader, session);
-if (!session  vtnr  0  vtnr  m-seat0-position_count)
+if (!session  vtnr  0  vtnr  m-seat0-position_count) {
 session = m-seat0-positions[vtnr];
+if (session  session-class == SESSION_GREETER)
+session = NULL;
+}
 if (session) {
 _cleanup_free_ char *path = NULL;
 _cleanup_close_ int fifo_fd = -1;
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd 221 regression: login - nonexistent sessions via lightdm

[David Herrmann]

Hi

On Tue, Jul 7, 2015 at 7:10 PM, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 On Tue, Jul 7, 2015 at 6:55 PM, Martin Pitt martin.p...@ubuntu.com wrote:
 Hey David,

 David Herrmann [2015-07-07 18:31 +0200]:
  Revert login: re-use VT-sessions if they already exist - commit 0204c4b
  http://cgit.freedesktop.org/systemd/systemd/commit/?id=0204c4b

 Can someone elaborate what exactly lightdm does here? We really want
 to prevent multiple sessions on the same VT. This is just nasty and
 never made any sense. So I'm really interested why lightdm doesn't
 kill it's manager-session before it starts the new session. Any
 particular reason here?

 I'll let Robert answer with the details, but something I noticed:

 It's not that simple to reproduce, but sometimes it seems the lightdm
 greeter session (running as user lightdm, where you select user/type
 password and so on) doesn't completely terminate, but some processes
 stay around in it. Thus the greeter session stays around in state
 Closing, and then the real session starts on the same VT.

 I asked the reporter of https://launchpad.net/bugs/1472259 to attach
 systemd-cgls, so that we can see what's running in the session.

 So it might indeed just be a race in lightdm. Hmm..
 Anyway, this patch here should also fix the issue (if it does, I'll
 commit something proper).

Ok, I pushed this to -git now. Should be fixed. Can you guys verify?

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

Re: [systemd-devel] sd 221 regression: login - nonexistent sessions via lightdm

[David Herrmann]

Hi

On Tue, Jul 7, 2015 at 6:14 PM, poma pomidorabelis...@gmail.com wrote:

 Revert login: re-use VT-sessions if they already exist - commit 0204c4b
 http://cgit.freedesktop.org/systemd/systemd/commit/?id=0204c4b

Can someone elaborate what exactly lightdm does here? We really want
to prevent multiple sessions on the same VT. This is just nasty and
never made any sense. So I'm really interested why lightdm doesn't
kill it's manager-session before it starts the new session. Any
particular reason here?

Furthermore, how exactly does lightdm do all this. Is there a control
daemon running outside the session, then there's the graphical login
processes with their own 'lightdm' session? Once the login is done,
you start the new session from the control daemon and _afterwards_
destroy the lightdm-session?

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

Re: [systemd-devel] possible message leak in bus-wqueue ?

[David Herrmann]

Hi

On Fri, Aug 7, 2015 at 12:07 PM, cee1 fykc...@gmail.com wrote:
 2015-08-07 17:18 GMT+08:00 eshark eshar...@163.com:
 Hi, all
   If  some message went into bus-wqueue, and  failed to run
 ioctl(KDBUS_CMD_SEND) and returned  r  0,
 I found that this message will remain in the bus-wqueue.   If  the peer is
 killed for some reason, this message will fail to be sent and remain in the
 wqueu for ever.

 Because in  dispatch_wqueue() ,  when bus_write_message() return r 0,
 dispatch_wqueue() will simply return this  r  into the caller.
 And the wqueue is invisible to user application, so user application also
 cannot   remove this message to handle this error case.

  I wonder whether this is a problem, and if yes,  should we remove this
 message  in dispatch_wqueue() when  r  0 ?

 I've the same question.

 E.g.

 dispatch_wqueue()
 bus_write_message()
 bus_kernel_write_message()

 
 r = ioctl(bus-output_fd, KDBUS_CMD_SEND, cmd);
 if (r  0) {
 ...
 else if (errno == ENXIO || errno == ESRCH) {
 ...
 if (m-header-type == SD_BUS_MESSAGE_METHOD_CALL)
 sd_bus_error_setf(error,
 SD_BUS_ERROR_SERVICE_UNKNOWN, Destination %s not known,
 m-destination);
 else {
 log_debug(Could not deliver message
 to %s as destination is not known. Ignoring., m-destination);
 return 0;

This probably needs to be return 1;. Lennart, any comments?

 }
 }
 

 If A __returns__ a result to B, but B has already died (After sending
 a method call message):

 1. It will return ENXIO or ESRCH, right?

It returns EBADSLT.

 2. dispatch_wqueue(), bus_write_message()  and
 bus_kernel_write_message() returns 0
 3. Next time dispatch_wqueue() called, it will retry, but never
 succeed - so, deadlocked?

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

Re: [systemd-devel] terminals not appearing

[David Herrmann]

Hi

On Tue, Aug 18, 2015 at 11:55 PM, Michał Zegan
webczat_...@poczta.onet.pl wrote:
 Seems like this does not apply. I said that terminals do not start, and this
 is random, sometimes they do. n_auto_vts = 6.

Can you provide more details about this? How do you reproduce it? What
are you running on your machine? What other graphical and/or text
console do you run?
Please be as specific as possible!

Btw., if you run a graphical login on a VT, then there might not be
any getty appearing on it for as much as 90s. So please try whether it
works after 90s.

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

Re: [systemd-devel] kdbus: busctl for user session and for system-wide shows weird information

[David Herrmann]

Hi

On Sat, Aug 1, 2015 at 3:48 PM, Igor Gnatenko
i.gnatenko.br...@gmail.com wrote:
 Hi,

 I'm running Fedora 24 with systemd-224 and kernel-4.2.0-0.rc4.git2.1
 with kdbus=1 in kernel cmdline.

 I have my own pulseaudio.service enabled for one user-session.
 $ cat /etc/systemd/user/pulseaudio.service
 [Unit]
 After=sound.target network.target avahi-daemon.service
 Requires=sound.target
 Wants=avahi-daemon.service
 Description=PulseAudio Sound System

 [Service]
 Type=dbus
 BusName=org.pulseaudio.Server
 BusName=org.PulseAudio1
 ExecStart=/usr/bin/pulseaudio -vv
 ExecStop=/usr/bin/pulseaudio --kill
 Restart=always

 [Install]
 WantedBy=default.target


 $ busctl --user
 shows me 4 names for pulseaudio:
 * :1.458
 * org.PulseAudio1
 * org.freedesktop.ReserveDevice1.Audio0
 * org.pulseaudio.Server

 # busctl
 shows me 2 names for pulseaudio:
 * :1.400
 * :1.752

 So the question is: Why I see unique IDs in system bus while process
 running only in user-session? If it's should be so -- why I don't see
 interface names like org.PulseAudio1 in system bus?

PulseAudio connects to the system bus to talk to system services. It
does not provide services on the system-bus, hence, it only has
unique-names there. On the user-bus, pulseaudio provides services so
it claims a well-known name.
Well-known names are only claimed if you offer a service (so others
can reach you). However, there are valid reasons to connect to a bus
without offering services and just using services provided by others.
Pulseaudio probably listens on the system bus for global events like
those provided by systemd-logind.

The reason you see multiple connections for pulseaudio is something to
ask the pulseaudio developers. They might have valid reasons to not
share a connection for all accesses.

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

[systemd-devel] [ANNOUNCE] systemd v223

[David Herrmann]

Hi

Here's the next version of systemd, v223:

https://github.com/systemd/systemd/archive/v223.tar.gz

Many bug-fixes, code cleanups and some new additions to networkd and
resolved. As announced with the previous release, systemd-python has
been removed from upstream and now resides in its own repository:

https://github.com/systemd/python-systemd

CHANGES WITH 223:

* The python-systemd code has been removed from the systemd repository.
  A new repository has been created which accommodates the code from
  now on, and we kindly ask distributions to create a separate package
  for this: https://github.com/systemd/python-systemd

* The systemd daemon will now reload its main configuration
  (/etc/systemd/system.conf) on daemon-reload.

* sd-dhcp now exposes vendor specific extensions via
  sd_dhcp_lease_get_vendor_specific().

* systemd-networkd gained a number of new configuration options.

  - A new boolean configuration option for TAP devices called
'VNetHeader='. If set, the IFF_VNET_HDR flag is set for the
device, thus allowing to send and receive GSO packets.

  - A new tunnel configuration option called 'CopyDSCP='.
If enabled, the DSCP field of ip6 tunnels is copied into the
decapsulated packet.

  - A set of boolean bridge configuration options were added.
'UseBPDU=', 'HairPin=', 'FastLeave=', 'AllowPortToBeRoot=',
and 'UnicastFlood=' are now parsed by networkd and applied to the
respective bridge link device via the respective IFLA_BRPORT_*
netlink attribute.

  - A new string configuration option to override the hostname sent
to a DHCP server, called 'Hostname='. If set and 'SendHostname='
is true, networkd will use the configured hostname instead of the
system hostname when sending DHCP requests.

  - A new tunnel configuration option called 'IPv6FlowLabel='. If set,
networkd will configure the IPv6 flow-label of the tunnel device
according to RFC2460.

  - The 'macvtap' virtual network devices are now supported, similar to
the already supported 'macvlan' devices.

* systemd-resolved now implements RFC5452 to improve resilience against
  cache poisoning. Additionally, source port randomization is enabled
  by default to further protect against DNS spoofing attacks.

* nss-mymachines now supports translating UIDs and GIDs of running
  containers with user-namespaces enabled. If a container 'foo'
  translates a host uid 'UID' to the container uid 'TUID', then
  nss-mymachines will also map uid 'UID' to/from username 'vu-foo-TUID'
  (with 'foo' and 'TUID' replaced accordingly). Similarly, groups are
  mapped as 'vg-foo-TGID'.

Contributions from: Beniamino Galvani, cee1, Christian Hesse, Daniel
Buch, Daniel Mack, daurnimator, David Herrmann, Dimitri John Ledkov,
HATAYAMA Daisuke, Ivan Shapovalov, Jan Alexander Steffens (heftig),
Johan Ouwerkerk, Jose Carlos Venegas Munoz, Karel Zak, Kay Sievers,
Lennart Poettering, Lidong Zhong, Martin Pitt, Michael Biebl, Michael
Olbrich, Michal Schmidt, Michal Sekletar, Mike Gilbert, Namhyung Kim,
Nick Owens, Peter Hutterer, Richard Maw, Steven Allen, Sungbae Yoo,
Susant Sahani, Thomas Blume, Thomas Hindoe Paaboel Andersen, Tom
Gundersen, Torstein Husebø, Umut Tezduyar Lindskog, Vito Caputo,
Vivenzio Pagliari, Zbigniew Jędrzejewski-Szmek

-- Berlin, 2015-07-29
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [ANNOUNCE] systemd-223 around the corner

[David Herrmann]

Hi

Following our ~2 week release plans, we intend to release v223 early
next week. If anyone has open issues that need to be resolved before a
release, please speak up.

Right now, the changes consist of mostly bugfixes and a few
configuration additions. I'll commit the full NEWS tomorrow.

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

Re: [systemd-devel] Confusing error message

[David Herrmann]

Hi

On Tue, Jun 23, 2015 at 4:28 AM, Johannes Ernst
johannes.er...@gmail.com wrote:
 $ systemctl restart systemd-networkd
 Failed to restart systemd-networkd.service: The name 
 org.freedesktop.PolicyKit1 was not provided by any .service files

 $ sudo systemctl restart systemd-networkd
 Works.

 Presumably this error message could be improved, in particular because that 
 name is indeed not provided by any .service files :-)

So if you're not root, systemctl needs to ask polkit to perform
authorization. It does this, by sending a dbus message to polkit. If
that well-known bus-name is not owned by anyone, the error message in
question gets returned. So with inside knowledge, it does make sense
;)

Regarding changing this: For debug purposes, it is highly valuable to
know the cause of failure. This message clearly tells a developer what
went wrong. Not sure we want to change this. Or more importantly, I'm
not entirely sure it is easy to change this, as this error is
generated deep down in the polkit-code.
We could just throw that message away and always return EPERM. Not
sure it's worth it, though.

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

Re: [systemd-devel] sd-bus object manager question

[David Herrmann]

Hi

On Mon, Jul 20, 2015 at 9:26 PM, David Härdeman da...@hardeman.nu wrote:
 On Sat, Jun 27, 2015 at 09:22:45AM +0200, David Härdeman wrote:
On Thu, Jun 25, 2015 at 04:25:29PM +0200, David Herrmann wrote:
On Tue, Jun 23, 2015 at 2:41 PM, David Härdeman da...@hardeman.nu wrote:
...
 Now, a question...how is an object manager supposed to be implemented in
 sd-bus?

 I've seen that there's a sd_bus_add_object_manager() function in sd-bus.h,
 but how would I notify the object manager when objects are added and
 removed?

 Two likely candidates seemed to be:
 sd_bus_emit_object_added()
 sd_bus_emit_object_removed()

 But calling them did not seem to do the right thing. And there seems to be
 zero usage of sd_bus_add_object_manager() in the systemd tree itself 
 (though
 plenty of calls to sd_bus_add_node_enumerator() which might be related?).

Not sure where the confusion is. Those calls generate the
InterfacesAdded/Removed signals that the objectmanager API specifies.
They collect the interfaces based on the vtables you registered on a
given path. have a look at test-bus-objects.c which uses these
interfaces.

I've done some more experimentation and I think I've got a better idea
of what's going on. Sorry if my first email was a bit confusing.

My problem is that I couldn't get the sd-bus object manager to properly
notify clients when objects are added or removed.

I'm testing my sd-bus server with a gdbus client. The
GDBusObjectManagerClient should normally generate signals (gobject
signals, that is) when objects are added or removed.

Anyway, I tried implementing an object manager server with gdbus as
well, and when talking to the gdbus server, the client is notified of
object additions/removals, so I used used busctl to monitor the signals
that were generated. I think I've found the problem.

Assume there's an object manager at /org/example/mgr and that a new
object is created at /org/example/mgr/object1.

With sd-bus, I'd call:
sd_bus_emit_object_added(bus, /org/example/mgr/object1);

The generated signal would be:
‣ Type=signal  Endian=l  Flags=1  Version=1  Priority=0 Cookie=11
  Sender=:1.297  Path=/org/example/mgr/object1
Interface=org.freedesktop.DBus.ObjectManager  Member=InterfacesAdded
  UniqueName=:1.297
  MESSAGE oa{sa{sv}} {
  OBJECT_PATH /org/example/mgr/object1;

With gdbus, the generated signal is instead:
The generated signal would be:
‣ Type=signal  Endian=l  Flags=1  Version=1  Priority=0 Cookie=21
  Sender=:1.297  Path=/org/example/mgr
Interface=org.freedesktop.DBus.ObjectManager  Member=InterfacesAdded
  UniqueName=:1.297
  MESSAGE oa{sa{sv}} {
  OBJECT_PATH /org/example/mgr/object1;

Note the difference in the sender path.

The GDBusObjectManagerClient seems to ignore the signal sd-bus generates
because of the different path.

I think that means that sd_bus_emit_object_added() would need to take
both the object manager path and the object path as arguments instead of
a single path?

 Ping?

Thanks for the reminder, almost forgot about this. And sorry for the
delay, many of us are on vacation right now, and the remaining few
have a hard time keeping up with reports.

I pushed a fix here:
https://github.com/systemd/systemd/pull/641

I'd prefer if we can move this discussion to github.

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

Re: [systemd-devel] Does socket activation block a TCP port for listening by other processes?

[David Herrmann]

Hi

On Tue, Jul 21, 2015 at 1:37 PM, Florian Weimer fwei...@redhat.com wrote:
 We have quite a zoo of services which listen on localhost, on a fixed
 TCP port, for use by local clients.  The canonical example is PostgreSQL
 on 5432/TCP, for the benefit of Java clients (which cannot use the UNIX
 domain socket).  This has the obvious issue that if a local attacker
 crashes the service, they can impersonate it by binding to the same port.

 Does socket activation reliably prevent such impersonation attacks?  Or
 is there race, say during systemd configuration reloading or service
 restarts, where systemd temporarily does not listen to that port?

This race *does* exist with socket activation. The sockets may be
re-created if the unit transitions between states (like restart).
However, this is only triggered by actions on the socket-unit, not the
actually activated unit. A crash of the activated service will thus
not trigger state-changes on the socket-unit.

Furthermore, we do not treat occupying a resource as security
mechanism. If an attacker has access to bind such a port, we do not
place restrictions to prevent that. Instead, you should place LSM
restrictions to prevent this. And please note, the actual activated
unit usually does *not* have rights to bind the socket. This is done
by pid1. So an attacker would require rights of PID1 for such an
attack.

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

Re: [systemd-devel] [PATCH] Changing configure.ac to make LTO optional.

[David Herrmann]

Hi

On Mon, Jul 20, 2015 at 4:56 PM, Kinsella, Ray ray.kinse...@intel.com wrote:
 There is a bug in GCC LTO such that it ignores assembler directives.
 This patch makes LTO enabled by default but also allows it to be disabled
 if required.

 See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47785

This is a gcc bug. They better fix it and backport it to stable. We do
not work around bugs in other software, unless they explicitly state
why it is not fixed in stable releases. I cannot see a statement why
this bug is unhandled since _2011_.

If gcc developers reject to respond to bug-reports, why do
distributions compile gcc with LTO enabled?

Anyway, why don't you use this workaround instead:
./configure CFLAGS=$CFLAGS -flto=n

*confused*
David

 ---
  configure.ac | 17 -
  1 file changed, 12 insertions(+), 5 deletions(-)

 diff --git a/configure.ac b/configure.ac
 index 999f9f8..294c440 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -194,11 +194,18 @@ AS_CASE([$CC], [*clang*],
 -Wno-gnu-variable-sized-type-not-at-end \
  ])])

 -AS_CASE([$CFLAGS], [*-O[[12345sz\ ]]*],
 -[CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\
 -   -flto -ffat-lto-objects])],
 -[AC_MSG_RESULT([skipping -flto, optimization not enabled])])
 -AC_SUBST([OUR_CFLAGS], $with_cflags $sanitizer_cflags)
 +AC_ARG_ENABLE(lto,
 +[AS_HELP_STRING([--enable-lto], [Enable link time optimization])],
 +   enable_lto=$enableval,
 +   enable_lto=yes; default_enable_lto=yes)
 +
 +if test x$enable_lto != xno; then
 +AS_CASE([$CFLAGS], [*-O[[12345sz\ ]]*],
 +[CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\
 +-flto -ffat-lto-objects])],
 +[AC_MSG_RESULT([skipping -flto, optimization not enabled])])
 +AC_SUBST([OUR_CFLAGS], $with_cflags $sanitizer_cflags)
 +fi

  AS_CASE([$CFLAGS], [*-O[[12345sz\ ]]*],
  [CC_CHECK_FLAGS_APPEND([with_cppflags], [CPPFLAGS], [\
 --
 2.1.0

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

Re: [systemd-devel] libudev: subdirectories in sysfs

[David Herrmann]

Hi

On Mon, Nov 16, 2015 at 5:35 PM, Anne Mulhern  wrote:
> Hi!
>
> libudev has some cooperating procedures that return the keys for a bunch of 
> sysfs attributes for a given device.
>
> These attributes all correspond to files that are stored in the sysfs device 
> directory.
>
> In the same directory there are sometimes subdirectories, that themselves 
> contain files
> with information about their corresponding attribute. The dm directory is one 
> obvious
> example.
>
> Are their any plans for libudev to add an ability to get the values from 
> these subdirectories
> as some kind of attributes?
>
> If no, why?

sd_device_get_sysattr_value(device, "foo/bar/baz", );

This should work fine (or its udev_device_* equivalent).

Btw., I recommend just using readdir(), open(), read(), and write().
sysfs is a filesystem, no reason to wrap all those commands.

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

Re: [systemd-devel] sd 221 regression: login - nonexistent sessions via lightdm

[David Herrmann]

Hi

On Wed, Jul 8, 2015 at 1:29 PM, poma pomidorabelis...@gmail.com wrote:
 Here is another case where this is still broken - LiveCD/DVD constellation.
 Initial log-in should work, but subsequent ones sind kaputt aber glücklich.
 So how to reproduce:
 just log-out  log-in, again.

 Here is a visual record:
 http://goo.gl/Gm4ffO
 Screencast/catch-a-tiger-by-the-toe.webm

 and here is a test compilation, so you can test it yourself:
 http://goo.gl/Gm4ffO
 ISO/Rawhide-Live-Xfce-708.iso

I see. I assume the greeter is again started on the same VT as the
leaving session. If the previous session now leaves stuff behind, we
end up with the same issue. Does the attached patch fix this?

(This is getting a bit convoluted.. we should really fix this properly)

Thanks
David

diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
index 82654ee..91cc67d 100644
--- a/src/login/logind-dbus.c
+++ b/src/login/logind-dbus.c
@@ -699,9 +699,12 @@ static int method_create_session(
  * after the user-session and want the user-session to take
  * over the VT. We need to support this for
  * backwards-compatibility, so make sure we allow new sessions
- * on a VT that a greeter is running on.
+ * on a VT that a greeter is running on. Furthermore, to allow
+ * re-logins, we have to allow a greeter to take over a used VT for
+ * the exact same reasons.
  */
-if (vtnr  0 
+if (class != SESSION_GREETER 
+vtnr  0 
 vtnr  m-seat0-position_count 
 m-seat0-positions[vtnr] 
 m-seat0-positions[vtnr]-class != SESSION_GREETER)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd 221 regression: login - nonexistent sessions via lightdm

[David Herrmann]

Hi

On Tue, Jul 7, 2015 at 10:08 PM, poma pomidorabelis...@gmail.com wrote:
 On 07.07.2015 19:48, David Herrmann wrote:
 Hi

 On Tue, Jul 7, 2015 at 7:10 PM, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 On Tue, Jul 7, 2015 at 6:55 PM, Martin Pitt martin.p...@ubuntu.com wrote:
 Hey David,

 David Herrmann [2015-07-07 18:31 +0200]:
 Revert login: re-use VT-sessions if they already exist - commit 0204c4b
 http://cgit.freedesktop.org/systemd/systemd/commit/?id=0204c4b

 Can someone elaborate what exactly lightdm does here? We really want
 to prevent multiple sessions on the same VT. This is just nasty and
 never made any sense. So I'm really interested why lightdm doesn't
 kill it's manager-session before it starts the new session. Any
 particular reason here?

 I'll let Robert answer with the details, but something I noticed:

 It's not that simple to reproduce, but sometimes it seems the lightdm
 greeter session (running as user lightdm, where you select user/type
 password and so on) doesn't completely terminate, but some processes
 stay around in it. Thus the greeter session stays around in state
 Closing, and then the real session starts on the same VT.

 I asked the reporter of https://launchpad.net/bugs/1472259 to attach
 systemd-cgls, so that we can see what's running in the session.

 So it might indeed just be a race in lightdm. Hmm..
 Anyway, this patch here should also fix the issue (if it does, I'll
 commit something proper).

 Ok, I pushed this to -git now. Should be fixed. Can you guys verify?

 Thanks
 David


 $ loginctl list-sessions
SESSIONUID USER SEAT
  1   1001 test seat0
 c1989 lightdm  seat0

 2 sessions listed.

 $ loginctl show-session c1
 Id=c1
 Name=lightdm
 Timestamp=Tue 2015-07-07 21:44:41 CEST
 TimestampMonotonic=51125373
 VTNr=1
 Display=:0
 Remote=no
 Service=lightdm-greeter
 Scope=session-c1.scope
 Leader=1346
 Audit=0
 Type=x11
 Class=greeter
 Active=no
 State=closing
 IdleHint=no
 IdleSinceHint=0
 IdleSinceHintMonotonic=0

 $ loginctl show-session 1
 Id=1
 Name=test
 Timestamp=Tue 2015-07-07 21:56:10 CEST
 TimestampMonotonic=739928248
 VTNr=1
 Display=:0
 Remote=no
 Service=lightdm
 Desktop=xfce
 Scope=session-1.scope
 Leader=1983
 Audit=1
 Type=x11
 Class=user
 Active=yes
 State=active
 IdleHint=no
 IdleSinceHint=0
 IdleSinceHintMonotonic=0

 $ rpm -q systemd lightdm lightdm-gtk
 systemd-222-2.fc23.x86_64
 lightdm-1.15.0-2.fc23.x86_64
 lightdm-gtk-2.0.1-2.fc23.x86_64

 It's OK.

Much appreciated, thanks!

I'd still prefer a comment from Robert about the intended behavior.
But that's not release critical.

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

Re: [systemd-devel] [HEADSUP] systemd-222 around the corner

[David Herrmann]

Hi

On Tue, Jul 7, 2015 at 5:10 PM, Michael Biebl mbi...@gmail.com wrote:
 2015-07-06 19:54 GMT+02:00 David Herrmann dh.herrm...@gmail.com:
 Hi

 We intend to release v222 tomorrow. If anyone has open issues that
 need to be in that release, please speak up. Right now, the release
 consists almost exclusively of bug-fixes, and we want to get those
 into distributions.

 Regarding the removal of the udev accelerometer, does anyone know,
 which software was actually using this information?
 I assume switching to iio-sensor-proxy means sourceful changes to
 those programs, i.e. iio-sensor-proxy is not a drop-in replacement?

It was used by iio-sensor-proxy before version 1.0, but then finally
included in iio-sensor-proxy for the 1.0 release. It might have some
weird interactions with g-s-d. Bastien Nocera (CC) should know more.

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

[systemd-devel] [ANNOUNCE] systemd v222

[David Herrmann]

Hi

This is primarily a bugfix release, but we also changed the way we
provide release sources. We no longer build tarballs but instead only
provide git archives. The build-system has been adjusted to make sure
git-archives will be the same as tarballs, apart from the pre-built
autotools scripts. Thus, you're free to continue building tarballs if
you require them. You can find the git-archives over at github:

https://github.com/systemd/systemd/archive/v222.tar.gz

This release includes a wide range of fixes, most notably to fix bugs
in kdbus backwards compatibility handling. Furthermore, we removed old
udev code that is obsolete or moved to another location.

Please also note that we now moved python-systemd into a separated
repository. We will very likely drop it in the next release, which
will be v223. You can find python-systemd over at github:

https://github.com/systemd/python-systemd

CHANGES WITH 222:

* udev does not longer support the WAIT_FOR_SYSFS= key in udev rules.
  There are no known issues with current sysfs, and udev does not need
  or should be used to work around such bugs.

* udev does no longer enable USB HID power management. Several reports
  indicate, that some devices cannot handle that setting.

* The udev accelerometer helper was removed. The functionality
  is now fully included in iio-sensor-proxy. But this means,
  older iio-sensor-proxy versions will no longer provide
  accelerometer/orientation data with this systemd version.
  Please upgrade iio-sensor-proxy to version 1.0.

* networkd gained a new configuration option IPv6PrivacyExtensions=
  which enables IPv6 privacy extensions (RFC 4941, Privacy Extensions
  for Stateless Address) on selected networks.

* For the sake of fewer build-time dependencies and less code in the
  main repository, the python bindings are about to be removed in the
  next release. A new repository has been created which accommodates
  the code from now on, and we kindly ask distributions to create a
  separate package for this. The removal will take place in v223.

https://github.com/systemd/python-systemd

Contributions from: Abdo Roig-Maranges, Andrew Eikum, Bastien Nocera,
Cédric Delmas, Christian Hesse, Christos Trochalakis, Daniel Mack,
daurnimator, David Herrmann, Dimitri John Ledkov, Eric Biggers, Eric
Cook, Felipe Sateler, Geert Jansen, Gerd Hoffmann, Gianpaolo Macario,
Greg Kroah-Hartman, Iago López Galeiras, Jan Alexander Steffens
(heftig), Jan Engelhardt, Jay Strict, Kay Sievers, Lennart Poettering,
Markus Knetschke, Martin Pitt, Michael Biebl, Michael Marineau, Michal
Sekletar, Miguel Bernal Marin, Peter Hutterer, Richard Maw, rinrinne,
Susant Sahani, Thomas Hindoe Paaboel Andersen, Tom Gundersen, Torstein
Husebø, Vedran Miletić, WaLyong Cho, Zbigniew Jędrzejewski-Szmek

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

Re: [systemd-devel] sd 221 regression: login - nonexistent sessions via lightdm

[David Herrmann]

Hi

On Wed, Jul 8, 2015 at 6:09 PM, poma pomidorabelis...@gmail.com wrote:
 On 08.07.2015 16:39, poma wrote:
 On 08.07.2015 13:54, David Herrmann wrote:
 diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
 index 82654ee..91cc67d 100644
 --- a/src/login/logind-dbus.c
 +++ b/src/login/logind-dbus.c
 @@ -699,9 +699,12 @@ static int method_create_session(
   * after the user-session and want the user-session to take
   * over the VT. We need to support this for
   * backwards-compatibility, so make sure we allow new sessions
 - * on a VT that a greeter is running on.
 + * on a VT that a greeter is running on. Furthermore, to allow
 + * re-logins, we have to allow a greeter to take over a used VT for
 + * the exact same reasons.
   */
 -if (vtnr  0 
 +if (class != SESSION_GREETER 

...crap. This obviously needs to be c != SESS... instead of class
!= SESS I really need to listen to compiler warnings.. I'm really
sorry. Corrected patch is appended below.

 +vtnr  0 
  vtnr  m-seat0-position_count 
  m-seat0-positions[vtnr] 
  m-seat0-positions[vtnr]-class != SESSION_GREETER)



 No land in sight
 no seagull in the sky
 no rum on board
 are we gonna die


 Translated from Haiku,
 patch does not change anything.
 :)

 I'll revert all the changes, actually unnecessary for lightdm scheme.
 Thank you for trying to help.

Thanks a lot for testing. I still cannot reproduce this locally. Any
hints on what exactly goes wrong are highly welcome (or maybe weird
log messages etc.).
I'd also help if we knew which patch exactly broke things. The patches
in question are (chron. order):

0204c4bd69f6: login: re-use VT-sessions if they already exist
586cd08e1bbf: logind: allow sessions to share a VT if it's a greeter
b80120c4cba7: logind: fail on CreateSession if already in session

Corrected patch is appended.

Thanks
David

diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
index 82654ee..a3a8b45 100644
--- a/src/login/logind-dbus.c
+++ b/src/login/logind-dbus.c
@@ -699,9 +699,12 @@ static int method_create_session(
  * after the user-session and want the user-session to take
  * over the VT. We need to support this for
  * backwards-compatibility, so make sure we allow new sessions
- * on a VT that a greeter is running on.
+ * on a VT that a greeter is running on. Furthermore, to allow
+ * re-logins, we have to allow a greeter to take over a used VT for
+ * the exact same reasons.
  */
-if (vtnr  0 
+if (c != SESSION_GREETER 
+vtnr  0 
 vtnr  m-seat0-position_count 
 m-seat0-positions[vtnr] 
 m-seat0-positions[vtnr]-class != SESSION_GREETER)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [ANNOUNCE] systemd v225

[David Herrmann]

Hi

Here's the next version of systemd, v225:

https://github.com/systemd/systemd/archive/v225.tar.gz

Many bug-fixes, code cleanups, man-page extensions and some new
additions to networkd and machined.

Also, please don't forget to sign up quickly to systemd.conf 2015, if
you plan to attend. There's only a limited number of tickets
available. For details see:

https://systemd.events/

CHANGES WITH 225:

* machinectl gained a new verb 'shell' which opens a fresh shell on the
  target machine. It is similar to 'login', but spawns the shell
  directly. The pseudo machine '.host' now refers to the local host and
  is used by default. Hence, 'machinectl shell' can be used as
  replacement for 'su' which spawns the session as a fresh systemd
  unit.

* systemd-networkd learned to cope with private-zone DHCP options and
  allows other programs to query the values.

Contributions from: Alastair Hughes, Alex Crawford, Daniel Mack, David
Herrmann, Dimitri John Ledkov, Eric Kostrowski, Evgeny Vereshchagin,
Felipe Sateler, HATAYAMA Daisuke, Jan Pokorný, Jan Synacek, Johnny
Robeson, Karel Zak, Kay Sievers, Kefeng Wang, Lennart Poettering, Major
Hayden, Marcel Holtmann, Markus Elfring, Martin Mikkelsen, Martin Pitt,
Matt Turner, Maxim Mikityanskiy, Michael Biebl, Namhyung Kim, Nicolas
Cornu, Owen W. Taylor, Patrik Flykt, Peter Hutterer, reverendhomer,
Richard Maw, Ronny Chevalier, Seth Jennings, Stef Walter, Susant Sahani,
Thomas Blume, Thomas Hindoe Paaboel Andersen, Thomas Meyer, Tom
Gundersen, Vincent Batts, WaLyong Cho, Zbigniew Jędrzejewski-Szmek

-- Berlin, 2015-08-27
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd-225 around the corner

[David Herrmann]

Hi

On Wed, Aug 26, 2015 at 1:04 AM, Thomas H.P. Andersen pho...@gmail.com wrote:
 On Wed, Aug 26, 2015 at 12:40 AM, David Herrmann dh.herrm...@gmail.com 
 wrote:
 Hi

 Trying to continue with our bi-weekly release schedule, we plan to
 release version 225 tomorrow. Please give it a spin and make sure
 there is no major breakage before the release.

 Hi,

 There is a mem leak triggered when running
 src/libsystemd-network/test-dhcp6-client.c. It would be good to know
 if that is from the test code or from dhcp6. I will probably not have
 time to check it myself before the release though.

Both fixed in git now:
e6b18ffaea7d557eec3028a37c043da67a78550c
a00458421dd4b6fcb9b4cdc433ba0c13970907f1

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

[systemd-devel] [ANNOUNCE] systemd-225 around the corner

[David Herrmann]

Hi

Trying to continue with our bi-weekly release schedule, we plan to
release version 225 tomorrow. Please give it a spin and make sure
there is no major breakage before the release.

Right now, the changes consist of mostly bugfixes and resolved
reworks. I'll commit the full NEWS tomorrow.

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

Re: [systemd-devel] Kdbus - dbus daemon

[David Herrmann]

Hi

On Mon, Aug 31, 2015 at 8:02 AM, arnaud gaboury
 wrote:
> Distro : Arch
> Systemd : 224
> Kdbus AUR package installed (kdbus module is not in default Arch Kernel)
> nspawn container : Fedora 22, systemd 219
>
>
> I want to give a try to kdbus. If I read correctly the kdbus[0] website:
> .
> Am I right to understand I will no more need dbus.service and I can
> disable it for system and users ?

Yes, you can even remove /usr/bin/dbus-daemon.

> Will it change something for the container, as it is running a lower
> version of systemd ?

You can run dbus-daemon in containers and kdbus on the host just fine
(or vice versa). However, if you run kdbus in the container, it must
use systemd-224 (preferably systemd-225).

> Thank you for tips.
>
> [0]http://www.freedesktop.org/wiki/Software/systemd/kdbus/

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

[systemd-devel] [ANNOUNCE] systemd-226 around the corner

[David Herrmann]

Hi

Trying to continue with our bi-weekly release schedule, we plan to
release version 226 (the day after) tomorrow. Please give it a spin
and make sure there is no major breakage before the release.

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

[systemd-devel] [ANNOUNCE] systemd v226

[David Herrmann]

h return the control group path of
  a process or peer of a connected AF_UNIX socket. This
  function call is particularly useful when implementing
  delegated subtrees support in the control group hierarchy.

* The "sd-event" event loop API of libsystemd now supports
  correct dequeuing of real-time signals, without losing
  signal events.

* When systemd requests a PolicyKit decision when managing
  units it will now add additional fields to the request,
  including unit name and desired operation. This enables more
  powerful PolicyKit policies, that make decisions depending
  on these parameters.

* nspawn learnt support for .nspawn settings files, that may
  accompany the image files or directories of containers, and
  may contain additional settings for the container. This is
  an alternative to configuring container parameters via the
  nspawn command line.

Contributions from: Cristian Rodríguez, Daniel Mack, David
Herrmann, Eugene Yakubovich, Evgeny Vereshchagin, Filipe
Brandenburger, Hans de Goede, Jan Alexander Steffens, Jan
Synacek, Kay Sievers, Lennart Poettering, Mangix, Marcel
Holtmann, Martin Pitt, Michael Biebl, Michael Chapman, Michal
Sekletar, Peter Hutterer, Piotr Drąg, reverendhomer, Robin
Hack, Susant Sahani, Sylvain Pasche, Thomas Hindoe Paaboel
Andersen, Tom Gundersen, Torstein Husebø

-- Berlin, 2015-09-08
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Disabled event sources / errors on sd-bus break the event loop (Looping too fast)

[David Herrmann]

Hey

On Thu, Sep 24, 2015 at 1:15 AM, Krzysztof Kotlenga  wrote:
> Krzysztof Kotlenga wrote:
>
>> 2. Maybe I don't get something right - please enlighten me if that's
>> the case - but prioq_put or rather shuffle_up function is buggy.
>>
>> (...)
>>
>> Am I wrong to believe that it should have swapped 2 and 1, not 2 and
>> 0?
>
> OK, I've finally realised that I'm a moron iterating over a heap-like
> structure...

For the archives: Is this fixed with the prioq-compare fix?

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

Re: [systemd-devel] Disabled event sources / errors on sd-bus break the event loop (Looping too fast)

[David Herrmann]

Hi

On Sat, Sep 26, 2015 at 7:56 PM, Krzysztof Kotlenga <k.kotle...@sims.pl> wrote:
> David Herrmann wrote:
>
>> Krzysztof Kotlenga wrote:
>>> Krzysztof Kotlenga wrote:
>>>
>>>> 2. Maybe I don't get something right - please enlighten me if
>>>> that's the case - but prioq_put or rather shuffle_up function is
>>>> buggy.
>>>>
>>>> (...)
>>>>
>>>> Am I wrong to believe that it should have swapped 2 and 1, not 2
>>>> and 0?
>>>
>>> OK, I've finally realised that I'm a moron iterating over a
>>> heap-like structure...
>>
>> For the archives: Is this fixed with the prioq-compare fix?
>
> The point quoted above was bogus, but otherwise yes - the main issue
> here is fixed with the said fix.
>
> Some more or less minor points still stand though:
>
> - errored/disabled bus-inputs are never freed, even after client
>   disconnect (!)

What's a "bus-input"?

> - data pointer comparison instead of index comparison for prioq
>   stability. Is this _really_ correct? Anyway, I made a pull
>   request...

-> https://github.com/systemd/systemd/pull/1393

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

Re: [systemd-devel] xorg uses 100% CPU after upgrading to 226

[David Herrmann]

Hi

On Mon, Sep 28, 2015 at 4:56 AM, Jin Liu  wrote:
[...]
> I tried to start X the usual way - as root, via sddm display manager. It
> works fine. Seems the problem only happens when X is running as normal user.
> Any directions to investigate?

TBH, it sounds like an Xorg problem. Sure, it might be triggered by a
slightly different DBus behavior on the systemd side, but that doesn't
necessarily mean it's a bug in systemd. I have no idea why your
Xserver loops, I don't know the codebase very well.

It looks like your xserver never dispatches the DBus FD, but I cannot
tell you why.

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

[systemd-devel] [ANNOUNCE] systemd-227 around the corner

[David Herrmann]

Hi

Continuing with our triweekly release schedule, we plan to release
version 227 the next few days. There are a couple of bugs pinned on
github, which should get fixed beforehand. Other than that, we should
be good to go. Please give it a spin and make sure there is no major
breakage before the release.

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

Re: [systemd-devel] xorg uses 100% CPU after upgrading to 226

[David Herrmann]

Hi

On Tue, Sep 22, 2015 at 9:23 PM, Jin Liu  wrote:
> After upgrading to 226, the Xorg process keeps using 100% CPU. Also, the
> "xrandr --dpi 168" command in my .xinitrc no longer works.
>
> My startx.service and .xinitrc:
>
> $ systemctl cat startx.service
> # /etc/systemd/system/startx.service
> [Unit]
> Description=Direct X login
> After=systemd-user-sessions.service
> Conflicts=getty@tty1.service
>
> [Service]
> User=jin
> TTYPath=/dev/tty1
> PAMName=login
> Environment=DISPLAY=:0
> ExecStart=/usr/bin/bash --login -c "cd; (/usr/lib/xorg-server/Xorg -nolisten
> tcp vt1 &); source .xinitrc"
>
> [Install]
> WantedBy=graphical.target
> $ cat .xinitrc
> #!/bin/sh
> #
> # ~/.xinitrc
> #
> # Executed by startx (run your window manager from here)
>
> export DESKTOP_SESSION="plasma"
>
> if [ -d /etc/X11/xinit/xinitrc.d ]; then
>  for f in /etc/X11/xinit/xinitrc.d/*; do
>[ -x "$f" ] && . "$f"
>  done
>  unset f
> fi
>
> xrandr --dpi 168
>
> exec /usr/bin/startkde
>
> $
>
> BTW, if I move the "xrandr --dpi 168" line into /usr/bin/startkde, it works
> again (only DPI setting. Xorg still uses 100% CPU).
>
> What change in version 226 could cause the above problem, and how should I
> change the above files to fix it? Thanks.

Please run "strace -p " on the offending process or "perf top".
Then try to figure out which function is spinning.

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

Re: [systemd-devel] systemd-firstboot skip root password initialisation if /etc/shadow is present

[David Herrmann]

Hi

On Tue, Sep 22, 2015 at 11:07 AM, Francis Moreau <francis.m...@gmail.com> wrote:
> Hello,
>
> On Mon, Sep 21, 2015 at 7:45 PM, David Herrmann <dh.herrm...@gmail.com> wrote:
>> Hi
>>
>> On Fri, Sep 18, 2015 at 6:31 PM, Francis Moreau <francis.m...@gmail.com> 
>> wrote:
>>> Hi,
>>>
>>> I find odd that systemd-firstboot skips root password init if
>>> /etc/shadow exists because AFAICS this file is always part of a
>>> minimal rootfs after being setup by an installer. Indeed it's
>>> populated during package installation.
>>>
>>> So I can't see a case where systemd-firstboot would prompt for a root 
>>> password.
>>
>> If an installer ships a shadow file, then we expect the installer to
>> populate it. The firstboot tool will recover situations where you
>> deleted /etc entirely (eg., factory reset).
>
> From the man page " systemd-firstboot initializes the most basic
> system settings interactively on the first boot, or optionally
> non-interactively when a system image is created."
>
> And when a system image is created, usually root password won't be set
> but it's *very* unlikely that /etc/shadow will be missing. That's the
> reason why I don't think its going to work in real life.

Why would an installer create an empty shadow file?

> BTW, I don't know if recovering when /etc/ has been deleted is
> possible even if systemd-firstboot will restore a couple of conf
> files...

Depending on your distribution, it is.

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

Re: [systemd-devel] Implicit unit dependency on slice might be too weak ?

[David Herrmann]

Hi

On Tue, Sep 22, 2015 at 10:58 AM, Francis Moreau <francis.m...@gmail.com> wrote:
> Hello,
>
> On Mon, Sep 21, 2015 at 7:43 PM, David Herrmann <dh.herrm...@gmail.com> wrote:
>> Hi
>>
>> On Mon, Sep 21, 2015 at 4:50 PM, Francis Moreau <francis.m...@gmail.com> 
>> wrote:
>>> Hi,
>>>
>>> If a unit depends on a slice, a Wants=machine.slice is automatically
>>> added to the unit constraints.
>>>
>>> Why is "Requires=machine.slice" not prefered instead ?
>>
>> Usually "Wants=" is preferred as it makes the units more fail-safe.
>> Especially for slices, I cannot see why "Requires=" would be
>> beneficial. If a specific unit needs this, a simple
>> "Requires=foobar.slice" gets you what you want.
>>
>
> But what if the slice fails to start ?
>
> Will the unit asking for a specific slice (which fails to start) be
> moved into another slice ? It seems that whatever the final
> destination used by systemd, the constraints used by the "fallback"
> slice won't be correct, no ?

Correct.

You still get a big fat error on your screen and you should fix your
setup. Again, if that's no suitable, you better use "Requires=".

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

Re: [systemd-devel] systemd-firstboot skip root password initialisation if /etc/shadow is present

[David Herrmann]

Hi

On Tue, Sep 22, 2015 at 11:59 AM, Francis Moreau <francis.m...@gmail.com> wrote:
> On Tue, Sep 22, 2015 at 11:16 AM, David Herrmann <dh.herrm...@gmail.com> 
> wrote:
>> Hi
>>
>> On Tue, Sep 22, 2015 at 11:07 AM, Francis Moreau <francis.m...@gmail.com> 
>> wrote:
>>> Hello,
>>>
>>> On Mon, Sep 21, 2015 at 7:45 PM, David Herrmann <dh.herrm...@gmail.com> 
>>> wrote:
>>>> Hi
>>>>
>>>> On Fri, Sep 18, 2015 at 6:31 PM, Francis Moreau <francis.m...@gmail.com> 
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> I find odd that systemd-firstboot skips root password init if
>>>>> /etc/shadow exists because AFAICS this file is always part of a
>>>>> minimal rootfs after being setup by an installer. Indeed it's
>>>>> populated during package installation.
>>>>>
>>>>> So I can't see a case where systemd-firstboot would prompt for a root 
>>>>> password.
>>>>
>>>> If an installer ships a shadow file, then we expect the installer to
>>>> populate it. The firstboot tool will recover situations where you
>>>> deleted /etc entirely (eg., factory reset).
>>>
>>> From the man page " systemd-firstboot initializes the most basic
>>> system settings interactively on the first boot, or optionally
>>> non-interactively when a system image is created."
>>>
>>> And when a system image is created, usually root password won't be set
>>> but it's *very* unlikely that /etc/shadow will be missing. That's the
>>> reason why I don't think its going to work in real life.
>>
>> Why would an installer create an empty shadow file?
>
> Well during package installation done by the installer, some packages,
> usually the ones that installs daemons/services, populates
> /etc/shadow.
>
> On Archlinux, after creating a minimal rootfs, shadow file is containing:
>
> bin:x:14871::
> daemon:x:14871::
> mail:x:14871::
> ftp:x:14871::
> http:x:14871::
> uuidd:x:14871::
> dbus:x:14871::
> nobody:x:14871::
> systemd-journal-gateway:x:14871::
> systemd-timesync:x:14871::
> systemd-network:x:14871::
> systemd-bus-proxy:x:14871::

Then "fix" the installer? These entries look like no-ops to me. We
assume that if the installer touches /etc, then it can as well prompt
for a root-password. If you want to make use of firstboot, we
recommend to adopt an "empty /etc" installer.

If we support looking for "root" in shadow files and prompt if
non-present, we start supporting legacy setups where /etc is
half-populated. We don't want that. Either go full legacy and make
your installer prompt for everything, or go "empty /etc" and firstboot
will take over.

>>
>>> BTW, I don't know if recovering when /etc/ has been deleted is
>>> possible even if systemd-firstboot will restore a couple of conf
>>> files...
>>
>> Depending on your distribution, it is.
>
> Just out of curiosity, which distros are supposed to support that ?

I can trash /etc on Archlinux and boot it as a container just fine. It
doesn't work as a full system, yet. Not all packages have adopted
empty /etc support.

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

Re: [systemd-devel] systemd-firstboot skip root password initialisation if /etc/shadow is present

[David Herrmann]

Hi

On Tue, Sep 22, 2015 at 2:26 PM, Francis Moreau <francis.m...@gmail.com> wrote:
> On Tue, Sep 22, 2015 at 12:19 PM, David Herrmann <dh.herrm...@gmail.com> 
> wrote:
>> On Tue, Sep 22, 2015 at 11:59 AM, Francis Moreau <francis.m...@gmail.com> 
>> wrote:
> [...]
>>>
>>> Well during package installation done by the installer, some packages,
>>> usually the ones that installs daemons/services, populates
>>> /etc/shadow.
>>>
>>> On Archlinux, after creating a minimal rootfs, shadow file is containing:
>>>
>>> bin:x:14871::
>>> daemon:x:14871::
>>> mail:x:14871::
>>> ftp:x:14871::
>>> http:x:14871::
>>> uuidd:x:14871::
>>> dbus:x:14871::
>>> nobody:x:14871::
>>> systemd-journal-gateway:x:14871::
>>> systemd-timesync:x:14871::
>>> systemd-network:x:14871::
>>> systemd-bus-proxy:x:14871::
>>
>> Then "fix" the installer? These entries look like no-ops to me. We
>> assume that if the installer touches /etc, then it can as well prompt
>> for a root-password. If you want to make use of firstboot, we
>> recommend to adopt an "empty /etc" installer.
>
> That's not about the installer, it's about packages and I suspect that
> very few are ready to run without /etc.

Ok, then fix those packages.

> And then if it's really the case, I think the man page of
> systemd-firstboot should be fixed because it never mentions the words
> "stateless" or "empty", which is quite fundamental in the design of
> firstboot then.
>
>>
>> If we support looking for "root" in shadow files and prompt if
>> non-present, we start supporting legacy setups where /etc is
>> half-populated. We don't want that. Either go full legacy and make
>> your installer prompt for everything, or go "empty /etc" and firstboot
>> will take over.
>>
>
> What you're calling legacy systems are actually *all* systems
> available out there: I don't think there's a actually a lot of
> packages which are prepared to do that.

We fix the packages we care about. I encourage everyone to do the
same. All upstream systemd can do is provide a guideline.

>>>>
>>>>> BTW, I don't know if recovering when /etc/ has been deleted is
>>>>> possible even if systemd-firstboot will restore a couple of conf
>>>>> files...
>>>>
>>>> Depending on your distribution, it is.
>>>
>>> Just out of curiosity, which distros are supposed to support that ?
>>
>> I can trash /etc on Archlinux and boot it as a container just fine. It
>> doesn't work as a full system, yet.
>
> Sure but what's your point ? your container is running no service at
> all, so it's pretty useless.

Why? You can store static configuration in /usr just fine. The point
is to get rid of _runtime_ configuration in /etc that can be modified.
Instead, you should ship vendor configuration via /usr (or
/usr/factory if packages are broken), and make it *read-only*.

>> Not all packages have adopted empty /etc support.
>
> You meant almost none of them ?

No.

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

Re: [systemd-devel] How to turn off some network interface?

[David Herrmann]

Hi

On Sun, Sep 13, 2015 at 1:40 PM, Reindl Harald  wrote:
>
>
> Am 13.09.2015 um 13:28 schrieb Rosen, Rami:
>>
>> What do you mean by stopping networkd, can you elaborate a bit about what
>> you want to achieve?
>>
>> If you want to stop the service, simply run
>> "systemctl stop systemd-networkd".
>>
>> The after that ifconfig command, it won't start.
>>
>> If you want to disable one network interface (let's say eth0),
>> then go to the proper configuration file under
>> /etc/systemd/networkd and comment/disable it, and
>> restart the networkd service by:
>>
>> systemctl restart systemd-networkd
>
>
> well, that's a little unfortune compared to a setup not using
> systemd-networkd where you can *temporary* disable interfaces just with
> "ifdown lan4" without changing a configuration
>
> the point is *temporary*, changing the config means it would be disabled at
> the next boot too, on a machine acting as router/switch temporary disable
> interfaces makes a lot of sense to disconnect a client from the network

Just modify your .network files and restart networkd. It will adapt to
the new configurations at runtime.

Proper runtime-management via networkctl is planned, but no-one
implemented it yet.

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

Re: [systemd-devel] Implicit unit dependency on slice might be too weak ?

[David Herrmann]

Hi

On Mon, Sep 21, 2015 at 4:50 PM, Francis Moreau  wrote:
> Hi,
>
> If a unit depends on a slice, a Wants=machine.slice is automatically
> added to the unit constraints.
>
> Why is "Requires=machine.slice" not prefered instead ?

Usually "Wants=" is preferred as it makes the units more fail-safe.
Especially for slices, I cannot see why "Requires=" would be
beneficial. If a specific unit needs this, a simple
"Requires=foobar.slice" gets you what you want.

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

Re: [systemd-devel] "StopWhenUnneeded"-like option for socket-activated services?

[David Herrmann]

Hi

On Thu, Sep 17, 2015 at 1:02 PM, Laércio de Sousa
 wrote:
> Hi there!
>
> I have a curiosity: is there some way to systemd to detect when all
> connections to a given socket are closed, so that the service assigned to
> that socket unit can be automatically stopped (but the socket unit itself
> keeps listening)? Something similar to StopWhenUnneeded option, which makes
> a service stop automatically when its dependants have stopped.

If your service is socket-activated, you should be able to shutdown
via sd_notify(false, "STOPPING=1") on idle. This way, systemd will
restart your unit on the next incoming connection.

Thanks
David

> My practical example: I'm trying new possibilities with my single-GPU
> multi-seat setup (a bare Xorg server spanning all video outputs, on top of
> which a Xephyr instance is started for each output/seat). My current system
> starts a socket-activated systemd service for the bare Xorg when my LightDM
> starts its first Xephyr instance. I would like to stop the bare Xorg service
> when all Xephyr-based seats are removed (e.g. their master devices are
> unplugged or LightDM service is stopped).
>
> Thanks in advance!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to turn off some network interface?

[David Herrmann]

Hi

On Sun, Sep 13, 2015 at 10:55 AM, Manuel Reimer
 wrote:
> Hello,
>
> it seems to be impossible to just stop networkd (keeps starting itself
> again).
>
> If I use "ifconfig" to turn off one NIC, then networkd immediately restarts
> it.
>
> What do I have to do to gain back control over my network interfaces? I want
> to be able to turn off one interface.

Why do you use networkd at all? Just disable it via `systemctl disable
systemd-networkd`.

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

Re: [systemd-devel] how-to run instantiated units from templates one after the other

[David Herrmann]

Hi

On Fri, Sep 18, 2015 at 8:34 PM, Dmitry Karpov  wrote:
> I have a template for creating the backup:
>
> backup@.service
>
> [Unit]
>
> Description=Instance %i
>
> [Service]
>
> ExecStart=/bin/sh -c "echo do backup job for %i"
>
> [Install]
>
> WantedBy=maintenance.target
>
> and some target:
>
> maintenance.target
>
> [Unit]
>
> Description=target for maintenance
>
> StopWhenUnneeded=yes
>
> As can be seen, instances from backup@ start with maintenance.target. But
> they run in parallel.
>
> There is some way to run them one after the other?
>
> I thought that specifying Conflicts=backup@*.service in the template should
> lead to this, but it is not.

Wildmasks are not supported. Furthermore, your logic would make the
unit conflict with itself, which I doubt is what you want. You should
implement such logic in your own tool instead of pushing it into
unit-files. For instance, if you don't need parallelism, why use
multiple units at all? Just make a single unit iterate over all
devices.

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

Re: [systemd-devel] How to turn off some network interface?

[David Herrmann]

Hi

On Mon, Sep 21, 2015 at 7:52 PM, Reindl Harald <h.rei...@thelounge.net> wrote:
>
> Am 21.09.2015 um 19:39 schrieb David Herrmann:
>>
>> On Sun, Sep 13, 2015 at 10:55 AM, Manuel Reimer
>> <manuel.s...@nurfuerspam.de> wrote:
>>>
>>> Hello,
>>>
>>> it seems to be impossible to just stop networkd (keeps starting itself
>>> again).
>>>
>>> If I use "ifconfig" to turn off one NIC, then networkd immediately
>>> restarts
>>> it.
>>>
>>> What do I have to do to gain back control over my network interfaces? I
>>> want
>>> to be able to turn off one interface.
>>
>>
>> Why do you use networkd at all? Just disable it via `systemctl disable
>> systemd-networkd`
>
>
> in the systemd-world you need to *mask* stuff instead just disable, i had
> networkd also running on machines nobody asked for it and the OP said
> already "keeps starting itself again"

Figure out what's pulling it in and disable it.

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

Re: [systemd-devel] Incorrect use return value of mount_one in mount_setup_early/mount_setup?

[David Herrmann]

Hi

On Tue, Sep 15, 2015 at 3:37 AM, cee1  wrote:
> Hi all,
>
> mount_one will return 1 if a mount action is performed; 0 for no mount
> performed; and <0 for an error occurred. Right?
>
> In mount_setup, we have the following logic:
> """
> for (i = 0; i < ELEMENTSOF(mount_table); i ++) {
> int j;
>
> j = mount_one(mount_table + i, loaded_policy);
>
> if (r == 0)
> r = j;
>
> }
>
> if (r < 0)
> return r;
> """
>
> That means the first non-zero return value determines the return value
> of mount_setup - If a mount is performed successfully in
> mount_one(which set r to 1), an error in next call of mount_one will
> *NOT* be detected(since r == 1). Is this the expected behavior?

Looks wrong, indeed. But note that if one of those mounts fails,
something is seriously wrong (and already logged earlier). It sounds
unlikely this ever happens. Anyway, I wrote a short patch for this:

https://github.com/systemd/systemd/pull/1323

(Please continue discussion on github)

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

Re: [systemd-devel] XSLT error compiling systemd

[David Herrmann]

Hi

On Sat, Dec 12, 2015 at 8:43 AM, Andrew Thompson
 wrote:
> With a new install of Fedora server, I'm having trouble building systemd
> documentation. It's driving me crazy.
>
> I've been able to fix this problem by editing the Makefile by hand, and
> removing the "--no-net" flag from the XSLT build command, but that is less
> than ideal. Has anyone run into this problem? What is the preferred way to
> fix it? Below is the error message I'm getting at the end of the output from
> "make":
>
>
>   XSLT man/bootup.7
> I/O error : Attempt to load network entity
> http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
> warning: failed to load external entity
> "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl;
> compilation error: file ./man/custom-man.xsl line 27 element import
> xsl:import : unable to load
> http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
> Makefile:22089: recipe for target 'man/bootup.7' failed

Do you have the required stylesheets installed? In particular,
docbook-xml and docbook-xsl? It should not load them from external
sources, if they're supplied locally.

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

[systemd-devel] [ANNOUNCE] systemd v228

[David Herrmann]

oiding blocking on AF_UNIX/SOCK_DGRAM sockets since it
  allows substantially larger numbers of queued
  datagrams. This should increase the capability of systemd to
  parallelize boot-up, as logging and sd_notify() are unlikely
  to stall execution anymore. If you need to change the value
  from the new defaults, use the usual sysctl.d/ snippets.

* The compression framing format used by the journal or
  coredump processing has changed to be in line with what the
  official LZ4 tools generate. LZ4 compression support in
  systemd was considered unsupported previously, as the format
  was not compatible with the normal tools. With this release
  this has changed now, and it is hence safe for downstream
  distributions to turn it on. While not compressing as well
  as the XZ, LZ4 is substantially faster, which makes
  it a good default choice for the compression logic in the
  journal and in coredump handling.

* Any reference to /etc/mtab has been dropped from
  systemd. The file has been obsolete since a while, but
  systemd refused to work on systems where it was incorrectly
  set up (it should be a symlink or non-existent). Please make
  sure to update to util-linux 2.27.1 or newer in conjunction
  with this systemd release, which also drops any reference to
  /etc/mtab. If you maintain a distribution make sure that no
  software you package still references it, as this is a
  likely source of bugs. There's also a glibc bug pending,
  asking for removal of any reference to this obsolete file:

  https://sourceware.org/bugzilla/show_bug.cgi?id=19108

* Support for the ".snapshot" unit type has been removed. This
  feature turned out to be little useful and little used, and
  has now been removed from the core and from systemctl.

* The dependency types RequiresOverridable= and
  RequisiteOverridable= have been removed from systemd. They
  have been used only very sparingly to our knowledge and
  other options that provide a similar effect (such as
  systemctl --mode=ignore-dependencies) are much more useful
  and commonly used. Moreover, they were only half-way
  implemented as the option to control behaviour regarding
  these dependencies was never added to systemctl. By removing
  these dependency types the execution engine becomes a bit
  simpler. Unit files that use these dependencies should be
  changed to use the non-Overridable dependency types
  instead. In fact, when parsing unit files with these
  options, that's what systemd will automatically convert them
  too, but it will also warn, asking users to fix the unit
  files accordingly. Removal of these dependency types should
  only affect a negligible number of unit files in the wild.

* Behaviour of networkd's IPForward= option changed
  (again). It will no longer maintain a per-interface setting,
  but propagate one way from interfaces where this is enabled
  to the global kernel setting. The global setting will be
  enabled when requested by a network that is set up, but
  never be disabled again. This change was made to make sure
  IPv4 and IPv6 behaviour regarding packet forwarding is
  similar (as the Linux IPv6 stack does not support
  per-interface control of this setting) and to minimize
  surprises.

* In unit files the behaviour of %u, %U, %h, %s has
  changed. These specifiers will now unconditionally resolve
  to the various user database fields of the user that the
  systemd instance is running as, instead of the user
  configured in the specific unit via User=. Note that this
  effectively doesn't change much, as resolving of these
  specifiers was already turned off in the --system instance
  of systemd, as we cannot do NSS lookups from PID 1. In the
  --user instance of systemd these specifiers where correctly
  resolved, but hardly made any sense, since the user instance
  lacks privileges to do user switches anyway, and User= is
  hence useless. Morever, even in the --user instance of
  systemd behaviour was awkward as it would only take settings
  from User= assignment placed before the specifier into
  account. In order to unify and simplify the logic around
  this the specifiers will now always resolve to the
  credentials of the user invoking the manager (which in case
  of PID 1 is the root user).

Contributions from: Andrew Jones, Beniamino Galvani, Boyuan
Yang, Daniel Machon, Daniel Mack, David Herrmann, David
Rey

Re: [systemd-devel] libudev: subdirectories in sysfs (what does "available" mean?)

[David Herrmann]

Hi

On Tue, Nov 17, 2015 at 11:57 PM, Anne Mulhern <amulh...@redhat.com> wrote:
>> From: "David Herrmann" <dh.herrm...@gmail.com>
>> On Mon, Nov 16, 2015 at 5:35 PM, Anne Mulhern <amulh...@redhat.com> wrote:
>> > libudev has some cooperating procedures that return the keys for a bunch of
>> > sysfs attributes for a given device.
>> >
>> > These attributes all correspond to files that are stored in the sysfs
>> > device directory.
>> >
>> > In the same directory there are sometimes subdirectories, that themselves
>> > contain files
>> > with information about their corresponding attribute. The dm directory is
>> > one obvious
>> > example.
>> >
>> > Are their any plans for libudev to add an ability to get the values from
>> > these subdirectories
>> > as some kind of attributes?
>> >
>> > If no, why?
>>
>> sd_device_get_sysattr_value(device, "foo/bar/baz", );
>>
>> This should work fine (or its udev_device_* equivalent).
>>
>> Btw., I recommend just using readdir(), open(), read(), and write().
>> sysfs is a filesystem, no reason to wrap all those commands.
>
> Thanks, I'm asking this more as the pyudev maintainer than as someone
> who actually wants these values.
>
> The funny thing is, I recently found out that the list obtained by
> udev_device_get_sysattr_list_entry () and friends contains so
> called "available" keys, but when those get passed to
> udev_device_get_sysattr_value () the result might be NULL.
> That makes sense in the sense that they might represent files
> that are unreadable.
>
> Now I find out that I can make up keys not in the results of
> udev_device_get_sysattr_list_entry () and pass those to
> udev_device_get_sysattr_value() and get a non-null result.
>
> So, what does "available" mean? Do these sysattr_list_entry()
> methods give any useful information?

"available" probably means attributes which are direct descendants of
the device. That is, sysattr_list_entry() only lists such direct
descendants, while sysattr_value() allows you to query anything (you
probably can even pass "foo/../../bar/baz").

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

Re: [systemd-devel] vt-less session switching

[David Herrmann]

Hi

On Thu, Nov 19, 2015 at 4:02 PM, SGT. Garcia  wrote:
>
> hello,
>
> in kmscon cdev-session was removed before dvdherm stopped working on it in
> favour of libuvt and systemd-logind; so reads the commit logs.
>
> i wonder if anyone here has managed to run X (or any other graphic server)
> on top of kmscon on a system where kernel is configured with 'CONFIG_VT=n'?

There is probably no-one testing it, but gdm+wayland+gnome should work
without VTs, but some tweaking may be required.

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

Re: [systemd-devel] libudev: subdirectories in sysfs (what does "available" mean?)

[David Herrmann]

Hi

On Tue, Nov 24, 2015 at 3:54 PM, Anne Mulhern <amulh...@redhat.com> wrote:
>> From: "David Herrmann" <dh.herrm...@gmail.com>
>> On Tue, Nov 17, 2015 at 11:57 PM, Anne Mulhern <amulh...@redhat.com> wrote:
>> >> From: "David Herrmann" <dh.herrm...@gmail.com>
>> >> On Mon, Nov 16, 2015 at 5:35 PM, Anne Mulhern <amulh...@redhat.com> wrote:
>> >> > libudev has some cooperating procedures that return the keys for a bunch
>> >> > of
>> >> > sysfs attributes for a given device.
>> >> >
>> >> > These attributes all correspond to files that are stored in the sysfs
>> >> > device directory.
>> >> >
>> >> > In the same directory there are sometimes subdirectories, that
>> >> > themselves
>> >> > contain files
>> >> > with information about their corresponding attribute. The dm directory
>> >> > is
>> >> > one obvious
>> >> > example.
>> >> >
>> >> > Are their any plans for libudev to add an ability to get the values from
>> >> > these subdirectories
>> >> > as some kind of attributes?
>> >> >
>> >> > If no, why?
>> >>
>> >> sd_device_get_sysattr_value(device, "foo/bar/baz", );
>> >>
>> >> This should work fine (or its udev_device_* equivalent).
>> >>
>> >> Btw., I recommend just using readdir(), open(), read(), and write().
>> >> sysfs is a filesystem, no reason to wrap all those commands.
>> >
>> > Thanks, I'm asking this more as the pyudev maintainer than as someone
>> > who actually wants these values.
>> >
>> > The funny thing is, I recently found out that the list obtained by
>> > udev_device_get_sysattr_list_entry () and friends contains so
>> > called "available" keys, but when those get passed to
>> > udev_device_get_sysattr_value () the result might be NULL.
>> > That makes sense in the sense that they might represent files
>> > that are unreadable.
>> >
>> > Now I find out that I can make up keys not in the results of
>> > udev_device_get_sysattr_list_entry () and pass those to
>> > udev_device_get_sysattr_value() and get a non-null result.
>> >
>> > So, what does "available" mean? Do these sysattr_list_entry()
>> > methods give any useful information?
>>
>> "available" probably means attributes which are direct descendants of
>> the device. That is, sysattr_list_entry() only lists such direct
>> descendants, while sysattr_value() allows you to query anything (you
>> probably can even pass "foo/../../bar/baz").
>>
>> Thanks
>> David
>>
>
> I think it's yet more complicated than that. For example,
> 'dm' (for device mapper) is not in the list of available
> attributes, but 'dm/name' is certainly an attribute that
> can be read by sysattr_value().

'dm' is not an attribute, so it will never be listed as available
attribute. Directories are never treated as attributes.

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

Re: [systemd-devel] libudev: subdirectories in sysfs (what does "available" mean?)

[David Herrmann]

Hi

On Tue, Nov 24, 2015 at 4:37 PM, Anne Mulhern <amulh...@redhat.com> wrote:
>> From: "David Herrmann" <dh.herrm...@gmail.com>
>> On Tue, Nov 24, 2015 at 3:54 PM, Anne Mulhern <amulh...@redhat.com> wrote:
>> >> From: "David Herrmann" <dh.herrm...@gmail.com>
>> >> On Tue, Nov 17, 2015 at 11:57 PM, Anne Mulhern <amulh...@redhat.com>
>> >> wrote:
>> >> >> From: "David Herrmann" <dh.herrm...@gmail.com>
>> >> >> On Mon, Nov 16, 2015 at 5:35 PM, Anne Mulhern <amulh...@redhat.com>
>> >> >> wrote:
>> >> >> > libudev has some cooperating procedures that return the keys for a
>> >> >> > bunch
>> >> >> > of
>> >> >> > sysfs attributes for a given device.
>> >> >> >
>> >> >> > These attributes all correspond to files that are stored in the sysfs
>> >> >> > device directory.
>> >> >> >
>> >> >> > In the same directory there are sometimes subdirectories, that
>> >> >> > themselves
>> >> >> > contain files
>> >> >> > with information about their corresponding attribute. The dm
>> >> >> > directory
>> >> >> > is
>> >> >> > one obvious
>> >> >> > example.
>> >> >> >
>> >> >> > Are their any plans for libudev to add an ability to get the values
>> >> >> > from
>> >> >> > these subdirectories
>> >> >> > as some kind of attributes?
>> >> >> >
>> >> >> > If no, why?
>> >> >>
>> >> >> sd_device_get_sysattr_value(device, "foo/bar/baz", );
>> >> >>
>> >> >> This should work fine (or its udev_device_* equivalent).
>> >> >>
>> >> >> Btw., I recommend just using readdir(), open(), read(), and write().
>> >> >> sysfs is a filesystem, no reason to wrap all those commands.
>> >> >
>> >> > Thanks, I'm asking this more as the pyudev maintainer than as someone
>> >> > who actually wants these values.
>> >> >
>> >> > The funny thing is, I recently found out that the list obtained by
>> >> > udev_device_get_sysattr_list_entry () and friends contains so
>> >> > called "available" keys, but when those get passed to
>> >> > udev_device_get_sysattr_value () the result might be NULL.
>> >> > That makes sense in the sense that they might represent files
>> >> > that are unreadable.
>> >> >
>> >> > Now I find out that I can make up keys not in the results of
>> >> > udev_device_get_sysattr_list_entry () and pass those to
>> >> > udev_device_get_sysattr_value() and get a non-null result.
>> >> >
>> >> > So, what does "available" mean? Do these sysattr_list_entry()
>> >> > methods give any useful information?
>> >>
>> >> "available" probably means attributes which are direct descendants of
>> >> the device. That is, sysattr_list_entry() only lists such direct
>> >> descendants, while sysattr_value() allows you to query anything (you
>> >> probably can even pass "foo/../../bar/baz").
>> >>
>> >> Thanks
>> >> David
>> >>
>> >
>> > I think it's yet more complicated than that. For example,
>> > 'dm' (for device mapper) is not in the list of available
>> > attributes, but 'dm/name' is certainly an attribute that
>> > can be read by sysattr_value().
>>
>> 'dm' is not an attribute, so it will never be listed as available
>> attribute. Directories are never treated as attributes.
>>
>> Thanks
>> David
>>
>
> But "bdi" is listed as an attribute, and is a directory.

Weird. Tom, any comments?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Is it possible to dynamically remove the "uaccess" tag?

[David Herrmann]

Hey

On Mon, Feb 15, 2016 at 2:26 PM, Lennart Poettering
 wrote:
> On Sun, 14.02.16 19:18, Manuel Reimer (manuel.s...@nurfuerspam.de) wrote:
>
>> Hello,
>>
>> I want to create a daemon which translates inputs, given by an game
>> controller (/dev/input/eventX). The default is, that the tag "uaccess" is
>> set there.
>>
>> As soon as my daemon runs, I don't want to use the original input device.
>> Other applications should not connect to the original device but to my
>> translated uinput device.
>>
>> Currently, the only way to do this seems to be to delete the device nodes,
>> which seems to be a bit harsh to me.
>>
>> Can someone suggest an alternative way to get rid of what uaccess does as
>> long as my daemon is running and handling the device? As far as I can see
>> there is no way to remove tags with libudev. It also seems to be impossible
>> to set an ACL rule to deny access for everyone. Any other suggestions?
>
> There isn't any concept of ownership in udev, and I am pretty sure
> there shouln't be.
>
> input does know one however, in EVIOCGRAB.

..but you shouldn't use it. It is deprecated and it took us years to
get rid of it in the whole graphics stack.

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

Re: [systemd-devel] [PATCH] hostnamed: regard convertible chassis type as laptop

[David Herrmann]

Hey Jani!

On Fri, Feb 24, 2017 at 4:16 PM, Jani Nikula  wrote:
> On Fri, 24 Feb 2017, Jani Nikula  wrote:
>> While both the DMI and ACPI data are regarded as unreliable in hostnamed
>> source, consumers of the chassis type use it to make rather drastic
>> policy decisions.
>
> BTW, since the implementation seems to think the data is unreliable,
> perhaps it would be prudent to say so in hostnamectl documentation, so
> the consumers of the data might be more thoughtful about what to use it
> for?

Turned into a github PR [1]. Can we continue the discussion there?

Thanks
David

[1] https://github.com/systemd/systemd/pull/5475
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Confusing hwdb matching behaviour

[David Herrmann]

Hey!

On Wed, Aug 31, 2016 at 6:37 AM, Peter Hutterer
 wrote:
> The hwdb behaviour is a bit hard to predict when multiple matches with globs
> apply to a device so I'm wondering whether this is just an implementation
> result or intended behaviour.
>
> Example 1:
> $> cat 99-test.hwdb
> test:*
>  match=generic
>
> test:specific*
>  match=specific
>
> $> systemd-hwdb  query "test:specific_match"
> match=specific
>
> This is what I would expect from the hwdb entries. But if we have a rule where
> glob matches before specific, the generic one overwrites the specific one:
>
> Example 2:
> $> cat 99-test.hwdb
> test:*
>  match=generic
>
> test:*specific*
>  match=specific
>  match2=yep
>
> $> systemd-hwdb  query "test:specific_match"
> match=generic
> match2=yep
>
> Definitely not what I expected (note: the order of the entries
> doesn't matter). This is actually a problem for libinput because it means we
> can't overwrite generic matches with specific matches.
> But it gets even weirder once we start stacking more:
>
> Example 3:
> $> cat 99-test.hwdb
> test:*
>  match=generic
>
> test:*specific*
>  match=specific
>  match2=yep
>
> test:*specific_match
>  match=specific
>  match2=nope
>  match3=yep
>
> $> sudo systemd-hwdb  query "test:specific_match"
> match=generic
> match2=nope
> match3=yep
>
> It picks the most generic one last but the more specific one over the less
> specific one. This is confusing and hard to predict. But it gets worse:
>
> Example 4:
> $> cat 99-test.hwdb
> test:*
>  match=generic
>
> test:*specific*
>  match=specific
>  match2=yep
>
> test:*spe*match
>  match=specific
>  match2=nope
>  match3=yep
>
> test:*specific*match
>  match=specific
>  match2=oh
>  match3=what
>  match4=confused
>
> $> sudo systemd-hwdb  query "test:specific_match"
> match=generic
> match2=yep
> match3=what
> match4=confused
>
> And now I'm lost :)
> As a homework, try predicting what this one produces:
>
> Exercise:
> test:*
>  MATCH=generic
>
> # changing this to test:specific gives different results
> test:*specific*
>  MATCH=specific
>  MATCH2=yep
>
> test:*spe*match
>  MATCH=specific
>  MATCH2=nope
>  MATCH3=yep
>
> test:*specific_*
>  MATCH=specific
>  MATCH2=oh
>  MATCH3=crap
>  MATCH4=what?
>
> test:*specific*match
>  MATCH=specific
>  MATCH2=doh
>  MATCH3=what
>  MATCH4=confused
>  MATCH5=boo
>
>
> Solution:
> "generic, oh, crap, what?, boo" with the glob, without the glob it's
> "specific, yep, crap, what?, boo"
>
> So the question is: is this the intended behaviour (if so, we should
> document it and make it official) or is this a side-effect. If that, can we
> change it or is it set in stone? I think no-one but me is currently eagerly
> stacking hwdb snippets, so maybe there's room to move.

The matching order always matches children before a node itself, and
children in alphabetical order (ASCII). The trie is built based on
prefix-matches. So parsing order does not matter. Lets look at your
last example (with both possible scenarios):

test:*
test:specific
test:*specific*
test:*spe*match
test:*specific_*
test:*specific*match

This will be searched in this order:

test:*spe*match
test:*specific*match
test:*specific*
test:*specific_*
test:*
test:specific

(Ascii order: '*' < UPPER-CASE < '_' < LOWER-CASE)
(Later matches override properties of earlier matches)

I'm not saying this is a useful order, I'm just describing what the
code currently does.

> As for expected behaviour, I'd intuitively expect a more sequential matching,
> with an entry in 99-test.hwd overwriting whatever entry was in 10-test.hwdb.

If things are not stored in ASCII order, you break bsearch() and
lookup performance would drop.

A much easier solution would be to use multiple virtual tries: Prefix
your generic matches with "test-generic:*foobar*" and your specific
ones with "test-specific:*foobar*" and then always lookup both. This
obviously only works if the number of levels is static.

As a hack, I think you can use "**", "***", ... to change the ordering
to your needs.

We could also say each hwdb-source gets its own virtual trie and
they're searched in alphabetical order. This would break ABI, but
would make it a lot more powerful.

Not sure. Maybe Kay has some comments?
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] bus1, dbus(-daemon) and systemd

[David Herrmann]

Hey

On Sat, Oct 1, 2016 at 1:30 PM, Michael Biebl  wrote:
> Hi,
>
> I've been watching the bus1 presentation from this years systemd.conf
> (thanks a lot for the video team btw for doing a stellar job).
>
> What didn't become clear to me i, how bus1, dbus(-daemon) and systemd
> are supposed to fit together in the future.
>
> If I understood David correctly, bus1 is not meant as a drop-in
> replacement for dbus-daemon, but rather provide some simpler, lower
> level communication primitives.

Yes!

> In an earlier talk by Lennart, he mentioned that systemd will
> (re)implement dbus-daemon.
> Would this reimplmentation be based on bus1 or be a completely
> separate re-implementation *not* using bus1?

The idea of re-implementing dbus-daemon with sd-bus (in systemd) is
much older than bus1. I don't think we ever discussed it with bus1 in
mind.

> Such a hypothetical dbus-daemon replacement based on bus1, how would
> this look like and what would systemd's role be there?
>
> I would guess you already thought about that and you already have
> plans in that regard.
> Would be great if you can share them with us.

There are many issues with dbus-daemon. Some can be solved with a
simple re-implementation and fixing the known issues, others cannot.
The bus1 transport does not magically solve them, either. However, we
do have ideas how to make use of bus1 capabilities to allow direct
channels between peers, without breaking with dbus semantics.
Furthermore, we have discussed subscription-models over match-rules
that would even allow to do broadcasts/multicasts without requiring a
broker.

We are currently doing a reevaluation of our ideas and writing them
up. The intention is to get a dbus-daemon drop-in extended with
optional bus1 features.

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

Re: [systemd-devel] How to unset "uaccess" tag in udev rule?

[David Herrmann]

Hi

On Sun, Mar 26, 2017 at 8:07 PM, Manuel Reimer
<manuel.s...@nurfuerspam.de> wrote:
> On 03/25/2017 05:16 PM, David Herrmann wrote:
>>>>
>>>> So far I did this by creating an empty file with the same name in
>>>> /etc/udev/rules.d which works well, but for no reason the name was
>>>> changed some time ago which overrides my empty file and reactivates
>>>> the problematic rule.
>>>
>>> That's the only way. Tags cannot be unset.
>>
>>
>> Use TAG-="foobar".
>
>
> I've tried that and it doesn't work.

The `-=' operator was introduced for exactly this use-case (which the
commit I quoted should explain). If it does not work, it has to be
fixed. Last time I checked, it worked.

Hence, if you need help using it, please give us as much information
as possible. Please verify the operator works with something that is
not already used (set some random TAG and remove it again, check with
`udevadm` whether it works).

If you have no clue how to debug it yourself, please specify _what_
you changed, what systemd version / distro / etc., you're running, so
we can reproduce it and help you further.

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

Re: [systemd-devel] How to unset "uaccess" tag in udev rule?

[David Herrmann]

Hi

On Tue, Mar 14, 2017 at 10:44 PM, Zbigniew Jędrzejewski-Szmek
<zbys...@in.waw.pl> wrote:
> On Sun, Mar 12, 2017 at 07:38:13PM +0100, Manuel Reimer wrote:
>> Hello,
>>
>> my distributor sets the following rule in /usr/lib/udev/rules.d:
>>
>> KERNEL=="uinput", SUBSYSTEM=="misc", OPTIONS+="static_node=uinput",
>> TAG+="uaccess"
>>
>> I think this is not a good idea and that there is a good reason why
>> users can't create uinput devices, so I want to get rid of that
>> rule.
>>
>> So far I did this by creating an empty file with the same name in
>> /etc/udev/rules.d which works well, but for no reason the name was
>> changed some time ago which overrides my empty file and reactivates
>> the problematic rule.
> That's the only way. Tags cannot be unset.

Use TAG-="foobar".

Thanks
David


commit 8e3ba3772cadf6a8292b0da533062dd4d377af67
Author: David Herrmann <dh.herrm...@gmail.com>
Date:   Thu Sep 11 13:25:21 2014 +0200

udev: allow removing tags via TAG-="foobar"

This extends the udev parser to support OP_REMOVE (-=) and adds support
for TAG-= to remove previously set tags. We don't fail if the tag didn't
exist.

This is pretty handy if we ship default rules for seat-assignments and
users want to exclude specific devices from that. They can easily add
rules that drop any automatically added "seat" tags again.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Herrmann]

Hi

On Fri, Apr 21, 2017 at 11:50 AM, David Härdeman <da...@hardeman.nu> wrote:
> On Thu, Apr 20, 2017 at 02:19:22PM +0200, David Herrmann wrote:
>>On Thu, Apr 20, 2017 at 12:06 PM, David Härdeman <da...@hardeman.nu> wrote:
>>> Hi,
>>>
>>> I'm implementing a server which creates an ObjectManager using the
>>> sd-bus API and there seems to be some differences between how gdbus and
>>> sd-bus implements the API.
>>>
>>> I implemented a simple ObjectManager at /org/gnome/TestManager which
>>> exports objects /org/gnome/TestManager/fooX with interface
>>> org.gnome.TestManager.Device.
>>>
>>> Under sd-bus, if an object is removed, the following signal is
>>> generated:
>>>
>>> signal time=1492642227.714223 sender=:1.104 -> destination=(null 
>>> destination)
>>> serial=90 path=/org/gnome/TestManager;
>>> interface=org.freedesktop.DBus.ObjectManager;
>>> member=InterfacesRemoved
>>>object path "/org/gnome/TestManager/foo0"
>>>array [
>>>   string "org.freedesktop.DBus.Peer"
>>>   string "org.freedesktop.DBus.Introspectable"
>>>   string "org.freedesktop.DBus.Properties"
>>>   string "org.freedesktop.DBus.ObjectManager"
>>>   string "org.gnome.TestManager.Device"
>>>]
>>>
>>> If I implement the same simple server in gdbus, the signal is instead:
>>>
>>> signal time=1492642227.714223 sender=:1.104 -> destination=(null 
>>> destination)
>>> serial=90 path=/org/gnome/TestManager;
>>> interface=org.freedesktop.DBus.ObjectManager;
>>> member=InterfacesRemoved
>>>object path "/org/gnome/TestManager/foo0"
>>>array [
>>>   string "org.gnome.TestManager.Device"
>>>]
>>>
>>> The corresponding signals are also generated when an object is added.
>>>
>>> Beside simply being different, this difference seems to confuse gdbus.
>>> If I create a test client, it will report that any object which is
>>> already existing when I start the client has 1 interface and any object
>>> which is added/removed subsequently is reported as having 5 interfaces,
>>> 4 of which are nameless (this would appear to be one or more gdbus
>>> bug(s)).
>>>
>>> This bug in gdbus also means that it doesn't correctly catch the removal
>>> of an object which existed at the time the client was started (because
>>> of the interface count mismatch).
>>>
>>> Anyway, gdbus bugs aside, it seems that the interfaces reported by
>>> sd-bus should match what gdbus does? (assuming, of course, that gdbus
>>> can be considered the "reference" implementation).
>>
>>Does the appended patch fix your issue?
>>(line-breaks might be screwed, sorry)
>
> Haven't tried it yet, but just from reading the patch...it seems to do
> the opposite of what I'd expect? I.e. add *more* interfaces?

This change makes sure all objects have the built-in interfaces
reported at all times. The GetManagedObjects() call didn't report them
so far.

Note that we really better report all interfaces an object supports. I
don't know why glib does not do this, but I think it should.

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

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Herrmann]

Hey

On Thu, Apr 20, 2017 at 12:06 PM, David Härdeman  wrote:
> Hi,
>
> I'm implementing a server which creates an ObjectManager using the
> sd-bus API and there seems to be some differences between how gdbus and
> sd-bus implements the API.
>
> I implemented a simple ObjectManager at /org/gnome/TestManager which
> exports objects /org/gnome/TestManager/fooX with interface
> org.gnome.TestManager.Device.
>
> Under sd-bus, if an object is removed, the following signal is
> generated:
>
> signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
> serial=90 path=/org/gnome/TestManager;
> interface=org.freedesktop.DBus.ObjectManager;
> member=InterfacesRemoved
>object path "/org/gnome/TestManager/foo0"
>array [
>   string "org.freedesktop.DBus.Peer"
>   string "org.freedesktop.DBus.Introspectable"
>   string "org.freedesktop.DBus.Properties"
>   string "org.freedesktop.DBus.ObjectManager"
>   string "org.gnome.TestManager.Device"
>]
>
> If I implement the same simple server in gdbus, the signal is instead:
>
> signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
> serial=90 path=/org/gnome/TestManager;
> interface=org.freedesktop.DBus.ObjectManager;
> member=InterfacesRemoved
>object path "/org/gnome/TestManager/foo0"
>array [
>   string "org.gnome.TestManager.Device"
>]
>
> The corresponding signals are also generated when an object is added.
>
> Beside simply being different, this difference seems to confuse gdbus.
> If I create a test client, it will report that any object which is
> already existing when I start the client has 1 interface and any object
> which is added/removed subsequently is reported as having 5 interfaces,
> 4 of which are nameless (this would appear to be one or more gdbus
> bug(s)).
>
> This bug in gdbus also means that it doesn't correctly catch the removal
> of an object which existed at the time the client was started (because
> of the interface count mismatch).
>
> Anyway, gdbus bugs aside, it seems that the interfaces reported by
> sd-bus should match what gdbus does? (assuming, of course, that gdbus
> can be considered the "reference" implementation).

Does the appended patch fix your issue?
(line-breaks might be screwed, sorry)

Thanks
David


diff --git a/src/libsystemd/sd-bus/bus-objects.c
b/src/libsystemd/sd-bus/bus-objects.c
index 9bd07ffca..b6f5afe1b 100644
--- a/src/libsystemd/sd-bus/bus-objects.c
+++ b/src/libsystemd/sd-bus/bus-objects.c
@@ -1057,6 +1057,22 @@ static int object_manager_serialize_path(
 if (r < 0)
 return r;

+r = sd_bus_message_append(reply, "{sa{sv}}",
"org.freedesktop.DBus.Peer", 0);
+if (r < 0)
+return r;
+
+r = sd_bus_message_append(reply, "{sa{sv}}",
"org.freedesktop.DBus.Introspectable", 0);
+if (r < 0)
+return r;
+
+r = sd_bus_message_append(reply, "{sa{sv}}",
"org.freedesktop.DBus.Properties", 0);
+if (r < 0)
+return r;
+
+r = sd_bus_message_append(reply, "{sa{sv}}",
"org.freedesktop.DBus.ObjectManager", 0);
+if (r < 0)
+return r;
+
 found_something = true;
 }
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Herrmann]

Hi

On Tue, Apr 25, 2017 at 9:40 AM, David Härdeman <da...@hardeman.nu> wrote:
> April 21, 2017 1:22 PM, "David Herrmann" <dh.herrm...@gmail.com> wrote:
>> On Fri, Apr 21, 2017 at 11:50 AM, David Härdeman <da...@hardeman.nu> wrote:
>>> On Thu, Apr 20, 2017 at 02:19:22PM +0200, David Herrmann wrote:
>>>> On Thu, Apr 20, 2017 at 12:06 PM, David Härdeman <da...@hardeman.nu> wrote:
>>> I'm implementing a server which creates an ObjectManager using the
>>> sd-bus API and there seems to be some differences between how gdbus and
>>> sd-bus implements the API.
>>>
>>> I implemented a simple ObjectManager at /org/gnome/TestManager which
>>> exports objects /org/gnome/TestManager/fooX with interface
>>> org.gnome.TestManager.Device.
>>>
>>> Under sd-bus, if an object is removed, the following signal is
>>> generated:
>>>
>>> signal time=1492642227.714223 sender=:1.104 -> destination=(null 
>>> destination)
>>> serial=90 path=/org/gnome/TestManager;
>>> interface=org.freedesktop.DBus.ObjectManager;
>>> member=InterfacesRemoved
>>> object path "/org/gnome/TestManager/foo0"
>>> array [
>>> string "org.freedesktop.DBus.Peer"
>>> string "org.freedesktop.DBus.Introspectable"
>>> string "org.freedesktop.DBus.Properties"
>>> string "org.freedesktop.DBus.ObjectManager"
>>> string "org.gnome.TestManager.Device"
>>> ]
>>>
>>> If I implement the same simple server in gdbus, the signal is instead:
>>>
>>> signal time=1492642227.714223 sender=:1.104 -> destination=(null 
>>> destination)
>>> serial=90 path=/org/gnome/TestManager;
>>> interface=org.freedesktop.DBus.ObjectManager;
>>> member=InterfacesRemoved
>>> object path "/org/gnome/TestManager/foo0"
>>> array [
>>> string "org.gnome.TestManager.Device"
>>> ]
>>>
>>> The corresponding signals are also generated when an object is added.
> 
>>>> Does the appended patch fix your issue?
>>>> (line-breaks might be screwed, sorry)
>>>
>>> Haven't tried it yet, but just from reading the patch...it seems to do
>>> the opposite of what I'd expect? I.e. add *more* interfaces?
>>
>> This change makes sure all objects have the built-in interfaces
>> reported at all times. The GetManagedObjects() call didn't report them
>> so far.
>
> Quite the contrary? If you look at the output from dbus-monitor above, you'll 
> see that it is sd-bus that already *does* report all interfaces while gdbus 
> doesnt?

No, it does not. sd-bus was inconsistent. See, there are 3 things
involved in the Object-Manager:

Signal: InterfacesAdded
Signal: InterfacesRemoved
Call: GetManagedObjects

The first two signals are used to add and remove objects (and their
respective interfaces) at runtime. The GetManagedObjects() call is
used to bootstrap, that is, to get the initial set of objects (and
their respective interfaces) when starting your application.

So far, sd-bus reported the builtin interfaces correctly via the
signals, but did not return that information in the
GetManagedObjects() call. My patch fixed this omission.
The effect of this is that objects added/removed at runtime work fine,
but if an object was there already when your application starts, then
it will never be removed, since gdbus will see an interface-count
mismatch (as you observed above).

Hence, the patch I provided fixes how sd-bus provides this
information. It does *not* change any policy.

I think the 2 underlying problems you saw are bugs in both gdbus and
sd-bus. The one in sd-bus I tried to fix above, the one in gdbus is
only about counting interfaces and properly detecting negative
interface-counts. The gdbus bug is non-severe, though, since it
originates in a buggy remote client. So there is no hard reason to
change gdbus there.

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

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Herrmann]

Hey

On Tue, Apr 25, 2017 at 10:05 AM, Lennart Poettering
<lenn...@poettering.net> wrote:
> On Tue, 25.04.17 09:54, David Herrmann (dh.herrm...@gmail.com) wrote:
>
>> >> This change makes sure all objects have the built-in interfaces
>> >> reported at all times. The GetManagedObjects() call didn't report them
>> >> so far.
>> >
>> > Quite the contrary? If you look at the output from dbus-monitor above, 
>> > you'll see that it is sd-bus that already *does* report all interfaces 
>> > while gdbus doesnt?
>>
>> No, it does not. sd-bus was inconsistent. See, there are 3 things
>> involved in the Object-Manager:
>>
>> Signal: InterfacesAdded
>> Signal: InterfacesRemoved
>> Call: GetManagedObjects
>>
>> The first two signals are used to add and remove objects (and their
>> respective interfaces) at runtime. The GetManagedObjects() call is
>> used to bootstrap, that is, to get the initial set of objects (and
>> their respective interfaces) when starting your application.
>>
>> So far, sd-bus reported the builtin interfaces correctly via the
>> signals, but did not return that information in the
>> GetManagedObjects() call. My patch fixed this omission.
>> The effect of this is that objects added/removed at runtime work fine,
>> but if an object was there already when your application starts, then
>> it will never be removed, since gdbus will see an interface-count
>> mismatch (as you observed above).
>>
>> Hence, the patch I provided fixes how sd-bus provides this
>> information. It does *not* change any policy.
>>
>> I think the 2 underlying problems you saw are bugs in both gdbus and
>> sd-bus. The one in sd-bus I tried to fix above, the one in gdbus is
>> only about counting interfaces and properly detecting negative
>> interface-counts. The gdbus bug is non-severe, though, since it
>> originates in a buggy remote client. So there is no hard reason to
>> change gdbus there.
>
> Could you please send the sd-bus side fix as PR?

Now pending as #5799.

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

[systemd-devel] [ANNOUNCE] D-Bus Broker Project

[David Herrmann]

This is the first public release of dbus-broker.

Git Tag: v3
Archive: 
https://github.com/bus1/dbus-broker/archive/v3/dbus-broker-v3.tar.gz

The dbus-broker project is an implementation of a message bus as
defined by the D-Bus specification. Its aim is to provide high
performance and reliability, while keeping compatibility to the D-Bus
reference implementation. It is exclusively written for linux systems,
and makes use of many modern features provided by recent linux kernel
releases. Details are discussed in its introductory blog post:

https://dvdhrm.github.io/rethinking-the-dbus-message-bus/

The project is still experimental and not meant for production use,
yet. Packages are available for Fedora and Arch Linux. Other
distributions will follow.

DETAILS:
https://github.com/bus1/dbus-broker/wiki

BUG REPORTS:
https://github.com/bus1/dbus-broker/issues

GIT:
g...@github.com:bus1/dbus-broker.git
https://github.com/bus1/dbus-broker.git

PACKAGES:
https://copr.fedorainfracloud.org/coprs/g/bus1/dbus/package/dbus-broker/
https://aur.archlinux.org/packages/dbus-broker
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel