Samba 3.14a is nearly two month out.. If no problems are reported against this package, it could be marked as stable. It provide many bugfixes compared to the old stable version 3.10.
This is not a GLSA, most a 'bug fix release', but some fixes are important. Could you please mark samba-3.0.14a-r1 stable for all supported archs?
sparc stable.
I've tested 3.14a-r1 on amd64 and the tests (enable them with FEATURES="maketest") fail. seems to work fine otherwise, not marking it stable for now since the test failure is a regression, maketest is no problem with the current stable samba-3.0.10.
Compiling torture/t_push_ucs2.c x86_64-pc-linux-gnu-gcc -O2 -march=k8 -I/usr/include/mysql -march=k8 -pipe -DHA VE_ERRNO_AS_DEFINE=1 -DUSE_OLD_FUNCTIONS -I/usr/include/libxml2 -Iinclude -I/va r/tmp/portage/samba-3.0.14a-r1/work/samba-3.0.14a/source/include -I/var/tmp/port age/samba-3.0.14a-r1/work/samba-3.0.14a/source/ubiqx -I/var/tmp/portage/samba-3. 0.14a-r1/work/samba-3.0.14a/source/smbwrapper -I. -D_LARGEFILE64_SOURCE -D_FILE _OFFSET_BITS=64 -D_GNU_SOURCE -I/var/tmp/portage/samba-3.0.14a-r1/work/samba-3.0 .14a/source -o bin/t_push_ucs2 -Wl,--export-dynamic -lcrypt -lnsl -ldl tortu re/t_push_ucs2.o -L ./bin -lbigballofmud x86_64-pc-linux-gnu-gcc -O2 -march=k8 -I/usr/include/mysql -march=k8 -pipe -DHA VE_ERRNO_AS_DEFINE=1 -DUSE_OLD_FUNCTIONS -I/usr/include/libxml2 -Iinclude -I/va r/tmp/portage/samba-3.0.14a-r1/work/samba-3.0.14a/source/include -I/var/tmp/port age/samba-3.0.14a-r1/work/samba-3.0.14a/source/ubiqx -I/var/tmp/portage/samba-3. 0.14a-r1/work/samba-3.0.14a/source/smbwrapper -I. -D_LARGEFILE64_SOURCE -D_FILE _OFFSET_BITS=64 -D_GNU_SOURCE -I/var/tmp/portage/samba-3.0.14a-r1/work/samba-3.0 .14a/source -o bin/t_snprintf -Wl,--export-dynamic -DTEST_SNPRINTF lib/snpri ntf.c -lm LD_LIBRARY_PATH="`pwd`/bin:$LD_LIBRARY_PATH" \ PATH="`pwd`/bin:$PATH" \ python stf/standardcheck.py; \ if test -n "python"; then \ python stf/pythoncheck.py; \ fi StrCaseCmp OK strstr_m OK PushUCS2_Tests OK NoArgs OK OneArg OK SmbdDest OK NmbdDest NOTRUN, not implemented WinbinddDest NOTRUN, not implemented PidDest OK SelfDest OK BadDest OK BadCmd OK Debug NOTRUN, must be root to run this test ForceElection NOTRUN, must be root to run this test SamSync NOTRUN, must be root to run this test SamRepl NOTRUN, must be root to run this test DmallocMark NOTRUN, must be root to run this test DmallocChanged NOTRUN, must be root to run this test Shutdown NOTRUN, must be root to run this test DrvUpgrade NOTRUN, must be root to run this test CloseShare NOTRUN, must be root to run this test Ping NOTRUN, must be root to run this test Debuglevel NOTRUN, must be root to run this test PrintNotify OK Profile NOTRUN, must be root to run this test ProfileLevel NOTRUN, must be root to run this test TimeoutArg OK ConfigFileArg OK BogusArg OK snprintf_Test OK ImportTest FAIL ----------------------------------------------------------------- Traceback (most recent call last): File "/var/tmp/portage/samba-3.0.14a-r1/work/samba-3.0.14a/source/stf/comfycha ir.py", line 325, in runtests obj.runtest() File "stf/pythoncheck.py", line 36, in runtest self.fail('error importing %s module' % m) File "/var/tmp/portage/samba-3.0.14a-r1/work/samba-3.0.14a/source/stf/comfycha ir.py", line 103, in fail raise AssertionError(reason) AssertionError: error importing tdb module test_log: /var/tmp/portage/samba-3.0.14a-r1/work/samba-3.0.14a/source/build/lib.linux-x86_ 64-2.4/samba/tdb.so: undefined symbol: tdb_lockkeys ----------------------------------------------------------------- make: *** [check] Error 1 !!! ERROR: net-fs/samba-3.0.14a-r1 failed. !!! Function src_test, Line 566, Exitcode 0 !!! Make check failed. See above for details. !!! If you need support, post the topmost build error, NOT this status message.
stable on ppc64
stop marking this stable, unless you can verify maketest passes on your architecture.
once bug 92575 is fixed, this can be considerd, but not till then (or until we understand why the tests fail and are comfortable with that).
there are two causes: FEATURES="sandbox" (leads to some not critical errors) USE="python" (critical: tdb module bindings not up to date) USE="-python" FEATURES="-sandbox maketest" emerge -Bav samba: all tests successful I think arch tests could proceed: a warning can be raised on tdb python bindings in emerge phase. There are no test issues/warnings about gentoo patches nor about other keywords. seemant: what do you think about?
I seem to have problems with growing numbers of smbd processes on some machines (all x86, just checking one alpha) which are only killable with -9. I am still investigating this.
> FEATURES="sandbox" (leads to some not critical errors) What errors? There shouldn't be going anything stable that doesn't work flawlessly with {user,}sandbox.
Ok, after looking at the logs I found it full of glibc errors trying to free invalid pointers. This seems to leave dead smbd processes, as I can spawn as many as I like with any simple CIFS connect to my box. Guess i have a blooper with the toolchain so I'll have to recompile it and samba and then try again.
Does nobody else get this? I recompiled mywhole toolchain (twice, of course ;-) and samba, but still get the same result. Invalid pointer on free(), and then the subprocess hangs. I don't know when this started. It could be related to the recent linux-headers update, but I am not sure.
Now this is fun. I can't believe this. I just set my malloc overcommit policy to 2 (don't overcommit) ... no more stale subprocesses. Doh.
Remove/ignore last comment (#13) ...
Christian, let's try and fix up all the tests if possible.
Restart from now: Abstract: stable status request for samba 3.0.14a-r2 Summary of previous comments: -- (9-14) wgi bugs were not related to samba, but to some kerberos related packages. Resolved (thanks to seemant) -- (4,6,10): minor fixes in python tdb bindings and python testsuite: no more sandbox violations now -- (2,5): ppc64 and sparc marked stable 3.0.14a-r1. Nothing (IMHO) requiring new tests changed, but following QA I reverted these to unstable in -r2.
10 Jun 2005; Christian Andreetta <satya@gentoo.org> files/samba.pam: reverting pam to old behaviour until pam-0.78 becomes stable You've now moved back to specifying the full path to the pam modules in your pam.d file, /lib/security/ when these are actually installed in $(get_libdir)/security. This causes problems on multilib systems. There is no need to specify the full path here, pam will load the module from it's default path if you just specify the module on it's own. I will not mark this stable on amd64 until this is fixed.
herbs: pam conf fixed (sorry)
Thanks satya, marked stable on amd64.
stamped hppa
satya, is x86 ok for stable (I'm assuming that's your architecture)?
seemant: yes, x86 is my architecture and I consider this version stable on it. Can I put it to stable?
I'm using .14-r2/-r1 on a x86 production machine for two weeks now, no problems so far.
Christian, yes of course you can :) It's your architecture and your package, so you have all the say in the world about it. Usually, your arch must go stable before any of the others :)
Marked ppc stable.
ping to mips, ia64, and alpha teams
No alpha team member, but it's been running on my alpha since the ebuild was put in portage, without problems .-)
What about bug #96453, btw? Doesn't that prevent marking it stable?
Stable on mips.
Seems like kloeri marked this yesterday on alpha and ia64, so removing them from the CC list. Cheers, Ferdy
wgi: (comment #30) bug #96453 was due to sandbox, not samba. This seems now fixed.
(In reply to comment #33) > wgi: (comment #30) bug #96453 was due to sandbox, not samba. This seems now fixed. But sandbox 1.2.12 is still hardmasked. So you have a stable samba requiring a masked package to even build?
I still have problems with winbindd in ADS mode. From time to time the process seems to "explode" and use up memory like mad. I've seen it make my workstation swap out 1+ Gig (from 0 to start with) in a couple of seconds, bogging the machine to a grinding crawl.
should be all set now
wgi (comment #35): this seems a known winbind (not much) vs kerberos (mostly) issue. Try to look at [1], and see if this applies to you (particularly the latest comments). [1] https://bugzilla.samba.org/show_bug.cgi?id=2739