242845 - Firefox disk image should use .dmg internal zlib-compression, not .dmg.gz

Status: VERIFIED FIXED

(Firefox Build System :: General, defect)

Description

[Sophia Poirier]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a) Gecko/20040506 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a) Gecko/20040506 Firefox/0.8.0+

The application should be distributed as a compressed disk image file, not an
uncompressed disk image that is then gzip compressed on top of that.  That's
silly and more stages than necessary, especially since Apple's default disk
image compression type is gzip.  Apple's guidelines state that this is how folks
should distribute single-bundle application, without an installer (which you
already do) and packaged in a compressed disk image file without the unnecessary
multiple-encodings stuff.

There is even a convenient shell command that you can use to accomplish this.  I
am guessing that you probably have shell scripts automating this stuff, so I
thought that you might find this useful.  Here is an example:

hdiutil create -srcfolder path-to-the-directory-enclosing-Firefox.app -volname
"Mozilla Firefox" -nouuid -gid 99 -format UDZO -imagekey zlib-level=9
firefox-0.8-mac

You need to change "path-to-the-directory-enclosing-Firefox.app" to be the path
to a directory that contains the Firefox.app bundle (and nothing else, otherwise
the other stuff will be included, too).  Other than that, run that command as is
and you'll get a disk image with good compression applied.

After running that command, you can optionally also run this command and the
resulting disk image file:

hdiutil internet-enable -yes firefox-0.8-mac.dmg

This will make it an "internet enabled" disk image file, which is also preferred
by Apple.  What that means is that, when downloaded, it will automatically mount
the disk image and copy the contents to the desktop and then automatically
unmount and delete the original disk image file.  This is pretty neat cuz then
basically you just unpack the disk image and the unecessary intermediate stuff
goes away and you are just left with the app that you downloaded.  However, if
for example you had the disk image volume with a special background that you
wanted the user to see, then you wouldn't want to do this I guess.

Reproducible: Always
Steps to Reproduce:

Comment 1

[riscky]

I agree with this bug and have for some time... howerver it is a dup of 169602

Reopen if you would like to protest

*** This bug has been marked as a duplicate of 169602 ***

Comment 2

[Sophia Poirier]

Well, when I said more about this at bug 169602, I was told my comments had
nothing to do with the bug since it was specific to Camino, so I guess I will
reopen this one as a report specific to Firefox.  Though actually, it is true of
how all of Mozilla's Mac OS X software is distributed, so I'll also change to
the product to Browser (which I hope is the best choice?).  So anyway, here were
my comments that I posted at bug 169602, with some changes to make them more
general to all of Mozilla's software:



Apple ships an /etc/httpd/mime.types file with this line:

application/octet-stream    bin dms lha lzh exe class so dll dmg

So is that good enough for the MIME whiners?  ;-)  Seriously, I just find that a
really thin reason to not distribute a simple DMG file.


Second, I'll add that Apple does have guidelines in the User Experience part of
the Human Interface Guidelines that specify this stuff.  In summary, it says
that drag'n'drop(TM) installation of a single application bundle is the ideal. 
If that's not possible, use a package installer.  So Mozilla apps are all single
app bundles and do that already, so great.  More info about this is at:

http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Concepts/sd_on_mac_os_x.html

The next step is packaging it for download.  Apple specifies that you make a
compressed DMG file and don't add any more needless, annoying encoding beyond
that.  This is discussed a bit at:

http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGFirstImpressions/chapter_6_section_3.html

and more at:

http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Concepts/sd_disk_images.html

You'll also see that this goes into internet-enabled disk images, which are
better yet.  It explains it all there, so I won't bother here.  But basically,
it leads to no intermediate files at all, you just get the application after
downloading.

I also watched one of the freebie videos from WWDC 2003 at ADC and it talked
about this a lot more (and other user experience stuff), I feel it's worth watching.


Aside from being tedious and annoying and introducing possible messups during
the process (not everyone has everything configured honky dory on their systems,
or has much of a clue what they're doing, etc.), there's also the fact that, at
least up until 10.3, Mac OS X had no non-shell built-in file archive
decompression software.  In 10.3, Finder handles ZIP files, that's all.  Not
everyone has StuffIt Expander installed.  It is an optional component, and also
some folks chuck it cuz of it's not so hot history with permissions problems and
some other bugginess.  So don't assume that everyone even has an immediately
obvious way to expand GZIP or BZIP2 files, cuz they don't all.  And the vast
majority of users don't know how to use gunzip from a shell.


Here's the best way to do this, for example for Firefox:

hdiutil create -srcfolder path-to-the-directory-enclosing-Firefox.app -volname
"Mozilla Firefox" -nouuid -gid 99 -format UDZO -imagekey zlib-level=9
firefox-0.8-mac

hdiutil internet-enable -yes firefox-0.8-mac.dmg

Change "path-to-the-directory-enclosing-Firefox.app" to be the path
to the parent directory of the Firefox.app bundle.  And likewise for other apps
(Thunderbird, Mozilla, Camino, etc.) and then you would also want to change the:
-volname "Mozilla Firefox"
to something more appropriate for those other apps, too.

Comment 3

[Jo Hermans]

moving this bug to Firefox (it was filed for Seamonkey, the application suite),
see comment 2

Comment 4

[Ali Ebrahim]

*** Bug 276570 has been marked as a duplicate of this bug. ***

Comment 5

[Ali Ebrahim]

Compressed .dmg archives have been supported since MacOS X 10.1. Since we
require 10.1 or newer in order to run Firefox, theoretically there should be no
problem with regards to backwards compatibility. .dmg files are also the
standard method of software distribution on Mac, so we also adhere to platform
standards, and avoid the unlikely problem case where a user may not have Stuffit
Expander installed to open the .gz.

This has also been discussed here at some length by various commenters:
http://blog.ebrahim.org/archives/2004/12/30/mac_firefox_install_problems.php

See the hdiutil man page here:
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/hdiutil.1.html

Comment 6

[Ali Ebrahim]

See bug 169602 comment 14 for more reasons why we should do this. Space savings
of dmg.gz over internally zlib-compressed dmg are negligible, users are
presented with a more familiar download process with dmg, and we remove an
unecessary dependency on Stuffit Expander.

Comment 7

[Arthur Wiebe]

Simply changing a line or two in packager.mk and make-diskimage will set things
straight.
I'm working on it and will submit a patch if it works out good.

Comment 8

[Arthur Wiebe]

Attachment: Creates compressed disk image.

This patch will create a zlib-compressed disk image. It is not internet enabled
though but that can be easily added.

The disk image it created for me is available at
http://artooro.spymac.net/files/firefox-1.0+.en-US.mac-svg-libart.dmg

Comment 9

[riscky]

Internet enabled disc images are very annoying & a bad idea... they don't do
what you expect... and you don't know what gets extraced.

Comment 10

[Sophia Poirier]

(In reply to comment #9)
> Internet enabled disc images are very annoying & a bad idea... they don't do
> what you expect... and you don't know what gets extraced.

Hmmm, I think that's rather overstating it.  In the case of a disk image with
only one thing in it (as is the case with Firefox), what you get is that, after
downloading, you have Firefox.app on your desktop.  The alternative is that you
have a disk image file and a mounted disk image on your desktop, you look inside
the mounted image to get to Firefox.app, copy it to your hard disk, eject the
disk image, and then chuck the disk image file.  I don't think that's so bad
either, but really, I definitely don't see what's so bad about having
Firefox.app just put onto your desktop rather than that other stuff.  If anyone
finds that confusing or unexpected, then they're definitely not going to be able
to deal with non-internet-enabled disk images.

Comment 11

[riscky]

Internet enabled disc don't function as a user excepts... I will restate that.
When you click on a disc image a user should expect it to mount a disc image. I
tend to think Internet enabled disc tend to present a potential security risk
and should be advoid at all cost.

Comment 12

[Ali Ebrahim]

Comment on attachment 170005 [details] [diff] [review]
Creates compressed disk image.

I think you also need to change in packager.mk:

PKG_SUFFIX	= .dmg.gz

to

PKG_SUFFIX	= .dmg

Also, you're missing a > after your email address in make-diskimage.

Also, since changing /mozilla/build/package/mac_osx/make-diskimage also affects
Seamonley, make similar changes as you did to the toolkit file to
/mozilla/xpinstall/packager/Makefile.in as well.

Then I think we'll end up fixing bug 242845, bug 268074 and bug 276571 in one
go.

It may also fix bug 169602 as well, but I'm not sure about that, because I
don't see any references from Camino to
/mozilla/build/package/mac_osx/make-diskimage in lxr. Bryner would know for
sure, probably.

There are other products as well, Sunbird for example that also generate dmg.gz
files, all of which probably call the same code to generate the images.

Offhand I've found:
http://lxr.mozilla.org/mozilla/source/calendar/installer/Makefile.in#96
http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/installer/packager.mk#186

The issue with making this kind of change is that you need to be sure it
doesn't break things that aren't related to Firefox. :)

Once you've made changes, re-request review from bryner, not me.

Comment 13

[Arthur Wiebe]

OK. I'll get to it tomorrow. Actually I mean later today, it's 2:41am and time
to go to bed :)

Comment 14

[Sophia Poirier]

(In reply to comment #11)
> Internet enabled disc don't function as a user excepts... I will restate that.
> When you click on a disc image a user should expect it to mount a disc image. I
> tend to think Internet enabled disc tend to present a potential security risk
> and should be advoid at all cost.

Again, it really doesn't matter to me that much whether it's distributed
internet-enabled or not, but I just would rather the decision at least be made
thoughtfully rather than with misinformation and based on such adamant
statements made vaguely and without substance.

Internet-enabling a disk image does not add any security risk.  The only
potential security risk with disk images is with respect to automounting them,
which has nothing to do with whether they're internet-enabled but instead has to
do with browser settings for the file type.  That applies for internet-enabled
and non-internet-enabled disk images.  The only extra action added to
internet-enabled ones is copying files to the download location.  If copying
files to the download location is a security risk to be avoided at all costs,
then we should also disable the downloading feature of Firefox.

So far as saying that users should only expect that disk images will mount,
well, why should they when that's not the case?  This isn't a discussion of
whether or not internet-enabled disk images should be allowed as a format, they
already do and are out there, so that argument is irrelevant.  They do exist,
folks use them, and they behave as they do.  Which again, I think is pretty
simple behavior and really not confusing, as I already described.

Comment 15

[Martin Creutziger [:MMx]]

May I note that a compressed diskimage results in higher download size than a
"gzip -9"? 
In another bug, I proposed the exact opposite, to reduce the download size that
is, its bug 271826.
I would not like to see the download size getting increased even further.
And, btw, Apple uses multiple encodings, too. Like ".dmg.bin" e.g.

Comment 16

[Sophia Poirier]

(In reply to comment #15)
> May I note that a compressed diskimage results in higher download size than a
> "gzip -9"? 

Someone else already pointed this out here, but I will again:  look at bug
169602 comment 14 and note, "(ii) the disk space/bandwidth saving is
negligiable, only 26kB (0.34%) on the latest nightly."  I agree with others that
the upshots to using just .dmg are more significant.

> And, btw, Apple uses multiple encodings, too. Like ".dmg.bin" e.g.

They don't with their "proper" release software, only sometimes with ADC
downloads, though I'm not sure why and that actually is even more inane and
inexplicable (MacBin provides no space saving, only re-encoding that preserves
Mac-specific file meta-data and resource data, of which DMG files have none).

Comment 17

[riscky]

Fist of this bug shouldn't even thing of implementing internet enabled disc, if
someone thinks thats a good idea [shutter] then a new bug should be opened for
that. My statements where prompted based on my belief shipping any m.o
product/project with the internet enabled bit is a bad idea. Yes I do not like
internet enabled disc, and yes Apple does "support them", I also support the
idea of removing any software that is packaged that way.

However my statements are not misinformation. You double click on the disc image
and what ever is enclosed on said disc image is dumped to folder/dir the "disc
image" is contained. If the image contains some hidden files you get them too...
bad. Chances are nothing bad will ever come from it, but why support such a
concept? But I know, any potential flaw could also just get shoved in the apps
bundle...

Also I still stand by my idea that disc images do not do what a user expects.
When you double click on a disc image you should expect it be treated like a
disc, and mount. You don't expect it for it to act like a compressed file
archive type (i.e. stuffit & zip). Yes I realize that exactly what Apple was
going for.

Apple even says "Some users may be confused when they double-click a disk image
file and it then “goes away” (to the Trash)." & "A user who finds and retrieves
the image file from the Trash may again be confused that double-clicking it a
second time doesn’t produce the same behavior." I simple believe that internet
enable disc are not the way to ship any product, until the end user has a way to
distinguish between an internet enabled disc and a non internet enabled disc...
and Apple must have stopped serving up internet enabled disc for a reason... at
least I can't remeber the last time I download one from Apple, after the fad
came about.

Comment 18

[Ali Ebrahim]

Implementing internet enabled dmgs is something that we should handle in a
separate bug, probably dependent on this one, since internet enabled dmgs are
pointless if packed in gz or bz2 or whatnot.

In reply to comment 15, my motivation here is to adhere to Apple's software
distribution guidelines and MacOS platform standards, which today dictate that
software is distributed via dmg file that's not wrapped in some other format.

In the small amount of time I've spent with OSX (I admit, not nearly as long as
you), I've downloaded various software from Apple and others (Adobe, Allume,
etc.), and without exception they have all been packed as dmg files without
being wrapped in some other format.

We should try and adhere to platform standards as much as possible. Similar
efforts are being made to adhere to Windows installer standards in bug 231062.

Comment 19

[Martin Creutziger [:MMx]]

(In reply to comment #16)
> Someone else already pointed this out here, but I will again:  look at bug
> 169602 comment 14 and note, "(ii) the disk space/bandwidth saving is
> negligiable, only 26kB (0.34%) on the latest nightly."  
OK, I did not read thouroghly enogh then, sorry about that.

To sum it up:
Either we want the easier way of only having a .dmg file, or we want a more
efficient compression to save analog-modem and ISDN users a little of the
download hassle.
As there is AFAIK no way to let hdiutil use BZIP2 compression, either bug 271826
or this bug has to be closed.

So: what do we want?

Comment 20

[Sophia Poirier]

(In reply to comment #19)
> To sum it up:
> Either we want the easier way of only having a .dmg file, or we want a more
> efficient compression to save analog-modem and ISDN users a little of the
> download hassle.
> As there is AFAIK no way to let hdiutil use BZIP2 compression, either bug 271826
> or this bug has to be closed.
> 
> So: what do we want?

I remember back in my analog-modem days getting about 5 kB/sec, which would mean
this is an issue of about adding on 5 seconds to a 30-minute download.  That's
the worst case we're looking at so far as the download-time issue goes.  Clearly
trivial.  So definitely I say that that doesn't matter and that having fewer
file wrappings is what does matter.

Comment 21

[Martin Creutziger [:MMx]]

(In reply to comment #20)

> I remember back in my analog-modem days getting about 5 kB/sec, which would mean
> this is an issue of about adding on 5 seconds to a 30-minute download.  That's
> the worst case we're looking at so far as the download-time issue goes.  Clearly
> trivial.  

Not quite. BZIP2 saves around 1MB compared to GZIP or UDRO-dmg. That is more
than 5 seconds.

Comment 22

[Arthur Wiebe]

Attachment: Updated patch

This patch should work now.

In response to those who don't think we should go this rout, here's reasons why
we should(n't) compared.

1) It is the standard and recommended way of distributing this type of software
on Mac OS X.
2) It makes the installation process more simple.
3) You don't have another extra file floating around.
4) If a person happens to not have Stuffit installed, it will still work. (rare
but possible)

And the opposition:

1) Arguably smaller file size using gzip'd read-only disk image. (Note that I
found that to be untrue in some situations, even when using Bzip)
2) If the file size is slightly smaller, it might save download time.

You see, even if the file size is a little larger using a compressed disk
image, it will hardly be noticeable, even when using dialup where it might take
an extra second to download.
So the facts are for it, and not against it.

Comment 23

[Ali Ebrahim]

I'm not sure that attachment 170033 [details] [diff] [review] addresses my comments in the bottom of
comment 12. I still think more work needs to be done to get that Sunbird part
fixed, and to address the other part of packager.mk that also mentions dmg.gz.

But I'm not sure, and at this point I'm going to defer to bryner. While this
patch *should* work for Firefox/Thunderbird/Seamonkey (I think), I'm not 100%
sure what effect it will have on other products (if any).

Comment 24

[Arthur Wiebe]

Comment on attachment 170033 [details] [diff] [review]
Updated patch

This patch won't work after all. It does seem as though a few more files need
to be edited.

Comment 25

[Arthur Wiebe]

Attachment: Patch 3

I really hope this is the final patch. :)

Applies to Firefox/Seamonkey/Sunbird/Thunderbird.
There's not much else. I don't know what Camino uses, but if it uses
make-diskimage then it will work as well.

Once this is checked in the documents need to be updated and the web site
download links. I want to do some more testing this time before requesting
review.

Comment 26

[Arthur Wiebe]

I just built Sunbird and it doesn't seem to use make-diskimage. Can anyone
confirm this? Nowhere in the Sunbird code can I find anything for making a Mac
OS X disk image. There's a UNIX and Windows installation wizard but that's it.

I'll submit one final patch a little later after some more testing. No problems
in sight though.

Comment 27

[Arthur Wiebe]

Attachment: Patch 3.01

Comment 28

[Ali Ebrahim]

One very small nit in attachment 170056 [details] [diff] [review] is that over here:

http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/installer/packager.mk#186

You should probably remove the entire $(DIST)/$(PKG_BASENAME).dmg.gz segment
instead of just removing the .gz at the end. This is because this just says what
files to remove, and $(DIST)/$(PKG_BASENAME).dmg already exists there.

It's also possible that leaving that section untouched is also a useful
solution, since people upgrading from old trees will have their old dmg.gz file
deleted.

Comment 29

[Arthur Wiebe]

Attachment: Trivial rm Update

You are correct. All I did was replace dmg.gz to .dmg wherever it was found.
This would cause rm to try removing $PACKAGENAME.dmg twice which would of
course not work. Not a show stopper or anything.

(I cannot remember making so many revisions of a patch in my life!)
Have all you Mozilla developers gone though this? ;)

Comment 30

[Chase Phillips]

I think we should have this but I don't see it going in until we get Suite 1.8a6
out the door in the next week or so.

We should continue getting the patch approved and ready (thanks all!) for when I
have time to update the build systems and Tinderbox client scripts to handle the
new file extension.  Hopefully that will be RSN. :)

Comment 31

[Brian Ryner (not reading)]

Comment on attachment 170086 [details] [diff] [review]
Trivial rm Update

This will also require an update to tools/tinderbox/post-mozilla-rel.pl to look
for the new filename.

Comment 32

[Arthur Wiebe]

Attachment: Tinderbox Patch

For what it's worth, here's a patch for Tinderbox.
The links on the Mozilla web site (Nightly builds for example) will need to be
changed by whoever handles that.

Comment 33

[Asaf Romano (gone)]

Internet Enabled disk image is bug 268794. Note: Starting from 10.3, the only
case they get automounted is when they are downloaded using Safari.

Comment 34

[Benjamin Smedberg]

Comment on attachment 170086 [details] [diff] [review]
Trivial rm Update

I'll mark r+ as an xpinstall/buildconfig peer, and you can count bryner for
sr+. I think that cmp should be the person to actually land this patch, in
coordination with the build automation.

Comment 35

[Chase Phillips]

Comment on attachment 171141 [details] [diff] [review]
Tinderbox Patch

Can you come up with a version of this patch that handles building both the
trunk after this patch has landed and versions of our source that won't (ever)
have the dmg.gz -> dmg patch?

For example, if I were to commit this Tinderbox patch as-is to a Mac
aviary-branch Tinderbox the build would break since aviary will always output
dmg.gz files.

Comment 36

[Arthur Wiebe]

I don't know a lot of Perl but I think that should be a simple task.

Comment 37

[Arthur Wiebe]

Just one question, is there a reason this patch can't be applied to aviary as
well? (Other than no approval-aviary1.0.1+)

Comment 38

[Chase Phillips]

I don't see why that wouldn't be technically feasible but from a practical point
of view it would be more difficult to handle overall.  I'm not ruling it out. 
I'm just saying that it's a good example of a place from which we build
Firefox/Thunderbird that doesn't currently support compressed DMGs and may
continue not to.

Comment 39

[Arthur Wiebe]

Attachment: Tinderbox Patch 1.01

What I did was write a loop that checks for both dmg and dmg.gz files and
executes the appropriate command(s).
I tested the code and it should work.

Comment 40

[Arthur Wiebe]

Does the Tinderbox patch need to go through review as well?

Comment 41

[Chase Phillips]

(In reply to comment #40)
> Does the Tinderbox patch need to go through review as well?

No, I'll apply it and touch up on the spot if the need arises.

Comment 42

[Chase Phillips]

Comment on attachment 170086 [details] [diff] [review]
Trivial rm Update

I plan to land this Monday, Jan 24.

Comment 43

[Chase Phillips]

Comment on attachment 170086 [details] [diff] [review]
Trivial rm Update

Checking in build/package/mac_osx/make-diskimage;
/cvsroot/mozilla/build/package/mac_osx/make-diskimage,v  <--  make-diskimage
new revision: 1.12; previous revision: 1.11
done
Checking in calendar/installer/Makefile.in;
/cvsroot/mozilla/calendar/installer/Makefile.in,v  <--	Makefile.in
new revision: 1.3; previous revision: 1.2
done
Checking in toolkit/mozapps/installer/packager.mk;
/cvsroot/mozilla/toolkit/mozapps/installer/packager.mk,v  <--  packager.mk
new revision: 1.4; previous revision: 1.3
done
Checking in xpinstall/packager/Makefile.in;
/cvsroot/mozilla/xpinstall/packager/Makefile.in,v  <--	Makefile.in
new revision: 1.61; previous revision: 1.60
done

Comment 44

[Arthur Wiebe]

So now the links to nightly builds at http://www.mozilla.org/developer/ need to
be changed.

Another issue I didn't think about before is some mirrors send the text/plain
content type for .dmg files.

Comment 45

[Chase Phillips]

(In reply to comment #44)
> So now the links to nightly builds at http://www.mozilla.org/developer/ need to
> be changed.

I've updated this page to use .dmg for Firefox and SeaMonkey.  Will Camino
inherit this change?  It doesn't have a build in latest/ younger than early
yesterday morning so I'm not certain.

> Another issue I didn't think about before is some mirrors send the text/plain
> content type for .dmg files.

I have mail into the sysadmin group seeking advice on the best way to solve this
one.

Comment 46

[Arthur Wiebe]

As far as I can tell Camino is not effected.

Comment 47

[Chase Phillips]

Comment on attachment 170086 [details] [diff] [review]
Trivial rm Update

Also seeking approval for 1.7 branch.

Comment 48

[Chase Phillips]

Comment on attachment 170086 [details] [diff] [review]
Trivial rm Update

Got a=asa and a=dveditz for landing this on the 1.7 and 1.0.1 branches.

Comment 49

[Chase Phillips]

Comment on attachment 170086 [details] [diff] [review]
Trivial rm Update

Landed this on Aviary 1.0.1:

Checking in build/package/mac_osx/make-diskimage;
/cvsroot/mozilla/build/package/mac_osx/make-diskimage,v  <--  make-diskimage
new revision: 1.7.20.2.2.1; previous revision: 1.7.20.2
done
Checking in toolkit/mozapps/installer/packager.mk;
/cvsroot/mozilla/toolkit/mozapps/installer/packager.mk,v  <--  packager.mk
new revision: 1.1.2.2.2.1; previous revision: 1.1.2.2
done
Checking in xpinstall/packager/Makefile.in;
/cvsroot/mozilla/xpinstall/packager/Makefile.in,v  <--	Makefile.in
new revision: 1.49.6.7.2.1; previous revision: 1.49.6.7
done

(calendar/installer/Makefile.in isn't on Aviary 1.0.1)

Comment 50

[Chase Phillips]

This still needs to land on the 1.7 branch.  I'll do that after I verify all's
well after landing this patch for Fx and Tb 1.0.1.

Comment 51

[sairuh (rarely reading bugmail)]

Chase, today's 1.0.1 builds downloaded, mounted and started up fine.

tested on Mac OS X 10.3.8:

* firefox 2005022304-1.0.1
* thunderbird 2005022302-1.0.1

Comment 52

[Chase Phillips]

(In reply to comment #51)
> Chase, today's 1.0.1 builds downloaded, mounted and started up fine.

Great!  Thanks for testing, sairuh!

Comment 53

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 170086 [details] [diff] [review]
Trivial rm Update

a=caillon for 1.7.6 too

Comment 54

[Chase Phillips]

Comment on attachment 170086 [details] [diff] [review]
Trivial rm Update

Landed this on the Mozilla 1.7 branch.

Checking in build/package/mac_osx/make-diskimage;
/cvsroot/mozilla/build/package/mac_osx/make-diskimage,v  <--  make-diskimage
new revision: 1.7.16.2; previous revision: 1.7.16.1
done
Checking in xpinstall/packager/Makefile.in;
/cvsroot/mozilla/xpinstall/packager/Makefile.in,v  <--	Makefile.in
new revision: 1.49.2.5; previous revision: 1.49.2.4
done

Slightly modified patch due to packaging fixes 1.7 had already taken.

Comment 55

[Chase Phillips]

Getting this landed on the trunk, the 1.7 branch, and the 1.0.1 branch means we
can resolve this bug as fixed.  Please file follow-ups regarding any breakage here.

Thanks to Arthur and everyone else involved in helping to make this happen!

Comment 56

[sairuh (rarely reading bugmail)]

and looks good with today's mozilla branch build (2005022408-1.7) on OS X
10.3.8. marking verified.

Comment 57

[Tom Hessman]

The release notes for Firefox 1.0.1 were not updated to reflect this change.  It
still tells you the file is a .dmg.gz, and tells you to decompress it and then
mount the disk image.  This needs to be updated to explain that it is now just a
.dmg, and it only needs to be mounted.

See http://www.mozilla.org/products/firefox/releases/#install

Comment 58

[Rafael Ebron (:rebron)]

release notes updated