Samba developers no longer supporting OS X

[mistydemeo]

It looks like the Samba developers are no longer willing to support OS X at all: https://bugzilla.samba.org/show_bug.cgi?id=9659

The developer in that bug's claiming that the fork(2) syscall does not work reliably on OS X, and closed an unrelated OS X build failure as WONTFIX as a result.

[jacknagel]

lol. just lol.

we should ping people who have been involved in samba issues here and get them to complain upstream.

[mistydemeo]

Yeah, pretty much.

I hope that complaining upstream would help, but in the mailing list thread about this from last year someone was pointing out that he was wrong and it didn't have any appreciable effect.

[MikeMcQuaid]

Thought this would happen. We should definitely remove from core unless this is resolved.

[samueljohn]

Yeah, a Homebrew/shame tap.

[cooljeanius]

we should ping people who have been involved in samba issues here and get them to complain upstream.

OK, I'll do that: hey @urdh @latristesse @thebodzio @BrazilianJoe @bpaf @MindTooth @vertis @2bits @ylluminate @82times y'all should come complain upstream.

[cooljeanius]

Aw darn it looks like there's a limit to the number of "@" mentions you can include in a single comment... let me move some of those to this one: hey @lasombra @philippelatulippe @eduo @maddox @asparagui you guys should come complain upstream, too.

[Sharpie]

Yeah, a Homebrew/shame tap.

Homebrew.new('pillory') unless upstream.regains_sanity?

[philippelatulippe]

This just seems like bizarre alarmism? Nothing has actually changed, as mentioned at the end of that mailing list thread:

The behaviour (and policy) [of fork] has been the same forever. The only thing new here is the documentation.

Someone could submit a patch to the real problem in samba bug #9659 as a new bug and wait for another developer to handle it. If the same developer comes about and closes the bug as wontfix, then we bring it up with the other devs.

[mistydemeo]

@philippelatulippe

A core samba developer closing an unrelated Mac bug as WONTFIX because OS X is no longer supported does seem to indicate policy. Rather than play whack-a-mole with bug reports, at this point the best thing to do would be to write to the mailing list asking directly if samba is supported on OS X or not. I can do that, or users of samba can.

Meanwhile, although the cause of the specific issue in that bug was identified and I've been able to work around it by enabling warnings in the formula, samba 4.0.0+ still will not build for me. We should revert to 3.6.8 in the meanwhile.

[mistydemeo]

I've reverted to 3.6.8 while we sort this out. The autoconf build we were using for samba 4.0.0 only installs a subset of samba's tools, and the waf build (which is now intended as the primary buildsystem) is presently broken on OS X because it generates bad installnames.

The issue for the waf buildsystem problem: https://bugzilla.samba.org/show_bug.cgi?id=9665

[eduo]

What's a shame is how clear the bias agains OS X is present in the Samba group. This bit about Darwin has existed since forever and has just recently been documented as a specific CAVEAT. This caveat, in reality, is a recommended guideline that Apple simply decided to not try and workaround but, in essence, a caveat that shouldn't affect Samba. The caveat has been documented since Lion, too.

The discussion in the Samba list then goes off-topic in asinine discussions about whether this makes OS X a true Unix (and not, you know, the UNIX certification). The implication, none too subtle, is that Linux is more of a Unix than OS X (which provides all the necessary moral high-ground to justify actions that are essentially retaliation against Apple for shunning Samba in Lion, something the Samba group has never really been able to put behind).

This also essentially means the bug in Samba about having users with more than 16 groups will never be addressed.

[tkrajacic]

Is there any update on this issue? I just updated my formula to 4.0.7 and it worked without a problem.
I did it to prevent ruby-net-smb to segfault (which it does with the current samba in homebrew) and with 4.0.7 it works flawlessly.
Why don't we update to 4.0.7 again? As the current version is obviously troubled in some way (assuming, since upgrading samba solved the segfault in the ruby gem)

I am using

    http://www.samba.org/samba/ftp/stable/samba-4.0.7.tar.gz
    a40a57049cd34ee8720f864063b946e38ffa8d3e

[mistydemeo]

Nothing has changed. Samba 4.x has officially switched from autotools to a waf buildscript. Using autotools only builds you a small subset of samba, so that's really a no-go. The waf buildsystem continues to be broken.

[adamv]

MacPorts has gotten some 3.6.x updates in the mean time: https://trac.macports.org/log/trunk/dports/net/samba3/Portfile

Should we attempt to pull any of that, or should we redact this software?

[eduo]

It makes no difference. These notes relate to 4 and the situation there hasn't changed.

Macports has kept updating their old version of samba 3 to less old versions is samba 3. I believe homebrew already supports the newer versions of the 3.x branch.

[adamv]

It makes no difference.

Should we drop Samba 3 from core entirely then?

[MikeMcQuaid]

Hmm, maybe. At least move it to a tap I guess. homebrew-upstreamhatesyou

[adamv]

MacPorts does some stuff to get a newer Samba3 working, including disabling Kerberos: https://trac.macports.org/browser/trunk/dports/net/samba3/Portfile?order=name

Tried going to x.x.20, but don't really want to backport all of what MacPorts is doing.

3.x.x is currently non-building on modern OS X versions out of Homebrew.

I'm not very motivated to try fixing it, but it seems doable.

[mistydemeo]

I couldn't convince it not to use kerberos even with --without-krb5 - not sure why it didn't work.

[adamv]

Figured it out, I had to also disable ldap.

[adamv]

Closing this issue in the interest of mercilessly reducing the open issue count.

We will definitely review a PR that tries to get Samba 4 working for OS X users.

[abartlet]

I can assure you that this is a misreading of a user-created by due to setting -w in CFLAGS. The fork() issue is serious, but is orthogonal to the bug at hand. We won't actively stop it working on MacOS, the rest is up to Apple.

[MikeMcQuaid]

"The rest is up to Apple" does mean "we aren't going to support OS X (because we think Apple should)". We work around lots of Apple bugs and weirdness in Homebrew; I'd suggest you do the same if you wish to support OS X. If you don't, no problem.

[abartlet]

On Fri, 2013-11-29 at 00:21 -0800, Mike McQuaid wrote:

"The rest is up to Apple" does mean "we aren't going to support OS X
(because we think Apple should)". We work around lots of Apple bugs
and weirdness in Homebrew; I'd suggest you do the same if you wish to
support OS X. If you don't, no problem.

Patches to have Samba, or components of it, continue to work on MacOS X
are still welcome, but we are very concerned about the situation around
fork(). That part isn't a good sign, but feel free to continue to work
around it, and to help us. We haven't deliberately removed any support,
but were shocked to find such a fundamental call go 'unsupported'.

Andrew Bartlett

Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba