Hi All, I'm sending this to oe-arch as it seems the best place to mention/discuss it. After reading an email about encouraging best practises when supporting older software releases, it got me thinkin

I suspect not since it is a significant change in behaviour which we're not seeing a pressing need for from kirkstone users? Cheers, Richard

Hi All, There has been some interest in some older bugs about empty packages and bogus dependencies and what we should do about them. Yohan and Fawzi were kind enough to post some patches to prompt so

FWIW unpack is controlled by the directory passed into the fetcher by the do_unpack task. Patch isn't configurable today, making it configurable would probably cause the most problems. This is configu

Dropping S = "${WORKDIR}" doesn't solve the problem being described here, it just removes something which complicates current code and makes that problem harder to solve. Even not supporting S = "${WO

I was asked about a WORKDIR/fetcher interaction problem and the bugs it results in. I've tried to write down my thoughts. The unpack task writes it's output to WORKDIR as base.bbclass says: fetcher =

That is really interesting data as it confirmed there are real world issues which changing the compiler flags is going to break. Thanks for sharing. What you describe is relatively easy for a maintain

That does sound useful, perhaps sharing it as an RFC patch might be a good place to start? We might be able to run one of the autobuilder world targets against it, see how it looks for our core recipe

I think we should fix those and we should add the target to the autobuilder but I'm reluctant to add a long test to a-full. The fact it is relatively clean suggests it doesn't regress that often. We c

That sounds interesting and something we should probably look into for both issues... That would cause runtime issues but not build time linking ones? Cheers, Richard

Perhaps, yes. I'm meaning disabling the 32 bit glibc time functions. Right, but the 32 bit time functions/symbols are still available for older binaries. My point is that anything using those older fu

Others have made some good comments. My thoughts: * We need to add some runtime tests to oeqa for this (in addition to the ptests) * We need to have a 32 bit ptest run on the autobuilder (qemux86 shou

For x86, yes. For arm, it varies and I know at least one of our arm hosts doesn't support it, I don't know about the newer ones. In general I think it shouldn't be too bad but we really do need to tes

lists.openembedded.org wrote: What is the potential issue with builtools? To be clear, we don't run ptests on 32 bit targets, only on qemux86-64 and qemuarm64 where we have KVM available. We do run im

Hi, I've a few things I've been pondering for a while and given the summit and OEDVM this week, I thought I'd sent out this email and some RFC patches. Export variable flag (and unexport/network) ----

That makes sense, I know we'd need to be careful about setuid (see my other email). If I can find a few minutes I guess I'll experiment a bit and see if I can come up with a patch to test the water wi

Yes, indeed. I also did notice: https://engineering.backtrace.io/2016-06-29-exploiting-elf-expansion-variables/ which mentions Solaris does support $ORIGIN in PT_INTERP and that if you're not careful

I thought I'd quickly write down some notes on the relocatable binary "problem" we have. We have a need to be able to run our binaries with a different dynamic loader in a few cases which basically co

Ultimately, I think we'll end up removing this file. Whilst I understand we might want to track where things came from, I think the current way breaks for two files and doesn't give version informatio

I wondered about that. The thing is if you're planning to decide to do some kind of automated update or user warning message, you need a version string in the file itself to know what version you're d