samba: deprecate package due to EOL

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

Signed-off-by Gustavo Zacarias <[email protected]>

ifeq ($(BR2_PACKAGE_ACL),y)

package/samba4/samba4.mk +18 -26

-	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

Dear Gustavo Zacarias,

Quoted 3 lines · Gustavo Zacarias

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

Quoted 1 line

Signed-off-by Gustavo Zacarias <[email protected]>

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.

Quoted 2 lines

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.

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?

Quoted 4 lines

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.

Quoted 4 lines

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.

Dear Gustavo Zacarias,

Quoted 5 lines · Gustavo Zacarias

Quoted 4 lines

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.

Quoted 2 lines

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.

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.

Quoted 2 lines

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.

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.

Quoted 4 lines

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.

Quoted 3 lines

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.

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

Quoted 3 lines

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.

Quoted 3 lines

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.

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.

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.

Quoted 1 line

And, for me personally, it just makes me

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

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.

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 ?

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Gustavo" == Gustavo Zacarias <[email protected]> writes:

Quoted 6 lines

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.

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.

Quoted 3 lines

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".

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

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.

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.

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 ?

Quoted 3 lines

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 ;)

Quoted 4 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> 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.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Gustavo" == Gustavo Zacarias <[email protected]> writes:

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 3 lines

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.

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.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Dear Gustavo Zacarias,

Quoted 5 lines · Gustavo Zacarias

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.

Quoted 2 lines

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

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

Signed-off-by Gustavo Zacarias <[email protected]>

+ 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.

Quoted 9 lines

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?

Quoted 2 lines

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.

Quoted 7 lines

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

Quoted 1 line

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 ;)

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

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 <[email protected]>

---
 package/samba/Config.in | 2 ++
 1 file changed, 2 insertions(+)

package/samba/Config.in +2 -0

index 9d04851..7ff8428 100644
@@ -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
 

Quoted 1 line · Gustavo Zacarias

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

What about samba support in mpd and kodi?

Dear Arnout Vandecappelle,

Quoted 4 lines · Arnout Vandecappelle

Quoted 1 line · Gustavo Zacarias

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.

Dear Arnout Vandecappelle,

Quoted 2 lines · Arnout Vandecappelle

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.

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.