incorrect file permissions within firefox-4.2a1pre x86_64 platform tar.bz file

RESOLVED FIXED

Status

Release Engineering
Other
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: p.kerry@sheffield.ac.uk, Assigned: jhford)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
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.

Reproducible: Always

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

Comment 1

6 years ago
The change occurred between these two releases:

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.tar.bz2


http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011-04-01-03-mozilla-central-debug/firefox-4.2a1pre.en-US.debug-linux-x86_64.tar.bz2
Thanks for narrowing that down! Changesets in that regression range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=422bbd8245a7&tochange=1a89509e25e4
(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.)

Comment 3

6 years ago
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?

Comment 4

6 years ago
Here the permission problem still exists:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011-04-03-03-mozilla-central-debug/firefox-4.2a1pre.en-US.debug-linux-x86_64.tar.bz2
http://hg.mozilla.org/mozilla-central/rev/4e4c7457e8f7

But now it's suddenly gone:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011-04-04-03-mozilla-central-debug/firefox-4.2a1pre.en-US.debug-linux-x86_64.tar.bz2
http://hg.mozilla.org/mozilla-central/rev/f76c34fd7228

That's just three changesets:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4e4c7457e8f7&tochange=f76c34fd7228

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.)
Component: Build Config → Release Engineering
Product: Firefox → mozilla.org
QA Contact: build.config → release
Version: unspecified → other

Comment 6

6 years ago
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

Comment 7

6 years ago
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.

Updated

6 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
That is when the new Linux64 machines were rolled out.  I will fix the umask issue on those slaves
Assignee: nobody → jhford
All machines other than

linux64-ix-slave26.build.mozilla.org
linux64-ix-slave14.build.mozilla.org
linux64-ix-slave16.build.mozilla.org
linux64-ix-slave13.build.mozilla.org
linux64-ix-slave10.build.mozilla.org
linux64-ix-slave04.build.mozilla.org
linux64-ix-slave12.build.mozilla.org
linux64-ix-slave11.build.mozilla.org

Have been fixed by setting umask = 002.  Those machines are not expected to be working because they are either defective or at IX.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.