Please test the upgrade to db-4.0.14-r2 on all non-x86 arches. Bug-wranglers: I don't know the ids for mips, hppa, arm, amd64, could you please add them to the CC list. From my email: Hopefully now all of the DB4.0 bugs have been worked out, as we haven't had any new reports of problems in over a month now. In line with this, and hopefully to make some progress, I have marked db-4.0.14-r2 as stable on x86, and marked it as testing on all other architectures. Would all non-x86 people please test it out? Upgrade to it, then try to re-merge at least the packages that depend on sys-libs/db and not a specific version of the db library. An emerge -e world is probably a much better test. If it works out for you, please mark it as stable for your architecture sometime in the next 2 weeks if possible, so that we can continue with DB-4.1. DB-4.1 will be moved into testing on x86 sometime in the next two weeks once I have done some more testing on it.
I'm making gcc-3.3.1 (not -r1) stages for sparc64 and mips, and I went on ahead and added db-4.0.14-r2 into the testing profiles for both. Figured I might as well test as many experimental things as possible. So far, sparc64 is doing great, mips however requires a small tweak to the ebuild. db-4.0.14 apparently doesn't understand mips-linux systems, so this is where gnuconfig comes into play. However, ${S} points to ${WORKDIR}/${P}/build_unix, which a plain gnuconfig_update call will fail on, because config.sub and config.guess are in ${WORKDIR}/${P}/dist instead. The attached patch to the db-4.0.14-r2 ebuild should remedy this.
Created attachment 17530 [details, diff] changes to db-4.0.14-r2.ebuild for mips
In the past, we had packages not to use db 4 by locking them into db 3. Was this done via package.mask or in the ebuilds themselves? Also what programs currently in portage will utilize db4? What can we use to measure a sucess factor?
Kumba: thanks i've added your patch now. Weeve: the changes to lock ebuilds down to a given version are contained in the ebuilds themselves. It cannot be done via package.mask as we need to be able to release them as some programs in the tree have definate dependancies on db-4.0 and db-4.1. dev-lang/perl-5.8.0-r12 dev-php/php-4.3.3 net-fs/netatalk-1.6.3 net-mail/bogofilter-0.14.5 net-www/apache-2.0.47 is a short list of packages. This command should produce a list of packages for your systems that presently use any db library. DIRS="{,/usr,/usr/kde/*,/usr/X11R6}/{bin,lib,sbin} /opt" eval find $DIRS -perm +111 -type f | xargs ldd 2>/dev/null |egrep ':|libdb' |grep -B1 'libdb' |grep ':' | cut -d: -f1 | xargs -n1 qpkg -f -v | sort | uniq
apache and bogofilter seem to be happy enough using db4. not sure what to look for in perl that would be linked to db. not sure what all i need to do with php to make it try to detect db4. seems to be a lot of stuff in there to not use db4.
I have the code in PHP itself to use DB disabled at the moment, as it wants DB4.1 and not just DB4.0. However it's detection code still runs and does a reasonable job of telling you if things are messed up with your DB enviroment.
Comment on attachment 17530 [details, diff] changes to db-4.0.14-r2.ebuild for mips Patch applied to bug.
update to my previous note about PHP. PHP does now use libdb again, since it's working in 4.3.3 (wasn't in 4.3.2).
php successfully built against db 4.0.14 on sparc.
Kumba/Weeve: If you are happy with db-4.0.14-r2 now, could you please mark the ebuild as stable? It's been in the tree more than a month with no problem reports about it directly.
Works for me, marked it stable.
I'll have to give apache/php a run on my mips box, since that looks like a valid test of db. Weeve, don't forget to change the default-sparc64 and default-sparc profiles to accept db4. Right now, they're locked down to db3, only the gcc33-sparc64 profile does db4.
this is still outstanding for: ppc, mips, hppa, arm do those arches (besides ppc) have mail aliases?
ppc stable now is on 4.1
i emerged db-4.0.14-r2 and tried some apps with it and seemed to work (on hppa) gmsoft: what are we missing in order to update the profile to let in db-4 ?
In fact we where thinking about directly marking stable db-4.1 very soon. We aldready tried it from stage1 to stage3 and we did a emerge -e world on a box with many pkg and we had no problems so far. We are just waiting for kdebase to compile atm. This is the last we'll do. Does db-4.1 hav any know problem ? It it a problem to skip db-4.0 ?
gmsoft: both of db-4.0 and db-4.1 need to be marked stable ultimately. Some packages have hard dependancies on specific versions, so that's why we need both of them.
nope, i have no problems with db-4.1 ... i just choose 4.0.14-r2 because that is what this bug was requesting :) so i guess we're good with both on hppa then eh ?
vapier: yup, just mark as stable and move along :-). ppc people: double checking your stuff you have only marked db-4.1 as stable, and missed db-4.0. please test and mark it as stable as well or leave me a note and I will. once both ppc and hppa are done on this, then we can finally close this bug.
I just marked both db-4.0 and 4.1 stable on hppa.
Is there any reason that there is no stable db-4.0 on ppc? Else please mark a version stable and close the bug. (Arm is not really being supported currently)
oops, looks like i forgot to close this one
