<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 5 February 2016 at 22:55, Nicolas Dechesne <span dir="ltr"><<a href="mailto:nicolas.dechesne@linaro.org" target="_blank">nicolas.dechesne@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Fri, Feb 5, 2016 at 9:46 PM, Burton, Ross <<a href="mailto:ross.burton@intel.com">ross.burton@intel.com</a>> wrote:<br>
> On 5 February 2016 at 20:44, Khem Raj <<a href="mailto:raj.khem@gmail.com">raj.khem@gmail.com</a>> wrote:<br>
>><br>
>> its added new to this version. May be packageconfig is better place<br>
>> for --with-sha1 stuff<br>
><br>
><br>
> Agreed - some may not want openssl at all and being able to switch it for<br>
> another alternative would be useful.<br>
<br>
</span>sure. but, then I have some questions..<br>
<br>
1. which one we default to? openssl?<br>
<br>
2. which one we support, from <a href="http://configure.ac" rel="noreferrer" target="_blank">configure.ac</a>:<br>
<br>
[choose SHA1 implementation])])<br>
case "x$with_sha1" in<br>
x | xlibc | xlibmd | xlibnettle | xlibgcrypt | xlibcrypto | xlibsha1 |<br>
xCommonCrypto | xCryptoAPI)<br>
;;<br></blockquote><div><br></div><div>Thanks for looking at this -- I was updating mesa last week as well and fell into the same maze of crypto choices, all alike. Currently OE-Core is pretty unorganized here: It's easy to end up with three big libraries just for calculating SHA1 hashes. </div><div><br></div><div>If you do this patch for mesa, I'll follow up with one for xorg: we should at least default to the same choice. Currently Xorg uses libcrypto for SHA1, I think that's reasonable for mesa as well? As Andre said, the maintained version of Nettle has the problem of being "LGPL3|GPLv2".</div><div><br></div><div>In addition there's quite a few unneeded crypto dependencies that I intend to remove: It's possible that with some smart choices we may be able to drop some libraries from the core images (see <a href="http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=jku/mesa-update">http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=jku/mesa-update</a> for a start).<br></div><div><br></div><div>If you don't have time to do the mesa-packageconfig patch, let me know and I'll do it. </div><div><br></div><div>Jussi </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
3. is there a good way to handle 'multiple choice' with PACKAGECONFIG?<br>
How can we prevent more than 1 PACKAGECONFIG to be set (nicely)?<br>
<div class=""><div class="h5">--<br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</div></div></blockquote></div><br></div></div>