User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.2a1pre) Gecko/20110403 Firefox/4.2a1pre
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.2a1pre) Gecko/20110403 Firefox/4.2a1pre
The tar.bz file for nightly builds of 4.2a1pre from around 20110403 for linux x86_64 extracts files with incorrect permissions - examples are mode 700 for all ".so" files, "firefox", "firefox-bin", "plugin-container", etc, etc instead of mode 755.
The i686 version from the same date looks to have the correct permissions.
Steps to Reproduce:
1.download "Linux 64-bit Intel" .tar.bz file from http://nightly.mozilla.org/
2.extract .tar.bz file
3.several extracted files have incorrect file permissions
The change occurred between these two releases:
Thanks for narrowing that down! Changesets in that regression range:
(For reference, you can get the changesets by looking at the .txt files next to each build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011-03-31-03-mozilla-central-debug/firefox-4.2a1pre.en-US.debug-linux-x86_64.txt or using about:buildconfig if you run the builds.)
I'm not familiar enough with the Firefox build tree to track this down, but I've done a couple of observations:
The tar balls created in http://hg.mozilla.org/mozilla-central/file/3a205e920ec0/toolkit/mozapps/installer/packager.mk are made by subtracting the write permissions from the files: --mode="go-w"
My own firefox-4.2a1pre.en-US.debug-linux-x86_64.tar.bz2 packages created the latest two days do not have this permission problem. (But my build environment is probably far from standard.)
Anyway: Are the i686 and x86_64 packages built on different computers/accounts/shells with different umask:s?
Here the permission problem still exists:
But now it's suddenly gone:
That's just three changesets:
And I can't imagine how these three changesets could ever re-enable the read-/execute-permissions for x86_64. But I'm not a programmer...
Maybe this despite everything is an umask-question outside the buildtree itself?
We'll throw this over the wall at Release Engineering and see if they can deduce anything. (RelEng maintains the build machines.)
The problem still exists in the current nightly build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-4.2a1pre.en-US.linux-x86_64.tar.bz2
But it's still gone in: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011-04-05-03-mozilla-central-debug/firefox-4.2a1pre.en-US.debug-linux-x86_64.tar.bz2
The linux64 buildbot.tac's need to set umask to 002 (instead of None).
This may be isolated to the new ix linux64 boxes; I haven't doublechecked the VMs.
That is when the new Linux64 machines were rolled out. I will fix the umask issue on those slaves
All machines other than
Have been fixed by setting umask = 002. Those machines are not expected to be working because they are either defective or at IX.