Bug 8282

This isn't an autobuilder issue per se:

On the autobuilder:

-rw-r--r--. 1 pokybuild users 2902224896 Sep 10 08:04 core-image-sato-sdk-genericx86-64-20150910063721.rootfs.ext4
-rw-r--r--. 1 pokybuild users        402 Sep 10 10:32 core-image-sato-sdk-genericx86-64-20150910063721.rootfs.ext4.md5sum
-rw-r--r--. 1 pokybuild users        208 Sep 10 10:32 core-image-sato-sdk-genericx86-64-20150910063721.rootfs.ext4.md5sum.md5sum
-rw-------. 1 pokybuild users     113352 Sep 10 08:01 core-image-sato-sdk-genericx86-64-20150910063721.rootfs.manifest
-rw-r--r--. 1 pokybuild users        410 Sep 10 10:32 core-image-sato-sdk-genericx86-64-20150910063721.rootfs.manifest.md5sum
-rw-r--r--. 1 pokybuild users        212 Sep 10 10:32 core-image-sato-sdk-genericx86-64-20150910063721.rootfs.manifest.md5sum.md5sum
-rw-r--r--. 1 pokybuild users  596979882 Sep 10 08:04 core-image-sato-sdk-genericx86-64-20150910063721.rootfs.tar.gz


You'll notice that in tmp/deploy/images/genericx86-64 the permissions for the manifest are incorrect.

Still looking at it.

This is most certainly not an Autobuilder issue as I'm seeing it outside the autobuilder as well. 

My guess is that something is adding the wrong umask and contaminating write_image_manifest with it. It seems to be a bit random and not associated to any worker per se. As far as I can tell, we don't seem to see this until around September 2nd (but older builds are gone now, so there is no way to tell).

Of the autobuilder builds we have with the correct permissions:

Sep  1 17:25 ./20150901-2
Sep  4 07:13 ./20150903-3
Sep  5 02:42 ./20150904-3
Sep  2 14:56 ./20150901-4
Aug 31 17:57 ./20150831-1

With the incorrect permissions, we have:

Sep  5 17:54 ./20150905-1
Sep  6 19:10 ./20150906-1
Sep  9 09:28 ./20150908-1
Sep  3 17:23 ./20150902-1
Sep  6 00:39 ./20150905-1

What this looks like is:

-rw-r--r--. 1 pokybuild users 702 Sep  1 01:09 ./20150831-1/machines/genericx86-64/core-image-minimal-genericx86-64-20150831174419.rootfs.manifest 84ab1f0ecb8b02c162fee7bcd594722fb583086e
-rw-r--r--. 1 pokybuild users 702 Sep  1 10:10 ./20150901-1/machines/genericx86-64/core-image-minimal-genericx86-64-20150901090709.rootfs.manifest 22afc047dd1b8f83e56c4a9862710776c509e3c5
-rw-r--r--. 1 pokybuild users 702 Sep  1 14:00 ./20150901-2/machines/genericx86-64/core-image-minimal-genericx86-64-20150901123804.rootfs.manifest 71b0568fa43285f0946fae93fb43cea5f3bbecec
-rw-r--r--. 1 pokybuild users 702 Sep  2 06:27 ./20150901-4/machines/genericx86-64/core-image-minimal-genericx86-64-20150902023222.rootfs.manifest 565637ae3b2ed09c682454287d0cff1f7c6e4375
-rw-------. 1 pokybuild users 702 Sep  3 04:17 ./20150902-1/machines/genericx86-64/core-image-minimal-genericx86-64-20150903021949.rootfs.manifest c6850c03686092d43303013a85e5f2cb5f28c0f9
-rw-r--r--. 1 pokybuild users 702 Sep  4 03:16 ./20150903-3/machines/genericx86-64/core-image-minimal-genericx86-64-20150904020859.rootfs.manifest a035f7355134d593f117c3b5b409e1ea21f0ae12
-rw-r--r--. 1 pokybuild users 702 Sep  4 22:48 ./20150904-3/machines/genericx86-64/core-image-minimal-genericx86-64-20150904213359.rootfs.manifest 2b1bbeec7865fe40a752581b7a02397411d97a03
-rw-------. 1 pokybuild users 702 Sep  5 16:53 ./20150905-1/machines/genericx86-64/core-image-minimal-genericx86-64-20150905130320.rootfs.manifest 68e18e10aba819df576fcadfaa5c9e244d70d112
-rw-------. 1 pokybuild users 702 Sep  6 17:41 ./20150906-1/machines/genericx86-64/core-image-minimal-genericx86-64-20150906162346.rootfs.manifest dd7f820f5abe4992ad87a18bd3d252f7402bff3e
-rw-------. 1 pokybuild users 722 Sep 10 05:59 ./20150908-1/machines/genericx86-64/core-image-minimal-genericx86-64-20150910033020.rootfs.manifest e0d77f635bca5ce5686e4bc68086bd7abb634796
-rw-------. 1 pokybuild users 722 Sep 10 10:29 ./20150909-2/machines/genericx86-64/core-image-minimal-genericx86-64-20150910063721.rootfs.manifest 3363837b39366d21ac9cf3b16d10563a6edc19df

I'm going to chmod the manifest files for M3.rc1 just to unblock, however this seems to still be an issue.

I'd suspect the pseudo upgrade...

That does look suspiciously like it started around the time of the pseudo upgrade. I note that there was a bug/misfeature (around 1.7.1ish) that would have caused files to get 0600 modes when broader modes had been intended. Should be fixed in 1.7.3 and later? And the merge notification I got from RP was dated September 7th, if there's a bit of lag time,that could get us 0902 through 0908. Is it still happening? If not, it's the 0600 bug that was already fixed. (Commit 0b3080ba90d58249c853f1ddd1a24c54f383a31f in pseudo.)

Yes, this still seems to be happening. I was pinged this morning about it for the M3 release.

Sorry Peter but this is definitely related to pseudo.

With current master the deploy/images/MACHINE/*.manifest files are mode 0600, if I revert the pseudo 1.7.3 upgrade the files are mode 0644.

I added some debugging around the creation code (image.bbclass, write_image_manifest) and the files are created with the umask set to 022, with python passing 0777 as the mode.

I've got a fairly minimal test case:

$ bitbake m4 -c devshell (any recipe will do, just need to be in pseudo context)
$ python
>> open("foo", "w+").write("test")
[exit python]
$ ls foo
-rw-r--r-- 1 root root      12 Sep 22 15:22 foo
$ exit

[now back in the real world]
$ ls foo
-rw------- 1 ross ross      12 Sep 22 15:22 foo

The debug log with -x fo shows this series of operations:

fopen64 '/data/poky-master/tmp/sysroots/x86_64-linux/usr/bin/foo': fd 4 <FILE 0xb81010>
creat /data/poky-master/tmp/sysroots/x86_64-linux/usr/bin/foo (+buf) (0100644): fuid: 0
open /data/poky-master/tmp/sysroots/x86_64-linux/usr/bin/foo [fd 4] (+buf) [dev/ino: 2065/60716306] (0100644): (14685) (no request)
fstat /data/poky-master/tmp/sysroots/x86_64-linux/usr/bin/foo [fd 4] (+buf) [dev/ino: 2065/60716306] (0100600): (14685) succeed mode 0100644 uid 0:0
close /data/poky-master/tmp/sysroots/x86_64-linux/usr/bin/foo [fd 4]: (14685) (no request)

Patch on the list.

Seems to be accessible now.

Indeed.  Fixed in oe-core fb6623e7b9f97dcd6749e441185e4183b9953171.

Setting as verified.