<div dir="ltr">Even with that patch to rename openssl10 back to openssl we still need to solve the openssl-native which wasn't reverted back to 1.0.<div><br></div><div>Upstream nodejs isn't going to be openssl-1.1 for a bit longer as explained:</div><div><a href="https://github.com/nodejs/node/pull/14761">https://github.com/nodejs/node/pull/14761</a><br></div><div><a href="https://github.com/nodejs/node/pull/11828">https://github.com/nodejs/node/pull/11828</a><br></div><div>so it would make sense to revert native and nativesdk versions as well - if it isn't done in oe-core, I'll do it in our own layers to keep the builds going.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 18, 2017 at 4:41 PM, Khem Raj <span dir="ltr"><<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Aug 18, 2017 at 3:53 AM, Alexander Kanavin<br>
<<a href="mailto:alexander.kanavin@linux.intel.com">alexander.kanavin@linux.<wbr>intel.com</a>> wrote:<br>
> On 08/18/2017 08:56 AM, Khem Raj wrote:<br>
><br>
>> I was trying nodejs and it seems its also broken by this openssl<br>
>> upgrade. Meta-oe alone has amost 50 recipes that are broken. there are<br>
>> hundreds of other layers.<br>
>> Many large packages in external layers are now broken, and the fact<br>
>> that openssl10<br>
>> is almost useless since some package will pull in openssl11 and cause<br>
>> conflicts. This<br>
>> is not a a good solution at least it seems to early for release. It<br>
>> might take a bit for packages to get working with openssl11, We should<br>
>> have carefully thought and considered postponing using it as default<br>
>> until next release ( april 2018). Its fine to keep it in if needed but<br>
>> keep openssl 1.0 as default preferred version, I don't think whole<br>
>> ecosystem is ready for it and we don't have man power to fix<br>
>> everything. This alone has a potential to make<br>
>> October release quite weak as far as external layers are concerned<br>
><br>
><br>
> FWIW, nodejs from meta-oe does build just fine with openssl10 dependency.<br>
<br>
</span>no it doesnt try building nodejs-native.<br>
<span class=""><br>
So<br>
> it's not exactly useless. And no one has established how many of the other<br>
> 50 packages can be fixed by either doing that, or updating them to latest<br>
> upstream releases.<br>
<br>
</span>Thats not going to solve everything. Neither does pointing to fedora patches.<br>
<span class=""><br>
><br>
> I'll send a patch that renames openssl10 recipe back to openssl and sets<br>
> that as a preferred version, so anyone can experiment with 1.1 without<br>
> widespread breakage.<br>
><br>
> But at the start of next development cycle this will be reverted back; no<br>
> more complaining then please, we have to do this at some point, and just<br>
> after a new cycle has started is as good time as it gets.<br>
<br>
</span>Just putting random deadlines is not going to solve this, there has to<br>
be some look<br>
at upstream packages and other distros switching to openssl11 and<br>
dropping openssl10<br>
completely. People have fielded products to support and they need some<br>
assurance of<br>
forward path, their ecosystem might involve a lot larger package set<br>
then just oe-core.<br>
<div class="HOEnZb"><div class="h5">--<br>
______________________________<wbr>_________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org">Openembedded-core@lists.<wbr>openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/<wbr>mailman/listinfo/openembedded-<wbr>core</a><br>
</div></div></blockquote></div><br></div>