From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Martin Jansa <martin.jansa@gmail.com>,
Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: openssl10 unusable for many components
Date: Thu, 17 Aug 2017 12:33:58 +0100 [thread overview]
Message-ID: <1502969638.13978.209.camel@linuxfoundation.org> (raw)
In-Reply-To: <CA+chaQc_oKOja+s54Ku-sCQqxdrqi8d16Dkj2=dJHofYnOR1xA@mail.gmail.com>
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 prev parent reply other threads:[~2017-08-17 11:33 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-17 10:31 openssl10 unusable for many components Martin Jansa
2017-08-17 11:23 ` Alexander Kanavin
2017-08-17 11:33 ` Richard Purdie [this message]
2017-08-17 11:46 ` Martin Jansa
2017-08-17 11:54 ` Alexander Kanavin
2017-08-18 5:56 ` Khem Raj
2017-08-18 10:53 ` Alexander Kanavin
2017-08-18 14:41 ` Khem Raj
2017-08-18 17:29 ` Martin Jansa
2017-08-18 17:56 ` Mark Hatle
2017-08-18 18:41 ` Alexander Kanavin
2017-08-18 18:55 ` Martin Jansa
2017-08-18 19:03 ` Mark Hatle
2017-08-18 18:19 ` Alexander Kanavin
2017-08-21 9:29 ` Richard Purdie
2017-08-21 9:59 ` Martin Jansa
2017-08-18 18:15 ` Alexander Kanavin
2017-08-18 17:41 ` Martin Jansa
2017-08-18 18:30 ` Alexander Kanavin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1502969638.13978.209.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=martin.jansa@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox