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.
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 ?
Cheers,
Richard
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
