date:20150411

On Fri, Apr 10, 2015 at 03:17:37PM +0300, Tomasz Bursztyka wrote:
 Hi,
 
 As it has been discussed in the systemd hackfest during the Linux Conference
 Europe, one daemon could centralize the management of all network proxy
 configurations. Idea is something user can do per-application (like in
 firefox for instance) or broader (per-DM like in Gnome), user could do it
 once and for all through such daemon and applications would then request it
 to know whether or not a proxy has to be used and which one.
 
 As a notice, this is nothing new. Such standalone daemon has been already
 done by the past, pacrunner. systemd-proxy-discoveryd will more or less
 implement the same ideas with improvements. It will get rid of big JS
 engines like spidermonkey or v8 which are overkill for the tiny PAC files
 to be executed on, for instance. From pacrunner experience, APIs will be
 also improved.
Hi,

the idea of having centralized proxy config is certainly nice. But the
PAC files make me shiver. So the first question: is it really necessary
to support PAC files? Are they widely used in corporate setting or something?
Is there no saner standard?

If the PAC files must be interpreted, I think this is the hardest
part.  FindProxyForURL is started for every request, potentially
hundreds of times per second and more. This means that starting a
process per invocation is out of the question, and even starting a
thread per invocation seems to be too much. But each call fall into an
infinite loop and hang. So the run time of FindProxyForURL should be
bounded. FindProxyForURL can also resolve names over the network,
which would best be done asynchronously.

Things in systemd are usually implemented through poll loops, which
makes it easy to support thousands of concurrent jobs. I'd think
that this would be the best option here too, with a number of workers
executing FindProxyForURL()s and stopping when name resolution is
requested and continuing when the name is resolved.

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

Re: [systemd-devel] [RFC 1/6] proxy-discoveryd: Basic core added

On Fri, Apr 10, 2015 at 03:17:38PM +0300, Tomasz Bursztyka wrote:
 +# This file is part of systemd.
 +#
 +# systemd is free software; you can redistribute it and/or modify it
 +# under the terms of the GNU Lesser General Public License as published by
 +# the Free Software Foundation; either version 2.1 of the License, or
 +# (at your option) any later version.
 +
 +[Unit]
 +Description=Proxy service
 +DefaultDependencies=no
 +Requires=dbus.socket
 +After=dbus.socket
 +Before=remote-fs.target
 +
 +[Service]
 +Restart=on-failure
 +ExecStart=@rootlibexecdir@/systemd-proxy-discoveryd
 +StandardOutput=null
What privileges does this daemon require? I'd guess it can run as normal
user at least... Since this is supposed to be executing untrusted javascript
code, let's lock it down heavily from the start.

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

Re: [systemd-devel] heads-up: chasing journal(?) related regression in 219 causing boot hang/fail

2015-04-11 Thread Martin Pitt

Hello Tobias,

Tobias Hunger [2015-04-11  2:17 +0200]:
 did you make any progress with this bug? Apparently the same issue is
 blocking systemd-219 from getting into arch linux (
 https://bugs.archlinux.org/task/44016 ), so this seems to be a
 wide-spread issue. Is anyone taking a serious look into this issue?

Sorry, no, I was pretty busy with making systemd work good enough
for the impending Debian and Ubuntu releases. A few weeks ago I mostly
wanted to see whether this was specific to Debian/Ubuntu somehow, and
I couldn't reproduce it in a VM with Fedora 21 plus dbus and systemd
from rawhide. But in the meantime we got plenty of confirmations that
it affects Fedora and now Arch, so I don't believe this is actually
related to d-bus or something such.

As for the actual lockup, I'm afraid I don't understand at all
what is happening (I'm anot familiar at all with how journald
interacts with other services and D-Bus/logind).

So from my POV my best recommendation would be to revert commit
13790add4 upstream for now until this gets understood and fixed
properly, especially if/when version 220 should be released. Breaking
booting is much worse than not being able to restart journald.

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

Re: [systemd-devel] [gummiboot][PATCH 3/5] configure: add AARCH64 support

Hi

On Sat, Apr 11, 2015 at 10:23 AM, Koen Kooi koen.k...@linaro.org wrote:
 This is just plumbing to add ARCH_AARCH64 for makefile tests and
 defining the machine name.

 Signed-off-by: Koen Kooi koen.k...@linaro.org
 ---
  configure.ac | 4 
  1 file changed, 4 insertions(+)

 diff --git a/configure.ac b/configure.ac
 index 27bbe1d..c2077b1 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -51,6 +51,7 @@ dnl Define ARCH_NAME conditionals
  SET_ARCH(IA32, i*86*)
  SET_ARCH(X86_64, x86_64*)
  SET_ARCH(IA64, ia64*)
 +SET_ARCH(AARCH64, aarch64*)

  ARCH=`echo $host | sed s/\(-\).*$//`

 @@ -61,6 +62,9 @@ AM_COND_IF(ARCH_IA32, [
  AM_COND_IF(ARCH_X86_64, [
  MACHINE_TYPE_NAME=x64])

 +AM_COND_IF(ARCH_AARCH64, [
 +MACHINE_TYPE_NAME=aa64])
 +

This is EFI_MACHINE_TYPE_NAME in -git. Fixed and applied!

Thanks
David

  AC_SUBST([ARCH])
  AC_SUBST([MACHINE_TYPE_NAME])

 --
 2.0.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] sshd.service fails on boot when primary listener is a bridge (br0) instead of real interface (eth0). What dependency is needed?

2015-04-11 Thread Andrei Borzenkov

В Fri, 10 Apr 2015 18:02:49 -0700
lynd...@your-mail.com пишет:

 
 So though not clear on the real-intfc-only case, it's clearly not enough of a 
 dependency check when the bridge interface comes into play.
 


This is entirely up to implementation of waiting for network. As was
already said, network-online.tagret itself does not do anything beyond
pulling in service that actually waits for network to be up. Without
knowing what service it is your question cannot be answered.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [gummiboot][PATCH 3/5] configure: add AARCH64 support

This is just plumbing to add ARCH_AARCH64 for makefile tests and
defining the machine name.

Signed-off-by: Koen Kooi koen.k...@linaro.org
---
 configure.ac | 4 
 1 file changed, 4 insertions(+)

diff --git a/configure.ac b/configure.ac
index 27bbe1d..c2077b1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -51,6 +51,7 @@ dnl Define ARCH_NAME conditionals
 SET_ARCH(IA32, i*86*)
 SET_ARCH(X86_64, x86_64*)
 SET_ARCH(IA64, ia64*)
+SET_ARCH(AARCH64, aarch64*)
 
 ARCH=`echo $host | sed s/\(-\).*$//`
 
@@ -61,6 +62,9 @@ AM_COND_IF(ARCH_IA32, [
 AM_COND_IF(ARCH_X86_64, [
 MACHINE_TYPE_NAME=x64])
 
+AM_COND_IF(ARCH_AARCH64, [
+MACHINE_TYPE_NAME=aa64])
+
 AC_SUBST([ARCH])
 AC_SUBST([MACHINE_TYPE_NAME])
 
-- 
2.0.1

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

[systemd-devel] [gummiboot][PATCH 4/5] util: confine x86 asm to x86 architectures

Also add a stub function that just returns '1' to avoid missing symbols.

Signed-off-by: Koen Kooi koen.k...@linaro.org
---
 src/efi/util.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/efi/util.c b/src/efi/util.c
index 689bc7c..6ce1f18 100644
--- a/src/efi/util.c
+++ b/src/efi/util.c
@@ -33,14 +33,17 @@ UINT64 ticks_read(VOID) {
 __asm__ volatile (rdtsc : =a (a), =d (d));
 return (d  32) | a;
 }
-#endif
-
-#ifdef __i386__
+#elif __i386__
 UINT64 ticks_read(VOID) {
 UINT64 val;
 __asm__ volatile (rdtsc : =A (val));
 return val;
 }
+#else
+UINT64 ticks_read(VOID) {
+UINT64 val = 1;
+return val;
+}
 #endif
 
 /* count TSC ticks during a millisecond delay */
-- 
2.0.1

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

[systemd-devel] [gummiboot][PATCH 1/5] Makefile: support non-x86 builds

Move the no-mmx/no-sse CFLAGS to X86-64 and IA32 defines in preparation
for ARM32 and Aarch64 support.

Signed-off-by: Koen Kooi koen.k...@linaro.org
---
 Makefile.am | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 6568a35..2cca313 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -94,17 +94,23 @@ efi_cflags = \
-ffreestanding \
-fno-strict-aliasing \
-fno-stack-protector \
-   -Wsign-compare \
-   -mno-sse \
-   -mno-mmx
+   -Wsign-compare
 
 if ARCH_X86_64
 efi_cflags += \
-mno-red-zone \
+   -mno-sse \
+   -mno-mmx
-DEFI_FUNCTION_WRAPPER \
-DGNU_EFI_USE_MS_ABI
 endif
 
+if ARCH_IA32
+efi_cflags += \
+   -mno-sse \
+   -mno-mmx
+endif
+
 efi_ldflags = \
$(EFI_LDFLAGS) \
-T $(EFI_LDS_DIR)/elf_$(ARCH)_efi.lds \
-- 
2.0.1

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

[systemd-devel] [gummiboot][PATCH 5/5] Makefile.am: Add support for AARCH64

Aarch64 and ARM32 lack an EFI capable objcopy, so use the ldflags + -O
binary trick gnu-efi and the Red Hat shimloader are using.

Signed-off-by: Koen Kooi koen.k...@linaro.org
---
 Makefile.am | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 2cca313..eba5ec4 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -121,6 +121,17 @@ efi_ldflags = \
-L $(EFI_LIB_DIR) \
$(EFI_LDS_DIR)/crt0-efi-$(ARCH).o
 
+# Aarch64 and ARM32 don't have an EFI capable objcopy
+if ARCH_AARCH64
+efi_ldflags += \
+   --defsym=EFI_SUBSYSTEM=0xa
+
+FORMAT = -O binary
+else
+FORMAT = --target=efi-app-$(ARCH) 
+endif
+
+
 # 
--
 gummiboot_headers = \
src/efi/util.h \
@@ -156,7 +167,7 @@ $(gummiboot_solib): $(gummiboot_objects)
 $(gummiboot): $(gummiboot_solib)
$(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \
  -j .dynsym -j .rel -j .rela -j .reloc \
- --target=efi-app-$(ARCH) $ $@
+ $(FORMAT) $ $@
 
 # 
--
 stub_headers = \
@@ -191,7 +202,7 @@ $(stub_solib): $(stub_objects)
 $(stub): $(stub_solib)
$(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \
  -j .dynsym -j .rel -j .rela -j .reloc \
- --target=efi-app-$(ARCH) $ $@
+ $(FORMAT) $ $@
 
 # 
--
 CLEANFILES += test-disk.img
-- 
2.0.1

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

Re: [systemd-devel] [gummiboot][PATCH 2/5] util: use x86 ASM only on x86(-64) platforms.

Hi

On Sat, Apr 11, 2015 at 10:23 AM, Koen Kooi koen.k...@linaro.org wrote:
 Signed-off-by: Koen Kooi koen.k...@linaro.org
 ---
  src/efi/util.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/src/efi/util.c b/src/efi/util.c
 index ba5ed7d..689bc7c 100644
 --- a/src/efi/util.c
 +++ b/src/efi/util.c
 @@ -33,7 +33,9 @@ UINT64 ticks_read(VOID) {
  __asm__ volatile (rdtsc : =a (a), =d (d));
  return (d  32) | a;
  }
 -#else
 +#endif
 +
 +#ifdef __i386__

I changed this to:
  #elif defined(__i386__)

Applied to systemd-git!

Thanks
David

  UINT64 ticks_read(VOID) {
  UINT64 val;
  __asm__ volatile (rdtsc : =A (val));
 --
 2.0.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

[systemd-devel] [gummiboot][PATCH 2/5] util: use x86 ASM only on x86(-64) platforms.

Signed-off-by: Koen Kooi koen.k...@linaro.org
---
 src/efi/util.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/efi/util.c b/src/efi/util.c
index ba5ed7d..689bc7c 100644
--- a/src/efi/util.c
+++ b/src/efi/util.c
@@ -33,7 +33,9 @@ UINT64 ticks_read(VOID) {
 __asm__ volatile (rdtsc : =a (a), =d (d));
 return (d  32) | a;
 }
-#else
+#endif
+
+#ifdef __i386__
 UINT64 ticks_read(VOID) {
 UINT64 val;
 __asm__ volatile (rdtsc : =A (val));
-- 
2.0.1

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

Re: [systemd-devel] [gummiboot][PATCH 5/5] Makefile.am: Add support for AARCH64

Hi

On Sat, Apr 11, 2015 at 10:23 AM, Koen Kooi koen.k...@linaro.org wrote:
 Aarch64 and ARM32 lack an EFI capable objcopy, so use the ldflags + -O
 binary trick gnu-efi and the Red Hat shimloader are using.

 Signed-off-by: Koen Kooi koen.k...@linaro.org
 ---
  Makefile.am | 15 +--
  1 file changed, 13 insertions(+), 2 deletions(-)

 diff --git a/Makefile.am b/Makefile.am
 index 2cca313..eba5ec4 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -121,6 +121,17 @@ efi_ldflags = \
 -L $(EFI_LIB_DIR) \
 $(EFI_LDS_DIR)/crt0-efi-$(ARCH).o

 +# Aarch64 and ARM32 don't have an EFI capable objcopy
 +if ARCH_AARCH64
 +efi_ldflags += \
 +   --defsym=EFI_SUBSYSTEM=0xa
 +
 +FORMAT = -O binary
 +else
 +FORMAT = --target=efi-app-$(ARCH)

Trailing whitespace, dropped.
Also, this is EFI_ARCH now, fixed.

 +endif
 +
 +

Double newline, dropped.

  # 
 --
  gummiboot_headers = \
 src/efi/util.h \
 @@ -156,7 +167,7 @@ $(gummiboot_solib): $(gummiboot_objects)
  $(gummiboot): $(gummiboot_solib)
 $(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \
   -j .dynsym -j .rel -j .rela -j .reloc \
 - --target=efi-app-$(ARCH) $ $@
 + $(FORMAT) $ $@

  # 
 --
  stub_headers = \
 @@ -191,7 +202,7 @@ $(stub_solib): $(stub_objects)
  $(stub): $(stub_solib)
 $(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \
   -j .dynsym -j .rel -j .rela -j .reloc \
 - --target=efi-app-$(ARCH) $ $@
 + $(FORMAT) $ $@

Both merged with the previous line, as they're pretty short now.

Applied, thanks!
David


  # 
 --
  CLEANFILES += test-disk.img
 --
 2.0.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 3/5] efi: use EFI_CC

Hi

On Tue, Apr 7, 2015 at 8:54 PM, Marc-Antoine Perennou
marc-anto...@perennou.com wrote:
 ---
  configure.ac | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/configure.ac b/configure.ac
 index 29111f5..1608c83 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -1172,7 +1172,7 @@ AS_IF([test x$enable_gnuefi != xno], [
 [AC_MSG_ERROR([*** gnuefi support requested but 
 headers not found])])
  ])

 -efiroot=$(echo $(cd /usr/lib/$(gcc -print-multi-os-directory); pwd))
 +efiroot=$(echo $(cd /usr/lib/$(${EFI_CC} -print-multi-os-directory); 
 pwd))

Applied!

Thanks
David

  EFI_LIB_DIR=$efiroot
  AC_ARG_WITH(efi-libdir,
 --
 2.3.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 v2 1/2] configure: allow setting EFI_CC

Hi

On Wed, Apr 8, 2015 at 10:33 PM, Marc-Antoine Perennou
marc-anto...@perennou.com wrote:
 ---
  configure.ac | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

Applied!

Thanks
David

 diff --git a/configure.ac b/configure.ac
 index 1608c83..7e4a574 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -1147,8 +1147,7 @@ fi
  AM_CONDITIONAL(ENABLE_EFI, [test x$have_efi = xyes])

  # 
 --
 -EFI_CC=gcc
 -AC_SUBST([EFI_CC])
 +AC_CHECK_TOOL(EFI_CC, gcc)

  EFI_ARCH=`echo $host | sed s/\(-\).*$//`

 --
 2.3.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] udevd: fix synchronization with settle when handling inotify events

On Tue, Apr 7, 2015 at 12:03 AM, Daniel Drake dr...@endlessm.com wrote:
udev uses inotify to implement a scheme where when the user closes
a writable device node, a change uevent is forcefully generated.
In the case of block devices, it actually requests a partition rescan.

This currently can't be synchronized with udevadm settle, i.e. this
is not reliable in a script:

sfdisk --change-id /dev/sda 1 81
udevadm settle
mount /dev/sda1 /foo

The settle call doesn't synchronize there, so at the same time we try
to mount the device, udevd is busy removing the partition device nodes and
readding them again. The mount call often happens in that moment where the
partition node has been removed but not readded yet.

This exact issue was fixed long ago:
http://git.kernel.org/cgit/linux/hotplug/udev.git/commit/?id=bb38678e3ccc02bcd970ccde3d8166a40edf92d3

but that fix is no longer valid now that sequence numbers are no longer
used.

Fix this by forcing another mainloop iteration after handling inotify events
before unblocking settle. If the inotify event caused us to generate a
change event, we'll pick that up in the following loop iteration, before
we reach the end of the loop where we respond to settle's control message,
unblocking it.
---
src/udev/udevd.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/src/udev/udevd.c b/src/udev/udevd.c
index 830aedd..dfecef8 100644
--- a/src/udev/udevd.c
+++ b/src/udev/udevd.c
@@ -1504,9 +1504,22 @@ int main(int argc, char *argv[]) {
continue;

/* device node watch */
-if (is_inotify)
+if (is_inotify) {
handle_inotify(udev);

+/*
+ * settle might be waiting on us to determine the
queue
+ * state. If we just handled an inotify event, we
might have
+ * generated a change event, but we won't have
queued up
+ * the resultant uevent yet.
+ *
+ * Before we go ahead and potentially tell settle
that the
+ * queue is empty, lets loop one more time to update
the
+ * queue state again before deciding.
+ */
+continue;
+}
+

Nice catch!

There's indeed a small race between handling inotify and queuing up
the change-event. We need to re-loop there. One day we should switch
to sd-event to avoid such bugs... I mean the symptom is inherent to
queuing up events while handling them. Meh!

Applied!

Thanks
David

/* tell settle that we are busy or idle, this needs to be
before the
* PING handling
*/
--
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] [gummiboot][PATCH 4/5] util: confine x86 asm to x86 architectures

Hi

On Sat, Apr 11, 2015 at 10:23 AM, Koen Kooi koen.k...@linaro.org wrote:
 Also add a stub function that just returns '1' to avoid missing symbols.

 Signed-off-by: Koen Kooi koen.k...@linaro.org
 ---
  src/efi/util.c | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

 diff --git a/src/efi/util.c b/src/efi/util.c
 index 689bc7c..6ce1f18 100644
 --- a/src/efi/util.c
 +++ b/src/efi/util.c
 @@ -33,14 +33,17 @@ UINT64 ticks_read(VOID) {
  __asm__ volatile (rdtsc : =a (a), =d (d));
  return (d  32) | a;
  }
 -#endif
 -
 -#ifdef __i386__
 +#elif __i386__

I dropped that hunk as I already fixed it in patch 2/5. This, I also
adjusted the commit-message to add ticks_read() stub.

Applied! Thanks
David

  UINT64 ticks_read(VOID) {
  UINT64 val;
  __asm__ volatile (rdtsc : =A (val));
  return val;
  }
 +#else
 +UINT64 ticks_read(VOID) {
 +UINT64 val = 1;
 +return val;
 +}
  #endif

  /* count TSC ticks during a millisecond delay */
 --
 2.0.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] [gummiboot][PATCH 1/5] Makefile: support non-x86 builds

On 11 April 2015 at 11:41, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 On Sat, Apr 11, 2015 at 10:23 AM, Koen Kooi koen.k...@linaro.org wrote:
 Move the no-mmx/no-sse CFLAGS to X86-64 and IA32 defines in preparation
 for ARM32 and Aarch64 support.

 Signed-off-by: Koen Kooi koen.k...@linaro.org
 ---
  Makefile.am | 12 +---
  1 file changed, 9 insertions(+), 3 deletions(-)

 Applied to systemd-git.

Thanks!

 Note that there is no gummiboot repository, anymore.

I realized that after sending the patches, I'll try to work against
the systemd tree in the future.

regards,

Koen


 Thanks
 David

 diff --git a/Makefile.am b/Makefile.am
 index 6568a35..2cca313 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -94,17 +94,23 @@ efi_cflags = \
 -ffreestanding \
 -fno-strict-aliasing \
 -fno-stack-protector \
 -   -Wsign-compare \
 -   -mno-sse \
 -   -mno-mmx
 +   -Wsign-compare

  if ARCH_X86_64
  efi_cflags += \
 -mno-red-zone \
 +   -mno-sse \
 +   -mno-mmx
 -DEFI_FUNCTION_WRAPPER \
 -DGNU_EFI_USE_MS_ABI
  endif

 +if ARCH_IA32
 +efi_cflags += \
 +   -mno-sse \
 +   -mno-mmx
 +endif
 +
  efi_ldflags = \
 $(EFI_LDFLAGS) \
 -T $(EFI_LDS_DIR)/elf_$(ARCH)_efi.lds \
 --
 2.0.1

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



-- 
Koen Kooi

Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v2 2/2] build: allow setting OBJCOPY

Hi

On Wed, Apr 8, 2015 at 10:33 PM, Marc-Antoine Perennou
marc-anto...@perennou.com wrote:
 ---
  Makefile.am  | 4 ++--
  configure.ac | 1 +
  2 files changed, 3 insertions(+), 2 deletions(-)

Applied!

Thanks
David

 diff --git a/Makefile.am b/Makefile.am
 index 9b769ee..397a71c 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -2596,7 +2596,7 @@ $(systemd_boot_solib): $(systemd_boot_objects)
 nm -D -u $@ | grep ' U '  exit 1 || :

  $(systemd_boot): $(systemd_boot_solib)
 -   $(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \
 +   $(AM_V_GEN)$(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic \
   -j .dynsym -j .rel -j .rela -j .reloc \
   --target=efi-app-$(EFI_ARCH) $ $@

 @@ -2634,7 +2634,7 @@ $(stub_solib): $(stub_objects)
 nm -D -u $@ | grep ' U '  exit 1 || :

  $(stub): $(stub_solib)
 -   $(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \
 +   $(AM_V_GEN)$(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic \
   -j .dynsym -j .rel -j .rela -j .reloc \
   --target=efi-app-$(EFI_ARCH) $ $@

 diff --git a/configure.ac b/configure.ac
 index 7e4a574..6d7c2af 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -119,6 +119,7 @@ GOBJECT_INTROSPECTION_CHECK([1.31.1])
 AM_CONDITIONAL([HAVE_INTROSPECTION], [false])
 enable_introspection=no])

 +AC_CHECK_TOOL(OBJCOPY, objcopy)
  AC_CHECK_TOOL(STRINGS, strings)
  AC_CHECK_TOOL(GPERF, gperf)
  if test -z $GPERF ; then
 --
 2.3.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] SystemD, Gnome permission problems

2015-04-11 Thread Kai Krakow

dean deanshann...@gmail.com schrieb:

 Ok thanks for your prompt reply. It is my understanding the the
 house-keeping-plugin cleans /tmp so does it need access? Does systemD
 clean its own /tmp files/folders?

Yes, it does. See man tmpfiles.d, it ships with defaults for the tmp 
directory.

The directories you are seeing are private (isolated) bind mounts for 
several services which systemd does the house keeping for. It comes from the 
service option PrivateTmp in *.service files. It provides a service its own 
private and empty tmp directory for security reasons.

-- 
Replies to list only preferred.

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

Re: [systemd-devel] SystemD, Gnome permission problems

On Sat, Apr 11, 2015 at 02:26:57PM +0200, Kai Krakow wrote:
 dean deanshann...@gmail.com schrieb:
 
  Ok thanks for your prompt reply. It is my understanding the the
  house-keeping-plugin cleans /tmp so does it need access?
That sounds wrong. First, systemd is already cleaning /tmp, so nothing
good is going to come out of cleaning it twice. Second, doing cleanup
as unprivileged user does not really work. If the user is not running,
the cleanup is not going to happen, so on a multi-user system, when the
user logs out, files would stay around infinetely. So cleanup from
the graphical session is ineffective. More importantly, an unprivileged
user cannot access files without bumping their access time stamp. So
trying to do the cleanup as an unprivileged user actually interferes
with systemd-tmpfiles (see df99a9ef5bb7a89b92 and 
https://bugzilla.redhat.com/show_bug.cgi?id=1183684).

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

Re: [systemd-devel] [PATCH 4/4] Add a new tmpfiles.d snippets to set the NOCOW the journal.

On Wed, Apr 08, 2015 at 11:48:21PM +0200, Lennart Poettering wrote:
 On Sun, 22.03.15 20:53, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
 
  On Fri, Mar 20, 2015 at 07:06:28PM +0100, Goffredo Baroncelli wrote:
   Hi Zbyszek,
   
   On 2015-03-21 14:37, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Mar 16, 2015 at 08:33:52PM +0100, Goffredo Baroncelli wrote:
From: Goffredo Baroncelli kreij...@inwind.it
   
Add a new tmpfiles.d snippets to set the NOCOW attributes for the
journal files. This allow better perfomance when the root file system
is BTRFS. Pay attention that the NOCOW flags disables the checksum and
prevent scrub to rebuild a corrupted journal.
I now merged patches 1-3/4, but not this one. Setting/unsetting
attributes seems to be generally useful, so the rest stands on its
own. The reason I held back with the last patch is that setting of the
attributes through tmpfiles should be added together with the removal
of the same functionality from journald. 
   
   You are right, the patch #4 and the removal of the current code are 
   coupled;
   with the patch #1..#3 included, I will re-issue the #4 with another patch 
   which reverts the code. And the discussion will restart.
   
   
   
But there are some details to
work out.

Setting +C on /var/log/journal/%m has smaller scope than the code in
journal-file.c now. For example it does not cover files opened by
systemd-journal-remote. 
   
   I am not familiar with s*d-journal-remote; from the man page it seems 
   that the log are stored /by default) in /var/log/journal/remote/ ; if so 
   it is sufficient to add a line like
   
   +h /var/log/journal/remote - - - - +C
  
  That's the problem: current functionality works no matter where you
  store the files, but it's hard to provide the same level of
  flexibility with the tmpfiles-based solution.
 
 Well, but we never store files outside of /var/log/journal,
 /var/log/journal/%m and /var/log/journal/remote/, do we? 
We can, if instructed to do so. journal-remote can store files wherever.

Original motivation for this patch was to make the NOCOW on journal files
configurable without too much fuss and without making it an explicit option.
Journal files on btrfs without NOCOW are rather slow, so it seems that most
people will want NOCOW on. But with the proposed patch, people would want
to add the tmpfile snippet to set NOCOW for every location they write too,
which is very visible and requires explicit configuration. Doing this in
journal-file directly was simple, synchronous, and worked everywhere, and
we are replacing this with a more complicated and more brittle scheme.

Dunno, if you think things are better this way, I'm fine with that,
since both schemes should get the job done. But in the end, adding a
switch in journald.conf seems more in the systemd spirit of doing the right
thing automatically and also less work for both sides...

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

Re: [systemd-devel] [PATCH 2/2] udev: Allow detection of udevadm settle timeout

(Please keep the ML in CC)

On Sat, Apr 11, 2015 at 5:38 PM, Nir Soffer nir...@gmail.com wrote:
 On Sat, Apr 11, 2015 at 1:50 PM, David Herrmann dh.herrm...@gmail.com
 wrote:

 Hi

 On Wed, Apr 8, 2015 at 9:40 PM, Nir Soffer nir...@gmail.com wrote:
  When udevadm settle times out, it exits with exit code 1. This make it
  impossible for users to detect a timeout and handle real errors.  Now we
  use exit code 3 on timeouts.

 What's the use-case for this?


 A program running this tool can detect a timeout (expected) or an error
 (unexpected), and can change the program flow based on this result.

 Without this, the only way to detect a timeout is to implement the timeout
 in the program calling udevadm.

That's an explanation of your patch.

 For example, see
 https://gerrit.ovirt.org/39740

I cannot really see a use-case here. I mean, yeah, the commit-message
says it warns about timeouts but fails loudly on real errors. But
again, what's the use-case? Why is a timeout not a real error? Why do
you need to handle it differently?

Anyway, if it's only about diagnostics this patch seems fine to me.

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

Re: [systemd-devel] SystemD, Gnome permission problems

2015-04-11 Thread Mantas Mikulėnas

On Sat, Apr 11, 2015 at 7:21 PM, Zbigniew Jędrzejewski-Szmek 
zbys...@in.waw.pl wrote:

 On Sat, Apr 11, 2015 at 02:26:57PM +0200, Kai Krakow wrote:
  dean deanshann...@gmail.com schrieb:
 
   Ok thanks for your prompt reply. It is my understanding the the
   house-keeping-plugin cleans /tmp so does it need access?
 That sounds wrong. First, systemd is already cleaning /tmp, so nothing
 good is going to come out of cleaning it twice.


I think the difference here is that g-s-d has per-user configuration, so
user A can set the expiry for their own files to 1 day, user B can set it
to 7 days, and systemd can enforce a system-wide maximum of 10 days.

Though it can be confusing if the GNOME UI allows selecting a longer expiry
than systemd has.


 If the user is not running,
 the cleanup is not going to happen, so on a multi-user system, when the
 user logs out, files would stay around infinetely.


Well, tmpfiles.d enforces it anyway.


 So cleanup from
 the graphical session is ineffective. More importantly, an unprivileged
 user cannot access files without bumping their access time stamp. So
 trying to do the cleanup as an unprivileged user actually interferes
 with systemd-tmpfiles (see df99a9ef5bb7a89b92 and
 https://bugzilla.redhat.com/show_bug.cgi?id=1183684).


Even a stat()? Ouch.

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

Re: [systemd-devel] [PATCH 1/2] Revert patch 11689d2a which force the NOCOW attribute

2015-04-11 Thread Goffredo Baroncelli

Hi Lennart,

On 2015-04-08 23:12, Lennart Poettering wrote:
 --- a/src/journal/journalctl.c
  +++ b/src/journal/journalctl.c
  @@ -1290,7 +1290,7 @@ static int setup_keys(void) {
   size_t mpk_size, seed_size, state_size, i;
   uint8_t *mpk, *seed, *state;
   ssize_t l;
  -int fd = -1, r;
  +int fd = -1, r, attr = 0;
   sd_id128_t machine, boot;
   char *p = NULL, *k = NULL;
   struct FSSHeader h;
  @@ -1385,9 +1385,13 @@ static int setup_keys(void) {
   
   /* Enable secure remove, exclusion from dump, synchronous
* writing and in-place updating */
  -r = chattr_fd(fd, true, 
  FS_SECRM_FL|FS_NODUMP_FL|FS_SYNC_FL|FS_NOCOW_FL);
  -if (r  0)
  -log_warning_errno(errno, Failed to set file attributes: 
  %m);
  +if (ioctl(fd, FS_IOC_GETFLAGS, attr)  0)
  +log_warning_errno(errno, FS_IOC_GETFLAGS failed: %m);
  +
  +attr |= FS_SECRM_FL|FS_NODUMP_FL|FS_SYNC_FL|FS_NOCOW_FL;
  +
  +if (ioctl(fd, FS_IOC_SETFLAGS, attr)  0)
  +log_warning_errno(errno, FS_IOC_SETFLAGS failed: %m);
 This is unrelated, and should not be reverted at all.
 
 Lennart

Ok, this was a my fault to revert this chunk; anyway I would like to know which 
is the purpose of the FS_NOCOW_FL flag here. If I read the code, the file is 
few hundred bytes long, so in BTRFS this would be stored in the metadata chunk, 
and I am not sure if FS_NOCOW_FL is honored at all...


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 2/2] udev: Allow detection of udevadm settle timeout

Hi

On Wed, Apr 8, 2015 at 9:40 PM, Nir Soffer nir...@gmail.com wrote:
 When udevadm settle times out, it exits with exit code 1. This make it
 impossible for users to detect a timeout and handle real errors.  Now we
 use exit code 3 on timeouts.

What's the use-case for this?

Thanks
David

 ---
  src/udev/udevadm-settle.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

 diff --git a/src/udev/udevadm-settle.c b/src/udev/udevadm-settle.c
 index 715d2e7..8f9ae81 100644
 --- a/src/udev/udevadm-settle.c
 +++ b/src/udev/udevadm-settle.c
 @@ -29,6 +29,8 @@
  #include udev.h
  #include util.h

 +#define EXIT_TIMEOUT 3
 +
  static void help(void) {
  printf(%s settle OPTIONS\n\n
 Wait for pending udev events.\n\n
 @@ -142,8 +144,10 @@ static int adm_settle(struct udev *udev, int argc, char 
 *argv[]) {
  break;
  }

 -if (now(CLOCK_MONOTONIC) = deadline)
 +if (now(CLOCK_MONOTONIC) = deadline) {
 +rc = EXIT_TIMEOUT;
  break;
 +}

  /* wake up when queue is empty */
  if (poll(pfd, 1, MSEC_PER_SEC)  0  pfd[0].revents  
 POLLIN)
 --
 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

[systemd-devel] [PATCH] input_id: Identify scroll-wheel device on Trust TB7300 tablet as keyboard

2015-04-11 Thread Hans de Goede

The Trust TB7300 (relabelled Waltop?) tablet has a scrollwheel which shows
up as a /dev/input/event# node all by itself. Currently input_id does not
set any ID_INPUT_FOO attr on this causing it it to not be recognized by
Xorg / libinput.

This commit fixes this by marking it with ID_INPUT_KEY.

Cc: Sjoerd Timmer the...@randomdata.nl
Reported-by: Sjoerd Timmer the...@randomdata.nl
Signed-off-by: Hans de Goede hdego...@redhat.com
---
 src/udev/udev-builtin-input_id.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/udev/udev-builtin-input_id.c b/src/udev/udev-builtin-input_id.c
index ecfc447..f07f86e 100644
--- a/src/udev/udev-builtin-input_id.c
+++ b/src/udev/udev-builtin-input_id.c
@@ -262,6 +262,13 @@ static int builtin_input_id(struct udev_device *dev, int 
argc, char *argv[], boo
 test_pointers(dev, bitmask_ev, bitmask_abs, bitmask_key,
   bitmask_rel, bitmask_props, test);
 test_key(dev, bitmask_ev, bitmask_key, test);
+/*
+ * The scrollwheel on some devices is a device all by itself,
+ * treat this as a keyboard with just a scrollwheel.
+ */
+if (bitmask_ev[0] == (BIT(EV_REL) | BIT(EV_SYN)) 
+bitmask_rel[0] == (bitmask_rel[0]  (BIT(REL_WHEEL) | 
BIT(REL_HWHEEL
+udev_builtin_add_property(dev, test, ID_INPUT_KEY, 
1);
 }
 
 devnode = udev_device_get_devnode(dev);
-- 
2.3.4

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

Re: [systemd-devel] [PATCH] udev: Restore udevadm settle timeout

Hi

On Wed, Apr 8, 2015 at 3:04 AM, Nir Soffer nir...@gmail.com wrote:
 Commit 9ea28c55a2 (udev: remove seqnum API and all assumptions about
 seqnums) introduced a regresion, ignoring the timeout option when
 waiting until the event queue is empty.

 Previously, if the udev event queue was not empty when the timeout was
 expired, udevadm settle was returning with exit code 1.  To check if the
 queue is empty, you could invoke udevadm settle with timeout=0. This
 patch restores the previous behavior.
 ---
  src/udev/udevadm-settle.c | 6 ++
  1 file changed, 6 insertions(+)

 diff --git a/src/udev/udevadm-settle.c b/src/udev/udevadm-settle.c
 index 0d3025e..715d2e7 100644
 --- a/src/udev/udevadm-settle.c
 +++ b/src/udev/udevadm-settle.c
 @@ -49,6 +49,7 @@ static int adm_settle(struct udev *udev, int argc, char 
 *argv[]) {
  { quiet,  no_argument,   NULL, 'q' }, /* 
 removed */
  {}
  };
 +usec_t deadline = 0;

This assignment is not required, dropped.

  const char *exists = NULL;
  unsigned int timeout = 120;
  struct pollfd pfd[1] = { {.fd = -1}, };
 @@ -98,6 +99,8 @@ static int adm_settle(struct udev *udev, int argc, char 
 *argv[]) {
  return EXIT_FAILURE;
  }

 +deadline = now(CLOCK_MONOTONIC) + timeout * USEC_PER_SEC;
 +
  /* guarantee that the udev daemon isn't pre-processing */
  if (getuid() == 0) {
  struct udev_ctrl *uctrl;
 @@ -139,6 +142,9 @@ static int adm_settle(struct udev *udev, int argc, char 
 *argv[]) {
  break;
  }

 +if (now(CLOCK_MONOTONIC) = deadline)
 +break;
 +

Previous udevadm allowed timeout=0 to disable this. I added the condition.

Applied!

Thanks
David

  /* wake up when queue is empty */
  if (poll(pfd, 1, MSEC_PER_SEC)  0  pfd[0].revents  
 POLLIN)
  udev_queue_flush(queue);
 --
 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] 42-usb-hid-pm.rules: Fix tests for removable state

Hi

On Thu, Apr 9, 2015 at 3:58 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
 From: Matthew Garrett mj...@coreos.com

 We only care about whether our direct parent is removable, not whether any
 further points up the tree are - the kernel will take care of policy for
 those itself. This enables autosuspend on devices where the root hub reports
 that its removable state is unknown.
 ---
  rules/42-usb-hid-pm.rules | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

We usually don't want fixed-path access to parent sysfs entries, as
the hierarchy is not guaranteed to be stable. However, in this case,
we actually want the direct parent, regardless of who it is. So this
looks fine to me!

Applied!

Thanks
David

 diff --git a/rules/42-usb-hid-pm.rules b/rules/42-usb-hid-pm.rules
 index 4c300da..3721219 100644
 --- a/rules/42-usb-hid-pm.rules
 +++ b/rules/42-usb-hid-pm.rules
 @@ -28,9 +28,9 @@ ACTION==add, SUBSYSTEM==usb, ATTR{idVendor}==14dd, 
 ATTR{idProduct}==0002

  # USB HID devices that are internal to the machine should also be safe to 
 autosuspend

 -ACTION==add, SUBSYSTEM==usb, SUBSYSTEMS==usb, 
 ATTRS{removable}==removable, GOTO=usb_hid_pm_end
 -ACTION==add, SUBSYSTEM==usb, SUBSYSTEMS==usb, 
 ATTRS{removable}==unknown, GOTO=usb_hid_pm_end
 +ACTION==add, SUBSYSTEM==usb, SUBSYSTEMS==usb, 
 ATTR{../removable}==removable, GOTO=usb_hid_pm_end
 +ACTION==add, SUBSYSTEM==usb, SUBSYSTEMS==usb, 
 ATTR{../removable}==unknown, GOTO=usb_hid_pm_end

 -ACTION==add, SUBSYSTEM==usb, ATTR{bInterfaceClass}==03, 
 ATTRS{removable}==fixed, TEST==../power/control, 
 ATTR{../power/control}=auto
 +ACTION==add, SUBSYSTEM==usb, ATTR{bInterfaceClass}==03, 
 ATTR{../removable}==fixed, TEST==../power/control, 
 ATTR{../power/control}=auto

  LABEL=usb_hid_pm_end
 --
 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] [PATCH 1/5] factory: install to datadir

Hi

On Tue, Apr 7, 2015 at 8:54 PM, Marc-Antoine Perennou
marc-anto...@perennou.com wrote:
 ---
  Makefile.am | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

Applied!

Thanks
David

 diff --git a/Makefile.am b/Makefile.am
 index a575af6..9fa4223 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -109,8 +109,8 @@ udevrulesdir=$(udevlibexecdir)/rules.d
  udevhwdbdir=$(udevlibexecdir)/hwdb.d
  catalogdir=$(prefix)/lib/systemd/catalog
  kernelinstalldir = $(prefix)/lib/kernel/install.d
 -factory_etcdir = $(prefix)/share/factory/etc
 -factory_pamdir = $(prefix)/share/factory/etc/pam.d
 +factory_etcdir = $(datadir)/factory/etc
 +factory_pamdir = $(datadir)/factory/etc/pam.d
  bootlibdir = $(prefix)/lib/systemd/boot/efi

  # And these are the special ones for /
 --
 2.3.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] hwdb: add Samsung ATIV Book 6 / 8

Hi

On Tue, Apr 7, 2015 at 12:30 PM,  gavi...@thegavinli.com wrote:
 From: Gavin Li g...@thegavinli.com

 This adds support for the keyboard illumination keys and fixes
 Fn+F1.
 ---
  hwdb/60-keyboard.hwdb | 6 ++
  1 file changed, 6 insertions(+)

 diff --git a/hwdb/60-keyboard.hwdb b/hwdb/60-keyboard.hwdb
 index 8f0565d..84356cb 100644
 --- a/hwdb/60-keyboard.hwdb
 +++ b/hwdb/60-keyboard.hwdb
 @@ -1013,6 +1013,12 @@ 
 keyboard:atkbd:dmi:bvn*:bvr*:bd*:svn[sS][aA][mM][sS][uU][nN][gG]*:pn*7[34]0U3E*:
   KEYBOARD_KEY_b3=!prog3 # Fn+F11 fan/cooling 
 mode changer
   KEYBOARD_KEY_d5=!wlan  # Fn+F12 
 wlan/airplane switch

 +# ATIV Book 6 / 8
 +keyboard:dmi:bvn*:bvr*:bd*:svn[sS][aA][mM][sS][uU][nN][gG]*:pn*[68][78]0Z*:pvr*
 + KEYBOARD_KEY_ce=!prog1 # Fn+F1 launch 
 settings
 + KEYBOARD_KEY_96=!kbdillumup# Fn+F10 keyboard 
 backlight up
 + KEYBOARD_KEY_97=!kbdillumdown  # Fn+F9 keyboard 
 backlight down
 +

systemd-git now uses evdev:atkbd:foobar. I fixed this!

Applied!

Thanks
David

  # SQ1US
  
 keyboard:atkbd:dmi:bvn*:bvr*:bd*:svn[sS][aA][mM][sS][uU][nN][gG]*:pnSQ1US:pvr*
   KEYBOARD_KEY_d4=menu
 --
 2.3.5

 ___
 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] README: glibc version 2.16 is required for IP_UNICAST_IF

Hi

On Fri, Apr 10, 2015 at 7:39 PM, Łukasz Stelmach stl...@poczta.fm wrote:
 https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=be08eda5
 https://bugs.gentoo.org/show_bug.cgi?id=546194
 ---
  README | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

2.16 is 3 years old, so this should be fine. If not, we can always add
IP_UNICAST_IF to missing.h.

Applied!

Thanks
David

 diff --git a/README b/README
 index 5222637..f8f31fb 100644
 --- a/README
 +++ b/README
 @@ -110,7 +110,7 @@ REQUIREMENTS:
  with audit being enabled. This works correctly only on kernels
  3.14 and newer though. TL;DR: turn audit off, still.

 -glibc = 2.14
 +glibc = 2.16
  libcap
  libmount = 2.20 (from util-linux)
  libseccomp = 1.0.0 (optional)
 --
 2.0.5

 ___
 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-commits] 8 commits - src/shared src/test src/tmpfiles

On Fri, Apr 10, 2015 at 07:24:27AM -0700, Lennart Poettering wrote:
 +static void item_array_sort(ItemArray *a) {
 +
 +/* Sort an item array, to enforce stable ordering in which we
 + * apply things. */
 +
 +if (a-count = 1)
 +return;
 +
 +qsort(a-items, a-count, sizeof(Item), item_compare);
 +}
qsort_safe already does this... I'll push a change to use that instead.

 -if (user  !streq(user, -)) {
 +if (!isempty(user)  !streq(user, -)) {
I think this change is misleading. user/group/mode/age can either be
NULL or - or should be set to a valid value. It should not be possible
to set them to an empty string. (Not that the change causes any problems,
just commenting on the fact that the patch description implies that it
changes stuff, but I don't see that.)

Zbyszek

  const char *u = user;
  
  r = get_user_creds(u, i.uid, NULL, NULL, NULL);
 @@ -1872,7 +1872,7 @@ static int parse_line(const char *fname, unsigned line, 
 const char *buffer) {
  i.uid_set = true;
  }
  
 -if (group  !streq(group, -)) {
 +if (!isempty(group)  !streq(group, -)) {
  const char *g = group;
  
  r = get_group_creds(g, i.gid);
 @@ -1884,7 +1884,7 @@ static int parse_line(const char *fname, unsigned line, 
 const char *buffer) {
  i.gid_set = true;
  }
  
 -if (mode  !streq(mode, -)) {
 +if (!isempty(mode)  !streq(mode, -)) {
  const char *mm = mode;
  unsigned m;
  
 @@ -1904,7 +1904,7 @@ static int parse_line(const char *fname, unsigned line, 
 const char *buffer) {
  i.mode = IN_SET(i.type, CREATE_DIRECTORY, CREATE_SUBVOLUME, 
 TRUNCATE_DIRECTORY)
  ? 0755 : 0644;
  
 -if (age  !streq(age, -)) {
 +if (!isempty(age)  !streq(age, -)) {
  const char *a = age;
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd_event_run

On Fri, Apr 10, 2015 at 06:14:40PM +0200, Lennart Poettering wrote:
 On Sat, 14.03.15 12:19, Tom Gundersen (t...@jklm.no) wrote:
 
   1. shouldn't SD_EVENT_PASSIVE become SD_EVENT_INITIAL? passive seems 
   strange
  in this context.
 
 I found it weird to name this INITIAL (or INIT or something like
 that) since we would return to it every single iteration... For me
 init kinda implies it's something fresh, unused, and hence not
 really something we routinely come back to...
In a sense it is fresh and unused, because the state after doing
an interation of the loop is exactly the same as if the loop never run.
(E.g. I don't think it would be wrong to say I cleaned the couch and
restored it to its initial state, even though it obviously has been used.)

Passive was confusing, so initial, even if imperfect, seems an
improvement. We really want to say the state in which you started,
without implying whether we have been there the whole time or not.
I don't know if there's a better word.

  Similarly, SD_EVENT_ARMED seems more self-explanatory than PREPARED.
  (I don't like PREPARED because it is not obvious whether sources are
  prepared to wait on, or events are prepared to be reaped.)
 
 I called this prepared since it what's _prepare() is supposed to get
 into...
 
 But ARMED is fine too...

We really should get some native speakers to help out with this :)

Maybe sd_event_prepare should be renamed to sd_event_arm?

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

Re: [systemd-devel] [systemd-commits] 2 commits - src/libsystemd-network src/udev

On Fri, Apr 10, 2015 at 07:54:33PM +0200, Ronny Chevalier wrote:
 On Fri, Apr 10, 2015 at 7:05 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Sat, 14.03.15 06:54, Ronny Chevalier (rcheval...@kemper.freedesktop.org) 
  wrote:
 
  commit 6ec8e7c763b7dfa82e25e31f6938122748d1608f
  Author: Shawn Landden sh...@churchofgit.com
  Date:   Tue Mar 10 20:45:15 2015 -0700
 
  sd-dhcp-client: fix strict aliasing issue
 
  diff --git a/src/libsystemd-network/sd-dhcp-client.c 
  b/src/libsystemd-network/sd-dhcp-client.c
  index 4224e01..a477ccc 100644
  --- a/src/libsystemd-network/sd-dhcp-client.c
  +++ b/src/libsystemd-network/sd-dhcp-client.c
  @@ -1469,7 +1469,7 @@ static int 
  client_receive_message_udp(sd_event_source *s, int fd,
   _cleanup_free_ DHCPMessage *message = NULL;
   int buflen = 0, len, r;
   const struct ether_addr zero_mac = { { 0, 0, 0, 0, 0, 0 } };
  -const struct ether_addr *expected_chaddr = NULL;
  +bool expect_chaddr;
   uint8_t expected_hlen = 0;
 
   assert(s);
  @@ -1514,11 +1514,11 @@ static int 
  client_receive_message_udp(sd_event_source *s, int fd,
 
   if (client-arp_type == ARPHRD_ETHER) {
   expected_hlen = ETH_ALEN;
  -expected_chaddr = (const struct ether_addr *) 
  client-mac_addr;
  +expect_chaddr = true;
   } else {
  /* Non-ethernet links expect zero chaddr */
  expected_hlen = 0;
  -   expected_chaddr = zero_mac;
  +   expect_chaddr = false;
   }
 
   if (message-hlen != expected_hlen) {
  @@ -1526,7 +1526,10 @@ static int 
  client_receive_message_udp(sd_event_source *s, int fd,
   return 0;
   }
 
  -if (memcmp(message-chaddr[0], expected_chaddr, ETH_ALEN)) {
  +if (memcmp(message-chaddr[0], expect_chaddr ?
  +  (void *)client-mac_addr :
  +  (void *)zero_mac,
  +ETH_ALEN)) {
   log_dhcp_client(client, received chaddr does not match 
   expected: ignoring);
   return 0;
 
  Ahum, what is this about? Please elaborate what kind of struct aliasing
  this fixes?
 
 I think Shawn was trying to avoid to cast mac_addr which is (uint8_t
 *) to a (const struct ether_addr *) which breaks the strict aliasing
 rule. Or I misunderstood the patch? Shawn?
  -expected_chaddr = (const struct ether_addr *) 
  client-mac_addr;
 
 
 
  The compiler knows very well what we are taking the pointer of... and
  memcmp() doesn't really care anyway it takes (void*) pointers anyway...
 
 The issue is not with memcmp but with the cast from a (uint8_t *) to a
 (const struct ether_addr *) which breaks the strict aliasing rule.
Given that we don't do any operations on it (besides memcmp which doesn't 
matter)
it doesn't actually violate, but it does generate an annoying warning.
 
 If I'm not mistaken Shawn is trying to remove all the strict aliasing
 violations reported by gcc, in order to add the warning later on.
 
 Ronny
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd_event_run

On Sat, Apr 11, 2015 at 4:52 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Fri, Apr 10, 2015 at 06:14:40PM +0200, Lennart Poettering wrote:
 On Sat, 14.03.15 12:19, Tom Gundersen (t...@jklm.no) wrote:

   1. shouldn't SD_EVENT_PASSIVE become SD_EVENT_INITIAL? passive seems 
   strange
  in this context.
How about SD_EVENT_STALE? Stale things are distasteful unless they are
freshened up.

 I found it weird to name this INITIAL (or INIT or something like
 that) since we would return to it every single iteration... For me
 init kinda implies it's something fresh, unused, and hence not
 really something we routinely come back to...
 In a sense it is fresh and unused, because the state after doing
 an interation of the loop is exactly the same as if the loop never run.
 (E.g. I don't think it would be wrong to say I cleaned the couch and
 restored it to its initial state, even though it obviously has been used.)

 Passive was confusing, so initial, even if imperfect, seems an
 improvement. We really want to say the state in which you started,
 without implying whether we have been there the whole time or not.
 I don't know if there's a better word.

  Similarly, SD_EVENT_ARMED seems more self-explanatory than PREPARED.
  (I don't like PREPARED because it is not obvious whether sources are
  prepared to wait on, or events are prepared to be reaped.)

 I called this prepared since it what's _prepare() is supposed to get
 into...

 But ARMED is fine too...

 We really should get some native speakers to help out with this :)

 Maybe sd_event_prepare should be renamed to sd_event_arm?
Armed is much better because it fits the analogy that events *fire*,
after which they are pending. Without reading the header I would think
_prepare() is the same as _new().


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



-- 
Liberty equality fraternity or death,

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

Re: [systemd-devel] [systemd-commits] 2 commits - src/libsystemd-network src/udev

2015-04-11 Thread Jan Alexander Steffens

On Sun, Apr 12, 2015 at 1:49 AM, Shawn Landden sh...@churchofgit.com wrote:
 Given that we don't do any operations on it (besides memcmp which doesn't 
 matter)
 it doesn't actually violate, but it does generate an annoying warning.

What about making expected_chaddr a void pointer? Would that remove the warning?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd_event_run

On Sat, Apr 11, 2015 at 6:01 PM, Shawn Landden shawnland...@gmail.com wrote:
 On Sat, Apr 11, 2015 at 4:52 PM, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl wrote:
 On Fri, Apr 10, 2015 at 06:14:40PM +0200, Lennart Poettering wrote:
 On Sat, 14.03.15 12:19, Tom Gundersen (t...@jklm.no) wrote:

   1. shouldn't SD_EVENT_PASSIVE become SD_EVENT_INITIAL? passive seems 
   strange
  in this context.
 How about SD_EVENT_STALE? Stale things are distasteful unless they are
 freshened up.
Nah, Prepared is good.

But this SD_EVENT_PASSIVE and SD_EVENT_RUNNING is incompatible with
making this multithreaded. Instead there could be a function (int
sd_event_references(sd_event *e)) that returns e-n_ref.

 I found it weird to name this INITIAL (or INIT or something like
 that) since we would return to it every single iteration... For me
 init kinda implies it's something fresh, unused, and hence not
 really something we routinely come back to...
 In a sense it is fresh and unused, because the state after doing
 an interation of the loop is exactly the same as if the loop never run.
 (E.g. I don't think it would be wrong to say I cleaned the couch and
 restored it to its initial state, even though it obviously has been used.)

 Passive was confusing, so initial, even if imperfect, seems an
 improvement. We really want to say the state in which you started,
 without implying whether we have been there the whole time or not.
 I don't know if there's a better word.

  Similarly, SD_EVENT_ARMED seems more self-explanatory than PREPARED.
  (I don't like PREPARED because it is not obvious whether sources are
  prepared to wait on, or events are prepared to be reaped.)

 I called this prepared since it what's _prepare() is supposed to get
 into...

 But ARMED is fine too...

 We really should get some native speakers to help out with this :)

 Maybe sd_event_prepare should be renamed to sd_event_arm?
 Armed is much better because it fits the analogy that events *fire*,
 after which they are pending. Without reading the header I would think
 _prepare() is the same as _new().


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



 --
 Liberty equality fraternity or death,

 Shawn Landden
 ChurchOfGit.com



-- 
Liberty equality fraternity or death,

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

[systemd-devel] [PATCH] sd-dhcp-client: shutup gcc aliasing warning