469814 - Nightly mac builds contain .dSYM bundles

Status: VERIFIED FIXED

(Firefox Build System :: General, defect)

Description

[Florian Quèze [:florian]]

+++ This bug was initially created as a clone of Bug #468494 +++

> Probably because the Contents/MacOS folder is full of .dSYM bundles.

(In reply to comment #2)
> Created an attachment (id=351959) [details]
> don't package .dSYM bundles

This patch removed only the .dSYM bundles in Contents/MacOS but there are still some in other folders:

$ find Minefield.app -name '*.dSYM'
Minefield.app/Contents/MacOS/components/libalerts_s.dylib.dSYM
Minefield.app/Contents/MacOS/components/libbrowsercomps.dylib.dSYM
Minefield.app/Contents/MacOS/components/libbrowserdirprovider.dylib.dSYM
Minefield.app/Contents/MacOS/crashreporter.app/Contents/MacOS/crashreporter.dSYM
Minefield.app/Contents/MacOS/plugins/DefaultPlugin.plugin/Contents/MacOS/DefaultPlugin.dSYM
Minefield.app/Contents/MacOS/plugins/JavaEmbeddingPlugin.bundle/Contents/MacOS/JavaEmbeddingPlugin.dSYM
Minefield.app/Contents/MacOS/plugins/MRJPlugin.plugin/Contents/MacOS/MRJPlugin.dSYM
Minefield.app/Contents/MacOS/updater.app/Contents/MacOS/updater.dSYM
Minefield.app/Contents/Plug-Ins/PrintPDE.plugin/Contents/MacOS/PrintPDE.dSYM

Comment 1

[(not currently active) Ted Mielczarek]

Thanks for spotting this.

Comment 2

[(not currently active) Ted Mielczarek]

Attachment: cleanup a bit better

This is the least sucky way I can figure out to do this. The alternative is hardcoding a whole bunch of paths in packager.mk. I added the test for "copy_debug" so we can support an OSX symbol server at some point.

Comment 3

[(not currently active) Ted Mielczarek]

Pushed:
http://hg.mozilla.org/mozilla-central/rev/30ee44d51589

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Ted, this patch doesn't remove the files from an existing installation. The dSYM bundles are still there after several updates for Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090101 Minefield/3.2a1pre ID:20090101020547

Could they be causing problems in any way? Do nightly testers have to install a fresh version instead of updating their build?

Comment 5

[(not currently active) Ted Mielczarek]

Comment on attachment 353251 [details] [diff] [review]
cleanup a bit better

This will prevent us from shipping unnecessary files in our Mac builds.

Comment 6

[(not currently active) Ted Mielczarek]

The only thing they'll do is take up space. I should land this on 1.9.1 before we ship b3, but otherwise it doesn't really matter, as we've never shipped a release with these extra files.

Comment 7

[Florian Quèze [:florian]]

(In reply to comment #4)

> Could they be causing problems in any way?

In Instantbird, the .dSYM bundles in the components/ folder caused weird XPCOM registration issues, but I don't remember noticing any impact with Minefield, except the overhead of course.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Interesting. Let's see if this will fix bug 471209 too.

Comment 9

[Florian Quèze [:florian]]

(In reply to comment #8)
> Interesting. Let's see if this will fix bug 471209 too.

The error I had in Instantbird was very similiar to the one reported in that bug, and the problem was only after a restart. IIRC, the compreg.dat file in the profile contained the path to a file inside the .dSYM bundle, instead of the path to the .dylib file of the XPCOM component.

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 353251 [details] [diff] [review]
cleanup a bit better

a191=beltzner

Comment 11

[(not currently active) Ted Mielczarek]

Pushed to 1.9.1:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/6085314c4678

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

All dSYM bundles are removed now. Verified with these two builds:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090103 Minefield/3.2a1pre ID:20090103020444

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090103 Shiretoko/3.1b3pre ID:20090103020545