[Buildroot] [PATCH 0/6] systemd improvements

[Buildroot] [PATCH 0/6] systemd improvements

[Eric Le Bihan]

Hi!

This series contains the following improvements for systemd:

 - fix systemd support in dbus.
 - fix kmod path in service files.
 - bump version to 214.
 - new hook to fix /var, /run.
 - enable network time synchronization if selected.

It takes into account the various suggestions from ThomasP and Arnout and
supersedes the previous bump patch.

Best regards,
ELB

Eric Le Bihan (6):
  dbus: enable systemd support
  systemd: revert getty service installation
  systemd: fix path for kmod in service files
  systemd: bump to version 214
  systemd: add hook to fix /run, /var
  systemd: install timesync service if selected

 package/dbus/Config.in                             |    1 +
 package/dbus/dbus.mk                               |    9 +++-
 ...ystemd-03-fix-am-path-libgcrypt-no-found.patch} |    0
 package/systemd/systemd-03-fix-no-gtk-doc.patch    |   23 --------
 package/systemd/systemd.mk                         |   56 +++++++++++++-------
 5 files changed, 46 insertions(+), 43 deletions(-)
 rename package/systemd/{systemd-04-fix-am-path-libgcrypt-no-found.patch => systemd-03-fix-am-path-libgcrypt-no-found.patch} (100%)
 delete mode 100644 package/systemd/systemd-03-fix-no-gtk-doc.patch

--
1.7.10.4

[Buildroot] [PATCH 1/6] dbus: enable systemd support

[Eric Le Bihan]

Enable systemd support if systemd is selected as init system (require
systemd compatibility libraries).

Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
---
 package/dbus/Config.in |    1 +
 package/dbus/dbus.mk   |    9 +++++++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/package/dbus/Config.in b/package/dbus/Config.in
index 653f748..7d49ce5 100644
--- a/package/dbus/Config.in
+++ b/package/dbus/Config.in
@@ -4,6 +4,7 @@ config BR2_PACKAGE_DBUS
 	# uses fork()
 	depends on BR2_USE_MMU
 	select BR2_PACKAGE_EXPAT
+	select BR2_PACKAGE_SYSTEMD_COMPAT if BR2_INIT_SYSTEMD
 	help
 	  The D-Bus message bus system.
 
diff --git a/package/dbus/dbus.mk b/package/dbus/dbus.mk
index 0c8fcf3..de699fc 100644
--- a/package/dbus/dbus.mk
+++ b/package/dbus/dbus.mk
@@ -50,8 +50,13 @@ else
 DBUS_CONF_OPT += --without-x
 endif
 
-ifeq ($(BR2_PACKAGE_SYSTEMD),y)
-DBUS_CONF_OPT += --with-systemdsystemunitdir=/lib/systemd/system
+ifeq ($(BR2_INIT_SYSTEMD),y)
+DBUS_CONF_OPT += \
+	--enable-systemd \
+	--with-systemdsystemunitdir=/lib/systemd/system
+DBUS_DEPENDENCIES += systemd
+else
+DBUS_CONF_OPT += --disable-systemd
 endif
 
 # fix rebuild (dbus makefile errors out if /var/lib/dbus is a symlink)
-- 
1.7.10.4

[Buildroot] [PATCH 1/6] dbus: enable systemd support

[Arnout Vandecappelle]

On 03/07/14 18:57, Eric Le Bihan wrote:
> Enable systemd support if systemd is selected as init system (require
> systemd compatibility libraries).
> 
> Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
> ---
>  package/dbus/Config.in |    1 +
>  package/dbus/dbus.mk   |    9 +++++++--
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/package/dbus/Config.in b/package/dbus/Config.in
> index 653f748..7d49ce5 100644
> --- a/package/dbus/Config.in
> +++ b/package/dbus/Config.in
> @@ -4,6 +4,7 @@ config BR2_PACKAGE_DBUS
>  	# uses fork()
>  	depends on BR2_USE_MMU
>  	select BR2_PACKAGE_EXPAT
> +	select BR2_PACKAGE_SYSTEMD_COMPAT if BR2_INIT_SYSTEMD
>  	help
>  	  The D-Bus message bus system.
>  
> diff --git a/package/dbus/dbus.mk b/package/dbus/dbus.mk
> index 0c8fcf3..de699fc 100644
> --- a/package/dbus/dbus.mk
> +++ b/package/dbus/dbus.mk
> @@ -50,8 +50,13 @@ else
>  DBUS_CONF_OPT += --without-x
>  endif
>  
> -ifeq ($(BR2_PACKAGE_SYSTEMD),y)
> -DBUS_CONF_OPT += --with-systemdsystemunitdir=/lib/systemd/system
> +ifeq ($(BR2_INIT_SYSTEMD),y)
> +DBUS_CONF_OPT += \
> +	--enable-systemd \
> +	--with-systemdsystemunitdir=/lib/systemd/system

 Doesn't systemd.pc specify this correctly?


 Otherwise, looks good to me.

 Regards,
 Arnout

> +DBUS_DEPENDENCIES += systemd
> +else
> +DBUS_CONF_OPT += --disable-systemd
>  endif
>  
>  # fix rebuild (dbus makefile errors out if /var/lib/dbus is a symlink)
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 2/6] systemd: revert getty service installation

[Eric Le Bihan]

Revert getty fixup from post installation hook to service installation,
because service installation is performed before the installation of the
package itself. The fixup will fail trying to delete a file that has not
been installed yet.

Fixes http://autobuild.buildroot.net/results/5b03174318d8a6dc3112053ff141b70a90869c20/

Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
---
 package/systemd/systemd.mk |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
index 95e7214..97fa61a 100644
--- a/package/systemd/systemd.mk
+++ b/package/systemd/systemd.mk
@@ -138,6 +138,11 @@ define SYSTEMD_INSTALL_INIT_HOOK
 	ln -fs ../../../lib/systemd/system/multi-user.target $(TARGET_DIR)/etc/systemd/system/default.target
 endef
 
+define SYSTEMD_INSTALL_TTY_HOOK
+	rm -f $(TARGET_DIR)/etc/systemd/system/getty.target.wants/getty at tty1.service
+	ln -fs ../../../../lib/systemd/system/serial-getty at .service $(TARGET_DIR)/etc/systemd/system/getty.target.wants/serial-getty@$(BR2_TARGET_GENERIC_GETTY_PORT).service
+endef
+
 define SYSTEMD_INSTALL_MACHINEID_HOOK
 	touch $(TARGET_DIR)/etc/machine-id
 endef
@@ -149,6 +154,7 @@ endef
 
 SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
 	SYSTEMD_INSTALL_INIT_HOOK \
+	SYSTEMD_INSTALL_TTY_HOOK \
 	SYSTEMD_INSTALL_MACHINEID_HOOK \
 	SYSTEMD_SANITIZE_PATH_IN_UNITS
 
@@ -158,13 +164,7 @@ define SYSTEMD_USERS
 	$(SYSTEMD_USER_TIMESYNC)
 endef
 
-define SYSTEMD_INSTALL_SERVICE_TTY
-	rm -f $(TARGET_DIR)/etc/systemd/system/getty.target.wants/getty at tty1.service
-	ln -fs ../../../../lib/systemd/system/serial-getty at .service $(TARGET_DIR)/etc/systemd/system/getty.target.wants/serial-getty@$(BR2_TARGET_GENERIC_GETTY_PORT).service
-endef
-
 define SYSTEMD_INSTALL_INIT_SYSTEMD
-	$(SYSTEMD_INSTALL_SERVICE_TTY)
 	$(SYSTEMD_INSTALL_SERVICE_NETWORK)
 endef
 
-- 
1.7.10.4

[Buildroot] [PATCH 2/6] systemd: revert getty service installation

[Yann E. MORIN]

Eric, All,

On 2014-07-03 18:57 +0200, Eric Le Bihan spake thusly:
> Revert getty fixup from post installation hook to service installation,
> because service installation is performed before the installation of the
> package itself. The fixup will fail trying to delete a file that has not
> been installed yet.
> 
> Fixes http://autobuild.buildroot.net/results/5b03174318d8a6dc3112053ff141b70a90869c20/

Another, nore generic fix has just been committed:
    http://git.buildroot.org/buildroot/commit/?id=ea0f52fc3fca5e5ba3ea5cd46033df2f53e9b5a5

Would you care verify if this proposed patch is still valid now?

Regards,
Yann E. MORIN.

> Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
> ---
>  package/systemd/systemd.mk |   12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> index 95e7214..97fa61a 100644
> --- a/package/systemd/systemd.mk
> +++ b/package/systemd/systemd.mk
> @@ -138,6 +138,11 @@ define SYSTEMD_INSTALL_INIT_HOOK
>  	ln -fs ../../../lib/systemd/system/multi-user.target $(TARGET_DIR)/etc/systemd/system/default.target
>  endef
>  
> +define SYSTEMD_INSTALL_TTY_HOOK
> +	rm -f $(TARGET_DIR)/etc/systemd/system/getty.target.wants/getty at tty1.service
> +	ln -fs ../../../../lib/systemd/system/serial-getty at .service $(TARGET_DIR)/etc/systemd/system/getty.target.wants/serial-getty@$(BR2_TARGET_GENERIC_GETTY_PORT).service
> +endef
> +
>  define SYSTEMD_INSTALL_MACHINEID_HOOK
>  	touch $(TARGET_DIR)/etc/machine-id
>  endef
> @@ -149,6 +154,7 @@ endef
>  
>  SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
>  	SYSTEMD_INSTALL_INIT_HOOK \
> +	SYSTEMD_INSTALL_TTY_HOOK \
>  	SYSTEMD_INSTALL_MACHINEID_HOOK \
>  	SYSTEMD_SANITIZE_PATH_IN_UNITS
>  
> @@ -158,13 +164,7 @@ define SYSTEMD_USERS
>  	$(SYSTEMD_USER_TIMESYNC)
>  endef
>  
> -define SYSTEMD_INSTALL_SERVICE_TTY
> -	rm -f $(TARGET_DIR)/etc/systemd/system/getty.target.wants/getty at tty1.service
> -	ln -fs ../../../../lib/systemd/system/serial-getty at .service $(TARGET_DIR)/etc/systemd/system/getty.target.wants/serial-getty@$(BR2_TARGET_GENERIC_GETTY_PORT).service
> -endef
> -
>  define SYSTEMD_INSTALL_INIT_SYSTEMD
> -	$(SYSTEMD_INSTALL_SERVICE_TTY)
>  	$(SYSTEMD_INSTALL_SERVICE_NETWORK)
>  endef
>  
> -- 
> 1.7.10.4
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 2/6] systemd: revert getty service installation

[Eric Le Bihan]

Hi!
On Sun, Jul 06, 2014 at 10:28:18PM +0200, Yann E. MORIN wrote:
> Eric, All,
>
> On 2014-07-03 18:57 +0200, Eric Le Bihan spake thusly:
> > Revert getty fixup from post installation hook to service installation,
> > because service installation is performed before the installation of the
> > package itself. The fixup will fail trying to delete a file that has not
> > been installed yet.
> >
> > Fixes http://autobuild.buildroot.net/results/5b03174318d8a6dc3112053ff141b70a90869c20/
>
> Another, nore generic fix has just been committed:
>     http://git.buildroot.org/buildroot/commit/?id=ea0f52fc3fca5e5ba3ea5cd46033df2f53e9b5a5
>
> Would you care verify if this proposed patch is still valid now?

This generic fix solves my issue: I will remove this patch.

Best regards,
ELB

[Buildroot] [PATCH 2/6] systemd: revert getty service installation

[Thomas Petazzoni]

Dear Eric Le Bihan,

On Thu, 17 Jul 2014 13:57:58 +0200, Eric Le Bihan wrote:

> > Would you care verify if this proposed patch is still valid now?
> 
> This generic fix solves my issue: I will remove this patch.

Thanks. I've therefore marked http://patchwork.ozlabs.org/patch/366936/
as Rejected.

Could you take care of respining the other patches in your systemd
series, i.e:

  http://patchwork.ozlabs.org/patch/366938/ (good on the principle, but
  I think it doesn't apply properly on top of master, and there were
  minor comments from Arnout)

  http://patchwork.ozlabs.org/patch/366939/ (some real concerns on this
  patch, maybe it should be last in the series, or reworked by a
  complete revamp of the skeleton strategy)

  http://patchwork.ozlabs.org/patch/366940/ (looks good, with a
  suggestion from Arnout).

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 2/6] systemd: revert getty service installation

[Eric Le Bihan]

Hi!
On Thu, Jul 17, 2014 at 09:03:30PM +0200, Thomas Petazzoni wrote:
> Dear Eric Le Bihan,
>
> On Thu, 17 Jul 2014 13:57:58 +0200, Eric Le Bihan wrote:
>
> > > Would you care verify if this proposed patch is still valid now?
> >
> > This generic fix solves my issue: I will remove this patch.
>
> Thanks. I've therefore marked http://patchwork.ozlabs.org/patch/366936/
> as Rejected.
>
> Could you take care of respining the other patches in your systemd
> series, i.e:
>
>   http://patchwork.ozlabs.org/patch/366938/ (good on the principle, but
>   I think it doesn't apply properly on top of master, and there were
>   minor comments from Arnout)

    A new version, with an updated commit log, is available:
    http://patchwork.ozlabs.org/patch/371527/.

>
>   http://patchwork.ozlabs.org/patch/366939/ (some real concerns on this
>   patch, maybe it should be last in the series, or reworked by a
>   complete revamp of the skeleton strategy)

    I dropped this patch, so I marked it as "rejected" in patchwork.
>
>   http://patchwork.ozlabs.org/patch/366940/ (looks good, with a
>   suggestion from Arnout).

    I resent it (without changes as the suggestion was not working) and marked
    the previous version as "superseeded":
    http://patchwork.ozlabs.org/patch/371528/.

Best regards,
ELB

[Buildroot] [PATCH 3/6] systemd: fix path for kmod in service files

[Eric Le Bihan]

The path for kmod used in kmod-static-nodes.service is the one found by
the ./configure script, which ends up being the path to the host kmod
program.

This patch forces the path to the target kmod program.

Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
---
 package/systemd/systemd.mk |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
index 97fa61a..756446b 100644
--- a/package/systemd/systemd.mk
+++ b/package/systemd/systemd.mk
@@ -50,6 +50,10 @@ SYSTEMD_CONF_OPT += \
 	--disable-dbus \
 	--without-python
 
+# Override path to kmod, used in kmod-static-nodes.service
+SYSTEMD_CONF_ENV = \
+	ac_cv_path_KMOD=/usr/bin/kmod
+
 ifeq ($(BR2_PACKAGE_SYSTEMD_COMPAT),y)
 SYSTEMD_CONF_OPT += --enable-compat-libs
 else
-- 
1.7.10.4

[Buildroot] [PATCH 4/6] systemd: bump to version 214

[Eric Le Bihan]

This patch bumps systemd to version 214.

Changes:

- add new users: systemd-bus-proxy, systemd-network and systemd-resolve.
- remove gtk-doc patch, as it is no longer needed.
- remove attr dependency.
- enable nss-myhostname.

Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
---
 ...ystemd-03-fix-am-path-libgcrypt-no-found.patch} |    0
 package/systemd/systemd-03-fix-no-gtk-doc.patch    |   23 --------------------
 package/systemd/systemd.mk                         |   23 +++++++++-----------
 3 files changed, 10 insertions(+), 36 deletions(-)
 rename package/systemd/{systemd-04-fix-am-path-libgcrypt-no-found.patch => systemd-03-fix-am-path-libgcrypt-no-found.patch} (100%)
 delete mode 100644 package/systemd/systemd-03-fix-no-gtk-doc.patch

diff --git a/package/systemd/systemd-04-fix-am-path-libgcrypt-no-found.patch b/package/systemd/systemd-03-fix-am-path-libgcrypt-no-found.patch
similarity index 100%
rename from package/systemd/systemd-04-fix-am-path-libgcrypt-no-found.patch
rename to package/systemd/systemd-03-fix-am-path-libgcrypt-no-found.patch
diff --git a/package/systemd/systemd-03-fix-no-gtk-doc.patch b/package/systemd/systemd-03-fix-no-gtk-doc.patch
deleted file mode 100644
index dc236a7..0000000
--- a/package/systemd/systemd-03-fix-no-gtk-doc.patch
+++ /dev/null
@@ -1,23 +0,0 @@
-Fix deactivation of gtk-doc
-
-The tarball contains the Makefile for building documentation with gtk-doc,
-Unfortunately the AM_CONDITIONAL variable is not the correct one, which
-results in an error when running autoreconf.
-
-This patch fixes this issue.
-
-Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
----
-Index: systemd-213/docs/gtk-doc.make
-===================================================================
---- systemd-213.orig/docs/gtk-doc.make	2014-02-14 09:27:47.000000000 +0100
-+++ systemd-213/docs/gtk-doc.make	2014-06-04 15:20:11.976845074 +0200
-@@ -267,7 +267,7 @@
- #
- # Require gtk-doc when making dist
- #
--if HAVE_GTK_DOC
-+if ENABLE_GTK_DOC
- dist-check-gtkdoc: docs
- else
- dist-check-gtkdoc:
diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
index 756446b..25bea0b 100644
--- a/package/systemd/systemd.mk
+++ b/package/systemd/systemd.mk
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-SYSTEMD_VERSION = 213
+SYSTEMD_VERSION = 214
 SYSTEMD_SITE = http://www.freedesktop.org/software/systemd/
 SYSTEMD_SOURCE = systemd-$(SYSTEMD_VERSION).tar.xz
 SYSTEMD_LICENSE = LGPLv2.1+; GPLv2+ for udev; MIT-like license for few source files listed in README
@@ -44,7 +44,6 @@ SYSTEMD_CONF_OPT += \
 	--enable-split-usr \
 	--enable-introspection=no \
 	--disable-efi \
-	--disable-myhostname \
 	--disable-tcpwrap \
 	--disable-tests \
 	--disable-dbus \
@@ -67,13 +66,6 @@ else
 SYSTEMD_CONF_OPT += --disable-acl
 endif
 
-ifeq ($(BR2_PACKAGE_ATTR),y)
-SYSTEMD_CONF_OPT += --enable-attr
-SYSTEMD_DEPENDENCIES += attr
-else
-SYSTEMD_CONF_OPT += --disable-attr
-endif
-
 ifeq ($(BR2_PACKAGE_LIBGLIB2),y)
 SYSTEMD_CONF_OPT += --enable-gudev
 SYSTEMD_DEPENDENCIES += libglib2
@@ -103,6 +95,10 @@ endif
 
 ifeq ($(BR2_PACKAGE_SYSTEMD_NETWORKD),y)
 SYSTEMD_CONF_OPT += --enable-networkd
+define SYSTEMD_INSTALL_RESOLVCONF_HOOK
+	ln -sf ../run/systemd/resolve/resolv.conf \
+		$(TARGET_DIR)/etc/resolv.conf
+endef
 else
 SYSTEMD_CONF_OPT += --disable-networkd
 define SYSTEMD_INSTALL_SERVICE_NETWORK
@@ -116,9 +112,6 @@ endif
 
 ifeq ($(BR2_PACKAGE_SYSTEMD_TIMESYNCD),y)
 SYSTEMD_CONF_OPT += --enable-timesyncd
-define SYSTEMD_USER_TIMESYNC
-	systemd-timesync -1 systemd-timesync -1 * - - - Network Time Synchronization
-endef
 else
 SYSTEMD_CONF_OPT += --disable-timesyncd
 endif
@@ -160,12 +153,16 @@ SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
 	SYSTEMD_INSTALL_INIT_HOOK \
 	SYSTEMD_INSTALL_TTY_HOOK \
 	SYSTEMD_INSTALL_MACHINEID_HOOK \
+	SYSTEMD_INSTALL_RESOLVCONF_HOOK \
 	SYSTEMD_SANITIZE_PATH_IN_UNITS
 
 define SYSTEMD_USERS
 	systemd-journal -1 systemd-journal -1 * /var/log/journal - - Journal
 	systemd-journal-gateway -1 systemd-journal-gateway -1 * /var/log/journal - - Journal Gateway
-	$(SYSTEMD_USER_TIMESYNC)
+	systemd-resolve -1 systemd-resolve -1 * - - - Network Name Resolution Manager
+	systemd-bus-proxy -1 systemd-bus-proxy -1 * - - - Proxy D-Bus messages to/from a bus
+	systemd-timesync -1 systemd-timesync -1 * - - - Network Time Synchronization
+	systemd-network -1 systemd-network -1 * - - - Network Manager
 endef
 
 define SYSTEMD_INSTALL_INIT_SYSTEMD
-- 
1.7.10.4

[Buildroot] [PATCH 4/6] systemd: bump to version 214

[Arnout Vandecappelle]

On 03/07/14 18:57, Eric Le Bihan wrote:
> This patch bumps systemd to version 214.
> 
> Changes:
> 
> - add new users: systemd-bus-proxy, systemd-network and systemd-resolve.
> - remove gtk-doc patch, as it is no longer needed.
> - remove attr dependency.
> - enable nss-myhostname.
> 
> Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>

Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

 It would be good however if you could explain in the commit log why removing
attr and enabling myhostname is OK.


 Regards,
 Arnout

[snip]

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 5/6] systemd: add hook to fix /run, /var

[Eric Le Bihan]

Add a post installation hook to fix target runtime data directories
/var/{lock,run,tmp} and /run. Theses directories will be populated by
systemd according to the configuration files from /usr/lib/tmpfiles.d.

Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
---
 package/systemd/systemd.mk |   13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
index 25bea0b..2da65e6 100644
--- a/package/systemd/systemd.mk
+++ b/package/systemd/systemd.mk
@@ -149,11 +149,24 @@ define SYSTEMD_SANITIZE_PATH_IN_UNITS
 		-exec $(SED) 's,$(HOST_DIR),,g' {} \;
 endef
 
+# /var/{lock,run,tmp} and /run will be populated at runtime by Systemd
+# according to the configuration files from /usr/lib/tmpfiles.d/.
+define SYSTEMD_FIX_RUNTIME_DIRS_HOOK
+	$(RM) -rf $(TARGET_DIR)/var/lock
+	$(RM) -rf $(TARGET_DIR)/var/run
+	$(RM) -rf $(TARGET_DIR)/var/tmp
+	ln -sf ../run $(TARGET_DIR)/var/run
+	ln -sf ../run $(TARGET_DIR)/var/lock
+	$(RM) -rf $(TARGET_DIR)/run
+	mkdir -p $(TARGET_DIR)/run
+endef
+
 SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
 	SYSTEMD_INSTALL_INIT_HOOK \
 	SYSTEMD_INSTALL_TTY_HOOK \
 	SYSTEMD_INSTALL_MACHINEID_HOOK \
 	SYSTEMD_INSTALL_RESOLVCONF_HOOK \
+	SYSTEMD_FIX_RUNTIME_DIRS_HOOK \
 	SYSTEMD_SANITIZE_PATH_IN_UNITS
 
 define SYSTEMD_USERS
-- 
1.7.10.4

[Buildroot] [PATCH 5/6] systemd: add hook to fix /run, /var

[Arnout Vandecappelle]

On 03/07/14 18:57, Eric Le Bihan wrote:
> Add a post installation hook to fix target runtime data directories
> /var/{lock,run,tmp} and /run. Theses directories will be populated by
> systemd according to the configuration files from /usr/lib/tmpfiles.d.

 I don't understand why this is needed, or how this can work...

 Currently, /run, /var/run, /var/lock, and /var/tmp are all symlinks to /tmp
where a tmpfs is mounted. I would expect that this is OK for systemd.

 With this change, /run no longer links to /tmp, but it becomes a directory on
the rootfs. So unless systemd mounts a tmpfs on /run, this won't work at all.
And on my Debian sid system which uses systemd, I see that /run is mounted in
/init in the initramfs, so before systemd is started. We don't do that in
buildroot, so how can this work?


 Regards,
 Arnout


> 
> Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
> ---
>  package/systemd/systemd.mk |   13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> index 25bea0b..2da65e6 100644
> --- a/package/systemd/systemd.mk
> +++ b/package/systemd/systemd.mk
> @@ -149,11 +149,24 @@ define SYSTEMD_SANITIZE_PATH_IN_UNITS
>  		-exec $(SED) 's,$(HOST_DIR),,g' {} \;
>  endef
>  
> +# /var/{lock,run,tmp} and /run will be populated at runtime by Systemd
> +# according to the configuration files from /usr/lib/tmpfiles.d/.
> +define SYSTEMD_FIX_RUNTIME_DIRS_HOOK
> +	$(RM) -rf $(TARGET_DIR)/var/lock
> +	$(RM) -rf $(TARGET_DIR)/var/run
> +	$(RM) -rf $(TARGET_DIR)/var/tmp
> +	ln -sf ../run $(TARGET_DIR)/var/run
> +	ln -sf ../run $(TARGET_DIR)/var/lock
> +	$(RM) -rf $(TARGET_DIR)/run
> +	mkdir -p $(TARGET_DIR)/run
> +endef
> +
>  SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
>  	SYSTEMD_INSTALL_INIT_HOOK \
>  	SYSTEMD_INSTALL_TTY_HOOK \
>  	SYSTEMD_INSTALL_MACHINEID_HOOK \
>  	SYSTEMD_INSTALL_RESOLVCONF_HOOK \
> +	SYSTEMD_FIX_RUNTIME_DIRS_HOOK \
>  	SYSTEMD_SANITIZE_PATH_IN_UNITS
>  
>  define SYSTEMD_USERS
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 5/6] systemd: add hook to fix /run, /var

[Eric Le Bihan]

Hi!
On Mon, Jul 07, 2014 at 06:43:52PM +0200, Arnout Vandecappelle wrote:
> On 03/07/14 18:57, Eric Le Bihan wrote:
> > Add a post installation hook to fix target runtime data directories
> > /var/{lock,run,tmp} and /run. Theses directories will be populated by
> > systemd according to the configuration files from /usr/lib/tmpfiles.d.
>
>  I don't understand why this is needed, or how this can work...
>
>  Currently, /run, /var/run, /var/lock, and /var/tmp are all symlinks to /tmp
> where a tmpfs is mounted. I would expect that this is OK for systemd.
>
>  With this change, /run no longer links to /tmp, but it becomes a directory on
> the rootfs. So unless systemd mounts a tmpfs on /run, this won't work at all.
> And on my Debian sid system which uses systemd, I see that /run is mounted in
> /init in the initramfs, so before systemd is started. We don't do that in
> buildroot, so how can this work?

When started, systemd will mount /run as tmpfs. Search for mount_table in
src/core/mount-setup.c in the source tree to see all the mount operations
performed.

Once running, systemd will start the service systemd-tmpfiles [1], which is in
charge of populating the volatile and temporary files and directories,
according to configuration files [2] located in /usr/lib/tmpfiles.d/.

The link from /run to /var/run is mentioned in var.conf:

  L /var/run - - - - ../run

/var/tmp is handled from tmp.conf:

  d /tmp 1777 root root 10d
  d /var/tmp 1777 root root 30d

/var/lock is handled from legacy.conf

  L /var/lock - - - - ../run/lock

And I've just noticed etc.conf will handle the creation of the symlink for
/etc/resolv.conf, so I can simplify my post installation hook :-)

  L /etc/resolv.conf - - - - ../run/systemd/resolve/resolv.conf

We can see that for /var/run and /var/tmp, the types 'd' and 'L' are used,
which means that if the directories/symlinks exist (created by the target
skeleton), systemd-tmpfiles will not touch them. /var/run not being a symlink
to /run made systemd-networkd not work properly on my system.

Best regards,
ELB

[1] http://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html
[2] http://www.freedesktop.org/software/systemd/man/tmpfiles.d.html

[Buildroot] [PATCH 5/6] systemd: add hook to fix /run, /var

[Arnout Vandecappelle]

On 08/07/14 15:05, Eric Le Bihan wrote:
> Hi!
> On Mon, Jul 07, 2014 at 06:43:52PM +0200, Arnout Vandecappelle wrote:
>> On 03/07/14 18:57, Eric Le Bihan wrote:
>>> Add a post installation hook to fix target runtime data directories
>>> /var/{lock,run,tmp} and /run. Theses directories will be populated by
>>> systemd according to the configuration files from /usr/lib/tmpfiles.d.
>>
>>  I don't understand why this is needed, or how this can work...
>>
>>  Currently, /run, /var/run, /var/lock, and /var/tmp are all symlinks to /tmp
>> where a tmpfs is mounted. I would expect that this is OK for systemd.
>>
>>  With this change, /run no longer links to /tmp, but it becomes a directory on
>> the rootfs. So unless systemd mounts a tmpfs on /run, this won't work at all.
>> And on my Debian sid system which uses systemd, I see that /run is mounted in
>> /init in the initramfs, so before systemd is started. We don't do that in
>> buildroot, so how can this work?
> 
> When started, systemd will mount /run as tmpfs. Search for mount_table in
> src/core/mount-setup.c in the source tree to see all the mount operations
> performed.

 It will not mount /run if it already is a mountpoint (after dereffing
symlinks). At least, that's what it looks like to me. So in our case, /run ->
/tmp and tmp being a tmpfs, it should be OK the way it is now.

 But indeed, making /run a real directory doesn't break anything, because
systemd will mount a tmpfs on it. However, do we really want two separate
tmpfses, one for /run and a different one for /tmp?


> Once running, systemd will start the service systemd-tmpfiles [1], which is in
> charge of populating the volatile and temporary files and directories,
> according to configuration files [2] located in /usr/lib/tmpfiles.d/.
> 
> The link from /run to /var/run is mentioned in var.conf:
> 
>   L /var/run - - - - ../run
> 
> /var/tmp is handled from tmp.conf:
> 
>   d /tmp 1777 root root 10d
>   d /var/tmp 1777 root root 30d
> 
> /var/lock is handled from legacy.conf
> 
>   L /var/lock - - - - ../run/lock
> 
> And I've just noticed etc.conf will handle the creation of the symlink for
> /etc/resolv.conf, so I can simplify my post installation hook :-)
> 
>   L /etc/resolv.conf - - - - ../run/systemd/resolve/resolv.conf

 Er, no: /etc may be readonly, so systemd-tmpfiles can't create the symlink.

> 
> We can see that for /var/run and /var/tmp, the types 'd' and 'L' are used,
> which means that if the directories/symlinks exist (created by the target
> skeleton), systemd-tmpfiles will not touch them. /var/run not being a symlink
> to /run made systemd-networkd not work properly on my system.

 OK, so the fact that /var/run is a symlink to /tmp and /run is also a symlink
to /tmp is not enough?


 Conclusions:

- This patch does seem to work after all.

- I personally don't like how it messes with the skeleton.

- I don't really like having two tmpfses (one for /tmp and a different one for
/run) either.

- Maybe it's better to make part of these changes in the default skeleton
instead. E.g., changing the symlink of /var/run to point to /run instead of /tmp
would be fine. Making /run a directory would not be OK, so if that is really
necessary for systemd, then a fixup like this is needed.



 Regards,
 Arnout


> 
> Best regards,
> ELB
> 
> [1] http://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html
> [2] http://www.freedesktop.org/software/systemd/man/tmpfiles.d.html
> 
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 5/6] systemd: add hook to fix /run, /var

[Mike Williams]

All,

Using the latest buildroot from git with systemd 215, timesyncd fails
to start with status 226/NAMESPACE. It appears to be due to
PrivateTmp=yes in the service file, and /var/tmp being a symlink. See
other bug reports for details:
https://bugzilla.redhat.com/show_bug.cgi?id=835131

Manually applying the steps in this patch to the target tree fixes the
problem and allows timesyncd to start properly.

Thanks,
Mike


On Tue, Jul 8, 2014 at 5:55 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 08/07/14 15:05, Eric Le Bihan wrote:
>> Hi!
>> On Mon, Jul 07, 2014 at 06:43:52PM +0200, Arnout Vandecappelle wrote:
>>> On 03/07/14 18:57, Eric Le Bihan wrote:
>>>> Add a post installation hook to fix target runtime data directories
>>>> /var/{lock,run,tmp} and /run. Theses directories will be populated by
>>>> systemd according to the configuration files from /usr/lib/tmpfiles.d.
>>>
>>>  I don't understand why this is needed, or how this can work...
>>>
>>>  Currently, /run, /var/run, /var/lock, and /var/tmp are all symlinks to /tmp
>>> where a tmpfs is mounted. I would expect that this is OK for systemd.
>>>
>>>  With this change, /run no longer links to /tmp, but it becomes a directory on
>>> the rootfs. So unless systemd mounts a tmpfs on /run, this won't work at all.
>>> And on my Debian sid system which uses systemd, I see that /run is mounted in
>>> /init in the initramfs, so before systemd is started. We don't do that in
>>> buildroot, so how can this work?
>>
>> When started, systemd will mount /run as tmpfs. Search for mount_table in
>> src/core/mount-setup.c in the source tree to see all the mount operations
>> performed.
>
>  It will not mount /run if it already is a mountpoint (after dereffing
> symlinks). At least, that's what it looks like to me. So in our case, /run ->
> /tmp and tmp being a tmpfs, it should be OK the way it is now.
>
>  But indeed, making /run a real directory doesn't break anything, because
> systemd will mount a tmpfs on it. However, do we really want two separate
> tmpfses, one for /run and a different one for /tmp?
>
>
>> Once running, systemd will start the service systemd-tmpfiles [1], which is in
>> charge of populating the volatile and temporary files and directories,
>> according to configuration files [2] located in /usr/lib/tmpfiles.d/.
>>
>> The link from /run to /var/run is mentioned in var.conf:
>>
>>   L /var/run - - - - ../run
>>
>> /var/tmp is handled from tmp.conf:
>>
>>   d /tmp 1777 root root 10d
>>   d /var/tmp 1777 root root 30d
>>
>> /var/lock is handled from legacy.conf
>>
>>   L /var/lock - - - - ../run/lock
>>
>> And I've just noticed etc.conf will handle the creation of the symlink for
>> /etc/resolv.conf, so I can simplify my post installation hook :-)
>>
>>   L /etc/resolv.conf - - - - ../run/systemd/resolve/resolv.conf
>
>  Er, no: /etc may be readonly, so systemd-tmpfiles can't create the symlink.
>
>>
>> We can see that for /var/run and /var/tmp, the types 'd' and 'L' are used,
>> which means that if the directories/symlinks exist (created by the target
>> skeleton), systemd-tmpfiles will not touch them. /var/run not being a symlink
>> to /run made systemd-networkd not work properly on my system.
>
>  OK, so the fact that /var/run is a symlink to /tmp and /run is also a symlink
> to /tmp is not enough?
>
>
>  Conclusions:
>
> - This patch does seem to work after all.
>
> - I personally don't like how it messes with the skeleton.
>
> - I don't really like having two tmpfses (one for /tmp and a different one for
> /run) either.
>
> - Maybe it's better to make part of these changes in the default skeleton
> instead. E.g., changing the symlink of /var/run to point to /run instead of /tmp
> would be fine. Making /run a directory would not be OK, so if that is really
> necessary for systemd, then a fixup like this is needed.
>
>
>
>  Regards,
>  Arnout
>
>
>>
>> Best regards,
>> ELB
>>
>> [1] http://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html
>> [2] http://www.freedesktop.org/software/systemd/man/tmpfiles.d.html
>>
>>
>
>
> --
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] [PATCH 6/6] systemd: install timesync service if selected

[Eric Le Bihan]

If support for systemd-timesyncd is selected, install the associated
service.

Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
---
 package/systemd/systemd.mk |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
index 2da65e6..3454e43 100644
--- a/package/systemd/systemd.mk
+++ b/package/systemd/systemd.mk
@@ -112,6 +112,11 @@ endif
 
 ifeq ($(BR2_PACKAGE_SYSTEMD_TIMESYNCD),y)
 SYSTEMD_CONF_OPT += --enable-timesyncd
+define SYSTEMD_INSTALL_SERVICE_TIMESYNC
+	mkdir -p $(TARGET_DIR)/etc/systemd/system/sysinit.target.wants
+	ln -sf ../../../../lib/systemd/system/systemd-timesyncd.service \
+		$(TARGET_DIR)/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service
+endef
 else
 SYSTEMD_CONF_OPT += --disable-timesyncd
 endif
@@ -180,6 +185,7 @@ endef
 
 define SYSTEMD_INSTALL_INIT_SYSTEMD
 	$(SYSTEMD_INSTALL_SERVICE_NETWORK)
+	$(SYSTEMD_INSTALL_SERVICE_TIMESYNC)
 endef
 
 $(eval $(autotools-package))
-- 
1.7.10.4

[Buildroot] [PATCH 6/6] systemd: install timesync service if selected

[Arnout Vandecappelle]

On 03/07/14 18:57, Eric Le Bihan wrote:
> If support for systemd-timesyncd is selected, install the associated
> service.
> 
> Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>

Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

> ---
>  package/systemd/systemd.mk |    6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> index 2da65e6..3454e43 100644
> --- a/package/systemd/systemd.mk
> +++ b/package/systemd/systemd.mk
> @@ -112,6 +112,11 @@ endif
>  
>  ifeq ($(BR2_PACKAGE_SYSTEMD_TIMESYNCD),y)
>  SYSTEMD_CONF_OPT += --enable-timesyncd
> +define SYSTEMD_INSTALL_SERVICE_TIMESYNC
> +	mkdir -p $(TARGET_DIR)/etc/systemd/system/sysinit.target.wants
> +	ln -sf ../../../../lib/systemd/system/systemd-timesyncd.service \
> +		$(TARGET_DIR)/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service
> +endef

 Not for this patch, but perhaps a cleaner way to do this would be to add

SYSTEMD_INSTALL_INIT_SYSTEMD += $(SYSTEMD_INSTALL_SERVICE_TIMESYNC)

instead having the list explicit below? Or wouldn't that work because there is
no separator between networkd and timesync?


 Regards,
 Arnout

>  else
>  SYSTEMD_CONF_OPT += --disable-timesyncd
>  endif
> @@ -180,6 +185,7 @@ endef
>  
>  define SYSTEMD_INSTALL_INIT_SYSTEMD
>  	$(SYSTEMD_INSTALL_SERVICE_NETWORK)
> +	$(SYSTEMD_INSTALL_SERVICE_TIMESYNC)
>  endef
>  
>  $(eval $(autotools-package))
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 6/6] systemd: install timesync service if selected

[Eric Le Bihan]

On Mon, Jul 07, 2014 at 06:46:12PM +0200, Arnout Vandecappelle wrote:
> On 03/07/14 18:57, Eric Le Bihan wrote:
> > If support for systemd-timesyncd is selected, install the associated
> > service.
> >
> > Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
>
> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
>
> > ---
> >  package/systemd/systemd.mk |    6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> > index 2da65e6..3454e43 100644
> > --- a/package/systemd/systemd.mk
> > +++ b/package/systemd/systemd.mk
> > @@ -112,6 +112,11 @@ endif
> >
> >  ifeq ($(BR2_PACKAGE_SYSTEMD_TIMESYNCD),y)
> >  SYSTEMD_CONF_OPT += --enable-timesyncd
> > +define SYSTEMD_INSTALL_SERVICE_TIMESYNC
> > +	mkdir -p $(TARGET_DIR)/etc/systemd/system/sysinit.target.wants
> > +	ln -sf ../../../../lib/systemd/system/systemd-timesyncd.service \
> > +		$(TARGET_DIR)/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service
> > +endef
>
>  Not for this patch, but perhaps a cleaner way to do this would be to add
>
> SYSTEMD_INSTALL_INIT_SYSTEMD += $(SYSTEMD_INSTALL_SERVICE_TIMESYNC)
>
> instead having the list explicit below? Or wouldn't that work because there is
> no separator between networkd and timesync?

Exactly! I tried the proposed solution and it does not work because of the
missing separator.

In order to have such a way of installing systemd unit files, we should do the
same as for the pre/post installation hooks.

The following change should be done in package/pkg-generic.mk:

   	$(if $(BR2_INIT_SYSTEMD),\
  -		$($(PKG)_INSTALL_INIT_SYSTEMD))
  +		$(foreach hook,$($(PKG)_INIT_SYSTEMD_HOOKS),$(call $(hook))$(sep)))

Then, we could use:

  SYSTEMD_INIT_SYSTEMD_HOOKS += SYSTEMD_INSTALL_SERVICE_TIMESYNC

This would require updating all the Makefiles of the packages installing
systemd unit files (and maybe do the same for SysV/Busybox to be coherent).

Best regards,
ELB

[Buildroot] [PATCH 6/6] systemd: install timesync service if selected

[Arnout Vandecappelle]

On 17/07/14 14:46, Eric Le Bihan wrote:
> On Mon, Jul 07, 2014 at 06:46:12PM +0200, Arnout Vandecappelle wrote:
>> On 03/07/14 18:57, Eric Le Bihan wrote:
>>> If support for systemd-timesyncd is selected, install the associated
>>> service.
>>>
>>> Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
>>
>> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
>>
>>> ---
>>>  package/systemd/systemd.mk |    6 ++++++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
>>> index 2da65e6..3454e43 100644
>>> --- a/package/systemd/systemd.mk
>>> +++ b/package/systemd/systemd.mk
>>> @@ -112,6 +112,11 @@ endif
>>>
>>>  ifeq ($(BR2_PACKAGE_SYSTEMD_TIMESYNCD),y)
>>>  SYSTEMD_CONF_OPT += --enable-timesyncd
>>> +define SYSTEMD_INSTALL_SERVICE_TIMESYNC
>>> +	mkdir -p $(TARGET_DIR)/etc/systemd/system/sysinit.target.wants
>>> +	ln -sf ../../../../lib/systemd/system/systemd-timesyncd.service \
>>> +		$(TARGET_DIR)/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service
>>> +endef
>>
>>  Not for this patch, but perhaps a cleaner way to do this would be to add
>>
>> SYSTEMD_INSTALL_INIT_SYSTEMD += $(SYSTEMD_INSTALL_SERVICE_TIMESYNC)
>>
>> instead having the list explicit below? Or wouldn't that work because there is
>> no separator between networkd and timesync?
> 
> Exactly! I tried the proposed solution and it does not work because of the
> missing separator.
> 
> In order to have such a way of installing systemd unit files, we should do the
> same as for the pre/post installation hooks.
> 
> The following change should be done in package/pkg-generic.mk:
> 
>    	$(if $(BR2_INIT_SYSTEMD),\
>   -		$($(PKG)_INSTALL_INIT_SYSTEMD))
>   +		$(foreach hook,$($(PKG)_INIT_SYSTEMD_HOOKS),$(call $(hook))$(sep)))
> 
> Then, we could use:
> 
>   SYSTEMD_INIT_SYSTEMD_HOOKS += SYSTEMD_INSTALL_SERVICE_TIMESYNC
> 
> This would require updating all the Makefiles of the packages installing
> systemd unit files (and maybe do the same for SysV/Busybox to be coherent).

 No, it's not worth it. There won't be more than one or two packages that need
to do more than one thing for the INSTALL_INIT things, so complicating all
packages in order for this to work is a bit too much.

 So your original patch (which you reposted) is fine.

 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 0/6] systemd improvements

[Thomas Petazzoni]

Dear Eric Le Bihan,

On Thu,  3 Jul 2014 18:57:33 +0200, Eric Le Bihan wrote:

> Eric Le Bihan (6):
>   dbus: enable systemd support

This one applied.

>   systemd: revert getty service installation

This one waiting for your feedback on Yann's comment.

>   systemd: fix path for kmod in service files

This one applied.

>   systemd: bump to version 214

This one no longer applies, probably due to "systemd: revert getty
service installation" not being applied.

>   systemd: add hook to fix /run, /var

Still unresolved issues during the discussion with Arnout. I believe
the only good way moving forward is to improve the skeleton strategy.

>   systemd: install timesync service if selected

One remaining suggestion/question from Arnout.

Could you respin with the appropriate changes?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com