IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Since tdb library will never be built from ctdb sources, we don't need the build
related files.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(This used to be ctdb commit a7aace3d165e6cb7d63950107e584edaee12a357)
Since talloc library will never be built from ctdb sources, we don't need the
build related files.
(This used to be ctdb commit 2cd6a7ce648c1d2cc4d5580c3809858c100fa930)
Since we are not going to build tevent library from ctdb source, remote build
related files.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(This used to be ctdb commit efbb7e0b9dcde547b46efd8e3b26c571e4fcf893)
This allows to build against system tevent library. Also include tevent header
along with other common headers.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(This used to be ctdb commit 9ae4389c2c959c5dcd8395fdae2b25ed7e1e873a)
Warnings are generated when compiling strptime.c. Why is it being
compiled on Linux? strptime(3) has been in glibc for 15 years!
It turns out that some of the test fragments were being looked for in
lib/replace/test/ and some in lib/replace/tests/. In addition,
test*/strptime.c was missing.
Move the tests to lib/replace/test/ for consistency with upstream
(Samba) and copy in test/strptime.c from Samba. Tweak repdir.m4 to
handle the directory rename.
Signed-off-by: Martin Schwenke <martin@meltin.net>
(This used to be ctdb commit aaf1ddfc83cf2ede29288baf04a1aa1c69a5cab5)
popt generates 4 compiler warnings with GCC 4.6. There are 2
different types:
* 3 instances of:
warning: cast discards ‘__attribute__((const))’ qualifier from pointer target type [-Wcast-qual]
One occurs in the _free() hack that is used to try and avoid a
compiler warning. I guess GCC got smarter? ;-)
The other is where an array of constant strings is passed to
execvp(2), which arguably has the wrong type, since it has no need
to modify the strings.
Both of these can be worked around by casting to intptr_t before
casting to the desired argument type.
In poptReadConfigFile() the variable file is declared to be a
constant string. However, it is then passed to read(2) straight
away and an attempt is made to cast away the "const". However, to
protect the value the of file is assigned to (const char *) chptr
before it is passed to any other functions, so this protects the
value anyway. I'm not sure exactly what the thinking was
here... but there seems to be no use having file be constant.
* 1 instance of:
warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
for the result of an execvp(2) call. Recast the return type to
void. However, due to some #if-fu in the function, that can make rc
unused in this function. So we also need to wrap the declaration of
rc in some corresponding #if-fu to make it disappear if not used.
Signed-off-by: Martin Schwenke <martin@meltin.net>
(This used to be ctdb commit ac9236e64bd0b61740cc787819a1222bc6a67d4a)
Have sent this upstream to Samba.
Signed-off-by: Martin Schwenke <martin@meltin.net>
(This used to be ctdb commit 080edee3d053d770466ebcc976eb1135c80feef8)
CTDB wants to use these functions but Samba's tevent wants to mark
them deprecated. This adds a #define to shut up the warnings and sets
it in CFLAGS.
Signed-off-by: Martin Schwenke <martin@meltin.net>
(This used to be ctdb commit 788cdbddbc902a5b076d23473450065b551d274d)
tdb_traverse_read() grabs the transaction lock. This can cause ctdbd
(which uses it) to block when it should not; expose mark and normal
variants of this lock, so ctdbd's child (the recovery daemon) can
acquire it and the ctdbd parent can mark it was held.
(This used to be ctdb commit d09fa845bd848d04507853809acf42e0471b44bf)
if we are the main ctdb daemon.
Other daemons/child processes are not guaranteed to get events on regular basis
so those should not be checked.
(This used to be ctdb commit ac2afe9c25753b837d5f6396020e0f3c65ef3628)
the original "Time jumped" messages are too coarse to interpret
exactly what was going wrong inside of CTDB.
This patch removes the original logs and adds two other logs that
differentiate between the time it took to work on an event and
the time it took to get the next event.
(This used to be ctdb commit fd8d54292f10b35bc4960d64cfa6843ce9aba225)
(Imported from SAMBA commit 09a6538969ac).
Chris Cowan tracked down a SEGV in sub_alloc: idp->level can actually
be equal to 7 (MAX_LEVEL) there, as it can be in sub_remove.
(We unfairly blamed a shift of a signed var for this crash in commit
2db1987f5a3a).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 73764104356d3738d9d20a9d06ce51535f74f475)
Right-shifting signed integers in undefined; indeed it seems that on
AIX with their compiler, doing a 30-bit shift on (INT_MAX-200) gives
0, not 1 as we might expect.
The obvious fix is to make id and oid unsigned: l (level count) is also
logically unsigned.
(Note: Samba doesn't generally get to ids > 1 billion, but ctdb does)
Reported-by: Chris Cowan <cc@us.ibm.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Autobuild-User: Rusty Russell <rusty@samba.org>
Autobuild-Date: Wed Oct 6 08:31:09 UTC 2010 on sn-devel-104
(This used to be ctdb commit 53d49df2d4519c35b270c30660e2504af2a5ed5c)
The call could fail with e.g. MemoryError, and we'll dereference NULL
pointer without checking.
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
Signed-off-by: Jelmer Vernooij <jelmer@samba.org>
(This used to be ctdb commit 09369aa86e233a58ed131fa5b7584b6c86527d40)
In 2dcf76 Rusty added TDB_INCOMPATIBLE_HASH open flag which selects
Jenkins lookup3 hash for new databases.
Expose this flag to python users too.
Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Jelmer Vernooij <jelmer@samba.org>
(This used to be ctdb commit 07880810941850e81442b888cd70d810d3f80fc3)
This flag to tdb_open/tdb_open_ex effects creation of a new database:
1) Uses the Jenkins lookup3 hash instead of the old gdbm hash if none is
specified,
2) Places a non-zero field in header->rwlocks, so older versions of TDB will
refuse to open it.
This means that the caller (ie Samba) can set this flag to safely
change the hash function. Versions of TDB from this one on will either
use the correct hash or refuse to open (if a different hash is specified).
Older TDB versions will see the nonzero rwlocks field and refuse to open
it under any conditions.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit dd86b24ae5307fe09d4ae22b7070d747013a2b07)
If the caller to tdb_open_ex() doesn't specify a hash, and tdb_old_hash
doesn't match, try tdb_jenkins_hash.
This was Metze's idea: it makes life simpler, especially with the upcoming
TDB_INCOMPATIBLE_HASH flag.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 3f7ed2b46cb304d553d3f7bd34554d695b8ccc52)
This is a better hash than the default: shipping it with tdb makes it easy
for callers to use it as the hash by passing it to tdb_open_ex().
This version taken from CCAN and modified, which took it from
http://www.burtleburtle.net/bob/c/lookup3.c.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 58c9d90c758aa7c062d84ab97f62947190526356)
The problem was tdb->name is NULL for TDB_INTERNAL databases, and
so it was crashing ...
#0 0xb76944f3 in strlen () from /lib/i686/cmov/libc.so.6
#1 0x0809862b in PyString_FromFormatV (format=0xb72b6a26 "Tdb('%s')", vargs=0xbfc26a94 "")
at ../Objects/stringobject.c:211
#2 0x08098888 in PyString_FromFormat (format=0xb72b6a26 "Tdb('%s')") at ../Objects/stringobject.c:358
#3 0xb72b65f2 in tdb_object_repr (self=0xb759e060) at ./pytdb.c:439
Cc: 597089@bugs.debian.org
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Jelmer Vernooij <jelmer@samba.org>
(This used to be ctdb commit 3ff413baf04ce28eb54a80141250ae1284b2a521)
