On Mon, 2020-03-02 at 13:33 -0800, Khem Raj wrote: > > On 3/2/20 1:08 PM, Richard Purdie wrote: > > On Mon, 2020-03-02 at 10:49 -0800, Khem Raj wrote: > > > On 3/1/20 9:05 AM, Richard Purdie wrote: > > > > On Sun, 2020-03-01 at 08:20 +0000, Richard Purdie wrote: > > > > > On Sun, 2020-03-01 at 00:17 -0800, Khem Raj wrote: > > > > > I understand the need for the fixes, I'm just very concerned > > > > > we > > > > > have > > > > > what amounts to undetected non-determinism in the build :( > > > > > > > > > > I'm more concerned about fixing that (and ensuring we can > > > > > detect/fix > > > > > all cases) than I am about the individual errors. > > > > > > > > I did a bit more thinking/checking on this. > > > > > > > > An interesting command to experiment with is: > > > > > > > > $ touch /tmp/test; ls -la /tmp/test; ./tmp/sysroots- > > > > components/x86_64/pseudo-native/usr/bin/pseudo sh -c "ls -la > > > > /tmp/test*; cp /tmp/test /tmp/test2; ls -la /tmp/test*; rm > > > > /tmp/test*" > > > > > > > > which for me shows: > > > > > > > > -rw-rw-r-- 1 richard richard 0 Mar 1 17:03 /tmp/test > > > > Warning: PSEUDO_PREFIX unset, defaulting to XXX./tmp/sysroots- > > > > components/x86_64/pseudo-native/usr. > > > > -rw-rw-r-- 1 1000 1000 0 Mar 1 17:03 /tmp/test > > > > -rw-rw-r-- 1 1000 1000 0 Mar 1 17:03 /tmp/test > > > > -rw-rw-r-- 1 0 0 0 Mar 1 17:03 /tmp/test2 > > > > > > > > Can you see if that is different on your two machines? > > > > > > above cmd output is exactly same as yours. > > > > > > -rw-r--r-- 1 build build 0 Mar 2 18:49 /tmp/test > > > Warning: PSEUDO_PREFIX unset, defaulting to > > > /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo- > > > native/usr. > > > -rw-r--r-- 1 1000 1000 0 Mar 2 18:49 /tmp/test > > > -rw-r--r-- 1 1000 1000 0 Mar 2 18:49 /tmp/test > > > -rw-r--r-- 1 0 0 0 Mar 2 18:49 /tmp/test2 > > > > Hmm, this means the test is flawed as we need to find out how > > /tmp/test2 becomes owned by 1000.1000. > > > > Any ideas how we can simplify this down to reproduce that? > > > > Even on baremetal ubuntu 18.04 I am seeing > > dlm-4.0.9: dlm: /usr/lib/libdlmcontrol.so is owned by uid 3004, which is > the same as the user running bitbake. This may be due to host contamination > dlm: /usr/lib/libdlm_lt.so is owned by uid 3004, which is the same as > the user running bitbake. This may be due to host contamination > dlm: /usr/lib/libdlm.so is owned by uid 3004, which is the same as the > user running bitbake. This may be due to host contamination > [host-user-contaminated] > dlm-4.0.9: dlm: /usr/lib/libdlmcontrol.so.3 is owned by uid 3004, which > is the same as the user running bitbake. This may be due to host > contamination > dlm: /usr/lib/libdlm_lt.so.3 is owned by uid 3004, which is the same as > the user running bitbake. This may be due to host contamination > dlm: /usr/lib/libdlm.so.3 is owned by uid 3004, which is the same as the > user running bitbake. This may be due to host contamination > [host-user-contaminated] > > this might be again a dlm issue to fix. but perhaps a good one to > try if AB system can build it without these QA diagnostics. > > dlm is in meta-networking.
That could well be a dlm recipe bug. I'm more interested in the ones which reproducibly break on one machine but work on another. > > I did wonder if its coreutils-native was somehow creeping into > > DEPENDS > > and had a different config between your two hosts which was causing > > different behaviour but I'd need to check into whether that > > happens. > > > > Any other ideas why the behaviour difference or how to reproduce > > it? > > > > can you promote host-user-contaminated form QA warning to QA error > in poky and see if builds fail ? As its already a warning, we'd see it on the autobuilder. *Any* warning turns the build orange rather than green. We don't any warnings in core builds, we fixed them all. This is why I know its not happening on the autobuilder... Cheers, Richard -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
