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)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla3.6a1
People
(Reporter: memex.2007, Assigned: nthomas)
References
Details
(Keywords: regression)
Attachments
(2 files)
1.12 KB,
patch
|
ted
:
review+
samuel.sidler+old
:
approval1.9.1.1+
|
Details | Diff | Splinter Review |
1.08 KB,
patch
|
Details | Diff | Splinter Review |
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.
Comment 1•15 years ago
|
||
I have no idea about what the reporter is talking. Josh or Steven can you help out?
Comment 2•15 years ago
|
||
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.
Comment 3•15 years ago
|
||
(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
Updated•15 years ago
|
Status: UNCONFIRMED → NEW
Hardware: PowerPC → All
Version: unspecified → 3.5 Branch
Comment 5•15 years ago
|
||
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).
Comment 6•15 years ago
|
||
The copy of FF3 I just built myself (yesterday, on OS X 10.5.7) has the "bad" PkgInfo ('-n APPLMOZB').
Comment 7•15 years ago
|
||
(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.
Assignee | ||
Comment 8•15 years ago
|
||
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.
Assignee | ||
Updated•15 years ago
|
Component: General → Build Config
QA Contact: general → build.config
Comment 9•15 years ago
|
||
> 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
Yes.
Assignee | ||
Comment 10•15 years ago
|
||
This creates a newline-less text file in both bash and sh, without any -n prefix.
Attachment #386146 -
Flags: review?(ted.mielczarek)
Comment 11•15 years ago
|
||
Nick, what about XULRunner, Thunderbird, and all the other products? Are they affected too? It looks like.
Assignee | ||
Comment 12•15 years ago
|
||
(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.
Comment 13•15 years ago
|
||
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 14•15 years ago
|
||
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 15•15 years ago
|
||
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?
Comment 16•15 years ago
|
||
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.
Comment 17•15 years ago
|
||
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.
Assignee | ||
Comment 18•15 years ago
|
||
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
Assignee | ||
Comment 19•15 years ago
|
||
Fixed on trunk, awaiting approval for 3.5.x.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.6a1
Comment 20•15 years ago
|
||
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
Comment 21•15 years ago
|
||
Not blocking on this, but I'll approve the patch.
Flags: blocking1.9.1.1? → blocking1.9.1.1-
Comment 22•15 years ago
|
||
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+
Assignee | ||
Comment 23•15 years ago
|
||
Comment on attachment 386146 [details] [diff] [review] Use printf instead of echo -n http://hg.mozilla.org/releases/mozilla-1.9.1/rev/1c898d62a9b8
Assignee | ||
Updated•15 years ago
|
Keywords: fixed1.9.1.1
Comment 24•15 years ago
|
||
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
Keywords: fixed1.9.1.1 → verified1.9.1.1
Comment 25•15 years ago
|
||
Dear SUMO: be ye aware, this was broken in 3.5 will be fixed in 3.5.1
Keywords: user-doc-needed
Updated•15 years ago
|
Keywords: user-doc-needed
Updated•5 years ago
|
Component: Build Config → General
Product: Firefox → Firefox Build System
Updated•5 years ago
|
Keywords: regression,
verified1.9.1.1
Target Milestone: Firefox 3.6a1 → mozilla3.6a1
Updated•5 years ago
|
Keywords: regression
You need to log in
before you can comment on or make changes to this bug.
Description
•