[Buildroot] [PATCH v5 0/2] package/unscd: new package

[Buildroot] [PATCH v5 0/2] package/unscd: new package

[Doug Kehn]

systemd recipe/support is removed. systemd support is best left to someone
versed in systemd who desires to use unscd with systemd.

The BR2_GLIBC_NSCD suggestion is incorporated. However, I'm not sure what the
proper next steps are to properly install glibc nscd for both internal/external
toolchains. Is it sufficient, for now, to just define BR2_GLIBC_NSCD?

Doug Kehn (2):
  package/unscd: new package
  toolchain/toolchain-common.in: install nscd

 package/Config.in             |  1 +
 package/unscd/Config.in       | 11 ++++++++++
 package/unscd/S46unscd        | 24 ++++++++++++++++++++++
 package/unscd/unscd.hash      |  3 +++
 package/unscd/unscd.mk        | 47 +++++++++++++++++++++++++++++++++++++++++++
 toolchain/toolchain-common.in |  4 ++++
 6 files changed, 90 insertions(+)
 create mode 100644 package/unscd/Config.in
 create mode 100644 package/unscd/S46unscd
 create mode 100644 package/unscd/unscd.hash
 create mode 100644 package/unscd/unscd.mk

--
Changes v4 -> v5
  - Reincorporate $(APPLY_PATCHES) suggestion after update by Arnout.
Changes v3 -> v4
  - Incorporate feedback/suggestions by Yann and Maxime.
Changes v2 -> v3
  - Remove trailing '/' from UNSCD_SITE.
  - Whitespace cleanup.
Changes v1 -> v2
  - Incorporate feedback/suggestions by Yann (from nss-pam-ldapd patch).

-- 
2.6.2

[Buildroot] [PATCH v5 1/2] package/unscd: new package

[Doug Kehn]

A daemon which handles passwd, group and host lookups for running
programs and caches the results for the next query. You only need this
package if you are using slow Name Services like LDAP, NIS or NIS+.

This particular NSCD is a complete rewrite of the GNU glibc nscd which
is a single threaded server process which offloads all NSS lookups to
worker children; cache hits are handled by the parent, and only cache
misses start worker children, making the parent immune to resource
leaks, hangs, and crashes in NSS libraries.

It should mostly be a drop-in replacement for existing installs using
nscd.

Signed-off-by: Doug Kehn <rdkehn@yahoo.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
CC: Arnout Vandecappelle <arnout@mind.be>
--
Changes v4 -> v5
  - Reincorporate $(APPLY_PATCHES) suggestion after update by Arnout.
Changes v3 -> v4
  - Incorporate feedback/suggestions by Yann and Maxime.
Changes v2 -> v3
  - Remove trailing '/' from UNSCD_SITE.
  - Whitespace cleanup.
Changes v1 -> v2
  - Incorporate feedback/suggestions by Yann (from nss-pam-ldapd patch).
---
 package/Config.in        |  1 +
 package/unscd/Config.in  | 11 +++++++++++
 package/unscd/S46unscd   | 24 ++++++++++++++++++++++++
 package/unscd/unscd.hash |  3 +++
 package/unscd/unscd.mk   | 47 +++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 86 insertions(+)
 create mode 100644 package/unscd/Config.in
 create mode 100644 package/unscd/S46unscd
 create mode 100644 package/unscd/unscd.hash
 create mode 100644 package/unscd/unscd.mk

diff --git a/package/Config.in b/package/Config.in
index bdc3063..7fd3f0d 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -1534,6 +1534,7 @@ if BR2_PACKAGE_BUSYBOX_SHOW_OTHERS
 	source "package/sysvinit/Config.in"
 	source "package/tar/Config.in"
 endif
+	source "package/unscd/Config.in"
 	source "package/util-linux/Config.in"
 endmenu
 
diff --git a/package/unscd/Config.in b/package/unscd/Config.in
new file mode 100644
index 0000000..1639bca
--- /dev/null
+++ b/package/unscd/Config.in
@@ -0,0 +1,11 @@
+config BR2_PACKAGE_UNSCD
+	bool "unscd"
+	depends on BR2_TOOLCHAIN_USES_GLIBC
+	depends on !BR2_GLIBC_NSCD
+	help
+	  Micro Name Service Caching Daemon
+
+	  https://packages.debian.org/unscd
+
+comment "unscd needs an (e)glibc toolchain"
+	depends on !BR2_TOOLCHAIN_USES_GLIBC
diff --git a/package/unscd/S46unscd b/package/unscd/S46unscd
new file mode 100644
index 0000000..7d18f94
--- /dev/null
+++ b/package/unscd/S46unscd
@@ -0,0 +1,24 @@
+#!/bin/sh
+
+NAME="nscd"
+DAEMON="/usr/sbin/${NAME}"
+
+case "$1" in
+start)
+        printf "Starting ${NAME}: "
+        start-stop-daemon -S -x ${DAEMON}
+        [ $? -eq 0 ] && echo "OK" || echo "FAIL"
+        ;;
+stop)
+        printf "Stopping ${NAME}: "
+        start-stop-daemon -K -x ${DAEMON}
+        [ $? -eq 0 ] && echo "OK" || echo "FAIL"
+        ;;
+restart|reload)
+        $0 stop
+        $0 start
+        ;;
+*)
+        echo "Usage: $0 {start|stop|restart|reload}"
+        exit 1
+esac
diff --git a/package/unscd/unscd.hash b/package/unscd/unscd.hash
new file mode 100644
index 0000000..f65ebda
--- /dev/null
+++ b/package/unscd/unscd.hash
@@ -0,0 +1,3 @@
+# From http://snapshot.debian.org/archive/debian/20150519T094547Z/pool/main/u/unscd/unscd_0.51-1.dsc
+sha256	0dbf717726e1c29af8f4ef7d2d2695e5eedb342320a730a56ae0d56fe32891f8	unscd_0.51.orig.tar.gz
+sha256	8ae16a826afd464639f6c6372fabafee5b93aea9645b3fbf23970296d4961f27	unscd_0.51-1.debian.tar.gz
diff --git a/package/unscd/unscd.mk b/package/unscd/unscd.mk
new file mode 100644
index 0000000..1ea8d5c
--- /dev/null
+++ b/package/unscd/unscd.mk
@@ -0,0 +1,47 @@
+################################################################################
+#
+# unscd
+#
+################################################################################
+
+UNSCD_VERSION = 0.51
+UNSCD_SOURCE = unscd_$(UNSCD_VERSION).orig.tar.gz
+UNSCD_SITE = http://snapshot.debian.org/archive/debian/20150519T094547Z/pool/main/u/unscd
+UNSCD_EXTRA_DOWNLOADS = unscd_$(UNSCD_VERSION)-1.debian.tar.gz
+UNSCD_LICENSE = GPLv2
+UNSCD_LICENSE_FILES = debian/copyright
+
+define UNSCD_EXTRACT_DEBIAN
+	$(call suitable-extractor,$(UNSCD_EXTRA_DOWNLOADS)) \
+		$(DL_DIR)/$(UNSCD_EXTRA_DOWNLOADS) \
+		| $(TAR) -C $(@D) -xf -
+endef
+
+UNSCD_POST_EXTRACT_HOOKS += UNSCD_EXTRACT_DEBIAN
+
+define UNSCD_APPLY_DEBIAN_PATCHES
+	$(APPLY_PATCHES) $(@D) $(@D)/debian/patches
+endef
+
+UNSCD_POST_PATCH_HOOKS += UNSCD_APPLY_DEBIAN_PATCHES
+
+define UNSCD_BUILD_CMDS
+	$(TARGET_CC) $(TARGET_CFLAGS) $(TARGET_LDFLAGS) \
+		$(@D)/nscd.c -o $(@D)/nscd
+endef
+
+define UNSCD_INSTALL_TARGET_CMDS
+	$(INSTALL) -m 755 -D $(@D)/nscd $(TARGET_DIR)/usr/sbin/nscd
+	$(INSTALL) -m 600 -D $(@D)/debian/nscd.conf $(TARGET_DIR)/etc/nscd.conf
+endef
+
+define UNSCD_INSTALL_INIT_SYSV
+	$(INSTALL) -m 755 -D package/unscd/S46unscd \
+		$(TARGET_DIR)/etc/init.d/S46unscd
+endef
+
+define UNSCD_USERS
+	unscd -1 unscd -1 * - - - unscd user
+endef
+
+$(eval $(generic-package))
-- 
2.6.2

[Buildroot] [PATCH v5 2/2] toolchain/toolchain-common.in: install nscd

[Doug Kehn]

Add BR2_GLIBC_NSCD for installing nscd. BR2_GLIBC_NSCD can be used by
other packages (e.g. unscd) to prevent the selection of multiple nscd
packages.

Signed-off-by: Doug Kehn <rdkehn@yahoo.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
--
Changes v4 -> v5
  - No changes.
Changes v3 -> v4
  - Incorporate feedback/suggestions by Yann and Maxime.
Changes v2 -> v3
  - Remove trailing '/' from UNSCD_SITE.
  - Whitespace cleanup.
Changes v1 -> v2
  - Incorporate feedback/suggestions by Yann (from nss-pam-ldapd patch).

---
 toolchain/toolchain-common.in | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/toolchain/toolchain-common.in b/toolchain/toolchain-common.in
index 6871d8b..a119c9c 100644
--- a/toolchain/toolchain-common.in
+++ b/toolchain/toolchain-common.in
@@ -136,6 +136,10 @@ config BR2_ECLIPSE_REGISTER
 	  configuration files to make your toolchain appear within
 	  Eclipse, through the Eclipse Buildroot plugin.
 
+config BR2_GLIBC_NSCD
+	bool "Install nscd"
+	depends on BR2_TOOLCHAIN_USES_GLIBC
+
 # Options for packages to depend on, if they require at least a
 # specific version of the kernel headers.
 # Toolchains should choose the adequate option (ie. the highest
-- 
2.6.2

[Buildroot] [PATCH v5 0/2] package/unscd: new package

[Vicente Olivert Riera]

Dear Doug Kehn, everyone,

just a small question. Perhaps I'm wrong, but..., isn't nscd deprecated
in favor of sssd? If so, shouldn't we add the sssd package instead?

Regards,

Vincent.

On 23/11/15 13:58, Doug Kehn wrote:
> systemd recipe/support is removed. systemd support is best left to someone
> versed in systemd who desires to use unscd with systemd.
> 
> The BR2_GLIBC_NSCD suggestion is incorporated. However, I'm not sure what the
> proper next steps are to properly install glibc nscd for both internal/external
> toolchains. Is it sufficient, for now, to just define BR2_GLIBC_NSCD?
> 
> Doug Kehn (2):
>   package/unscd: new package
>   toolchain/toolchain-common.in: install nscd
> 
>  package/Config.in             |  1 +
>  package/unscd/Config.in       | 11 ++++++++++
>  package/unscd/S46unscd        | 24 ++++++++++++++++++++++
>  package/unscd/unscd.hash      |  3 +++
>  package/unscd/unscd.mk        | 47 +++++++++++++++++++++++++++++++++++++++++++
>  toolchain/toolchain-common.in |  4 ++++
>  6 files changed, 90 insertions(+)
>  create mode 100644 package/unscd/Config.in
>  create mode 100644 package/unscd/S46unscd
>  create mode 100644 package/unscd/unscd.hash
>  create mode 100644 package/unscd/unscd.mk
> 
> --
> Changes v4 -> v5
>   - Reincorporate $(APPLY_PATCHES) suggestion after update by Arnout.
> Changes v3 -> v4
>   - Incorporate feedback/suggestions by Yann and Maxime.
> Changes v2 -> v3
>   - Remove trailing '/' from UNSCD_SITE.
>   - Whitespace cleanup.
> Changes v1 -> v2
>   - Incorporate feedback/suggestions by Yann (from nss-pam-ldapd patch).
> 

[Buildroot] [PATCH v5 0/2] package/unscd: new package

[rdkehn at yahoo.com]

Hi Vincent,

On Mon, Nov 23, 2015 at 02:35:56PM +0000, Vicente Olivert Riera wrote:
> Dear Doug Kehn, everyone,
> 
> just a small question. Perhaps I'm wrong, but..., isn't nscd deprecated
> in favor of sssd? If so, shouldn't we add the sssd package instead?

I believe [u]nscd is deprecated for RHEL/CENTOS. I'm not sure about
other distros. My Arch Linux distro installs glibc nscd by default.

I'm by no means an sssd expert; however, from a quick cursory look

http://serverfault.com/questions/534791/what-are-the-dependencies-of-sssd-nscd-to-function

it appears sssd may have dependencies that may not be desirable for
some systems.  This is of course debatable. 

I use unscd in my Buildroot system so I thought I would share what
is working for me since unscd was not an available package. I'm okay
with this patch not being accepted in favor of sssd.

Regards,
...doug

> 
> Regards,
> 
> Vincent.
> 
> On 23/11/15 13:58, Doug Kehn wrote:
> > systemd recipe/support is removed. systemd support is best left to someone
> > versed in systemd who desires to use unscd with systemd.
> > 
> > The BR2_GLIBC_NSCD suggestion is incorporated. However, I'm not sure what the
> > proper next steps are to properly install glibc nscd for both internal/external
> > toolchains. Is it sufficient, for now, to just define BR2_GLIBC_NSCD?
> > 
> > Doug Kehn (2):
> >   package/unscd: new package
> >   toolchain/toolchain-common.in: install nscd
> > 
> >  package/Config.in             |  1 +
> >  package/unscd/Config.in       | 11 ++++++++++
> >  package/unscd/S46unscd        | 24 ++++++++++++++++++++++
> >  package/unscd/unscd.hash      |  3 +++
> >  package/unscd/unscd.mk        | 47 +++++++++++++++++++++++++++++++++++++++++++
> >  toolchain/toolchain-common.in |  4 ++++
> >  6 files changed, 90 insertions(+)
> >  create mode 100644 package/unscd/Config.in
> >  create mode 100644 package/unscd/S46unscd
> >  create mode 100644 package/unscd/unscd.hash
> >  create mode 100644 package/unscd/unscd.mk
> > 
> > --
> > Changes v4 -> v5
> >   - Reincorporate $(APPLY_PATCHES) suggestion after update by Arnout.
> > Changes v3 -> v4
> >   - Incorporate feedback/suggestions by Yann and Maxime.
> > Changes v2 -> v3
> >   - Remove trailing '/' from UNSCD_SITE.
> >   - Whitespace cleanup.
> > Changes v1 -> v2
> >   - Incorporate feedback/suggestions by Yann (from nss-pam-ldapd patch).
> > 

[Buildroot] [PATCH v5 1/2] package/unscd: new package

[Thomas Petazzoni]

Dear Doug Kehn,

On Mon, 23 Nov 2015 07:58:15 -0600, Doug Kehn wrote:

> diff --git a/package/unscd/Config.in b/package/unscd/Config.in
> new file mode 100644
> index 0000000..1639bca
> --- /dev/null
> +++ b/package/unscd/Config.in
> @@ -0,0 +1,11 @@
> +config BR2_PACKAGE_UNSCD
> +	bool "unscd"
> +	depends on BR2_TOOLCHAIN_USES_GLIBC
> +	depends on !BR2_GLIBC_NSCD

I think you should leave this BR2_GLIBC_NSCD thing on the side for now.
Just make unscd a normal package, and don't worry about nscd coming
from glibc: there is anyway no mechanism in Buildroot today to install
the nscd coming from the toolchain.

> +UNSCD_POST_EXTRACT_HOOKS += UNSCD_EXTRACT_DEBIAN
> +
> +define UNSCD_APPLY_DEBIAN_PATCHES
> +	$(APPLY_PATCHES) $(@D) $(@D)/debian/patches
> +endef
> +
> +UNSCD_POST_PATCH_HOOKS += UNSCD_APPLY_DEBIAN_PATCHES

This doesn't work because the patches don't end with an extension that
is recognized by our apply-patch script. So all what you see is:

>>> unscd 0.51 Patching
support/scripts/apply-patches.sh  /home/thomas/projets/buildroot/output/build/unscd-0.51 /home/thomas/projets/buildroot/output/build/unscd-0.51/debian/patches
Unsupported file type for /home/thomas/projets/buildroot/output/build/unscd-0.51/debian/patches/change_invalidate_request_info_output, skipping
Unsupported file type for /home/thomas/projets/buildroot/output/build/unscd-0.51/debian/patches/support_large_numbers_in_config, skipping

which makes the entire dance around applying the Debian patches useless.

Unfortunately, fixing this requires fixing our apply-patches script.
Generally speaking, I am not super happy with all the logic we need to
add in various packages to get them to apply the Debian patches. But
Debian packages vary quite a bit in the way the patches are organized,
so I don't know if it's doable to fix.

BTW any reason to not use the upstream version, at
http://busybox.net/~vda/unscd/nscd-0.52.c, which is higher than 0.51 ?

Can you look into this patching issue (or alternatively use 0.52 with
no patches) and send an updated version ?

Thanks !

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

[Buildroot] [PATCH v5 2/2] toolchain/toolchain-common.in: install nscd

[Thomas Petazzoni]

Dear Doug Kehn,

On Mon, 23 Nov 2015 07:58:16 -0600, Doug Kehn wrote:

> diff --git a/toolchain/toolchain-common.in b/toolchain/toolchain-common.in
> index 6871d8b..a119c9c 100644
> --- a/toolchain/toolchain-common.in
> +++ b/toolchain/toolchain-common.in
> @@ -136,6 +136,10 @@ config BR2_ECLIPSE_REGISTER
>  	  configuration files to make your toolchain appear within
>  	  Eclipse, through the Eclipse Buildroot plugin.
>  
> +config BR2_GLIBC_NSCD
> +	bool "Install nscd"
> +	depends on BR2_TOOLCHAIN_USES_GLIBC

If this option were to be used by PATCH 1/2, then it should be
introduced before.

However, it is very useless to add an option that doesn't do anything
at all: if you add this option, it should actually install nscd.

If you want an example on how to do that, look at how the gconv library
installation is implemented. It works fine for both internal and
external toolchains.

Thanks!

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

[Buildroot] [PATCH v5 1/2] package/unscd: new package

[Arnout Vandecappelle]

On 30-11-15 22:44, Thomas Petazzoni wrote:
> Dear Doug Kehn,
> 
> On Mon, 23 Nov 2015 07:58:15 -0600, Doug Kehn wrote:
> 
>> diff --git a/package/unscd/Config.in b/package/unscd/Config.in
>> new file mode 100644
>> index 0000000..1639bca
>> --- /dev/null
>> +++ b/package/unscd/Config.in
>> @@ -0,0 +1,11 @@
>> +config BR2_PACKAGE_UNSCD
>> +	bool "unscd"
>> +	depends on BR2_TOOLCHAIN_USES_GLIBC
>> +	depends on !BR2_GLIBC_NSCD
> 
> I think you should leave this BR2_GLIBC_NSCD thing on the side for now.
> Just make unscd a normal package, and don't worry about nscd coming
> from glibc: there is anyway no mechanism in Buildroot today to install
> the nscd coming from the toolchain.
> 
>> +UNSCD_POST_EXTRACT_HOOKS += UNSCD_EXTRACT_DEBIAN
>> +
>> +define UNSCD_APPLY_DEBIAN_PATCHES
>> +	$(APPLY_PATCHES) $(@D) $(@D)/debian/patches
>> +endef
>> +
>> +UNSCD_POST_PATCH_HOOKS += UNSCD_APPLY_DEBIAN_PATCHES
> 
> This doesn't work because the patches don't end with an extension that
> is recognized by our apply-patch script. So all what you see is:
> 
>>>> unscd 0.51 Patching
> support/scripts/apply-patches.sh  /home/thomas/projets/buildroot/output/build/unscd-0.51 /home/thomas/projets/buildroot/output/build/unscd-0.51/debian/patches
> Unsupported file type for /home/thomas/projets/buildroot/output/build/unscd-0.51/debian/patches/change_invalidate_request_info_output, skipping
> Unsupported file type for /home/thomas/projets/buildroot/output/build/unscd-0.51/debian/patches/support_large_numbers_in_config, skipping

 Uh, that shouldn't happen, since 7caf464 everything in the series file should
be applied regardless of name...

> 
> which makes the entire dance around applying the Debian patches useless.
> 
> Unfortunately, fixing this requires fixing our apply-patches script.

 Which I did :-)


 Regards,
 Arnout

> Generally speaking, I am not super happy with all the logic we need to
> add in various packages to get them to apply the Debian patches. But
> Debian packages vary quite a bit in the way the patches are organized,
> so I don't know if it's doable to fix.
> 
> BTW any reason to not use the upstream version, at
> http://busybox.net/~vda/unscd/nscd-0.52.c, which is higher than 0.51 ?
> 
> Can you look into this patching issue (or alternatively use 0.52 with
> no patches) and send an updated version ?
> 
> Thanks !
> 
> Thomas
> 


-- 
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:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH v5 1/2] package/unscd: new package

[Thomas Petazzoni]

Arnout,

On Mon, 30 Nov 2015 23:17:18 +0100, Arnout Vandecappelle wrote:

> >>>> unscd 0.51 Patching
> > support/scripts/apply-patches.sh  /home/thomas/projets/buildroot/output/build/unscd-0.51 /home/thomas/projets/buildroot/output/build/unscd-0.51/debian/patches
> > Unsupported file type for /home/thomas/projets/buildroot/output/build/unscd-0.51/debian/patches/change_invalidate_request_info_output, skipping
> > Unsupported file type for /home/thomas/projets/buildroot/output/build/unscd-0.51/debian/patches/support_large_numbers_in_config, skipping
> 
>  Uh, that shouldn't happen, since 7caf464 everything in the series file should
> be applied regardless of name...

I tested on top of next, so it should have worked... but it did not. I
didn't check if the patches were actually applied, but it is clear that
this message was displayed, since I copy/pasted from my terminal.

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

[Buildroot] [PATCH v5 1/2] package/unscd: new package

[Arnout Vandecappelle]

On 30-11-15 23:22, Thomas Petazzoni wrote:
> Arnout,
> 
> On Mon, 30 Nov 2015 23:17:18 +0100, Arnout Vandecappelle wrote:
> 
>>>>>> unscd 0.51 Patching
>>> support/scripts/apply-patches.sh  /home/thomas/projets/buildroot/output/build/unscd-0.51 /home/thomas/projets/buildroot/output/build/unscd-0.51/debian/patches
>>> Unsupported file type for /home/thomas/projets/buildroot/output/build/unscd-0.51/debian/patches/change_invalidate_request_info_output, skipping
>>> Unsupported file type for /home/thomas/projets/buildroot/output/build/unscd-0.51/debian/patches/support_large_numbers_in_config, skipping
>>
>>  Uh, that shouldn't happen, since 7caf464 everything in the series file should
>> be applied regardless of name...
> 
> I tested on top of next, so it should have worked... but it did not. I
> didn't check if the patches were actually applied, but it is clear that
> this message was displayed, since I copy/pasted from my terminal.

 7caf464 was applied to master only, and there has been no merge from master to
next. So that explains it.

 next will be gone soon so don't worry ;-)

 Regards,
 Arnout

-- 
Arnout Vandecappelle      arnout dot vandecappelle at essensium dot com
Senior Embedded Software Architect . . . . . . +32-478-010353 (mobile)
Essensium, Mind division . . . . . . . . . . . . . . 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:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH v5 1/2] package/unscd: new package

[Thomas Petazzoni]

Hello,

On Mon, 30 Nov 2015 23:24:12 +0100, Arnout Vandecappelle wrote:

>  7caf464 was applied to master only, and there has been no merge from master to
> next. So that explains it.

Ah damn, ok.

>  next will be gone soon so don't worry ;-)

Indeed.

Doug: can you resend a new version of the unscd patch, without the
attempt to integrate the installation of the glibc provided nscd
daemon? This way, we can merge unscd quickly, and then work on
installing the one from glibc if you are interested.

Thanks!

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

[Buildroot] [PATCH v5 1/2] package/unscd: new package

[rdkehn at yahoo.com]

Hi Thomas,

On Mon, Nov 30, 2015 at 11:44:21PM +0100, Thomas Petazzoni wrote:
> Hello,
> 
> On Mon, 30 Nov 2015 23:24:12 +0100, Arnout Vandecappelle wrote:
> 
> >  7caf464 was applied to master only, and there has been no merge from master to
> > next. So that explains it.
> 
> Ah damn, ok.
> 
> >  next will be gone soon so don't worry ;-)
> 
> Indeed.
> 
> Doug: can you resend a new version of the unscd patch, without the
> attempt to integrate the installation of the glibc provided nscd
> daemon? This way, we can merge unscd quickly, and then work on
> installing the one from glibc if you are interested.

Yes, I will resend, after incorporating/updating to 0.52 as
suggested.

Regards,
...doug