Please test RE24 in preparation for 2.4.8.
Thanks, Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
<quote who="Quanah Gibson-Mount">
Please test RE24 in preparation for 2.4.8.
Seems to just sit there at:
Using ldapadd to populate producer... Waiting 20 seconds for syncrepl to receive changes... Using ldapsearch to check that syncrepl received database changes... Using ldapsearch to check that syncrepl received database changes on consumer2...
on test050
will try again on a different box.
Thanks, Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount writes:
Please test RE24 in preparation for 2.4.8.
Passes all tests on Linux - Ubuntu/x86_64 and RHEL/i386.
CHANGES says:
Fixed ldapmodify exit code init (ITS#5317)
ldapsearch, not ldapmodify. And only half fixed, I asked a question and let the other half wait. The other half looks trivial, though I don't have time to test it now:
--- ldapsearch.c.~1.249.~ 2008-01-09 22:03:44.000000000 +0100 +++ ldapsearch.c 2008-02-12 16:27:04.000000000 +0100 @@ -627,3 +627,3 @@ FILE *fp = NULL; - int rc, i, first; + int rc, rc1, i, first; LDAP *ld = NULL; @@ -992,7 +992,9 @@ } - rc = dosearch( ld, base, scope, filtpattern, line, + rc1 = dosearch( ld, base, scope, filtpattern, line, attrs, attrsonly, NULL, NULL, NULL, -1 );
- if ( rc != 0 && !contoper ) { - break; + if ( rc1 != 0 ) { + rc = rc1; + if ( !contoper ) + break; }
Fixed slapd indexing with component matching (ITS#4112)
Disabled the broken code, not fixed it, according to the cvs log. (So the ITS should mention it's been disabled, I guess.)
Gavin Henry writes:
Using ldapadd to populate producer... Waiting 20 seconds for syncrepl to receive changes... Using ldapsearch to check that syncrepl received database changes... Using ldapsearch to check that syncrepl received database changes on consumer2...
on test050
will try again on a different box.
HEAD too, on Linux RHEL/i386. testrun/server[12].log keep growing, but no other files change. I've patched it a bit though, so I can't be sure it's not my fault. No time to test with clean sources now, trying later.
Hallvard B Furuseth wrote:
Gavin Henry writes:
Using ldapadd to populate producer... Waiting 20 seconds for syncrepl to receive changes... Using ldapsearch to check that syncrepl received database changes... Using ldapsearch to check that syncrepl received database changes on consumer2...
on test050
will try again on a different box.
HEAD too, on Linux RHEL/i386. testrun/server[12].log keep growing, but no other files change. I've patched it a bit though, so I can't be sure it's not my fault. No time to test with clean sources now, trying later.
I saw that as well. Should be fixed now in HEAD/RE24.
Hallvard B Furuseth wrote:
Quanah Gibson-Mount writes:
Please test RE24 in preparation for 2.4.8.
Passes all tests on Linux - Ubuntu/x86_64 and RHEL/i386.
CHANGES says:
Fixed ldapmodify exit code init (ITS#5317)
ldapsearch, not ldapmodify.
Right, that should be fixed in the CHANGES file.
And only half fixed, I asked a question and let the other half wait. The other half looks trivial, though I don't have time to test it now:
It's a lost cause. What do you do if a second error (or further) occurs?
--- ldapsearch.c.~1.249.~ 2008-01-09 22:03:44.000000000 +0100 +++ ldapsearch.c 2008-02-12 16:27:04.000000000 +0100 @@ -627,3 +627,3 @@ FILE *fp = NULL;
- int rc, i, first;
- int rc, rc1, i, first; LDAP *ld = NULL;
@@ -992,7 +992,9 @@ }
rc = dosearch( ld, base, scope, filtpattern, line,
rc1 = dosearch( ld, base, scope, filtpattern, line, attrs, attrsonly, NULL, NULL, NULL, -1 );
if ( rc != 0&& !contoper ) {break;
if ( rc1 != 0 ) {rc = rc1;if ( !contoper )break; }Fixed slapd indexing with component matching (ITS#4112)
Disabled the broken code, not fixed it, according to the cvs log. (So the ITS should mention it's been disabled, I guess.)
I was skeptical about recording this in RE24 changes. LDAP_COMP_MATCH is still behind #ifdef LDAP_DEVEL so this patch shouldn't have had any effect on RE24 either way.
Howard Chu writes:
And only half fixed, I asked a question and let the other half wait. The other half looks trivial, though I don't have time to test it now:
It's a lost cause. What do you do if a second error (or further) occurs?
Can't report all the errors, but it's better to report one error than to report success. This patch reports the latest error.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Quanah Gibson-Mount wrote:
Please test RE24 in preparation for 2.4.8.
All tests passed on FreeBSD/amd64 7.0-RC2 with RE24 tree as of 13:00 PST.
Cheers, - -- Xin LI delphij@delphij.net http://www.delphij.net/ FreeBSD - The Power to Serve!
-
Gavin Henry -
Hallvard B Furuseth -
Howard Chu -
Quanah Gibson-Mount -
Xin LI