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.3.29-4 Actual results: db4-4.3.29-4 Expected results: db4-4.4.20-1 or newer ;-)
Hi Robert, I'll update to the latest db after FC6 release to keep a well known and stable version there.
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 regressions?
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...
http://people.redhat.com/jnovy/files/db4-4.5.20-1.src.rpm 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 function) ./Modules/_bsddb.c:2453: error: (Each undeclared identifier is reported only once ./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 function) ./Modules/_bsddb.c:5039: error: 'DB_RECORDCOUNT' undeclared (first use in this function) 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/ tests.log 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/? func=detail&atid=105470&aid=1571754&group_id=5470
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.
Ping?
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....