I have just updated old emul set, it works ok with the old way (only precompiled stuff), but it will probably need some updated for people running the mix between them and native multilib (probably some list needs to be updated). Also, as they are based in last revision, they pull in hardmasked cairo (well, maybe it could simply be unmasked). By the way, maybe you could consider dropping some old revisions, I only touched the old versions, not the revisions as I guess they were available for some reason Thanks
Bad timing, baselibs still ships dev-libs/openssl-1.0.1f which is affected by bug 507074 (TLS heartbleed bug). Presumably, this should be fixed before unmasking.
I don't intend to actually try these (http://forums.gentoo.org/viewtopic-p-7509542.html?sid=c5b44664c998872c1c014477e22c3048#7509542 is adequate for my needs), but based on my research, I might have some useful suggestions for anyone interested: As Pacho suggests, it would probably work to leave AMD_X86=-32 disabled in most packages (except for applications like wine), and unmask and use the 2014 packages in /etc/portage/package.unmask and /etc/portage/package.keywords both. ---- But getting 2014 packages working with AMD_X86=32 requires some more work. Background: The main reason there are so many 2013 revisions is that each successive -r revision corresponds to installing fewer files from emul-linux in favor of getting them from the (newly implemented) native-multilib version of the corresponding native package. Since there are so many different packages involved, and they each have their own schedule of going from in-tree-but-masked to ~amd64 to actually stable, there are a lot of -r versions of emul-linux to correspond to the various in-use combinations. Suggested sequence of events: 1. Fix openssl problem. 2. Make a series of 2014 -r packages that EXACTLY MIRROR the 2013 -r packages, with corresponding file removal lists, etc. This means skipping some -r numbers, but the benefits of keeping things easy to map are probably worth it. 3. Change the 2013 hard masks in /usr/portage/profile/package.mask to the corresponding 2014 packages instead. (Gotcha: Not sure if maybe some individual package version dependencies need to be updated in some .ebuild files as well.) 4. Once that is working well, stabilize the appropriate 2014 -r version. This will finally get stable working again after months of issues... 5. Retire the 2013 packages, and continue on with the 2014 packages as previously planned with the 2013 packages.
(In reply to Ulrich Müller from comment #1) > Bad timing, baselibs still ships dev-libs/openssl-1.0.1f which is affected > by bug 507074 (TLS heartbleed bug). Presumably, this should be fixed before > unmasking. Will try to update for that... but all this security issues are affecting emul sets for years :/ (we would need to bump them each week to inherit security stabilizations from x86 fast enough)
+*emul-linux-x86-baselibs-20140406-r1 (12 Apr 2014) + + 12 Apr 2014; Pacho Ramos <pacho@gentoo.org> + +emul-linux-x86-baselibs-20140406-r1.ebuild, +files/remove-native-20140406: + Update to newer openssl due security bug +
(In reply to Pacho Ramos from comment #4) > +*emul-linux-x86-baselibs-20140406-r1 (12 Apr 2014) > + > + 12 Apr 2014; Pacho Ramos <pacho@gentoo.org> > + +emul-linux-x86-baselibs-20140406-r1.ebuild, > +files/remove-native-20140406: > + Update to newer openssl due security bug > + files/remove-native-20140406-r1 missing: --- ./remove-native-20140406 2014-04-12 12:35:17.000000000 +0400 +++ ./remove-native-20140406-r1 2014-04-12 15:49:34.152400296 +0400 @@ -43,6 +43,8 @@ usr/lib32/librom1394.so.0.3.0 usr/lib32/libjpeg.so usr/lib32/libturbojpeg.so +usr/lib32/libturbojpeg.so.0 +usr/lib32/libturbojpeg.so.0.0.0 usr/lib32/libjpeg.so.62 usr/lib32/libexpat.so usr/lib32/libexpat.so.1
+ 12 Apr 2014; Pacho Ramos <pacho@gentoo.org> +files/remove-native-20140406-r1: + Update remove-native file (#506900#c5 by nE0sIghT) + Any more pending?
