01:23 <tonyj> @purple  there are no processes at all.  ps -ef or  ps awuux,  nothing

01:24 <tonyj> just the python running the bitbake instance

09:37 <RP> tonyj: I don't know then. I'd have expected to see something in one of the logs I'd mentioned :/

09:37 <RP> smurray: thanks, seems to be resolved now

09:47 <Nathan52> Hi everyone! I'm having an issue running podman within the devshell, I've thrown in PSEUDO_DISABLED=1 and PSEUDO_UNLOAD=1 just for good measure but the UID of the devshell is still set as "0" so podman seems to be running as root and failing spectacularly! Is there a way to tell the devshell to run under the environment of the actual user running

09:47 <Nathan52> bitbake? Seemed to work on Poky 23 but not as successful on 26 :(

09:55 <RP> Nathan52: fakeroot is set for do_devshell in base.bbclass. You could try some anonymous python to delete that flag?

09:59 <Nathan52> Oh looking at base.bbclass I could just move my logic outside of do_install as well, might be something to try. I've been developing in the `bitbake -c devshell` environment, but I can develop outside of that if it solves the issue 🤞

10:00 <Nathan52> Much appreciated - the codebase is a bit daunting at times to look through for new eyes :D

10:50 <Nathan52> Okay, I've got the right UID but the devshell seems to be clearing the Linux Capabilities and fiddling around with another few things that is causing podman to error out with a "cannot setresgid: Invalid argument" error, makes me think it's still trying to run as root. Potentially something that podman needs to fix instead. Thanks for the help!

11:30 <kanavin> RP: other than the continuing virgl fails, master-next looks pretty good; I'm working to fix those properly

11:30 <kanavin> RP: LD_PRELOAD interferes with host bash, which is used to run a wrapper to set up gtk frontend properly

12:20 <RP> kanavin: thanks, I'll drop the virtgl patches for now until we work out the right fix

12:22 <kanavin> RP: I'm close to it, won't take long :)

12:26 <kanavin> RP: should be something like this - I'm going to run a-full with the whole patchset of mine https://git.yoctoproject.org/poky-contrib/commit/?h=akanavin/package-version-updates&id=880ba2234d2e9dd374bad031ec22933def7a90a0

16:02 <RP> kanavin: if we're sure we don't need those other variables...

17:13 <kanavin> RP: I checked locally, we don't. gdkpixbuf has the most important loaders built into the library itself nowadays, and adwaita seems also used by default.

17:14 <kanavin> RP: I'm also going to test this https://git.yoctoproject.org/poky-contrib/commit/?h=akanavin/package-version-updates

17:14 <kanavin> happened twice in my a-full selftests

17:19 <RP> kanavin: there is a known issue with our public sstate mirror not handling requests fast enough

17:19 <RP> although a better error would be nice

17:20 <kanavin> RP: yes but there's a timeout in there somewhere that's too strict, and would be good to know where it is, and if we can bump it up

17:20 <kanavin> in python's client code

17:20 <RP> kanavin: I think it is probably our server :(

18:38 <kanavin> RP: seems like AVX is (mostly) a 256 bit extension of SSE (which is 128 bit), with a few new instructions thrown in. It's not a 'major new thing'.

18:38 <kanavin> So I'm cautiously hopeful it can be supported in qemu with careful extensions of existing sse code

20:15 <RP> kanavin: that would make sense to me

22:12 <RP> kanavin: what was the reproducibility failure in your branch? :/

22:13 <kanavin> RP: git and git-dbg, trying to figure it out

22:13 <RP> kanavin: I pinched a couple of your patches for my test run ;-)

22:13 <RP> kanavin: ok, cool

22:13 <kanavin> RP: if you fancy an evening with objdump https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20220206-mvvpep0g/packages/

22:14 <kanavin> diffoscope choked on t

22:14 <kanavin> on it

22:16 <RP> kanavin: upstream diffoscope would likely take a bug report, they find these test cases useful

22:18 <RP> kanavin: even with the single git binary pulled out, it doesn;t like it does it :/

22:20 <kanavin> RP: oh:

22:20 <kanavin> - <0><549>: Abbrev Number: 42 (DW_TAG_compile_unit)

22:20 <kanavin> - <54a> DW_AT_producer : (indirect string, offset: 0x56a): GNU C17 11.2.0 -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse -g -O2 -O2 -fstack-protector-strong -feliminate-unused-debug-types

22:20 <kanavin> - <54e> DW_AT_language : 29 (C11)

22:20 <kanavin> + <0><549>: Abbrev Number: 41 (DW_TAG_compile_unit)

22:20 <kanavin> + <54a> DW_AT_producer : (indirect string, offset: 0x469): GNU C99 11.2.0 -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse -g -O2 -O2 -std=c99 -fstack-protector-strong -feliminate-unused-debug-types

22:20 <kanavin> + <54e> DW_AT_language : 12 (ANSI C99)

22:20 <RP> kanavin: I was going to say, first difference is the dynamic symbol table is longer

22:21 <RP> kanavin: that looks like a promising lead

22:23 <RP> kanavin: I'll leave that with you :)

22:26 <kanavin> RP: https://github.com/git/git/commit/ffb9f2980902d23a5640435306031bc298eb4e02

22:27 <kanavin> how many grey hairs centos7 is going to give us before we can dump it :-/

22:31 <RP> kanavin: doing that in configure is horrible, but yes, centos7 won't be around for much longer. Or stream the way I'm feeling about that

22:31 <RP> kanavin: I had a feeling we'd find something horrible like that :(

22:31 <kanavin> RP: it's because they don't use autotools properly either

22:32 <kanavin> RP: I'm tempted to patch it out and mark as Inappropriate

22:36 <kanavin> RP: I'll leave it for tomorrow, I'd file a bug too

22:41 <RP> kanavin: perhaps suggest they make it cross compile conditional? Patching it out is the easiest solution for us for now

22:41 <RP> good plan re: tomorrow