[Buildroot] [PATCH 1/2] samba: deprecate package due to EOL

[Buildroot] [PATCH 1/2] samba: deprecate package due to EOL

[Gustavo Zacarias]

Samba 3.6.x is now EOL, people should move to samba4.

See: https://www.samba.org/samba/history/samba-4.2.0.html

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 package/samba/Config.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/samba/Config.in b/package/samba/Config.in
index 9d04851..7ff8428 100644
--- a/package/samba/Config.in
+++ b/package/samba/Config.in
@@ -1,5 +1,6 @@
 config BR2_PACKAGE_SAMBA
 	bool "samba"
+	depends on BR2_DEPRECATED_SINCE_2015_05
 	depends on BR2_TOOLCHAIN_HAS_THREADS
 	depends on BR2_USE_MMU # fork()
 	depends on !BR2_nios2 # binary too large, relocations don't fit
@@ -15,6 +16,7 @@ config BR2_PACKAGE_SAMBA
 		so choose only the components you need.
 
 comment "samba needs a toolchain w/ threads"
+	depends on BR2_DEPRECATED_SINCE_2015_05
 	depends on BR2_USE_MMU
 	depends on !BR2_TOOLCHAIN_HAS_THREADS
 
-- 
2.0.5

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Gustavo Zacarias]

Now with support for AD DC, ADS and clustering features.
All dropped patches are upstream.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 ...001-build-find-FILE_OFFSET_BITS-via-array.patch |  56 -------
 ...able-libbsd.patch => 0001-disable-libbsd.patch} |  12 +-
 ...uild-allow-some-python-variable-overrides.patch |  47 ------
 .../0003-build-find-blkcnt_t-size-via-array.patch  |  54 -------
 .../0004-build-unify-and-fix-endian-tests.patch    | 165 ---------------------
 ...fsamba-CHECK_SIZEOF-cross-compile-friendl.patch |  68 ---------
 .../0006-build-tweak-SIZEOF-utmp-ut_line.patch     |  33 -----
 package/samba4/Config.in                           |  35 +++--
 package/samba4/samba4.hash                         |   2 +-
 package/samba4/samba4.mk                           | 100 +++++++------
 10 files changed, 91 insertions(+), 481 deletions(-)
 delete mode 100644 package/samba4/0001-build-find-FILE_OFFSET_BITS-via-array.patch
 rename package/samba4/{0007-disable-libbsd.patch => 0001-disable-libbsd.patch} (66%)
 delete mode 100644 package/samba4/0002-build-allow-some-python-variable-overrides.patch
 delete mode 100644 package/samba4/0003-build-find-blkcnt_t-size-via-array.patch
 delete mode 100644 package/samba4/0004-build-unify-and-fix-endian-tests.patch
 delete mode 100644 package/samba4/0005-build-make-wafsamba-CHECK_SIZEOF-cross-compile-friendl.patch
 delete mode 100644 package/samba4/0006-build-tweak-SIZEOF-utmp-ut_line.patch

diff --git a/package/samba4/0001-build-find-FILE_OFFSET_BITS-via-array.patch b/package/samba4/0001-build-find-FILE_OFFSET_BITS-via-array.patch
deleted file mode 100644
index 8dae44d..0000000
--- a/package/samba4/0001-build-find-FILE_OFFSET_BITS-via-array.patch
+++ /dev/null
@@ -1,56 +0,0 @@
-From 16d88e7813a7739c070a7a1cf6388fd4f236fd99 Mon Sep 17 00:00:00 2001
-From: Gustavo Zacarias <gustavo@zacarias.com.ar>
-Date: Fri, 31 Jan 2014 06:45:18 -0300
-Subject: [PATCHv2] build: find FILE_OFFSET_BITS via array
-
-This makes cross-compiling happy, use a trick similar to autoconf's
-AC_CHECK_SIZEOF macro.
-Basically we make an array:
-
-static int array[1 - 2 * !(((long int)(sizeof(off_t))) < 8)];
-
-This gives -1 multiplied by the negation of the condition
-(sizeof(off_t) < 8) cast to a long int.
-So if the condition is true it gives array[(-1 * 0)] (remember the
-condition is cast and negated) thus passing a build test with a 0-sized
-array.
-If it's false it gives array[(-1 * 1)] thus failing with a
-negative-sized array.
-
-Status: Upstream.
-
-Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
----
- lib/ccan/wscript | 11 +++++++----
- 1 file changed, 7 insertions(+), 4 deletions(-)
-
-diff --git a/lib/ccan/wscript b/lib/ccan/wscript
-index 59b8205..81039d0 100644
---- a/lib/ccan/wscript
-+++ b/lib/ccan/wscript
-@@ -127,15 +127,18 @@ def configure(conf):
-     # Only check for FILE_OFFSET_BITS=64 if off_t is normally small:
-     # use raw routines because wrappers include previous _GNU_SOURCE
-     # or _FILE_OFFSET_BITS defines.
-+    # The math for these tests is:
-+    # array[-1 * !((int)(condition)) ] (condition is true) = array[0] = builds
-+    # array[-1 * !((int)(condition)) ] (condition is false) = array[-1] = fails
-     conf.check(fragment="""#include <sys/types.h>
--               int main(void) { return !(sizeof(off_t) < 8); }""",
--               execute=True, msg='Checking for small off_t',
-+               int main(void) { static int test_array[1 - 2 * !(((long int)(sizeof(off_t))) < 8)]; }""",
-+               msg='Checking for small off_t',
-                define_name='SMALL_OFF_T')
-     # Unreliable return value above, hence use define.
-     if conf.CONFIG_SET('SMALL_OFF_T'):
-         conf.check(fragment="""#include <sys/types.h>
--                   int main(void) { return !(sizeof(off_t) >= 8); }""",
--                   execute=True, msg='Checking for -D_FILE_OFFSET_BITS=64',
-+		   int main(void) { static int test_array[1 - 2 * !(((long int)(sizeof(off_t))) >= 8)]; }""",
-+                   msg='Checking for -D_FILE_OFFSET_BITS=64',
-                    ccflags='-D_FILE_OFFSET_BITS=64',
-                    define_name='HAVE_FILE_OFFSET_BITS')
- 
--- 
-1.8.3.2
-
diff --git a/package/samba4/0007-disable-libbsd.patch b/package/samba4/0001-disable-libbsd.patch
similarity index 66%
rename from package/samba4/0007-disable-libbsd.patch
rename to package/samba4/0001-disable-libbsd.patch
index b29a812..67f79d0 100644
--- a/package/samba4/0007-disable-libbsd.patch
+++ b/package/samba4/0001-disable-libbsd.patch
@@ -5,10 +5,10 @@ and bsd/unistd.h get included.
 
 Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
 
-diff -Nura samba-4.1.7.orig/lib/replace/wscript samba-4.1.7/lib/replace/wscript
---- samba-4.1.7.orig/lib/replace/wscript	2014-04-17 04:59:14.000000000 -0300
-+++ samba-4.1.7/lib/replace/wscript	2014-05-19 09:17:25.561947774 -0300
-@@ -253,15 +253,6 @@
+diff -Nura samba-4.2.0rc1.orig/lib/replace/wscript samba-4.2.0rc1/lib/replace/wscript
+--- samba-4.2.0rc1.orig/lib/replace/wscript	2014-10-01 06:17:32.000000000 -0300
++++ samba-4.2.0rc1/lib/replace/wscript	2014-10-01 07:21:13.559498987 -0300
+@@ -282,15 +282,6 @@
      conf.CHECK_FUNCS('strtouq strtoll __strtoll strtoq memalign posix_memalign')
      conf.CHECK_FUNCS('prctl')
  
@@ -18,8 +18,8 @@ diff -Nura samba-4.1.7.orig/lib/replace/wscript samba-4.1.7/lib/replace/wscript
 -                checklibc=True)
 -    if not conf.CHECK_FUNCS('getpeereid'):
 -        conf.CHECK_FUNCS_IN('getpeereid', 'bsd', headers='sys/types.h bsd/unistd.h')
--    if not conf.CHECK_FUNCS_IN('setproctitle', 'bsd', headers='sys/types.h bsd/unistd.h'):
--        conf.CHECK_FUNCS_IN('setproctitle', 'setproctitle', headers='setproctitle.h')
+-    if not conf.CHECK_FUNCS_IN('setproctitle', 'setproctitle', headers='setproctitle.h'):
+-        conf.CHECK_FUNCS_IN('setproctitle', 'bsd', headers='sys/types.h bsd/unistd.h')
 -
      conf.CHECK_CODE('''
                  struct ucred cred;
diff --git a/package/samba4/0002-build-allow-some-python-variable-overrides.patch b/package/samba4/0002-build-allow-some-python-variable-overrides.patch
deleted file mode 100644
index 91634b9..0000000
--- a/package/samba4/0002-build-allow-some-python-variable-overrides.patch
+++ /dev/null
@@ -1,47 +0,0 @@
-From fdbdf04a9ab3f3a204e95106c4f8f6729d0bab1a Mon Sep 17 00:00:00 2001
-From: Gustavo Zacarias <gustavo@zacarias.com.ar>
-Date: Tue, 4 Feb 2014 14:11:52 -0300
-Subject: [PATCH] build: allow some python variable overrides
-
-The python variables (settings) are fetched from a running python
-interpreter which usually isn't the target one when cross compiling,
-hence libraries and flags aren't the same and can pollute the target
-build.
-Allow some of these variables to be redefined via environment variables
-in order to aid cross-compiling.
-According to testing python_LDFLAGS and python_LIBDIR should be enough.
-
-Status: Upstream.
-
-Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
----
- buildtools/wafadmin/Tools/python.py | 13 +++++++++++++
- 1 file changed, 13 insertions(+)
-
-diff --git a/buildtools/wafadmin/Tools/python.py b/buildtools/wafadmin/Tools/python.py
-index ab1e817..35c61c2 100644
---- a/buildtools/wafadmin/Tools/python.py
-+++ b/buildtools/wafadmin/Tools/python.py
-@@ -193,6 +193,19 @@ MACOSX_DEPLOYMENT_TARGET = %r
- """ % (python, python_prefix, python_SO, python_SYSLIBS, python_LDFLAGS, python_SHLIBS,
- 	python_LIBDIR, python_LIBPL, INCLUDEPY, Py_ENABLE_SHARED, python_MACOSX_DEPLOYMENT_TARGET))
- 
-+	# Allow some python overrides from env vars for cross-compiling
-+	os_env = dict(os.environ)
-+
-+	override_python_LDFLAGS = os_env.get('python_LDFLAGS', None)
-+	if override_python_LDFLAGS is not None:
-+		conf.log.write("python_LDFLAGS override from environment = %r\n" % (override_python_LDFLAGS))
-+		python_LDFLAGS = override_python_LDFLAGS
-+
-+	override_python_LIBDIR = os_env.get('python_LIBDIR', None)
-+	if override_python_LIBDIR is not None:
-+		conf.log.write("python_LIBDIR override from environment = %r\n" % (override_python_LIBDIR))
-+		python_LIBDIR = override_python_LIBDIR
-+
- 	if python_MACOSX_DEPLOYMENT_TARGET:
- 		conf.env['MACOSX_DEPLOYMENT_TARGET'] = python_MACOSX_DEPLOYMENT_TARGET
- 		conf.environ['MACOSX_DEPLOYMENT_TARGET'] = python_MACOSX_DEPLOYMENT_TARGET
--- 
-1.8.3.2
-
diff --git a/package/samba4/0003-build-find-blkcnt_t-size-via-array.patch b/package/samba4/0003-build-find-blkcnt_t-size-via-array.patch
deleted file mode 100644
index f6e4d03..0000000
--- a/package/samba4/0003-build-find-blkcnt_t-size-via-array.patch
+++ /dev/null
@@ -1,54 +0,0 @@
-From 934f8c8e9439de4f15b2e61016d5d29233d8d5fa Mon Sep 17 00:00:00 2001
-From: Gustavo Zacarias <gustavo@zacarias.com.ar>
-Date: Wed, 16 Apr 2014 08:01:36 -0300
-Subject: [PATCH 5/5] build: find blkcnt_t size via array
-
-Using the same trick as commit 0d9bb86293c9d39298786df095c73a6251b08b7e
-find blkcnt_t size via an array so that it can be determined via build
-rather than running it.
-
-Status: Upstream.
-
-Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
----
- source3/wscript | 22 ++++++++++++----------
- 1 file changed, 12 insertions(+), 10 deletions(-)
-
-diff --git a/source3/wscript b/source3/wscript
-index aade503..6a5728f 100644
---- a/source3/wscript
-+++ b/source3/wscript
-@@ -277,18 +277,20 @@ int main(int argc, char **argv)
-                                 headers='sys/types.h sys/stat.h unistd.h')
- 
-     if "HAVE_BLKCNT_T" in conf.env:
--	conf.CHECK_CODE('''
--	return sizeof(blkcnt_t) == 4 ? 0 : 1''',
--		'SIZEOF_BLKCNT_T_4', execute=True,
--		headers='replace.h sys/types.h sys/stat.h unistd.h',
--		msg="Checking whether blkcnt_t is 32 bit")
-+        conf.CHECK_CODE('''
-+        static int test_array[1 - 2 * !(((long int)(sizeof(blkcnt_t))) <= 4)];''',
-+                'SIZEOF_BLKCNT_T_4',
-+                headers='replace.h sys/types.h sys/stat.h unistd.h',
-+                msg="Checking whether blkcnt_t is 32 bit")
- 
-+    # If sizeof is 4 it can't be 8
-     if "HAVE_BLKCNT_T" in conf.env:
--	conf.CHECK_CODE('''
--	return sizeof(blkcnt_t) == 8 ? 0 : 1''',
--		'SIZEOF_BLKCNT_T_8', execute=True,
--		headers='replace.h sys/types.h sys/stat.h unistd.h',
--		msg="Checking whether blkcnt_t is 64 bit")
-+        if not conf.CONFIG_SET('SIZEOF_BLKCNT_T_4'):
-+            conf.CHECK_CODE('''
-+            static int test_array[1 - 2 * !(((long int)(sizeof(blkcnt_t))) <= 8)];''',
-+                    'SIZEOF_BLKCNT_T_8',
-+                    headers='replace.h sys/types.h sys/stat.h unistd.h',
-+                    msg="Checking whether blkcnt_t is 64 bit")
- 
-     # Check for POSIX capability support
-     conf.CHECK_FUNCS_IN('cap_get_proc', 'cap', headers='sys/capability.h')
--- 
-1.8.3.2
-
diff --git a/package/samba4/0004-build-unify-and-fix-endian-tests.patch b/package/samba4/0004-build-unify-and-fix-endian-tests.patch
deleted file mode 100644
index 3fdfe6e..0000000
--- a/package/samba4/0004-build-unify-and-fix-endian-tests.patch
+++ /dev/null
@@ -1,165 +0,0 @@
-From ee4e06b7223fb2925bc887c89216a66029d44862 Mon Sep 17 00:00:00 2001
-From: Gustavo Zacarias <gustavo@zacarias.com.ar>
-Date: Tue, 1 Apr 2014 06:41:47 -0300
-Subject: [PATCH 2/5] build: unify and fix endian tests
-
-Unify the endian tests out of lib/ccan/wscript into wafsamba since
-they're almost cross-compile friendly.
-While at it fix them to be so by moving the preprocessor directives out
-of main scope since that will fail.
-And keep the WORDS_BIGENDIAN, HAVE_LITTLE_ENDIAN and HAVE_BIG_ENDIAN
-defines separate because of different codebases.
-
-Status: Upstream.
-
-Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
----
- buildtools/wafsamba/wscript | 65 ++++++++++++++++++++++++++++++++++++++++++---
- lib/ccan/wscript            | 55 --------------------------------------
- 2 files changed, 62 insertions(+), 58 deletions(-)
-
-diff --git a/buildtools/wafsamba/wscript b/buildtools/wafsamba/wscript
-index 7984227..1a2cfe6 100755
---- a/buildtools/wafsamba/wscript
-+++ b/buildtools/wafsamba/wscript
-@@ -390,9 +390,68 @@ def configure(conf):
-     else:
-         conf.define('SHLIBEXT', "so", quote=True)
- 
--    conf.CHECK_CODE('long one = 1; return ((char *)(&one))[0]',
--                    execute=True,
--                    define='WORDS_BIGENDIAN')
-+    # First try a header check for cross-compile friendlyness
-+    conf.CHECK_CODE(code = """#ifdef __BYTE_ORDER
-+                        #define B __BYTE_ORDER
-+                        #elif defined(BYTE_ORDER)
-+                        #define B BYTE_ORDER
-+                        #endif
-+
-+                        #ifdef __LITTLE_ENDIAN
-+                        #define LITTLE __LITTLE_ENDIAN
-+                        #elif defined(LITTLE_ENDIAN)
-+                        #define LITTLE LITTLE_ENDIAN
-+                        #endif
-+
-+                        #if !defined(LITTLE) || !defined(B) || LITTLE != B
-+                        #error Not little endian.
-+                        #endif
-+                        int main(void) { return 0; }""",
-+                            addmain=False,
-+                            headers="endian.h sys/endian.h",
-+                            define="HAVE_LITTLE_ENDIAN")
-+    conf.CHECK_CODE(code = """#ifdef __BYTE_ORDER
-+                        #define B __BYTE_ORDER
-+                        #elif defined(BYTE_ORDER)
-+                        #define B BYTE_ORDER
-+                        #endif
-+
-+                        #ifdef __BIG_ENDIAN
-+                        #define BIG __BIG_ENDIAN
-+                        #elif defined(BIG_ENDIAN)
-+                        #define BIG BIG_ENDIAN
-+                        #endif
-+
-+                        #if !defined(BIG) || !defined(B) || BIG != B
-+                        #error Not big endian.
-+                        #endif
-+                        int main(void) { return 0; }""",
-+                            addmain=False,
-+                            headers="endian.h sys/endian.h",
-+                            define="HAVE_BIG_ENDIAN")
-+
-+    if not conf.CONFIG_SET("HAVE_BIG_ENDIAN") and not conf.CONFIG_SET("HAVE_LITTLE_ENDIAN"):
-+        # That didn't work!  Do runtime test.
-+        conf.CHECK_CODE("""union { int i; char c[sizeof(int)]; } u;
-+            u.i = 0x01020304;
-+            return u.c[0] == 0x04 && u.c[1] == 0x03 && u.c[2] == 0x02 && u.c[3] == 0x01 ? 0 : 1;""",
-+                          addmain=True, execute=True,
-+                          define='HAVE_LITTLE_ENDIAN',
-+                          msg="Checking for HAVE_LITTLE_ENDIAN - runtime")
-+        conf.CHECK_CODE("""union { int i; char c[sizeof(int)]; } u;
-+            u.i = 0x01020304;
-+            return u.c[0] == 0x01 && u.c[1] == 0x02 && u.c[2] == 0x03 && u.c[3] == 0x04 ? 0 : 1;""",
-+                          addmain=True, execute=True,
-+                          define='HAVE_BIG_ENDIAN',
-+                          msg="Checking for HAVE_BIG_ENDIAN - runtime")
-+
-+    # Extra sanity check.
-+    if conf.CONFIG_SET("HAVE_BIG_ENDIAN") == conf.CONFIG_SET("HAVE_LITTLE_ENDIAN"):
-+        Logs.error("Failed endian determination.  The PDP-11 is back?")
-+	sys.exit(1)
-+    else:
-+        if conf.CONFIG_SET("HAVE_BIG_ENDIAN"):
-+            conf.DEFINE('WORDS_BIGENDIAN', 1)
- 
-     # check if signal() takes a void function
-     if conf.CHECK_CODE('return *(signal (0, 0)) (0) == 1',
-diff --git a/lib/ccan/wscript b/lib/ccan/wscript
-index 1c5f337..0e540db 100644
---- a/lib/ccan/wscript
-+++ b/lib/ccan/wscript
-@@ -25,61 +25,6 @@ def configure(conf):
-     conf.CHECK_CODE('int __attribute__((used)) func(int x) { return x; }',
-                     addmain=False, link=False, cflags=conf.env['WERROR_CFLAGS'],
-                     define='HAVE_ATTRIBUTE_USED')
--    # We try to use headers for a compile-time test.
--    conf.CHECK_CODE(code = """#ifdef __BYTE_ORDER
--                        #define B __BYTE_ORDER
--                        #elif defined(BYTE_ORDER)
--                        #define B BYTE_ORDER
--                        #endif
--
--                        #ifdef __LITTLE_ENDIAN
--                        #define LITTLE __LITTLE_ENDIAN
--                        #elif defined(LITTLE_ENDIAN)
--                        #define LITTLE LITTLE_ENDIAN
--                        #endif
--
--                        #if !defined(LITTLE) || !defined(B) || LITTLE != B
--                        #error Not little endian.
--                        #endif""",
--                           headers="endian.h sys/endian.h",
--                           define="HAVE_LITTLE_ENDIAN")
--    conf.CHECK_CODE(code = """#ifdef __BYTE_ORDER
--                        #define B __BYTE_ORDER
--                        #elif defined(BYTE_ORDER)
--                        #define B BYTE_ORDER
--                        #endif
--
--                        #ifdef __BIG_ENDIAN
--                        #define BIG __BIG_ENDIAN
--                        #elif defined(BIG_ENDIAN)
--                        #define BIG BIG_ENDIAN
--                        #endif
--
--                        #if !defined(BIG) || !defined(B) || BIG != B
--                        #error Not big endian.
--                        #endif""",
--                           headers="endian.h sys/endian.h",
--                           define="HAVE_BIG_ENDIAN")
--
--    if not conf.CONFIG_SET("HAVE_BIG_ENDIAN") and not conf.CONFIG_SET("HAVE_LITTLE_ENDIAN"):
--        # That didn't work!  Do runtime test.
--        conf.CHECK_CODE("""union { int i; char c[sizeof(int)]; } u;
--	  u.i = 0x01020304;
--	  return u.c[0] == 0x04 && u.c[1] == 0x03 && u.c[2] == 0x02 && u.c[3] == 0x01 ? 0 : 1;""",
--                        addmain=True, execute=True,
--                        define='HAVE_LITTLE_ENDIAN',
--                        msg="Checking for HAVE_LITTLE_ENDIAN - runtime")
--        conf.CHECK_CODE("""union { int i; char c[sizeof(int)]; } u;
--	  u.i = 0x01020304;
--	  return u.c[0] == 0x01 && u.c[1] == 0x02 && u.c[2] == 0x03 && u.c[3] == 0x04 ? 0 : 1;""",
--                        addmain=True, execute=True,
--                        define='HAVE_BIG_ENDIAN',
--                        msg="Checking for HAVE_BIG_ENDIAN - runtime")
--
--    # Extra sanity check.
--    if conf.CONFIG_SET("HAVE_BIG_ENDIAN") == conf.CONFIG_SET("HAVE_LITTLE_ENDIAN"):
--        Logs.error("Failed endian determination.  The PDP-11 is back?")
--        sys.exit(1)
- 
-     conf.CHECK_CODE('return __builtin_choose_expr(1, 0, "garbage");',
-                     link=True,
--- 
-1.8.3.2
-
diff --git a/package/samba4/0005-build-make-wafsamba-CHECK_SIZEOF-cross-compile-friendl.patch b/package/samba4/0005-build-make-wafsamba-CHECK_SIZEOF-cross-compile-friendl.patch
deleted file mode 100644
index 72176cb..0000000
--- a/package/samba4/0005-build-make-wafsamba-CHECK_SIZEOF-cross-compile-friendl.patch
+++ /dev/null
@@ -1,68 +0,0 @@
-From fd3eb1e9f712e4c96c0b55d4203745afb2bcc8c2 Mon Sep 17 00:00:00 2001
-From: Gustavo Zacarias <gustavo@zacarias.com.ar>
-Date: Wed, 9 Apr 2014 10:21:59 -0300
-Subject: [PATCH 3/5] build: make wafsamba CHECK_SIZEOF cross-compile friendly
-
-Use the same trick as commit 0d9bb86293c9d39298786df095c73a6251b08b7e
-We do the same array trick iteratively starting from 1 (byte) by powers
-of 2 up to 32.
-
-The new 'critical' option is used to make the invocation die or not
-according to each test.
-The default is True since normally it's expected to find a proper
-result and should error out if not.
-
-Status: Upstream.
-
-Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
----
- buildtools/wafsamba/samba_autoconf.py | 28 ++++++++++++++++------------
- 1 file changed, 16 insertions(+), 12 deletions(-)
-
-diff --git a/buildtools/wafsamba/samba_autoconf.py b/buildtools/wafsamba/samba_autoconf.py
-index 59d9e79..f60ce9d 100644
---- a/buildtools/wafsamba/samba_autoconf.py
-+++ b/buildtools/wafsamba/samba_autoconf.py
-@@ -304,23 +304,27 @@ def CHECK_FUNCS(conf, list, link=True, lib=None, headers=None):
- 
- 
- @conf
--def CHECK_SIZEOF(conf, vars, headers=None, define=None):
-+def CHECK_SIZEOF(conf, vars, headers=None, define=None, critical=True):
-     '''check the size of a type'''
--    ret = True
-     for v in TO_LIST(vars):
-         v_define = define
-+        ret = False
-         if v_define is None:
-             v_define = 'SIZEOF_%s' % v.upper().replace(' ', '_')
--        if not CHECK_CODE(conf,
--                          'printf("%%u", (unsigned)sizeof(%s))' % v,
--                          define=v_define,
--                          execute=True,
--                          define_ret=True,
--                          quote=False,
--                          headers=headers,
--                          local_include=False,
--                          msg="Checking size of %s" % v):
--            ret = False
-+        for size in list((1, 2, 4, 8, 16, 32)):
-+            if CHECK_CODE(conf,
-+                      'static int test_array[1 - 2 * !(((long int)(sizeof(%s))) <= %d)];' % (v, size),
-+                      define=v_define,
-+                      quote=False,
-+                      headers=headers,
-+                      local_include=False,
-+                      msg="Checking if size of %s == %d" % (v, size)):
-+                conf.DEFINE(v_define, size)
-+                ret = True
-+                break
-+        if not ret and critical:
-+            Logs.error("Couldn't determine size of '%s'" % v)
-+            sys.exit(1)
-     return ret
- 
- @conf
--- 
-1.8.3.2
-
diff --git a/package/samba4/0006-build-tweak-SIZEOF-utmp-ut_line.patch b/package/samba4/0006-build-tweak-SIZEOF-utmp-ut_line.patch
deleted file mode 100644
index 28f5f10..0000000
--- a/package/samba4/0006-build-tweak-SIZEOF-utmp-ut_line.patch
+++ /dev/null
@@ -1,33 +0,0 @@
-From 1a7f4f5e3fbbe83e147fffdfe00d7f37181a8ec1 Mon Sep 17 00:00:00 2001
-From: Gustavo Zacarias <gustavo@zacarias.com.ar>
-Date: Wed, 9 Apr 2014 10:39:06 -0300
-Subject: [PATCH 4/5] build: tweak SIZEOF utmp->ut_line
-
-Set the critical parameter of CHECK_SIZEOF utmp->ut_line to False since
-it's used to find out if utmp support should be enabled.
-This is necessary with the introduction of the cross-compile aware
-CHECK_SIZEOF.
-
-Status: Upstream.
-
-Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
----
- source3/wscript | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/source3/wscript b/source3/wscript
-index e81a47b..aade503 100644
---- a/source3/wscript
-+++ b/source3/wscript
-@@ -812,7 +812,7 @@ msg.msg_acctrightslen = sizeof(fd);
-                         'PUTUTLINE_RETURNS_UTMP', headers='utmp.h',
-                         msg="Checking whether pututline returns pointer")
-         conf.CHECK_SIZEOF(['((struct utmp *)NULL)->ut_line'], headers='utmp.h',
--                          define='SIZEOF_UTMP_UT_LINE')
-+                          define='SIZEOF_UTMP_UT_LINE', critical=False)
-         if not conf.CONFIG_SET('SIZEOF_UTMP_UT_LINE'):
-             conf.env.with_utmp = False
-         elif int(conf.env.SIZEOF_UTMP_UT_LINE) < 15:
--- 
-1.8.3.2
-
diff --git a/package/samba4/Config.in b/package/samba4/Config.in
index b841f42..5a83ab8 100644
--- a/package/samba4/Config.in
+++ b/package/samba4/Config.in
@@ -1,11 +1,10 @@
+comment "samba4 needs an (e)glibc toolchain"
+	depends on !BR2_TOOLCHAIN_USES_GLIBC
+
 config BR2_PACKAGE_SAMBA4
 	bool "samba4"
 	depends on !BR2_PACKAGE_SAMBA
-	depends on BR2_INET_IPV6
-	depends on BR2_USE_MMU # fork()
-	depends on BR2_USE_WCHAR # e2fsprogs
-	depends on BR2_LARGEFILE
-	depends on BR2_TOOLCHAIN_HAS_THREADS # talloc python threads
+	depends on BR2_TOOLCHAIN_USES_GLIBC # needs nss.h, $ORIGIN support
 	depends on !BR2_nios2 # binary too large, relocations don't fit
 	select BR2_PACKAGE_E2FSPROGS
 	select BR2_PACKAGE_POPT
@@ -18,7 +17,25 @@ config BR2_PACKAGE_SAMBA4
 
 	  http://www.samba.org/
 
-comment "samba4 needs a toolchain w/ IPv6, wchar, largfile, threads"
-	depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_LARGEFILE || \
-		!BR2_USE_WCHAR || !BR2_INET_IPV6
-	depends on BR2_USE_MMU
+if BR2_PACKAGE_SAMBA4
+
+config BR2_PACKAGE_SAMBA4_AD_DC
+	bool "AD DC"
+	select BR2_PACKAGE_GNUTLS
+	help
+	  Enable Active Directory Domain Controller functionality.
+
+config BR2_PACKAGE_SAMBA4_ADS
+	bool "ADS"
+	select BR2_PACKAGE_OPENLDAP
+	help
+	  Enable Active Directory member Server functionality.
+
+config BR2_PACKAGE_SAMBA4_SMBTORTURE
+	bool "smbtorture"
+	help
+	  Install the smbtorture test suite.
+	  It's normally used for validation and stress testing.
+	  Approximately +5 MB of stripped uncompressed target space.
+
+endif
diff --git a/package/samba4/samba4.hash b/package/samba4/samba4.hash
index 721c3dc..3dbea5a 100644
--- a/package/samba4/samba4.hash
+++ b/package/samba4/samba4.hash
@@ -1,2 +1,2 @@
 # Locally calculated after checking pgp signature
-sha256	7aeb5d09e9c84bbeeb4b98d33404e9dbc4d99c54e64a447cc9c4d57e9255cb1d	samba-4.1.17.tar.gz
+sha256	66a6057815a971fee64fbe936ff6cbad542421a4bd52cba8d8d41afc9abc490f	samba-4.2.0.tar.gz
diff --git a/package/samba4/samba4.mk b/package/samba4/samba4.mk
index bd8ed12..cb6ff0a 100644
--- a/package/samba4/samba4.mk
+++ b/package/samba4/samba4.mk
@@ -4,8 +4,8 @@
 #
 ################################################################################
 
-SAMBA4_VERSION = 4.1.17
-SAMBA4_SITE = http://ftp.samba.org/pub/samba/stable
+SAMBA4_VERSION = 4.2.0
+SAMBA4_SITE = http://ftp.samba.org/pub/samba
 SAMBA4_SOURCE = samba-$(SAMBA4_VERSION).tar.gz
 SAMBA4_LICENSE = GPLv3+
 SAMBA4_LICENSE_FILES = COPYING
@@ -14,61 +14,63 @@ SAMBA4_DEPENDENCIES = host-e2fsprogs host-heimdal e2fsprogs popt python zlib \
 	$(if $(BR2_PACKAGE_READLINE),readline)
 
 ifeq ($(BR2_PACKAGE_ACL),y)
-	SAMBA4_CONF_OPTS += --with-acl-support
-	SAMBA4_DEPENDENCIES += acl
+SAMBA4_CONF_OPTS += --with-acl-support
+SAMBA4_DEPENDENCIES += acl
 else
-	SAMBA4_CONF_OPTS += --without-acl-support
+SAMBA4_CONF_OPTS += --without-acl-support
 endif
 
 ifeq ($(BR2_PACKAGE_CUPS),y)
-	SAMBA4_CONF_ENV += CUPS_CONFIG="$(STAGING_DIR)/usr/bin/cups-config"
-	SAMBA4_CONF_OPTS += --enable-cups
-	SAMBA4_DEPENDENCIES += cups
+SAMBA4_CONF_ENV += CUPS_CONFIG="$(STAGING_DIR)/usr/bin/cups-config"
+SAMBA4_CONF_OPTS += --enable-cups
+SAMBA4_DEPENDENCIES += cups
 else
-	SAMBA4_CONF_OPTS += --disable-cups
+SAMBA4_CONF_OPTS += --disable-cups
 endif
 
 ifeq ($(BR2_PACKAGE_LIBAIO),y)
-	SAMBA4_CONF_OPTS += --with-aio-support
-	SAMBA4_DEPENDENCIES += libaio
+SAMBA4_CONF_OPTS += --with-aio-support
+SAMBA4_DEPENDENCIES += libaio
 else
-	SAMBA4_CONF_OPTS += --without-aio-support
+SAMBA4_CONF_OPTS += --without-aio-support
 endif
 
 ifeq ($(BR2_PACKAGE_DBUS)$(BR2_PACKAGE_AVAHI_DAEMON),yy)
-	SAMBA4_CONF_OPTS += --enable-avahi
-	SAMBA4_DEPENDENCIES += avahi
+SAMBA4_CONF_OPTS += --enable-avahi
+SAMBA4_DEPENDENCIES += avahi
 else
-	SAMBA4_CONF_OPTS += --disable-avahi
+SAMBA4_CONF_OPTS += --disable-avahi
 endif
 
 ifeq ($(BR2_PACKAGE_GAMIN),y)
-	SAMBA4_CONF_OPTS += --with-fam
-	SAMBA4_DEPENDENCIES += gamin
+SAMBA4_CONF_OPTS += --with-fam
+SAMBA4_DEPENDENCIES += gamin
 else
-	SAMBA4_CONF_OPTS += --without-fam
+SAMBA4_CONF_OPTS += --without-fam
 endif
 
 ifeq ($(BR2_PACKAGE_GETTEXT),y)
-	SAMBA4_CONF_OPTS += --with-gettext=$(STAGING_DIR)/usr
-	SAMBA4_DEPENDENCIES += gettext
+SAMBA4_CONF_OPTS += --with-gettext=$(STAGING_DIR)/usr
+SAMBA4_DEPENDENCIES += gettext
 else
-	SAMBA4_CONF_OPTS += --without-gettext
-endif
-
-ifeq ($(BR2_PACKAGE_GNUTLS),y)
-	SAMBA4_CONF_OPTS += --enable-gnutls
-	SAMBA4_DEPENDENCIES += gnutls
-else
-	SAMBA4_CONF_OPTS += --disable-gnutls
+SAMBA4_CONF_OPTS += --without-gettext
 endif
 
 ifeq ($(BR2_PACKAGE_NCURSES_TARGET_FORM)$(BR2_PACKAGE_NCURSES_TARGET_MENU)$(BR2_PACKAGE_NCURSES_TARGET_PANEL),yyy)
-	SAMBA4_DEPENDENCIES += ncurses
+SAMBA4_DEPENDENCIES += ncurses
 else
-	SAMBA4_CONF_OPTS += --without-regedit
+SAMBA4_CONF_OPTS += --without-regedit
 endif
 
+# The ctdb tests (cluster) need bash and take up some space
+# They're normally intended for debugging so remove them
+define SAMBA4_REMOVE_CTDB_TESTS
+	rm -rf $(TARGET_DIR)/usr/lib/ctdb-tests
+	rm -rf $(TARGET_DIR)/usr/share/ctdb-tests
+	rm -f $(TARGET_DIR)/usr/bin/ctdb_run_*tests
+endef
+SAMBA4_POST_INSTALL_TARGET_HOOKS += SAMBA4_REMOVE_CTDB_TESTS
+
 define SAMBA4_CONFIGURE_CMDS
 	cp package/samba4/samba4-cache.txt $(@D)/cache.txt;
 	echo 'Checking uname machine type: $(BR2_ARCH)' >>$(@D)/cache.txt;
@@ -93,9 +95,7 @@ define SAMBA4_CONFIGURE_CMDS
 			--without-pam \
 			--without-dmapi \
 			--disable-glusterfs \
-			--without-ldap \
-			--without-cluster-support \
-			--without-ads \
+			--with-cluster-support \
 			--bundled-libraries='!asn1_compile,!compile_et' \
 			$(SAMBA4_CONF_OPTS) \
 	)
@@ -119,18 +119,34 @@ endef
 SAMBA4_POST_INSTALL_TARGET_HOOKS += SAMBA4_BUILD_PYC_FILES
 endif
 
+ifeq ($(BR2_PACKAGE_SAMBA4_AD_DC),)
+SAMBA4_CONF_OPTS += --without-ad-dc
+endif
+
+ifeq ($(BR2_PACKAGE_GNUTLS),y)
+SAMBA4_CONF_OPTS += --enable-gnutls
+SAMBA4_DEPENDENCIES += gnutls
+else
+SAMBA4_CONF_OPTS += --disable-gnutls
+endif
+
+ifeq ($(BR2_PACKAGE_SAMBA4_ADS),y)
+SAMBA4_CONF_OPTS += --with-ads --with-ldap --with-shared-modules=idmap_ad
+SAMBA4_DEPENDENCIES += openldap
+else
+SAMBA4_CONF_OPTS += --without-ads --without-ldap
+endif
+
+ifeq ($(BR2_PACKAGE_SAMBA4_SMBTORTURE),)
+define SAMBA4_REMOVE_SMBTORTURE
+	rm -f $(TARGET_DIR)/usr/bin/smbtorture
+endef
+SAMBA4_POST_INSTALL_TARGET_HOOKS += SAMBA4_REMOVE_SMBTORTURE
+endif
+
 define SAMBA4_INSTALL_INIT_SYSV
 	$(INSTALL) -m 0755 -D package/samba4/S91smb \
 		$(TARGET_DIR)/etc/init.d/S91smb
 endef
 
-# uClibc doesn't honor $ORIGIN so we need to move a few libs
-ifeq ($(BR2_TOOLCHAIN_USES_UCLIBC),y)
-define SAMBA4_MOVE_LIBS
-	mv -f $(TARGET_DIR)/usr/lib/samba/libreplace* $(TARGET_DIR)/usr/lib
-	mv -f $(TARGET_DIR)/usr/lib/samba/libtalloc* $(TARGET_DIR)/usr/lib
-endef
-SAMBA4_POST_INSTALL_TARGET_HOOKS += SAMBA4_MOVE_LIBS
-endif
-
 $(eval $(generic-package))
-- 
2.0.5

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Thu,  5 Mar 2015 17:44:09 -0300, Gustavo Zacarias wrote:
> Now with support for AD DC, ADS and clustering features.
> All dropped patches are upstream.
> 
> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>

Ok, I'm going to be annoying on this one, but since this is something
we generally ask all developers to do, I think we should ask you to do
it too.

>  ifeq ($(BR2_PACKAGE_ACL),y)
> -	SAMBA4_CONF_OPTS += --with-acl-support
> -	SAMBA4_DEPENDENCIES += acl
> +SAMBA4_CONF_OPTS += --with-acl-support
> +SAMBA4_DEPENDENCIES += acl
>  else
> -	SAMBA4_CONF_OPTS += --without-acl-support
> +SAMBA4_CONF_OPTS += --without-acl-support
>  endif
>  
>  ifeq ($(BR2_PACKAGE_CUPS),y)
> -	SAMBA4_CONF_ENV += CUPS_CONFIG="$(STAGING_DIR)/usr/bin/cups-config"
> -	SAMBA4_CONF_OPTS += --enable-cups
> -	SAMBA4_DEPENDENCIES += cups
> +SAMBA4_CONF_ENV += CUPS_CONFIG="$(STAGING_DIR)/usr/bin/cups-config"
> +SAMBA4_CONF_OPTS += --enable-cups
> +SAMBA4_DEPENDENCIES += cups
>  else
> -	SAMBA4_CONF_OPTS += --disable-cups
> +SAMBA4_CONF_OPTS += --disable-cups
>  endif
>  
>  ifeq ($(BR2_PACKAGE_LIBAIO),y)
> -	SAMBA4_CONF_OPTS += --with-aio-support
> -	SAMBA4_DEPENDENCIES += libaio
> +SAMBA4_CONF_OPTS += --with-aio-support
> +SAMBA4_DEPENDENCIES += libaio
>  else
> -	SAMBA4_CONF_OPTS += --without-aio-support
> +SAMBA4_CONF_OPTS += --without-aio-support
>  endif
>  
>  ifeq ($(BR2_PACKAGE_DBUS)$(BR2_PACKAGE_AVAHI_DAEMON),yy)
> -	SAMBA4_CONF_OPTS += --enable-avahi
> -	SAMBA4_DEPENDENCIES += avahi
> +SAMBA4_CONF_OPTS += --enable-avahi
> +SAMBA4_DEPENDENCIES += avahi
>  else
> -	SAMBA4_CONF_OPTS += --disable-avahi
> +SAMBA4_CONF_OPTS += --disable-avahi
>  endif
>  
>  ifeq ($(BR2_PACKAGE_GAMIN),y)
> -	SAMBA4_CONF_OPTS += --with-fam
> -	SAMBA4_DEPENDENCIES += gamin
> +SAMBA4_CONF_OPTS += --with-fam
> +SAMBA4_DEPENDENCIES += gamin
>  else
> -	SAMBA4_CONF_OPTS += --without-fam
> +SAMBA4_CONF_OPTS += --without-fam
>  endif
>  
>  ifeq ($(BR2_PACKAGE_GETTEXT),y)
> -	SAMBA4_CONF_OPTS += --with-gettext=$(STAGING_DIR)/usr
> -	SAMBA4_DEPENDENCIES += gettext
> +SAMBA4_CONF_OPTS += --with-gettext=$(STAGING_DIR)/usr
> +SAMBA4_DEPENDENCIES += gettext
>  else
> -	SAMBA4_CONF_OPTS += --without-gettext
> -endif
> -
> -ifeq ($(BR2_PACKAGE_GNUTLS),y)
> -	SAMBA4_CONF_OPTS += --enable-gnutls
> -	SAMBA4_DEPENDENCIES += gnutls
> -else
> -	SAMBA4_CONF_OPTS += --disable-gnutls
> +SAMBA4_CONF_OPTS += --without-gettext
>  endif
>  
>  ifeq ($(BR2_PACKAGE_NCURSES_TARGET_FORM)$(BR2_PACKAGE_NCURSES_TARGET_MENU)$(BR2_PACKAGE_NCURSES_TARGET_PANEL),yyy)
> -	SAMBA4_DEPENDENCIES += ncurses
> +SAMBA4_DEPENDENCIES += ncurses
>  else
> -	SAMBA4_CONF_OPTS += --without-regedit
> +SAMBA4_CONF_OPTS += --without-regedit
>  endif

This cleanup of the indentation is definitely good, but has nothing to
do with the bump to 4.2.0. It should be part of a separate patch.

Thanks!

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

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Gustavo Zacarias]

On 03/05/2015 07:29 PM, Thomas Petazzoni wrote:

> Dear Gustavo Zacarias,
> 
> On Thu,  5 Mar 2015 17:44:09 -0300, Gustavo Zacarias wrote:
>> Now with support for AD DC, ADS and clustering features.
>> All dropped patches are upstream.
>>
>> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
> 
> Ok, I'm going to be annoying on this one, but since this is something
> we generally ask all developers to do, I think we should ask you to do
> it too.
> 
> This cleanup of the indentation is definitely good, but has nothing to
> do with the bump to 4.2.0. It should be part of a separate patch.

Well, it's pointless IMHO to split it, since some options changed and
it's a major bump, does it really make sense?
I won't make a badly-indented 4.2.x package file to fix it later, it
would be pointless. It'll give me one more commit that doesn't do
anything useful.
And "fixing" 4.1.x just to just stomp on it later with the bump would
make no sense either, same case, many changes.
Regards.

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Thu, 05 Mar 2015 21:11:24 -0300, Gustavo Zacarias wrote:

> > This cleanup of the indentation is definitely good, but has nothing to
> > do with the bump to 4.2.0. It should be part of a separate patch.
> 
> Well, it's pointless IMHO to split it, since some options changed and
> it's a major bump, does it really make sense?
> I won't make a badly-indented 4.2.x package file to fix it later, it
> would be pointless. It'll give me one more commit that doesn't do
> anything useful.
> And "fixing" 4.1.x just to just stomp on it later with the bump would
> make no sense either, same case, many changes.

I'm sorry, but I don't buy this. Separating logical changes is
something we ask to all contributors. And the specific chunk I pointed
at does not change at *all* when doing the 4.1 -> 4.2 bump. And even if
some parts of it are changed by the 4.1 -> 4.2 bump, that's OK.

Best regards,

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

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Gustavo Zacarias]

On 03/06/2015 05:40 AM, Thomas Petazzoni wrote:

> I'm sorry, but I don't buy this. Separating logical changes is
> something we ask to all contributors. And the specific chunk I pointed
> at does not change at *all* when doing the 4.1 -> 4.2 bump. And even if
> some parts of it are changed by the 4.1 -> 4.2 bump, that's OK.

Well,  i've done it several times in the past, just search for "While at
it" and "Also" in the commit logs - in fact it was you who committed
them in many cases (and not only mine).
Does this mean that i should separate bumps from adding hash files
and/or renaming patches?
Because the workload and noise committing will go up higher if that's
the choice.
And how does a package style fix differ from renaming patches that's
another style fix?
Regards.

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Fri, 06 Mar 2015 06:04:03 -0300, Gustavo Zacarias wrote:

> Well,  i've done it several times in the past, just search for "While at
> it" and "Also" in the commit logs - in fact it was you who committed
> them in many cases (and not only mine).
> Does this mean that i should separate bumps from adding hash files
> and/or renaming patches?

There is obviously a line to draw between things that we can do in the
same commit, and things that we should not. I believe adding a hash
file together with a bump is OK since anyway doing the bump would
change the hash file.

> Because the workload and noise committing will go up higher if that's
> the choice.
> And how does a package style fix differ from renaming patches that's
> another style fix?

I'd say readability. Renaming patches is clearly separated from .mk
changes. In the case of your Samba 4.2 bump, the changes within the .mk
file are mixed between bump-related changes, and indentation-related
changes, and this is what bothers me.

Best regards,

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

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Gustavo Zacarias]

On 03/06/2015 06:26 AM, Thomas Petazzoni wrote:

>> Because the workload and noise committing will go up higher if that's
>> the choice.
>> And how does a package style fix differ from renaming patches that's
>> another style fix?
> 
> I'd say readability. Renaming patches is clearly separated from .mk
> changes. In the case of your Samba 4.2 bump, the changes within the .mk
> file are mixed between bump-related changes, and indentation-related
> changes, and this is what bothers me.

It doesn't break any bisectability so what's the problem, you don't like
a patch that changes too many things at once?
Sorry to rehash an old thread but this kind of things don't motivate me
at all.
One thing is when you say "typo" which well, yes, it's a typo and it's
fine to correct it.
But this is just personal preference.
Regards.

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Fri, 06 Mar 2015 06:34:59 -0300, Gustavo Zacarias wrote:

> > I'd say readability. Renaming patches is clearly separated from .mk
> > changes. In the case of your Samba 4.2 bump, the changes within the .mk
> > file are mixed between bump-related changes, and indentation-related
> > changes, and this is what bothers me.
> 
> It doesn't break any bisectability so what's the problem, you don't like
> a patch that changes too many things at once?

Exactly. I'm surprised you even ask, separate logical changes is just
the 101 of open-source contribution in many projects. See
http://lxr.free-electrons.com/source/Documentation/SubmittingPatches#L74
for example.

> Sorry to rehash an old thread but this kind of things don't motivate me
> at all.

I don't quite understand your feeling here. What I'm asking you to do
is something we ask to *all* contributors, including newcomers who have
never contributed a single patch to Buildroot. Why would we have more
relaxed/special rules for long-term contributors like you ?

If I was annoying you with something unusual, which I never bother
other people with, I would understand. But here I'm just asking a very
basic thing, which I also ask to every other contributor.

> One thing is when you say "typo" which well, yes, it's a typo and it's
> fine to correct it.

Sorry I did not understand this part.

Anyway, I'll take care of doing the split of the Samba 4.2 patch and
I'll apply. I would have expected a bit more help and understanding from
a long term contributor such as you.

Thanks,

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

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Gustavo Zacarias]

On 03/06/2015 06:40 AM, Thomas Petazzoni wrote:

> Dear Gustavo Zacarias,
> 
> On Fri, 06 Mar 2015 06:34:59 -0300, Gustavo Zacarias wrote:
> 
>>> I'd say readability. Renaming patches is clearly separated from .mk
>>> changes. In the case of your Samba 4.2 bump, the changes within the .mk
>>> file are mixed between bump-related changes, and indentation-related
>>> changes, and this is what bothers me.
>>
>> It doesn't break any bisectability so what's the problem, you don't like
>> a patch that changes too many things at once?
> 
> Exactly. I'm surprised you even ask, separate logical changes is just
> the 101 of open-source contribution in many projects. See
> http://lxr.free-electrons.com/source/Documentation/SubmittingPatches#L74
> for example.

Well i'd say the same applies to trivial/redundant stuff, like "hey
bump" + "hey hash" and you never complain with that aspect.
Style changes aren't usually very readable in diff format, so why not
make it part of a major bump? You'll have to re-read the full package
anyway for any QA you do.

> I don't quite understand your feeling here. What I'm asking you to do
> is something we ask to *all* contributors, including newcomers who have
> never contributed a single patch to Buildroot. Why would we have more
> relaxed/special rules for long-term contributors like you ?

FYI that's a linux kernel rule, it's not how every project out there
works. Life isn't just the linux kernel.

> If I was annoying you with something unusual, which I never bother
> other people with, I would understand. But here I'm just asking a very
> basic thing, which I also ask to every other contributor.

Sorry to nitpick here, but if we weren't changing little bits of style
all the time then we'd have more time for really cool stuff, and that
bothers me.
My feeling is that lately the patchflow is getting slower, and i'm not
talking about my patches, those usually get applied quickly because
they're, bluntly speaking, stupid patches.
And they're stupid because i don't feel any support/interest/whatever in
putting any serious effort in doing anything cool, because i feel
intertia in getting real advancement in some areas.
When you ask "why would we have more relaxed/special rules for long-term
contributors like you?" it sounds very detached to me - kind of saying
contributors don't matter.
It doesn't mean you should have special rules, but bringing it up that
way isn't nice IMO.
And, for me personally, it just makes me

So, one time offer with no strings attached: if you don't want me around
just tell me, i think we are all adults and i'll just move to doing
something elsewhere with my free time where i feel more welcome/appreciated.

>> One thing is when you say "typo" which well, yes, it's a typo and it's
>> fine to correct it.
> 
> Sorry I did not understand this part.

It means that i'm not angry/mad at every comment you make in case you
got that impression.

> Anyway, I'll take care of doing the split of the Samba 4.2 patch and
> I'll apply. I would have expected a bit more help and understanding from
> a long term contributor such as you.

Same goes both ways FYI (understanding).
I was going to say i'll do it myself because of a borderline failure
that needs fixing that my autobuilder caught, but you already did it so
i'll send a followup patch to fix that.
Regards.

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Fri, 06 Mar 2015 07:32:21 -0300, Gustavo Zacarias wrote:

> Well i'd say the same applies to trivial/redundant stuff, like "hey
> bump" + "hey hash" and you never complain with that aspect.

Yes, because as I said in my earlier e-mail, the "hey bump" and "hey
hash" parts are clearly separated in the patch, so having them mixed in
the same patch doesn't cause any readability issue.

> Style changes aren't usually very readable in diff format, so why not
> make it part of a major bump? You'll have to re-read the full package
> anyway for any QA you do.

Whether style changes are or are not very readable in diff format is
your vision, not mine. I do review style changes in diff format,
specifically because it allows me to visually check that only style
changes are made, and no functional changes are made.

So clearly, I want style changes separated from functional changes.

> > I don't quite understand your feeling here. What I'm asking you to do
> > is something we ask to *all* contributors, including newcomers who have
> > never contributed a single patch to Buildroot. Why would we have more
> > relaxed/special rules for long-term contributors like you ?
> 
> FYI that's a linux kernel rule, it's not how every project out there
> works. Life isn't just the linux kernel.

Absolutely. But it happens that we follow quite a few of the rules of
the Linux kernel: Signed-off-by, how patch series revisions are
handled, how the review process takes place, etc. And the "split
patches by logical changes" is not only a kernel rule, a lot of
projects want this as well.

> > If I was annoying you with something unusual, which I never bother
> > other people with, I would understand. But here I'm just asking a very
> > basic thing, which I also ask to every other contributor.
> 
> Sorry to nitpick here, but if we weren't changing little bits of style
> all the time then we'd have more time for really cool stuff, and that
> bothers me.

I agree that quite a number of changes are style changes. However, my
feeling is that such changes are 1/ trivial to review and apply when
cleanly separated from functional changes, and therefore don't consume
much time, and 2/ make the code base more homogeneous which is nice for
new comers.

> My feeling is that lately the patchflow is getting slower, and i'm not
> talking about my patches, those usually get applied quickly because
> they're, bluntly speaking, stupid patches.
> And they're stupid because i don't feel any support/interest/whatever in
> putting any serious effort in doing anything cool, because i feel
> intertia in getting real advancement in some areas.

There is some inertia, but this inertia is mainly due to the lack of
review and testing of the patches from other core developers. Yann is
doing a lot of this, Vicente is also doing some work in this area,
Romain has recently joined.

But for example, you almost never ever give a Reviewed-by or a
Tested-by tag on a patch submitted by another developer. Whenever there
is a patch touching a package you typically take care of (Samba, Squid,
etc.) submitted by another developer, I have to ping you to get your
feedback/input on the patch.

So if you feel there is inertia on a given topic, just help the topic
make progress by reviewing the patches, saying you tested the series,
etc. When a core developer like you gives his positive feedback on a
given patch, for me (and I believe for Peter as well) it's a very
strong sign that the patch is good to apply. I never build test your
patches because I fully trust you. You can use this trust to help other
patches go in.

> When you ask "why would we have more relaxed/special rules for long-term
> contributors like you?" it sounds very detached to me - kind of saying
> contributors don't matter.

Contributors don't matter?

Do you realize that since a few months, I've basically stopped doing
any development of Buildroot on the topics I'm interested in, and
switched to spending all my available time to review, test and merge
the patches submitted by all the contributors? I'm spending all my
evenings and week-ends shrinking the patchwork backlog so that
patches sent by contributors get merged at some point.

All what I was saying is that I ask new comers to split their patches
in logical changes, as a quality rule like we have many others. And I
don't see why this quality rule wouldn't apply to a long-term
trusted core developer such as you.

> It doesn't mean you should have special rules, but bringing it up that
> way isn't nice IMO.

I'm sorry if you felt it wasn't nice, it really wasn't the intention.

> And, for me personally, it just makes me

Seems like there's a missing part here :-)

> So, one time offer with no strings attached: if you don't want me around
> just tell me, i think we are all adults and i'll just move to doing
> something elsewhere with my free time where i feel more welcome/appreciated.

One time offer rejected.

I definitely want you part of the Buildroot core developers. You're
doing an invaluable work taking care of many complex packages, doing a
lot of very useful work looking at security issues and making the
corresponding package updates.

I think we should really meet once in person one day so you can feel how
much I value the contributions done by all developers, and especially
yours.

Back on the Samba 4.2, my point is really only: "hey this patch is OK,
I would just like it to be split a bit differently". I don't really
understand why such a stupid/silly request generates such a huge amount
of discussion.

> It means that i'm not angry/mad at every comment you make in case you
> got that impression.

Ok. Glad to hear that :-)

> > Anyway, I'll take care of doing the split of the Samba 4.2 patch and
> > I'll apply. I would have expected a bit more help and understanding from
> > a long term contributor such as you.
> 
> Same goes both ways FYI (understanding).

I'm not sure what I should understand? That because you are a long-term
contributor, you have the right to do patches that don't comply with
the quality rules we request all other contributors to comply with?

Sorry, but that doesn't work for me.

Do you remember that I already yelled at Peter because he wasn't
posting to the list his patches before committing them ? So clearly,
this is nothing personal with you, you see ?

> I was going to say i'll do it myself because of a borderline failure
> that needs fixing that my autobuilder caught, but you already did it so
> i'll send a followup patch to fix that.

Sure, seen the ncurses fix. I'll apply.

Thanks!

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

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Gustavo Zacarias]

On 03/06/2015 08:35 AM, Thomas Petazzoni wrote:

>> Sorry to nitpick here, but if we weren't changing little bits of style
>> all the time then we'd have more time for really cool stuff, and that
>> bothers me.
> 
> I agree that quite a number of changes are style changes. However, my
> feeling is that such changes are 1/ trivial to review and apply when
> cleanly separated from functional changes, and therefore don't consume
> much time, and 2/ make the code base more homogeneous which is nice for
> new comers.

Style changes should ideally be done all at once, once said change is
documented or agreed upon.
It shouldn't be considered any different than the *_CONF_OPT ->
*_CONF_OPTS rename.
If we just wait for a waterfall effect in updating packages you'll just
have mixed styles around the tree which will just confuse users and
waste peoples time in mails and respins.

> There is some inertia, but this inertia is mainly due to the lack of
> review and testing of the patches from other core developers. Yann is
> doing a lot of this, Vicente is also doing some work in this area,
> Romain has recently joined.
> 
> But for example, you almost never ever give a Reviewed-by or a
> Tested-by tag on a patch submitted by another developer. Whenever there
> is a patch touching a package you typically take care of (Samba, Squid,
> etc.) submitted by another developer, I have to ping you to get your
> feedback/input on the patch.

This shouldn't be of any surprise, i'm just (not) doing what i said i
wouldn't back at the end of the qemu-system thread.
Also i'm not territorial, sometimes people add up features to packages
that i usually maintain and evidently they're features i normally don't
care/use about otherwise i would have done so myself, so i don't have
any strong opinion or interest on them.
Example: squidguard, i already have a package from a long time ago, but
i never submitted it since it's quality is dubious, let alone a release
hasn't been forthcoming for years (you gotta use the latest with several
security patches or some beta).

> So if you feel there is inertia on a given topic, just help the topic
> make progress by reviewing the patches, saying you tested the series,
> etc. When a core developer like you gives his positive feedback on a
> given patch, for me (and I believe for Peter as well) it's a very
> strong sign that the patch is good to apply. I never build test your
> patches because I fully trust you. You can use this trust to help other
> patches go in.

...

> Contributors don't matter?
> 
> Do you realize that since a few months, I've basically stopped doing
> any development of Buildroot on the topics I'm interested in, and
> switched to spending all my available time to review, test and merge
> the patches submitted by all the contributors? I'm spending all my
> evenings and week-ends shrinking the patchwork backlog so that
> patches sent by contributors get merged at some point.

This is the kind of inertia i'm refering to.
Something needs to change or eventually you'll wear out/wane out of
interest.
Without wanting to "rub it" and being pretty one-sided the qemu-system
package/idea went nowhere, a lot of time passed.
I still stand on my original argument for it being split.
I don't care what does or doesn't happen with that any more, i'm
bringing it up as an example of my lack of interest of doing anything
big regarding out-of-the-box experience.
Post build scripts are all great, but some things should really be
easier for the users.
Making the initscripts configurable for example is one of them, but
every time i want to start writing the proposal and samples i feel
"Bleh, Peter or Thomas won't take it" and just leave it be.
And it _really_ needs to happen, right now samba4 AD DC support isn't
complete since the initscript isn't adequate for that.
You've got scenarios where you start smbd, nmbd and winbindd, more usual
without winbindd, but for AD-DC you need to start samba, and it's hard
to predict based on smb.conf with dubious grepping.
It's also not very feasible to "try" both approaches since some delays
must be thrown in for the samba master process to really kick in before
checking things are running.

>> And, for me personally, it just makes me
> 
> Seems like there's a missing part here :-)

Morning rush.
It just makes me question if i should continue working with BR.

> I definitely want you part of the Buildroot core developers. You're
> doing an invaluable work taking care of many complex packages, doing a
> lot of very useful work looking at security issues and making the
> corresponding package updates.

We'll see how much people like my security "updates" once i send the
cups deprecation series - it really needs to happen, nobody stepped up
and it's pretty bad. I don't have an exact count of how many
remotely-exploitable CVEs affect it, but it's probably safe to say a dozen.
Maybe it'll entice someone to step up, but it really can't go on like this.
Even though we don't guarantee that packages are free of bugs/security
holes in them when we do know we should get something done about them,
either fix them or kill them.

> I think we should really meet once in person one day so you can feel how
> much I value the contributions done by all developers, and especially
> yours.

That'd be hard to achieve i'm afraid, we've got a phrase here which
literally translates to "we're in the ass of the world".
All of the relevant places (OSS/technology-wise) are no less than a 10
hour flight from here. It's just the way it is.

> Back on the Samba 4.2, my point is really only: "hey this patch is OK,
> I would just like it to be split a bit differently". I don't really
> understand why such a stupid/silly request generates such a huge amount
> of discussion.

Well, it shouldn't have, i didn't think you'd go all "by the book" on
that silly detail and it caught me by surprise.

> I'm not sure what I should understand? That because you are a long-term
> contributor, you have the right to do patches that don't comply with
> the quality rules we request all other contributors to comply with?
> 
> Sorry, but that doesn't work for me.
> 
> Do you remember that I already yelled at Peter because he wasn't
> posting to the list his patches before committing them ? So clearly,
> this is nothing personal with you, you see ?

For me core developer = Peter and you since you're the ones with commit
access to the tree, the rest are varying degrees of contributors.
And you mixed and matched contributor with core developer here and above
where it suited you best, don't be nasty ;)
I know it's probably not personal, but writing frankly, we're both
wasting time on a technicality that changes nothing, is it worth the
(virtual) saliva?
Regards.

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Peter Korsgaard]

>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes:

Hi,

>> Do you realize that since a few months, I've basically stopped doing
 >> any development of Buildroot on the topics I'm interested in, and
 >> switched to spending all my available time to review, test and merge
 >> the patches submitted by all the contributors? I'm spending all my
 >> evenings and week-ends shrinking the patchwork backlog so that
 >> patches sent by contributors get merged at some point.

 > This is the kind of inertia i'm refering to.
 > Something needs to change or eventually you'll wear out/wane out of
 > interest.
 > Without wanting to "rub it" and being pretty one-sided the qemu-system
 > package/idea went nowhere, a lot of time passed.
 > I still stand on my original argument for it being split.
 > I don't care what does or doesn't happen with that any more, i'm
 > bringing it up as an example of my lack of interest of doing anything
 > big regarding out-of-the-box experience.
 > Post build scripts are all great, but some things should really be
 > easier for the users.
 > Making the initscripts configurable for example is one of them, but
 > every time i want to start writing the proposal and samples i feel
 > "Bleh, Peter or Thomas won't take it" and just leave it be.
 > And it _really_ needs to happen, right now samba4 AD DC support isn't
 > complete since the initscript isn't adequate for that.
 > You've got scenarios where you start smbd, nmbd and winbindd, more usual
 > without winbindd, but for AD-DC you need to start samba, and it's hard
 > to predict based on smb.conf with dubious grepping.
 > It's also not very feasible to "try" both approaches since some delays
 > must be thrown in for the samba master process to really kick in before
 > checking things are running.

I understand. Working on new features are nice (and yes, reviewing other
peoples patches all day does get boring after some time), but we also
need to keep in mind that Buildroot should stay a simple system
(otherwise you might as well use one of the other bigger systems) and we
should try to keep it stable.

We simply cannot cater to everyones needs. With that said, we have
merged a number of new features over the years to automate some of these
things (rootfs overlays, getty settings, root password, users, init
systems, /bin/sh handling, timezones, network config, ..), and I'm sure
we will merge even more in the future.


 > remotely-exploitable CVEs affect it, but it's probably safe to say a dozen.
 > Maybe it'll entice someone to step up, but it really can't go on like this.
 > Even though we don't guarantee that packages are free of bugs/security
 > holes in them when we do know we should get something done about them,
 > either fix them or kill them.

Agreed (and not only about security issues). If a package has serious
issues and nobody cares enough to fix it then we need to deprecate and
remove the package.

We keep on adding new packages every single release, so we also need to
cleanup unloved ones.


 >> I think we should really meet once in person one day so you can feel how
 >> much I value the contributions done by all developers, and especially
 >> yours.

 > That'd be hard to achieve i'm afraid, we've got a phrase here which
 > literally translates to "we're in the ass of the world".

Heh ;)

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

> But for example, you almost never ever give a Reviewed-by or a
 > Tested-by tag on a patch submitted by another developer. Whenever there
 > is a patch touching a package you typically take care of (Samba, Squid,
 > etc.) submitted by another developer, I have to ping you to get your
 > feedback/input on the patch.

 > So if you feel there is inertia on a given topic, just help the topic
 > make progress by reviewing the patches, saying you tested the series,
 > etc. When a core developer like you gives his positive feedback on a
 > given patch, for me (and I believe for Peter as well) it's a very
 > strong sign that the patch is good to apply. I never build test your
 > patches because I fully trust you. You can use this trust to help other
 > patches go in.

Yes, exactly!


> I think we should really meet once in person one day so you can feel how
 > much I value the contributions done by all developers, and especially
 > yours.

Buildroot dev days in Argentina? I'm up for it if we can find a sponsor
;)


 > Do you remember that I already yelled at Peter because he wasn't
 > posting to the list his patches before committing them ? So clearly,
 > this is nothing personal with you, you see ?

And that is good, thanks. Open source (to me atleast) is very much about
everyone playing according to the same rules.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Thomas Petazzoni]

Dear Peter Korsgaard,

On Tue, 10 Mar 2015 22:53:53 +0100, Peter Korsgaard wrote:

> > I think we should really meet once in person one day so you can feel how
>  > much I value the contributions done by all developers, and especially
>  > yours.
> 
> Buildroot dev days in Argentina? I'm up for it if we can find a sponsor
> ;)

Me too! But I guess I'll try to avoid flying helicopters.

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

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 >> Buildroot dev days in Argentina? I'm up for it if we can find a sponsor
 >> ;)

 > Me too! But I guess I'll try to avoid flying helicopters.

Yeah :/

-- 
Bye, Peter Korsgaard 

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Peter Korsgaard]

>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes:

Hi,

 >> Exactly. I'm surprised you even ask, separate logical changes is just
 >> the 101 of open-source contribution in many projects. See
 >> http://lxr.free-electrons.com/source/Documentation/SubmittingPatches#L74
 >> for example.

 > Well i'd say the same applies to trivial/redundant stuff, like "hey
 > bump" + "hey hash" and you never complain with that aspect.
 > Style changes aren't usually very readable in diff format, so why not
 > make it part of a major bump? You'll have to re-read the full package
 > anyway for any QA you do.

Not if it is a pure style change as you can check with 'git diff -w'.


 >> I don't quite understand your feeling here. What I'm asking you to do
 >> is something we ask to *all* contributors, including newcomers who have
 >> never contributed a single patch to Buildroot. Why would we have more
 >> relaxed/special rules for long-term contributors like you ?

 > FYI that's a linux kernel rule, it's not how every project out there
 > works. Life isn't just the linux kernel.

Agreed, but we have adapted quite a bit of the same rules as the Linux
kernel (git, signed-off-by, review on mailing list, patchwork, single
maintainer, ..).


 >> If I was annoying you with something unusual, which I never bother
 >> other people with, I would understand. But here I'm just asking a very
 >> basic thing, which I also ask to every other contributor.

 > Sorry to nitpick here, but if we weren't changing little bits of style
 > all the time then we'd have more time for really cool stuff, and that
 > bothers me.
 > My feeling is that lately the patchflow is getting slower, and i'm not
 > talking about my patches, those usually get applied quickly because
 > they're, bluntly speaking, stupid patches.
 > And they're stupid because i don't feel any support/interest/whatever in
 > putting any serious effort in doing anything cool, because i feel
 > intertia in getting real advancement in some areas.

This is not true in absolute numbers (E.G. we keep on increasing the
number of changes in each release), but it may be true that Buildroot is
getting more mature / stable (and therefore in a sense boring).

I don't think it is really a problem if complicated / controversial
patches takes longer to get applied than simple version bumps, but if
they never get applied or atleast responded to then that is certainly a
problem.

As a maintainer it isn't always easy to make progress on that kind of
patches when:

- There's plenty of other patches waiting in patchwork
- Patches risk breaking stuff / cause maintenance issues down the road
- Nobody else have reviewed / acked those patches.

If I look in patchwork, I see very few patches having anything else than
0/0/0 in the acked-by/review-by/tested-by columns.

This is one of the reasons why we are doing the dev days, as we then
discuss some of these patch series.


 > So, one time offer with no strings attached: if you don't want me around
 > just tell me, i think we are all adults and i'll just move to doing
 > something elsewhere with my free time where i feel more welcome/appreciated.

I must say that I'm surprised by this statement and I wonder how come
you think Thomas or anybody else feels like that? I very much appreciate
your Buildroot contributions, and I'm sure everyone else does as well!

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Dear Gustavo Zacarias,
 > On Fri, 06 Mar 2015 06:04:03 -0300, Gustavo Zacarias wrote:

 >> Well,  i've done it several times in the past, just search for "While at
 >> it" and "Also" in the commit logs - in fact it was you who committed
 >> them in many cases (and not only mine).
 >> Does this mean that i should separate bumps from adding hash files
 >> and/or renaming patches?

 > There is obviously a line to draw between things that we can do in the
 > same commit, and things that we should not. I believe adding a hash
 > file together with a bump is OK since anyway doing the bump would
 > change the hash file.

Exactly, the changes logically belong together and are easy/fast to
review.

A version bump + whitespace changes leading to a diffstat like this:

 package/samba4/samba4.mk                           | 100 +++++++------

Is certainly less so. If it was purely a white space change it would be
trivial to verify with git diff -w, E.G.:

git show -w 7152a50588

 >> Because the workload and noise committing will go up higher if that's
 >> the choice.

We already have 400+ commits/month, so 1 extra commit imho doesn't
hurt. It is true that it involves a bit more time on the contributor,
but is saves time for the maintainer (E.G. the version bumps, especially
yours are normally nobrainers to apply), and the limiting factor these
days seems to be maintainer/review cycles.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Thu,  5 Mar 2015 17:44:09 -0300, Gustavo Zacarias wrote:
> Now with support for AD DC, ADS and clustering features.
> All dropped patches are upstream.
> 
> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>

Applied, after splitting into a separate patch the indentation fixes of
samba4.mk.

Thanks,

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

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Bernd Kuhls]

Gustavo Zacarias <gustavo@zacarias.com.ar> wrote in 
news:1425588249-20942-2-git-send-email-gustavo at zacarias.com.ar:

> +     depends on BR2_TOOLCHAIN_USES_GLIBC # needs nss.h, $ORIGIN support

Hi,

is this really necessary? Building samba4 with uclibc worked here and I guess 
the problem you saw with nss.h was fixed in 4.2.0rc3:
https://bugzilla.samba.org/show_bug.cgi?id=11026

Please note that I tested compilation only, for a runtime test I need more 
time.

Regards, Bernd

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Gustavo Zacarias]

On 04/09/2015 07:33 AM, Bernd Kuhls wrote:

> Hi,
> 
> is this really necessary? Building samba4 with uclibc worked here and I guess 
> the problem you saw with nss.h was fixed in 4.2.0rc3:
> https://bugzilla.samba.org/show_bug.cgi?id=11026
> 
> Please note that I tested compilation only, for a runtime test I need more 
> time.

Even if building with nss.h is fixed you still need $ORIGIN support
which uClibc lacks in the current releases.
So you'll have runtime issues.
In the past (samba 4.1.x) i moved libraries to /usr/lib as a workaround,
but for 4.2.x this didn't seem enough/there's a lot of new libraries to
move.
Regards.

PD: next time CC me otherwise you leave my answer to the chance i don't
miss the mail on the list.

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Waldemar Brodkorb]

Hi,
Gustavo Zacarias wrote,

> On 04/09/2015 07:33 AM, Bernd Kuhls wrote:
> 
> > Hi,
> > 
> > is this really necessary? Building samba4 with uclibc worked here and I guess 
> > the problem you saw with nss.h was fixed in 4.2.0rc3:
> > https://bugzilla.samba.org/show_bug.cgi?id=11026
> > 
> > Please note that I tested compilation only, for a runtime test I need more 
> > time.
> 
> Even if building with nss.h is fixed you still need $ORIGIN support
> which uClibc lacks in the current releases.
> So you'll have runtime issues.
> In the past (samba 4.1.x) i moved libraries to /usr/lib as a workaround,
> but for 4.2.x this didn't seem enough/there's a lot of new libraries to
> move.

uClibc-ng has $ORIGIN support. Can you test it with samba4?

best regards
 Waldemar

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Gustavo Zacarias]

On 04/09/2015 05:20 PM, Waldemar Brodkorb wrote:

> uClibc-ng has $ORIGIN support. Can you test it with samba4?

Yes, and it fails to work, snip:

-----
# /etc/init.d/S91smb start
Starting SMB services: /usr/sbin/smbd: can't load library 'libtalloc.so.2'
FAIL
Starting NMB services: /usr/sbin/nmbd: can't load library 'libtalloc.so.2'
FAIL
# ls -l /lib/*uClibc*
-rwxr-xr-x    1 root     root         25304 Apr  9  2015
/lib/ld-uClibc-1.0.1.so
lrwxrwxrwx    1 root     root            14 Apr  9  2015
/lib/ld-uClibc.so.0 -> ld-uClibc.so.1
lrwxrwxrwx    1 root     root            18 Apr  9  2015
/lib/ld-uClibc.so.1 -> ld-uClibc-1.0.1.so
-rwxr-xr-x    1 root     root        367544 Apr  9  2015
/lib/libuClibc-1.0.1.so
# ls -l /usr/lib/samba/libtalloc*
lrwxrwxrwx    1 root     root            18 Apr  9  2015
/usr/lib/samba/libtalloc.so.2 -> libtalloc.so.2.1.1
-rwxr-xr-x    1 root     root         19396 Apr  9  2015
/usr/lib/samba/libtalloc.so.2.1.1
-----

On the build machine:
$ readelf -d ?mbd|grep RPATH
 0x0000000f (RPATH)                      Library rpath: [/usr/lib/samba]
 0x0000000f (RPATH)                      Library rpath: [/usr/lib/samba]

So, it's not up to it yet.

Regards.

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Waldemar Brodkorb]

Hi,
Gustavo Zacarias wrote,

> On 04/09/2015 05:20 PM, Waldemar Brodkorb wrote:
> 
> > uClibc-ng has $ORIGIN support. Can you test it with samba4?
> 
> Yes, and it fails to work, snip:
> 
> -----
> # /etc/init.d/S91smb start
> Starting SMB services: /usr/sbin/smbd: can't load library 'libtalloc.so.2'
> FAIL
> Starting NMB services: /usr/sbin/nmbd: can't load library 'libtalloc.so.2'
> FAIL
> # ls -l /lib/*uClibc*
> -rwxr-xr-x    1 root     root         25304 Apr  9  2015
> /lib/ld-uClibc-1.0.1.so
> lrwxrwxrwx    1 root     root            14 Apr  9  2015
> /lib/ld-uClibc.so.0 -> ld-uClibc.so.1
> lrwxrwxrwx    1 root     root            18 Apr  9  2015
> /lib/ld-uClibc.so.1 -> ld-uClibc-1.0.1.so
> -rwxr-xr-x    1 root     root        367544 Apr  9  2015
> /lib/libuClibc-1.0.1.so
> # ls -l /usr/lib/samba/libtalloc*
> lrwxrwxrwx    1 root     root            18 Apr  9  2015
> /usr/lib/samba/libtalloc.so.2 -> libtalloc.so.2.1.1
> -rwxr-xr-x    1 root     root         19396 Apr  9  2015
> /usr/lib/samba/libtalloc.so.2.1.1
> -----
> 
> On the build machine:
> $ readelf -d ?mbd|grep RPATH
>  0x0000000f (RPATH)                      Library rpath: [/usr/lib/samba]
>  0x0000000f (RPATH)                      Library rpath: [/usr/lib/samba]
> 
> So, it's not up to it yet.

It is not a missing or broken $ORIGIN support. As you posted, there
is no $ORIGIN used in RPATH.
I am really sure it is this commit and option which is solving the
runtime problem:
http://git.uclibc.org/uClibc/commit/?id=409f14d9b5e47513d5c939120a33965997c8ceb2

Will be part of uClibc-ng 1.0.2.

best regards
 Waldemar

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Gustavo Zacarias]

On 04/16/2015 04:55 PM, Waldemar Brodkorb wrote:

> It is not a missing or broken $ORIGIN support. As you posted, there
> is no $ORIGIN used in RPATH.
> I am really sure it is this commit and option which is solving the
> runtime problem:
> http://git.uclibc.org/uClibc/commit/?id=409f14d9b5e47513d5c939120a33965997c8ceb2
> 
> Will be part of uClibc-ng 1.0.2.

In any case it's just the comment that's wrong but the conditions are
the same, current releases are not up to snuff.
We can revisit that when there are newer releases, even though i think
samba is a big enough package that any uclibc* space savings are
pointless, after all it needs to share some storage besides the obvious
firmware size and RAM requirements.
Regards.

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Waldemar Brodkorb]

Hi,
Gustavo Zacarias wrote,

> On 04/16/2015 04:55 PM, Waldemar Brodkorb wrote:
> 
> > It is not a missing or broken $ORIGIN support. As you posted, there
> > is no $ORIGIN used in RPATH.
> > I am really sure it is this commit and option which is solving the
> > runtime problem:
> > http://git.uclibc.org/uClibc/commit/?id=409f14d9b5e47513d5c939120a33965997c8ceb2
> > 
> > Will be part of uClibc-ng 1.0.2.
> 
> In any case it's just the comment that's wrong but the conditions are
> the same, current releases are not up to snuff.
> We can revisit that when there are newer releases, even though i think
> samba is a big enough package that any uclibc* space savings are
> pointless, after all it needs to share some storage besides the obvious
> firmware size and RAM requirements.

But you still have uClibc as default when using internal toolchain.
So it would be nice if more packages are working out of the box.
And you have users using uClibc for Kodi, which is even bigger than
samba ;)

best regards
 Waldemar

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Gustavo Zacarias]

On 04/16/2015 05:09 PM, Waldemar Brodkorb wrote:

> But you still have uClibc as default when using internal toolchain.
> So it would be nice if more packages are working out of the box.
> And you have users using uClibc for Kodi, which is even bigger than
> samba ;)

I didn't say no ;)
I said that i don't think it makes sense, there's a difference :P
Regards.

[Buildroot] [PATCH 2/2] samba4: bump to version 4.2.0

[Bernd Kuhls]

Waldemar Brodkorb <wbx@openadk.org> wrote in 
news:20150416200943.GM27057 at waldemar-brodkorb.de:

> And you have users using uClibc for Kodi, which is even bigger than
> samba ;)

Hi,

I am using Samba and Kodi on the same machine, so it will be nice to have a 
Samba 4.x :) I?ll try to find some time to test Samba4 with 
LDSO_RUNPATH_OF_EXECUTABLE enabled in uClibc. Thx for the hint!

Regards, Bernd

[Buildroot] [PATCH 1/2] samba: deprecate package due to EOL

[Arnout Vandecappelle]

On 05/03/15 21:44, Gustavo Zacarias wrote:
> Samba 3.6.x is now EOL, people should move to samba4.

 What about samba support in mpd and kodi?

 Regards,
 Arnout

> 
> See: https://www.samba.org/samba/history/samba-4.2.0.html
> 
> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
> ---
>  package/samba/Config.in | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/package/samba/Config.in b/package/samba/Config.in
> index 9d04851..7ff8428 100644
> --- a/package/samba/Config.in
> +++ b/package/samba/Config.in
> @@ -1,5 +1,6 @@
>  config BR2_PACKAGE_SAMBA
>  	bool "samba"
> +	depends on BR2_DEPRECATED_SINCE_2015_05
>  	depends on BR2_TOOLCHAIN_HAS_THREADS
>  	depends on BR2_USE_MMU # fork()
>  	depends on !BR2_nios2 # binary too large, relocations don't fit
> @@ -15,6 +16,7 @@ config BR2_PACKAGE_SAMBA
>  		so choose only the components you need.
>  
>  comment "samba needs a toolchain w/ threads"
> +	depends on BR2_DEPRECATED_SINCE_2015_05
>  	depends on BR2_USE_MMU
>  	depends on !BR2_TOOLCHAIN_HAS_THREADS
>  
> 


-- 
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 1/2] samba: deprecate package due to EOL

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Thu, 05 Mar 2015 22:53:35 +0100, Arnout Vandecappelle wrote:
> On 05/03/15 21:44, Gustavo Zacarias wrote:
> > Samba 3.6.x is now EOL, people should move to samba4.
> 
>  What about samba support in mpd and kodi?

And gvfs.

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

[Buildroot] [PATCH 1/2] samba: deprecate package due to EOL

[Arnout Vandecappelle]

On 05/03/15 23:06, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
> 
> On Thu, 05 Mar 2015 22:53:35 +0100, Arnout Vandecappelle wrote:
>> On 05/03/15 21:44, Gustavo Zacarias wrote:
>>> Samba 3.6.x is now EOL, people should move to samba4.
>>
>>  What about samba support in mpd and kodi?
> 
> And gvfs.

 But that's just a condition on the .mk file so it has no implications for the
missing reverse dependencies.

 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 1/2] samba: deprecate package due to EOL

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Thu, 05 Mar 2015 23:10:56 +0100, Arnout Vandecappelle wrote:

>  But that's just a condition on the .mk file so it has no implications for the
> missing reverse dependencies.

Absolutely. But it means that the gvfs Samba support becomes unusable.

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

[Buildroot] [PATCH 1/2] samba: deprecate package due to EOL

[Gustavo Zacarias]

On 03/05/2015 07:23 PM, Thomas Petazzoni wrote:

> Dear Arnout Vandecappelle,
> 
> On Thu, 05 Mar 2015 23:10:56 +0100, Arnout Vandecappelle wrote:
> 
>>  But that's just a condition on the .mk file so it has no implications for the
>> missing reverse dependencies.
> 
> Absolutely. But it means that the gvfs Samba support becomes unusable.

There's no pretty way out of this, the 3.6.x codebase is going
completely unmaintained upstream.
It's basically sheer luck that upstream fixed CVE-2015-0240 (which is
pretty severe) on the 3.6.x branch, just because 4.2.0 was delayed.
The best solution i can think of is either use samba 3.6.x as a fallback
libsmbclient (not very nice looking forward) or switch everything to
samba4 with the added size and restrictions.
kodi and mpd aren't small so i don't think it should be a deciding
factor, gvfs is meh, but then it's optional.
I'd favor the 2nd option.
Another factor to consider is that eventually (maybe already) the old
libsmbclient won't be able to talk to newer windows servers anyway,
specially when older versions of the protocol are disabled for security
reasons.
Regards.

[Buildroot] [PATCH 1/2] samba: deprecate package due to EOL

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Thu, 05 Mar 2015 21:11:22 -0300, Gustavo Zacarias wrote:

> There's no pretty way out of this, the 3.6.x codebase is going
> completely unmaintained upstream.
> It's basically sheer luck that upstream fixed CVE-2015-0240 (which is
> pretty severe) on the 3.6.x branch, just because 4.2.0 was delayed.
> The best solution i can think of is either use samba 3.6.x as a fallback
> libsmbclient (not very nice looking forward) or switch everything to
> samba4 with the added size and restrictions.
> kodi and mpd aren't small so i don't think it should be a deciding
> factor, gvfs is meh, but then it's optional.
> I'd favor the 2nd option.
> Another factor to consider is that eventually (maybe already) the old
> libsmbclient won't be able to talk to newer windows servers anyway,
> specially when older versions of the protocol are disabled for security
> reasons.

Switching everything to Samba 4 is fine for me: that's the upstream
decision, and in Buildroot we generally try to follow upstream
decisions. If people are unhappy with Samba 4 being much bigger than
Samba 3, then it's up to them to work with the Samba folks upstream to
solve this. One guy posted some Buildroot patches at some point to only
install certain parts of Samba 4 to reduce the installed size, and we
invited him to work with upstream to resolve this.

So in my side, I'm fully OK with a solution that consists in switching
kodi, mpd and gvfs over to Samba 4.

Best regards,

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

[Buildroot] [PATCH 1/2] samba: deprecate package due to EOL

[Gustavo Zacarias]

On 03/06/2015 05:19 AM, Thomas Petazzoni wrote:
> Switching everything to Samba 4 is fine for me: that's the upstream
> decision, and in Buildroot we generally try to follow upstream
> decisions. If people are unhappy with Samba 4 being much bigger than
> Samba 3, then it's up to them to work with the Samba folks upstream to
> solve this. One guy posted some Buildroot patches at some point to only
> install certain parts of Samba 4 to reduce the installed size, and we
> invited him to work with upstream to resolve this.
> 
> So in my side, I'm fully OK with a solution that consists in switching
> kodi, mpd and gvfs over to Samba 4.

Just to document for people: The problem is that the libsmbclient
library is pretty much connected with many of the other libraries, you
just can't build that library alone and expect it to work.
And for samba4 it's not binary (as in /usr/bin/* & /usr/sbin/*) size
that bloats since all common code was moved to libraries.
With the new smbtorture option (the one and only big binary) i think
it's not worth the effort, specially that python is being pulled in and,
again, it's pretty wired into the samba4 build system hence hard to avoid.
Regards.