Re: [OE-core] [PATCH] python3-cryptography: workaround broken native functionality

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2022-09-13 at 14:13 +0300, Mikko Rapeli wrote:
> On Tue, 13 Sept 2022 at 13:34, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > Are you using uninative? I'd have expected glibc and pthreads to come
> > from there rather than the host.
> 
> Yes, using uninative, not host libc, sorry. Added full list of
> openat()'d files to the end of this email, from master branch with
> this patch applied.
> Delta to without this patch is just a few python modules. I can't see
> anything wrong in that list.

It looks correct to me too.

It is weird it is ubuntu 18.04 as we had a lot of problems with the
rust SDK work specifically on that platform. The problem there was rust
running things with LD_LIBRARY_PATH set which meant host tools tried to
use the SDK sysroot libs which then broke in interesting ways. It was
specific to the form of the version mismatch on 18.04.

I have no idea if there is a connection, your strace output certainly
suggests not.
> 
> > > And then in bitbake -c devshell busybox:
> > > 
> > > # python3 -c  "from OpenSSL import crypto"
> > > 
> > > I guess there is no way to add a test like that for python3-cryptography-native?
> > 
> > You could probably put that in do_configure to test it?
> 
> Yes, on my layer and recipes I can do this. But I'd rather upstream
> the test to python3-cryprography-native or somewhere else but I guess
> native recipes don't have selftests or similar.

I was wondering about putting something into upstream recipe...

We do somehow need to get more information about what is breaking here
:/.

Cheers,

Richard