5240 2013-09-19 21:02:05 +0000 do_rootfs fails for libcrypto due to stale cache from version change of openssl recipe 2013-09-25 14:32:44 +0000 1 1 7 Build System, Metadata & Runtime OE-Core connectivity 1.4 x86 Multiple RESOLVED INVALID Low minor 1.5.1 1 rcalhoun-bugzilla cristian.iorga meta.mr.watcher meta.watcher richard.purdie sgw --- --- No (bug/feature does not impact docs) oldest_to_newest 37005 0 rcalhoun-bugzilla 2013-09-19 21:02:05 +0000 Starting with poky "dylan", build image containing openvpn (custom autotools recipe), which has opensll as a DEPENDS. Upgrade to poky branch 1.4_M5 via git and rebuild. Build of image fails, relevant line being: Computing transaction...error: Can't install libssl1.0.0-1.0.0j-r15.4@armv7a_vfp_neon: no package provides libcrypto1.0.0 >= 1.0.1e Fix is "bitbake -c cleanall openssl" followed by re-baking the image. Core issue appears to be that openssl rev moved backwards in 1.4_M5, with branch 1.4_M5 containing a recipe for openssl_1.0.0j.bb while dylan release had openssl_1.0.1e.bb, resulting in an invalid cache. http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/meta/recipes-connectivity/openssl?h=1.4_M5 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-connectivity/openssl?h=dylan It looks like the commits since 4fb837687dd68363f25fbfc15207dd05d1369661 had some issues so dropping back to 1.0.0j might have been intentional. Bitbake should invalidate the cache when this happens. Baring making a change there, a comment to the release notes re: the need for a clean build of openssl would be nice. 37169 1 richard.purdie 2013-09-25 09:36:26 +0000 I don't think anything went backwards. 1.0.1 (e) > 1.0.0 (j) so the dylan release had a later version than the 1.4M5 milestone release. Regardless, it shouldn't have failed like that but it wasn't due to a version going backwards... 37204 2 rcalhoun-bugzilla 2013-09-25 14:32:44 +0000 Re: moving backwards you are correct. I had mixed up the Poky 1.4_M5 *branch* with the Poky 1.5_M4 *tag* on branch dylan. (I'm a long-time svn user but new to git.) I'm going to mark this as invalid, there being no point to ticketing against the 1.4_M5 branch.