On Feb 14, 2011, at 11:46 AM, Silvan Calarco wrote: >> On Thursday 03 February 2011 15:18:02 Jeff Johnson wrote: >>> The procedure isn't hard, its essentially this 1 command (snipped from >>> tests/Makefile.am) ... >>> >>> @__DB_DUMP@ olddb/Packages \ >>> >>> | sed \ >>> | >>> -e 's/^type=hash$$/type=btree/' \ >>> -e '/^h_nelem=/d' \ >>> -e 's/^ \(..\)\(..\)\(..\)\(..\)$$/ \4\3\2\1/' \ >>> >>> | @__DB_LOAD@ newdb/Packages; \ >>> >>> [...] >>> >>> That process (with hardening) is being accomplished in Mandriva and IDMS >>> by adding to rpm.spec >>> >>> %posttrans >>> /usr/lib/rpm/dbconvert.sh >> >> The procedure is clear, thanks, I'll try this when it's time for another >> rpm upgrade (i.e. when other current higher priority distribution tasks >> are completed). > > On a couple of arm devices with kernel 2.6.28 and 2.6.29 I noticed that there > is maybe a kernel bug which causes rpm 5.2.1 to fail with a kernel oops. The > problem was in beecrypt 4.1.2 and though I was able to fix similar problems > with other libraries, I didn't succeed with beecrypt. So I tested beecrypt > 4.2.1 and it works in this environment so now I need to move necessarily to > rpm 5.3.8 because 5.2.1 is not compatible with beecrypt 4.2.1. >
A kernel OOPS, eh? If you can narrow down what routine in BeeCrypt is causing the kernel OOPS, I can likely figure a work-around. Is it digests? Signatures? What is causing the OOPS? Good to hear that 4.2.1 has the fix. You will almost certainly need to use the latest 4.2.1 version of BeeCrypt because I have handed off the ripemd digests to BeeCrypt and removed from RPM (like 4 years after implementing). SO now there's a RPM build failure unless beecrypt-4.2.1 is used. <snip> I think these issues were answered already. 73 de Jeff
smime.p7s
Description: S/MIME cryptographic signature
