Bug 198038 - Berkeley db4 4.5.20 is released
Berkeley db4 4.5.20 is released
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: db4 (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jindrich Novy
: Reopened
Depends On: 215234
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-08 09:10 EDT by Robert Scheck
Modified: 2013-07-02 19:16 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-01 01:00:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robert Scheck 2006-07-08 09:10:27 EDT
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 ;-)
Comment 1 Jindrich Novy 2006-07-09 16:39:07 EDT
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 17:24:28 EDT
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 00:11:35 EDT
Thanks Robert, this would be definitely helpful.
Comment 4 Robert Scheck 2006-07-22 18:05:21 EDT
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 07:34:50 EDT
Thanks for the info, have you tested the new db4? Did you encounter some other
regressions?
Comment 6 Robert Scheck 2006-08-07 07:43:02 EDT
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 07:06:20 EDT
Waiting for db4-4.5.20 (stable) after FC6 was released...
Comment 8 Jindrich Novy 2006-10-05 08:45:12 EDT
http://people.redhat.com/jnovy/files/db4-4.5.20-1.src.rpm

Testing SRPM. Any feedback is appreciated.
Comment 9 Robert Scheck 2006-10-05 14:27:01 EDT
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
Comment 10 Robert Scheck 2006-10-05 17:37:23 EDT
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
Comment 11 Robert Scheck 2006-10-07 15:21:38 EDT
I submitted a working patch for python resolving this to upstream...
Comment 12 Jindrich Novy 2006-10-08 01:27:52 EDT
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 18:53:03 EST
Ping?
Comment 14 Robert Scheck 2006-11-09 16:08:15 EST
Any plan when the end of "short time" is reached to break Rawhide?
Comment 15 Jindrich Novy 2006-11-10 03:04:51 EST
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 13:33:26 EST
db-4.5.20 is now built in rawhide.
Comment 17 Jindrich Novy 2006-11-12 01:11:58 EST
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 08:10:30 EST
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 08:11:21 EST
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 13:31:20 EST
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 11:53:15 EST
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 12:21:39 EST
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 17:07:24 EST
% 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....

Note You need to log in before you can comment on or make changes to this bug.