458467 - Fix bogus executable attributes on non-executable files in Thunderbird

Status: RESOLVED FIXED

(Thunderbird :: Build Config, defect)

Description

[Henry N.]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.6) Gecko/20070730 SUSE/2.0.0.6-25 Firefox/2.0.0.6
Build Identifier: 20081003030503

For follow files the executable flag is active, but not need it:
removed-files
defaults/profile/localstore.rdf
defaults/profile/mimeTypes.rdf
defaults/profile/prefs.js
defaults/profile/US/localstore.rdf
defaults/profile/US/defaults/profile/US/localstore.rdf


Reproducible: Always

Comment 1

[Henry N.]

The follow files also not need the executable flag:
icons/*.xpm
chrome/icons/default/*.xpm
components/*.js

Comment 2

[Magnus Melin [:mkmelin]]

Confirming. I wonder where in the process that happens...

Comment 3

[Henry N.]

Most of this files are plain readable text files and graphic binaries. So, it can be wrong in the source repository (Mercurial)?

Comment 4

[Phil Ringnalda (:philor)]

It happens with IFLAGS1 (which is 644) - see http://mxr.mozilla.org/comm-central/source/mozilla/config/rules.mk#565 and for example http://mxr.mozilla.org/comm-central/source/mozilla/browser/locales/Makefile.in#149 where the stuff that Fx locales (but, oddly, not Fx itself) put into defaults/profile gets a dose of IFLAGS1. As to why libs:: (generally) doesn't and install:: does, um, someone should figure out whether that's intentional or not :)

Comment 5

[Henry N.]

Here is the install for defaults/profile/prefs.js:
http://mxr.mozilla.org/comm-central/source/mail/app/Makefile.in#386

Here is the line for icons/mozicon16.xpm and icons/mozicon50.xpm, which are also executable on installation:
http://mxr.mozilla.org/comm-central/source/mail/app/Makefile.in#330

is IFLAGS1 exported into this Makefile?
I'm not understand, why there sometimes used INSTALL without FLAGS1 and some others SYSINSTALL with FLAGS1?

I'm not sure about right source. I have never self build Thunderbird.
Exist a build log from nightly build somewhere? To lock into these steps.

Comment 6

[Phil Ringnalda (:philor)]

Very roughly, $(INSTALL) is "symlink this" and $(SYSINSTALL) is "copy this, and if I don't pass mode flags make it 755." But the */app/Makefile.ins add bonus fun, with NSDISTMODE = copy which is "turn $(INSTALL) into the equivalent of $(SYSINSTALL), and copy instead of symlinking for both, and thus require mode flags for non-executable things."

Oh, and in a lot of cases, it's not a matter of IFLAGS, it's just a matter of correcting the bogus permissions from some long-ago checkin (as in the case of components, which is certainly not components/*.js, it's just newsblog.js (our fault) and nsContentPrefService.js and nsHandlerService.js (not ours, and separate bugs).

Comment 7

[Phil Ringnalda (:philor)]

Attachment: chmod 644 newsblog.js

Comment 8

[Phil Ringnalda (:philor)]

Attachment: IFLAGS for app/Makefile.in

Of the two choices, stick with $(INSTALL) that's going to be the same as $(SYSINSTALL) or switch to $(SYSINSTALL), I think this is the better one: we don't actually *want* these things copied rather than symlinked, so if someone either kills the NSDISTMODE or copy-pastes them out to some other makefile, they ought to revert to symlinking.

Comment 9

[Henry N.]

Hello Phil
(In reply to comment #8)
> Created an attachment (id=348901) [details]
> IFLAGS for app/Makefile.in

You changed lines where "$(DIST)/bin" is in destination path. Has this also an effect for the tar install? For example from http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/thunderbird-3.0b1pre.en-US.linux-i686.tar.bz2

I ask, because inside the tar no "bin" directory exist.

Comment 10

[Phil Ringnalda (:philor)]

Yes.

Comment 11

[Phil Ringnalda (:philor)]

http://hg.mozilla.org/comm-central/rev/87367bf662cd
http://hg.mozilla.org/comm-central/rev/c3188fbc768b

Comment 12

[Henry N.]

Thanks, some files are changed (icons/*.xpm, other *.xpm and prefs.js), 
but not all.

Build Identifier: 20081121030347 (de), 20081121030347 (us)
This files are still executable:
removed-files
components/nsContentPrefService.js
components/nsHandlerService.js
defaults/profile/localstore.rdf
defaults/profile/mimeTypes.rdf
defaults/profile/US/localstore.rdf
defaults/profile/US/mimeTypes.rdf

Reopened because it's incomplete for initial report.

Comment 13

[Phil Ringnalda (:philor)]

(In reply to comment #12)
> removed-files

Bug 464632, listed in the dependencies of this bug.

> components/nsContentPrefService.js
> components/nsHandlerService.js

Bug 465487, listed in the dependencies of this bug.

> defaults/profile/localstore.rdf
> defaults/profile/mimeTypes.rdf
> defaults/profile/US/localstore.rdf
> defaults/profile/US/mimeTypes.rdf

mail/app/profile/Makefile.in, you mangy bit of crud, what on earth are you doing with those US/ directories?

> Reopened because it's incomplete for initial report.

Reclosed because this did land for b1, and as you can see by the fact that I'm actually getting this crap fixed, in separate bugs on separate problems in separate parts of the tree, crap which people have reported over and over in single bugs listing every single executable file they found no matter the reason or source, it actually works better to have separate bugs on the separate issues.

Comment 14

[Henry N.]

(In reply to comment #13)
ok, understand. Thanks for details. I'm sorry, that the internals "who manage what part of source" are not known from outside.