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.pur...@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 > > >
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
