Bug 198038

Summary: Berkeley db4 4.5.20 is released
Product: [Fedora] Fedora Reporter: Robert Scheck <redhat-bugzilla>
Component: db4Assignee: Jindrich Novy <jnovy>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: pknirsch, valdis.kletnieks
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-12-01 06:00:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 215234    
Bug Blocks:    

Description Robert Scheck 2006-07-08 13:10:27 UTC
Description of problem:
Berkeley db4 4.4.20 (stable) was released some time ago and Fedora Core 
development hangs around the older 4.3.29...

Version-Release number of selected component (if applicable):

Actual results:

Expected results:
db4-4.4.20-1 or newer ;-)

Comment 1 Jindrich Novy 2006-07-09 20:39:07 UTC
Hi Robert,

I'll update to the latest db after FC6 release to keep a well known and stable
version there.

Comment 2 Robert Scheck 2006-07-18 21:24:28 UTC
Thanks Jindrich for response. I'm a guy always using the latest version, so I 
tried to upgrade myself which caused me to open bug report #14939 at Sleepycat 
Software, because it looks like they wrote sloppy code. Rebuilding currently
fails, because they are re-defining some stuff shipped with gcc or glibc-devel 
packages. I'll keep this bug report up2date about any problems and failures I 
experience to make the update after FC6 release more easily.

Comment 3 Jindrich Novy 2006-07-19 04:11:35 UTC
Thanks Robert, this would be definitely helpful.

Comment 4 Robert Scheck 2006-07-22 22:05:21 UTC
Okay, closed my bug report at Sleepycat Software. The problem was a regression 
or bug within the compiler which was fixed at least with gcc-4.1.1-9.

Comment 5 Jindrich Novy 2006-08-07 11:34:50 UTC
Thanks for the info, have you tested the new db4? Did you encounter some other

Comment 6 Robert Scheck 2006-08-07 11:43:02 UTC
I didn't encounter further problems, but I've got to say, I'm using db4 only
at the iproute, perl, webalizer, mod_perl, pam_abl, php-cli, apr-util, python, 
sendmail and httpd packages and only on ix86 arch. My rpm 4.4.7-0.x package is 
from upstream and uses latest db4, too.

Comment 7 Robert Scheck 2006-10-03 11:06:20 UTC
Waiting for db4-4.5.20 (stable) after FC6 was released...

Comment 8 Jindrich Novy 2006-10-05 12:45:12 UTC

Testing SRPM. Any feedback is appreciated.

Comment 9 Robert Scheck 2006-10-05 18:27:01 UTC
Your package works for me, but I had to do the following things:

- Building pam- with internal db4-4.5.20 to avoid conflicts etc.
- Patch50 (db-4.3.27-initmem.patch) from cyrus-sasl-2.1.22-4 can be removed
  when using 4.5.20 for internal db4
- subversion-1.3.2-6 as to be rebuilt after apr-utils was built against 4.5.20

Rebuilding of python-2.4.3-18 and subversion-1.3.2-6 failed:

./Modules/_bsddb.c: In function 'DB_length':
./Modules/_bsddb.c:2453: error: 'DB_CACHED_COUNTS' undeclared (first use in this 
./Modules/_bsddb.c:2453: error: (Each undeclared identifier is reported only 
./Modules/_bsddb.c:2453: error: for each function it appears in.)
./Modules/_bsddb.c: In function 'DBEnv_set_lk_max':
./Modules/_bsddb.c:3811: error: 'DB_ENV' has no member named 'set_lk_max'
./Modules/_bsddb.c: In function 'init_bsddb':
./Modules/_bsddb.c:5004: error: 'DB_CACHED_COUNTS' undeclared (first use in this 
./Modules/_bsddb.c:5039: error: 'DB_RECORDCOUNT' undeclared (first use in this 
make: *** [Modules/_bsddb.o] Error 1
make: *** Waiting for unfinished jobs....

Running all tests in strings-reps-test...success
At least one test FAILED, checking /usr/src/rpm/BUILD/subversion-1.3.2/tests.log
FAIL:  fs-base-test 2: open an existing Berkeley DB filesystem
At least one test was SKIPPED, checking /usr/src/rpm/BUILD/subversion-1.3.2/
SKIP:  utf8_tests.py 1: conversion of paths and logs to/from utf8
SKIP:  authz_tests.py 1: authz issue #2486 - open root
SKIP:  authz_tests.py 2: authz issue #2486 - open directory
make: *** [check] Error 1

Comment 10 Robert Scheck 2006-10-05 21:37:23 UTC
The problem rebuilding python using db 4.5 seems to be a bug which is tracked 
down here: https://sourceforge.net/tracker/?

Comment 11 Robert Scheck 2006-10-07 19:21:38 UTC
I submitted a working patch for python resolving this to upstream...

Comment 12 Jindrich Novy 2006-10-08 05:27:52 UTC
Thanks! I'll try to rebuild the rest of the db4 dependencies next week locally
to be sure we can add the db4-4.5.20 to rawhide as soon as FC6 is released.

Comment 13 Robert Scheck 2006-10-29 23:53:03 UTC

Comment 14 Robert Scheck 2006-11-09 21:08:15 UTC
Any plan when the end of "short time" is reached to break Rawhide?

Comment 15 Jindrich Novy 2006-11-10 08:04:51 UTC
Yup, I needed to discuss what will be in the upcoming compat-db, what is now
clear so you can expect db4/compat-db upgrade during the weekend, followed by
rawhide breakage ;-)

Comment 16 Jindrich Novy 2006-11-10 18:33:26 UTC
db-4.5.20 is now built in rawhide.

Comment 17 Jindrich Novy 2006-11-12 06:11:58 UTC
The new db4 build was untagged because of buildroot breakage caused by conflict
with pam. I'll close this again when it's resolved.

Comment 18 Robert Scheck 2006-11-12 13:10:30 UTC
I saw at the lists, rebuild pam using the following in spec file:

  %define db_version 4.5.20
  %define db_conflicting_version 4.6.0

But I told you about this conflict in comment #9, you remember? ;-)

Comment 19 Robert Scheck 2006-11-12 13:11:21 UTC
Ah and you should make the compat-db packages ready _before_ pushing the new
db4 package, otherwise you'll run in other unresolved dependency problems...

Comment 20 Jindrich Novy 2006-11-12 18:31:20 UTC
I know the solution is to remove/update the pam conflict tags, but it's not an
usual practise to modify packages that have a different maintainer before
letting him know at least.

Comment 21 Valdis Kletnieks 2006-12-05 16:53:15 UTC
I tried building sendmail 8.14.0-Beta1, and got this nice error message:

/usr/bin/ld: cannot find -ldb
collect2: ld returned 1 exit status

A round of applause for whoever coded the Obsoletes: such that my db4-devel got
de-installed, nuking /usr/lib/libdb.so - this will probably bite others as well.

Comment 22 Jindrich Novy 2006-12-05 17:21:39 UTC
Obsoletes has nothing to do with it. libdb.so is simply removed as soon as you
remove db4-devel because the devel package only ships the nonversioned .so as a
symlink to a versioned library libdb-4.5.so which is a part of the main db4
package. This is an usual practise for any devel package and it is nothing unusual.

Comment 23 Valdis Kletnieks 2006-12-05 22:07:24 UTC
% rpm -q -obsoletes compat-db
db4 < 4.4
db4-devel < 4.4

So when compat-db got installed by yum, db4-devel evaporated.  Apparently, I hit
a window when compat-db and the new db4 were in the yum repository, but
db4-devel wasn't available yet, so db4-devel got removed rather than upgraded....