Summary: verify-db.pl still assumes the db dir is always in the instance dir https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233215 nhosoi@xxxxxxxxxx changed: What |Removed |Added ---------------------------------------------------------------------------- Status|MODIFIED |ASSIGNED This review request contains the proposed changes on ldapserver, internal spec file for Berkeley DB 4.2.52, and the Berkeley DB 4.2.52. ------- Additional Comments From nhosoi@xxxxxxxxxx 2007-03-29 21:30 EST ------- There are mutiple problems found around verify-db.pl on Solaris... :( 1, I introduced "DB-DIR" macro for template-verify-db.pl.in, but the corresponding version if create_instance.c hasn't been checked in yet (* create_instance.c.diff is being attached) 2. template-verify-db.in has the following envirament variable PATH set: $ENV{'PATH'} = "$prefix@db_bindir@:$prefix/usr/bin:@db_bindir@:/usr/bin"; And the derived verify-db.pl on 64-bit Solaris looks like this: $ENV{'PATH'} = "$prefix/usr/bin:$prefix/usr/bin:/usr/bin:/usr/bin"; 2-1. The problem is db_* utilities on 64-bit Solaris are installed in /usr/bin/sparcv9, thus verify-db.pl fails to find the executables and exits. 2-2. To get the right path, db4 packaging is supposed to generate db.pc and put the file in /usr/lib/sparcv9/pkgconfig, but svn:pkgs/db4 spec file does not have the code (** db4.template.diff is being attached) Note: the system Berkeley DB on RHELs has db.pc in /usr/lib/pkgconfig. 2-3. Even though db.pc is placed in the right place, ldapserver/m4/db.m4 does not check db.pc with pkg-config, but sets the hardcoded path /usr/bin to db_bindir (*** db.m4.diff is being attached) 3. With all the above fixes, ran verify-db.pl, then one of the Berkeley DB utilities db_printlog crashed... The cause of the crash was a field called timestamp is declared as int32_t, but the pointer to the value is casted to (time_t *), where time_t is 64 bits on the 64-bit machine. The cast mismatch makes ctime/localtime fail and it leads the utility crash. I looked at the db 4.4.20 code, and verified it was fixed. I back-ported the change to 4.2.52 and made a patch since I could not find the patch on the Sleepycat site. (**** patch.4.2.52.txn is being attached) ------- Additional Comments From nhosoi@xxxxxxxxxx 2007-03-29 21:32 EST ------- Created an attachment (id=151245) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=151245&action=view) cvs diff create_instance.c (* create_instance.c.diff in Comment #7) File: ldap/admin/src/create_instance.cChange: 1, I introduced "DB-DIR" macro for template-verify-db.pl.in, but the
corresponding version if create_instance.c hasn't been checked in yet. ------- Additional Comments From nhosoi@xxxxxxxxxx 2007-03-29 21:37 EST ------- Created an attachment (id=151246) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=151246&action=view) svn diff db4.template (** db4.template.diff in Comment #7) File: svn:rpms/pkgs/db4/SPECS/db4.templateChanges: 1) added a code to generate db.pc for pkg-config
2) apply a patch to fix the db_printlog crash problem. The patch proposal is being attached later (**** patch.4.2.52.txn) ------- Additional Comments From nhosoi@xxxxxxxxxx 2007-03-29 21:42 EST ------- Created an attachment (id=151247) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=151247&action=view) cvs diff ldapserver/m4/db.m4 (*** db.m4.diff) File: ldapserver/m4/db.m4 Change: To set db_bindir, if db.pc exists, check if bindir variable is defined in the file or not. If it's defined, set it to db_bindir. If not, set the default path /usr/bin to db_bindir. ------- Additional Comments From nhosoi@xxxxxxxxxx 2007-03-29 21:47 EST ------- Created an attachment (id=151248) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=151248&action=view) Proposed patch (**** patch.4.2.52.txn) File: svn:rpms/pkgs/db4/SOURCES/patch.4.2.52.txn Fix Description: The cause of the db_printlog crash was the unexpected cast from the pointer to the 32-bit integer to the pointer to time_t/long (64-bit). The patch is a back-port from db 4.4.20, where the problem was already fixed.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-directory-devel mailing list Fedora-directory-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-devel
