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):
db4-4.4.20-1 or newer ;-)
I'll update to the latest db after FC6 release to keep a well known and stable
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.
Thanks Robert, this would be definitely helpful.
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.
Thanks for the info, have you tested the new db4? Did you encounter some other
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.
Waiting for db4-4.5.20 (stable) after FC6 was released...
Testing SRPM. Any feedback is appreciated.
Your package works for me, but I had to do the following things:
- Building pam-0.99.6.2-3 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
The problem rebuilding python using db 4.5 seems to be a bug which is tracked
down here: https://sourceforge.net/tracker/?
I submitted a working patch for python resolving this to upstream...
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.
Any plan when the end of "short time" is reached to break Rawhide?
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 ;-)
db-4.5.20 is now built in rawhide.
The new db4 build was untagged because of buildroot breakage caused by conflict
with pam. I'll close this again when it's resolved.
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? ;-)
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...
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.
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.
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.
% 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....