[OE-core] openssl10 unusable for many components

[Martin Jansa]

The qtbase was just an example, the link with the last report:
http://lists.openembedded.org/pipermail/openembedded-core/2017-August/140829.html

shows that instead of 5 failures reported in previous one:
http://lists.openembedded.org/pipermail/openembedded-devel/2017-August/114108.html

we have around 40 failures (numbers differs for different MACHINEs) and
that's probably far from complete list of failing recipes, because many
recipes weren't built at all, because one of their dependencies failed
already.

I meant "real-world" as builds for any products on the market (which are
likely using one of the failing recipes) - e.g. in LGE we have many more
failures over all internal components, so I'll just undo this openssl
switch (renaming openssl_1.1 as openssl11 and openssl11_1.0 back as
openssl_1.0 with PROVIDES openssl11). We won't be able to use openssl-1.1
for long time anyway, because there are some 3rd party component which are
difficult (or expensive) to get rebuilt against new openssl ABI, but we
might be interested in some other improvements in oe-core/master.

I'm not saying that oe-core should be blocked until the oldest and slowly
moving project is updated to be compatible with it, just keep in mind that
"real-world" products are far more complicated than keeping oe-core
autobuilder green and that some companies might see it as blocker for
upgrading to newer oe-core.

Regards,

On Thu, Aug 17, 2017 at 1:33 PM, Richard Purdie <
richard.purdie at linuxfoundation.org> wrote:

> On Thu, 2017-08-17 at 12:31 +0200, Martin Jansa wrote:
> > Does openssl10 work for anyone in real-world scenarios?
>
> Depends what "real-world" means really.
>
> I've strongly pushed for OE-Core to have at least some spectrum of
> coverage of various elements of the software stacks people use so we
> can use it as an indicator of changes readiness to be merged. This goes
> against those who want it stripped to the bare bones.
>
> There was a strong desire to keep qt5 out of OE-Core and I've gone
> along with that, this is one of the downsides, it doesn't get testing
> when changes like this get integrated. We did test openssl 1.1 as far
> as we reasonably could before it merged and it was posted on the list
> for quite a while and discussed.
>
> There is a problem here and I don't know how we solve it to be honest
> (other than the obvious upgrading of problematic recipes).
>
> I can imagine some fancy sstate code in the openssl recipes where they
> could prune their populate_sysroot data depending on the dependency
> chains being installed. Equally, that code would be hard to right and
> would only stop another subset of issues, not solve the problem. For
> example, if python3 references the openssl headers, there could be
> ABI/API issues if QT uses python3 openssl functions, depending on how
> the headers are structured.
>
> So I'm not sure how we move forward here, one plus point is that there
> are 1.1 patches for qt5 which is something at least.
>
> People could suggest more testing. The reason patches merge slowly in
> OE-Core is the infrastructure struggles with the current range of
> testing. I've actually "destroyed" one of the autobuilder clusters this
> week and we're running on degraded infrastructure right now until we
> fix the overloading problem I caused there :(.
>
> Cheers,
>
> Richard
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170817/4a748e20/attachment-0002.html>