On 5/2/20 4:35 AM, Alexander Kanavin wrote: Can you clarify what you mean by silently disappear. By the time I have time to process an update, someone else has sent the patches.

Hello all, the current maintenance model in openembedded-core is problematic due to lack of well-working process of finding maintainers, and replacing them when they're no longer able to contribute.

Hi all, I still had a couple of ¢ to give so here they are. I summoned the Google god and I found this stackoverflow on how to execute multiple lines instead of the one eval is

Hi all, Giving my 2¢. Indeed, and the thing is... it does not fix the original issue, so third party layers not doing that will still have the same bug which is hard to detect. Since we can't

lists.openembedded.org wrote: The project historically supports setting "libdir" and "base_libdir" to whatever the user sets it to. This includes the paths to the dynamic loaders. In the past, if

I've noticed that patch http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/gcc/gcc-9.3/0011-Define-GLIBC_DYNAMIC_LINKER-and-UCLIBC_DYNAMIC_LINKE.patch?h=dunfell applied to gcc

I've recently found that OE-core with usrmerge distro feature enabled prepares image with ELF files where default linker path changed (i.e. /usr/lib/ld-linux-x86-64.so.2). According to glibc ABIList

On 4/22/20 5:11 AM, Richard Purdie wrote: I was trying to avoid anything too complex to parse.... but I wonder if we can enlist the help of the python interpreter. If we have an

Not that I see at the moment. Only for native/nativesdk/multiconfig (anything using the class extension code). Cheers, Richard

Out of curiosity, do you anticipate that this will be used for any part of the implementation of multiconfig as well? Chris

I think that is a sensible idea. The good news is we know roughly what the current needs look like, the code is in lib/oe/classextend.py: def extend_name(self, name): if

Right, mixing them definitely gives the worst possible behaviours. Sadly we have recipes doing this today, with unpredictable side effects. We have always said we don't support this but it does

"Philip Balister" <philip@...> wrote: Sounds like an excellent idea, thanks for organising this! I'll see you all there. -- Paul Barker Konsulko Group

"Richard Purdie" <richard.purdie@...> wrote: At first glance this appears to be a mismatch between PACKAGES and the override used on LICENSE. It should either be: PACKAGES +=

<richard.purdie@...> wrote: Continuing the discussion from the OE TSC meeting, now that I've had a little time to digest the idea: I don't think the filter functions are necessarily a

We (the OpenEmbedded board, with help from Automotive Grade Linux who are providing the meeting "space") would like to invite you a a virtual happy hour on April 29 at Noon EDT, 6PM CET (Is that the

I'm a bit worried about some of the mulitlib issues we've seen recently. In particular we have a bug where license exclusion doesn't work properly in multilib builds, which is fairly serious. To dive

There was one e-mail today, but it doesn't seem to be working correctly: https://lists.openembedded.org/g/openembedded-commits/message/186006 Cheers,

Hi, thanks Michael! Can you please check if git hooks sending e-mail notifications still work or need some change (possibly related to this)? There were new commits recently in couple repositories,

Superb job Michael