Re: [Pkg-samba-maint] Bug#759008: libtdb1: FTBFS on hurd-i386
On 23/08/2014 22:27, Jelmer Vernooij wrote:
block 759008 by 748943
tags 759008 -patch
Yes, I get that. But that doesn't mean it doesn't work without this
patch, since samba actually works with this, which was the point.
On Sat, Aug 23, 2014 at 02:30:33PM -0400, Manuel Menal wrote:
tdb fails to build on hurd-i386 (blocking ldb and thus samba) because
it uses two features that are not yet implemented on GNU/Hurd: msync(1)
and partial file locking.
You'll find attached two small patches that make it build.
The first patch adds a configure test for partial file locking and make
tdb use whole file locking when it's not supported.
The second one adds a configure test for msync(1) and correct tdb's
Please note that this package should be built with 'nocheck' because
some tests do not run well without partial file locking. The tools in
tdbtools/ run fine though.
Please also note that hurd-any should be added to debian/control so it
gets built on hurd-i386.
The whole point of tdb is that it allows multiple concurrent
readers/writers, and that is why the various applications that depend
on tdb use it.
The only tests that fail are those which check specifically for partial
file locking (test/lock-tracking.c specifically checks for lock
overlaps, which of course happen since the whole file is locked; which
makes run-die-during-transaction and run-no-lock-during-traverse fail).
This patch might make tdb build, but it makes it pointless. Any
patches to fix tdb on the Hurd the should also pass the test
suite, or downstream users risk database corruption and/or other
I fail to see how it could cause database corruption, since, indeed, the
whole file is always locked. The only thing it does (as you rightly
pointed out) is limit functionality.
I do hope too that partial file locking gets implemented on GNU/Hurd
ASAP. But in the meantime, it would be a shame not to have a working
samba, when it *does* work fine with this patch.
Please fix byte range locking in the Hurd (see the blocking bug I've
added), or propose a patch that uses an alternative *and* passes the
Thank you for your answer,