Closed Bug 501457 Opened 15 years ago Closed 15 years ago

FF3.5finalMac: type/creator name is not APPL/MOZB but incorrect

Categories

(Firefox Build System :: General, defect)

3.5 Branch
All
macOS
defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED
mozilla3.6a1

People

(Reporter: memex.2007, Assigned: nthomas)

References

Details

(Keywords: regression)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5

In FF3.5finalMac, the type/creator ID in the application file is not APPL/MOZB anymore as it was in FF3.0.11. Instead, it is erroneously:

-n A/PPLM

Because of this strange type/creator name, a mousedriver like “USB Overdrive X” (from MacUpdate.com etc.) does not recognize FF3.5 as an application to define mousekey settings for it. Evil! In FF3.0.11 or Camino etc. it’s no problem at all.


Reproducible: Always

Steps to Reproduce:
1. Locate the application file of FF3.5macFinal.
2. Display the type/creator name of that application file using a file info software like File Buddy or similar.
3. You'll see that the type/creator name of FF3.5 is not APPL/MOZB anymore as it was in FF3.0.11. Instead, it is erroneously "-n A/PPLM". 
Actual Results:  
Because of this strange type/creator name, a mousedriver like  “USB Overdrive X” (from MacUpdate.com etc.) does not recognize FF3.5 as an application to define mousekey settings for it. Evil! In FF3.0.11 or Camino etc. it’s no problem at all to do that.


Expected Results:  
The type/creator code of the app file must be APPL/MOZB again ... and not something else.
I have no idea about what the reporter is talking. Josh or Steven can you help out?
The Contents/PkgInfo file in FF 3.5 (and in current Minefield and
Shiretoko nightlies) is '-n APPLMOZB'.  In FF 3.0.11 (and current
GranParadiso nightlies) it's 'APPLMOZB'.  I'll bet that has something
to do with it.
(In reply to comment #2)
> The Contents/PkgInfo file in FF 3.5 (and in current Minefield and
> Shiretoko nightlies) is '-n APPLMOZB'.  In FF 3.0.11 (and current
> GranParadiso nightlies) it's 'APPLMOZB'.  I'll bet that has something
> to do with it.

Ben or Benjamin, are we using a different packaging method on 1.9.1? I can see this with 3.1a1 too.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9.1.1?
Keywords: regression
Hardware: PowerPC → All
Version: unspecified → 3.5 Branch
That's not good. We should fix this in the first update.
Status: NEW → UNCONFIRMED
Hardware: All → PowerPC
Version: 3.5 Branch → unspecified
Status: UNCONFIRMED → NEW
Hardware: PowerPC → All
Version: unspecified → 3.5 Branch
This looks a lot like bug 494576, and can probably be fixed the same way.

Why it doesn't also effect FF 3 I don't know.  It might have something to do with the machines on which the various distros are built (which OS version they're running, and what other software is installed).
The copy of FF3 I just built myself (yesterday, on OS X 10.5.7) has the "bad" PkgInfo ('-n APPLMOZB').
(In reply to comment #5)
> This looks a lot like bug 494576, and can probably be fixed the same way.

But the checkin didn't touch any of the browser files. Only calendar, mail, and suite. So there has to be a similar bug/checkin.
I think this is the relevant line for Fx3.5
  http://mxr.mozilla.org/mozilla1.9.1/source/browser/app/Makefile.in#407
and for 3.0
  http://mxr.mozilla.org/seamonkey/source/browser/app/Makefile.in#414

I'm not sure how this is happening, but we appear to be getting sh for 3.5 and bash for 3.0 on the release machines.
Component: General → Build Config
QA Contact: general → build.config
This creates a newline-less text file in both bash and sh, without any -n prefix.
Attachment #386146 - Flags: review?(ted.mielczarek)
Nick, what about XULRunner, Thunderbird, and all the other products? Are they affected too? It looks like.
(In reply to comment #11)
> Nick, what about XULRunner, Thunderbird, and all the other products? Are they
> affected too? It looks like.

comm-central's {mail,suite,calendar/sunbird}/app/Makefile.in also need the fix. mxr says there are lots of other instances of echo -n, but no other ones in Makefile.in.

(In reply to comment #8)
> I'm not sure how this is happening, but we appear to be getting sh for 3.5 and
> bash for 3.0 on the release machines.

What's actually happening is that we have OS X 10.4 on the Fx3.0 machines, and 10.5 on the Fx3.5 ones. 

Fx3.0 (sh v2.05b, make v3.80)
$ /bin/sh -c 'echo -n foo > test'; cat test
foo$

Fx3.5 (sh v3.2, make v3.81): 
$ /bin/sh -c 'echo -n foo > test'; cat test
-n foo
$

So 3.0 is doing the right thing (writing foo and no newline to the file), and 3.5 is wrong.
Blocks: 501574
That means that SeaMonkey nightlies and Alphas are OK now (coming from 10.4), but will be broken soon when we switch to the new 10.5 VMs. Thanks for the note.
Comment on attachment 386146 [details] [diff] [review]
Use printf instead of echo -n

We should eradicate all vestiges of "echo -n" from our codebase as it's not portable and we wind up with subtle bugs like this.
Attachment #386146 - Flags: review?(ted.mielczarek) → review+
Comment on attachment 386146 [details] [diff] [review]
Use printf instead of echo -n

Requesting 1.9.1.1 approval so this isn't forgotten.
Attachment #386146 - Flags: approval1.9.1.1?
Assignee: nobody → nthomas
Amusingly enough, it *is* portable in nsprpub/configure and directory/c-sdk/configure, which go to all kinds of trouble to test echo -n and define an ac_n based on the results, though I sort of doubt that definition is actually carrying through to where it's used in several build/autoconf/*.m4s.

And for those that don't read dependencies, the comm-central patch is in bug 501574.
FWIW, build/autoconf/*.m4 are preprocessed along with configure.in by m4, and then the macros that they define are inserted verbatim into configure, so as long as the variable has been defined anywhere in configure prior to the use of that macro, it's usable.
Makefile.in is slightly different on mozilla-central, so here's the equivalent patch. Carrying review since only the context is changing.

http://hg.mozilla.org/mozilla-central/rev/acd251e1fb15
Fixed on trunk, awaiting approval for 3.5.x.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.6a1
Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090706 Minefield/3.6a1pre ID:20090706031418
Status: RESOLVED → VERIFIED
Not blocking on this, but I'll approve the patch.
Flags: blocking1.9.1.1? → blocking1.9.1.1-
Comment on attachment 386146 [details] [diff] [review]
Use printf instead of echo -n

Approved for 1.9.1.1. a=ss
Attachment #386146 - Flags: approval1.9.1.1? → approval1.9.1.1+
Keywords: fixed1.9.1.1
Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1pre) Gecko/20090713 Shiretoko/3.5.1pre ID:20090713031225
Dear SUMO: be ye aware, this was broken in 3.5 will be fixed in 3.5.1
Keywords: user-doc-needed
Component: Build Config → General
Product: Firefox → Firefox Build System
Target Milestone: Firefox 3.6a1 → mozilla3.6a1
You need to log in before you can comment on or make changes to this bug.