185436 - Software update for release builds

Status: RESOLVED FIXED

(Camino Graveyard :: General, enhancement, P1)

Description

[Matt Carrell]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021120 Chimera/0.6+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021120 Chimera/0.6+

Apple's Software Update application works only with Mac OS X and Apple's
components. It does not work for all the third-party software you install
yourself. All these components, software, shareware and freeware you install
yourself are not checked by Apple's Software Update application.

AlphaOmega Software developed a more global application: Extended Software
Updater.  From a user's point of view, it is as simple to use as Apple's
Software Update application, provides the same functionnality, but does not
limit to Apple's components and can work with all your other third-party software.

From a developer or editor's point of view, it is very simple to make an
application compatible with Extended Software Updater (only 2 text files are
necessary) and make users benefit from it.

Read the whole documentation for more details on the URL linked with this request.


Reproducible: Always

Steps to Reproduce:





Only one small text file needs to be added to the application bundle and one
small text file put on the Chimera site to add full compatibility for this great
software updating app..

I have already generated the two text files for adding to v.6.  Only minor
changes need be made to the version.txt file that would be posted to the chimera
website for each release (version # and new feature description only).. Not a
big effort really and a nice convenience for Chimera users who don't live 24/7
on Version Tracker to track all their apps.. :)

I added the Updater.esud file to the Navigator bundle and the software updater
instantly picked up on it.. now if someone in authority can check the file into
the tree, and add the version.txt file to the website (as the URL is spelled out
in the Updater.eusd file), then it's done already!

Comment 1

[Matt Carrell]

Attachment: Extended Software Updater compatible text info file for Navigator.

This file goes into the application bundle.

Comment 2

[Matt Carrell]

Attachment: Extended Software Update compatible text file. For the Chimera website.

Would need to be placed on the Chimera website to be read by the updater
application checking for new versions.	It would be expected to be found at the
URL: 

http://www.mozilla.org/projects/chimera/version.txt 

(The URL for this file is changeable.  It can be changed in the Updater.esud
file to indicate another URL if need be.)

Comment 3

[Sören 'Chucker' Kuklau (gone)]

A tiny nice update mechanism would be cool, but I don't like the idea of a
proprietary, non-Apple software for that.

Comment 4

[Stephane Moureau]

I agree with Soren and what happen if they 'disappear', it's a "small french
developer", privacy concerns also, no guarantee.
With several friends, we made a similar request to Apple several months ago, to
extend the check to non-apple products. We could perhaps wait to see if Apple
will extend it. It's already the case for MSIE and StuffIt, but they are
included in OSX.

Comment 5

[Matt Carrell]

Curios:  What's the difference between update compatibility with non-Apple proprietary, 
and puttng a non-Apple proprietary update in the browser itself.  In my view, the 
difference is (having over 400 applications in my apps drawer) I don't have to open each 
app, find and initiate an update check which usually doesn't even give you a direct link to 
download the new version nor a description of  the changes.  This way, only one app 
need be opened.. Hey, it works, it's available, it doesn't require waiting add infinitum on 
Apple's non response, and it doesn't really require any real programming.  So if the outfit 
folded. not like it was a lot of work lost..  And for now, it's something you can do right 
away.  No waiting on update manager programming and arguing over the method, the 
format, the x,y, and z  as we've seen with other requests (like nixing tabs for something 
more Aqualike)..this is out there, free, works, and. what more could you ask for?  

As it is, Apple's playing favorites.  IE for example is NOT Apple software nor part of the 
OS in any real aspect, yet Microsoft gets to use Apple's software update.. grrr.

Lastly, would it really HARM anything to include compatibility since it's not a real effort or 
expenditure of time to do it?

Comment 6

[Matt Carrell]

Actually ,  I dont' know why it didn't hit me before.. all three concerns about EDU are 
patently false because they all relie on the premise of a "master version server".. which is 
not how this program works.  I would encourage doubters to look more carefully at the 
information on ESU..

Q:  What if the "small French developer goes belly-up?"

A:  Doesn't matter.  Version #s are served  by the website of the developer of each 
compatible application, not the french developer.

Q:  What about privacy and security?

A:  Why should this be a concernwith ESU?   ESU is only activated when the user loads 
the ESU application.  Beyond that, ESU only goes to website of each developer which 
has made a compatible application to check the posted current version file.   Just like 
Windows update, it doens't share info with M$, Apple, or anyone else.  It simply reads a 
text file with version # info. This could hardly be misconstrued as being a security hazard!

Comment 7

[Sören 'Chucker' Kuklau (gone)]

"Lastly, would it really HARM anything to include compatibility since it's not a
real effort or expenditure of time to do it?"

Write a patch (or get someone to do so) and it may be considered. Don't write a
patch and this won't be fixed.

Comment 8

[Matt Carrell]

Arrghh.. I must be in a different chapter or book or something.. :)  I had uploaded the 
patches with the initial report.. see the two textfiles.. the top file updater.esud is simply put 
into the application bundle before shipping it off to the net.. easy.. done.. voila!  The other 
file, version.txt has to be placed on the developer page indicated within the first text file 
for it to be found.  This is what ESU will look for when you click "check"..  Someone with 
an ESU compatible copy of Chimera will see Navigator v.6 pop up in the ESU list..  When 
they click check, when it gets to Chimera, it will go to the developer page and compare 
the version file there (current) with the one on the user's disk.. (potentially outdated)..

Comment 9

[Stephane Moureau]

What about 'SmartUpdate' ?
http://mozilla.org/owners.html

Comment 10

[Sören 'Chucker' Kuklau (gone)]

That's pretty dead. Last checkin on Nov 6 1999 (see
http://lxr.mozilla.org/mozilla/source/modules/softupdt ).

Comment 11

[Mike Pinkerton (not reading bugmail)]

worth investigating since it's easy, but i don't think many people use it.

Comment 12

[Jasper]

Having a version check on cold launch would be nice, especially for those users
that are not constantly looking for the latest releases. Juts a simple window:

There is a new version of Camino available.
A newer version of this software has just been detected, would you like to
download it?

(Never) (No) (Yes)

That would be more than sufficiant for most of the people. And it would be
really easy to implement using a shel script.

Comment 13

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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

Comment 14

[olivier]

http://los.dtcurrie.net/code/ have a framework for just this. I will try to
write a patch including this so that people can check it out.

Comment 15

[Jasper]

Before you do so please make sure the licensing is compatable and useable with
the mozilla public license.

Comment 16

[olivier]

(In reply to comment #15)
> Before you do so please make sure the licensing is compatable and useable with
> the mozilla public license.

from the read me of the framework:

"THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER "AS IS" AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE COPYRIGHT OWNER BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
OF SUCH DAMAGE."

would that work?

Comment 17

[Samuel Sidler (old account; do not CC)]

I have a better idea. How about we do what Colloquy currently does and just
offer the box as Jasper suggested. We know it can be done (Colloquy did it!) so
why not go the same route instead of using third-party software to accomplish
this? This would be *excellent* for 09a1!

Comment 18

[Mike Pinkerton (not reading bugmail)]

ben is working on a reimplementation of their update manager, we should be using
that rather than something different. it should be done in time for ff1.1.

Comment 19

[Samuel Sidler (old account; do not CC)]

(Adding "software" to the description for easier searching)

Comment 20

[Jasper]

Apperantly OmniGroup has released a open source software update framework
(called OmniSoftwareUpdate) which can be downloaded for free from their ftp site.

I quickly looked over it and it provides a host of very usefull extra features
I'm sure we'd all love to see in camino aswell. Including hardware and system
checks for stats and such.

It would be great if a developer could have a look at this.

http://www.omnigroup.com/developer/sourcecode/

Comment 21

[Samuel Sidler (old account; do not CC)]

This won't make 1.0, retargeting for 1.1 per discussion with pink.

Comment 22

[Samuel Sidler (old account; do not CC)]

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

Comment 23

[Steve Jacobs (irc: encro)]

Repost of https://bugzilla.mozilla.org/show_bug.cgi?id=322592#c37
Sorry I mis-read the bug title for #322592 originally

--

It's probably worth pointing out the following update facility.

Sparkle:
http://www.andymatuschak.org/pages/sparkle

Open-Source, Free (MIT License)

From the website:
Sparkle is a module that developers can stick in their Cocoa applications
(five-step install!) to get instant self-update functionality. By that, I mean
that your app will be able to update itself, not just check for new versions:
it値l read the update information from an appcast on your server, download,
extract, install, restart, and even offer to show the users release notes
before they decide if they want to update.

Comment 24

[Samuel Sidler (old account; do not CC)]

We're planning on using the mozilla.org implementation of software update (which Firefox 1.5 uses) for this.

Comment 25

[Nick Kreeger]

Taking.

Comment 26

[Didier Oswald]

(In reply to comment #24)
> We're planning on using the mozilla.org implementation of software update
> (which Firefox 1.5 uses) for this.
> 

Sparkle is almost the new standart for open-source mac apps. It's realy easy to set up (basically it's just a drag and drop + customization). Should be easier to add than the already existing mozilla.org SU-engine (I said should :p) so maybe it worths giving a shot ...

Comment 27

[Samuel Sidler (old account; do not CC)]

Sparkle was already mentioned above.

Please don't comment in this bug unless you're working on the implementation of the mozilla.org update system into Camino. Thanks.

Comment 28

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Kicking to 1.2.

Comment 29

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Setting priority per 1.6 roadmap.

Comment 31

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Blocker for a1 per meeting.

Comment 32

[Stuart Morgan]

Attachment: fix, v1

First-pass at an implementation; it still has at least one problem. This adds the framework to the build, adds a GUI pref to turn auto-check on and off, adds a menu-item for manual checking, and adds the necessary bits to default to auto-checking (every 24 hours). It builds a check URL dynamically that includes: OS version, Camino version, CPU architecture, and whether or not it's the International release, which I think covers everything we thought we would need to know.

Notes:
- This assumes sparkle is in the tree (bug 399977)
- This does not address the EULA issue; I suggest we leave that for a follow-up bug, since we're not sure what the solution will be yet and it doesn't impact any of this code.
- It assumes an update URL of https://caminobrowser.org/update-check just for the sake of putting something; we should figure out what the actual URL will be.
- Most importantly, there's a build problem that I haven't been able to figure out: the framework copy stage is bound and determined to copy Sparkle.framework out of Camino's build directory, rather than the correct location of sparkle/build/Release/. Xcode knows where it lives, but I can't seem to teach the build step. Obviously I could add a skanky workaround in the form of a shell script to put it in the right place, but I'm hoping you can use your build-fu to tell me what I'm doing wrong.

Anyone interested in testing this (you'll have to copy the build Sparkle.framework into the Camino build directory to work around the above), you can use:
  user_pref("app.update.url.override", "http://escapedthoughts.com/camino/update-test.rss");
which points to a dmg with no EULA and doctored to be version 9.9.

Comment 33

[Stuart Morgan]

Attachment: new MainMenu.nib

Comment 34

[Stuart Morgan]

Attachment: new general prefs nib

Comment 35

[Mark Mentovai]

Comment on attachment 285625 [details] [diff] [review]
fix, v1

I don't know what sparkle/ and sparke/build look like.  How does this interact with objdir builds?

Comment 36

[Stuart Morgan]

Badly (i.e., it ignores objdir); since I didn't want to muck with their build system, and it's a smallbuild, I just punted on that. Any thoughts on how to do that without forking their project (and without copying the entire tree, ideally)?

Comment 37

[Mark Mentovai]

Where can I look at their tree?

Comment 38

[Mark Mentovai]

Comment on attachment 285625 [details] [diff] [review]
fix, v1

>Index: Info-Camino.plist.in

> 	<key>mozProfileDirName</key>
> 	<string>Camino</string>
>+	<key>SUCheckAtStartup</key>
>+	<false/>

Nit: Apple's plist utilities output keys in order according to a case-sensitive sort, so the SU* entries should come before mozProfileDirName.

(We used to be good about keeping things sorted in here, looks like we've kinda gotten a little bit lazy recently.  Feel free to fix that here.)

>Index: Makefile.in

We really do this without support for objdirs.  It'll totally screw with lots of things if we don't account for it, including universal builds.  Where you currently have this:

>+	ln -fs $(srcdir)/sparkle

Let's do this:

+	mkdir -p sparkle
+	ln -fs $(ABS_topsrcdir)/camino/sparkle/* sparkle

The rest of your patch should work as-is with only that change.

> Index: src/preferences/PreferenceManager.mm

>+    baseURL = [self getStringPref:"app.update.url" withSuccess:NULL];

It's still possible to end up without a baseURL here.  What happens in that case?  Should we just set manifestURL to @""?  Will that avoid checking for updates while still leaving the user-facing prefs alone?

I'm still going to look at your framework problem this afternoon, so hang tight for comments on that.

In the future, could you use -U 8 on your diffs to give a little bit more context?

Comment 39

[Mark Mentovai]

I wrote:

>We really do this without support for objdirs.

I meant that we really CAN'T do this without support for objdirs.  :)

In playing with your patch, I also found that my suggestion didn't quite work.  We need to do this:

        mkdir -p sparkle
        ln -fs $(ABS_topsrcdir)/camino/sparkle/* sparkle
        rm -rf sparkle/Sparkle.xcodeproj
        rsync -aC $(ABS_topsrcdir)/camino/sparkle/Sparkle.xcodeproj sparkle

Xcode actually follows the symlink to the xcodeproj and bases the location of the build directory on that, so we can live with symbolic links for everything except the xcodeproj.

Comment 40

[Mark Mentovai]

Ugh, make that:

        mkdir -p sparkle
        rm -rf sparkle/Sparkle.xcodeproj
        ln -fs $(ABS_topsrcdir)/camino/sparkle/* sparkle
        rm -rf sparkle/Sparkle.xcodeproj
        rsync -aC $(ABS_topsrcdir)/camino/sparkle/Sparkle.xcodeproj sparkle

Too bad ln has no "exclude" option.

Comment 41

[Mark Mentovai]

Comment on attachment 285625 [details] [diff] [review]
fix, v1

>Index: src/application/UserDefaults.h

>+#define USER_DEFAULTS_UPDATE_INTERVAL_DEFAULT   86400

Use:

#define USER_DEFAULTS_UPDATE_INTERVAL_DEFAULT   (24 * 60 * 60)

This patch looks good to me, with this comment and my previous comments addressed.  I'll post a patch to handle the build stuff shortly.

Comment 42

[Mark Mentovai]

Attachment: Build patch for Sparkle

The first problem I found was that there was no proper dependency relationship set up, so nothing guaranteed that Sparkle would be built before anything that requires it.  Stuart says that he set up the dependencies, but they must have gotten eaten along the way.

I actually started with the current trunk pbxproj to build this one, since I wanted to try a few things out.

The problem that Stuart mentioned in comment 32 about the Copy Frameworks phase not finding Sparkle.framework seems like an Xcode bug to me.  To work around it, I've added a reference to Sparkle.framework in sparkle/build/Release in addition to the proxy reference that comes in from our inclusion of Sparkle.xcodeproj.  The sparkle/build/Release/Sparkle.framework reference is only used for the two Copy Frameworks phases (Camino and CaminoStatic).  We use the proxy reference from Sparkle.xcodeproj for the three link phases (Camino, CaminoStatic, and NavigationPrefPane).  It's a little ugly, but it shouldn't hurt anything.

This patch includes a safe change to mozilla/config/config.mk, to get it to pass an ARCHS argument to xcodebuild at all times.  Currently, ARCHS is only passed for cross compilations, because it's assumed that none of the project files specify their own ARCHS and will thus default to building for the native architecture in the absence of ARCHS.  Sparkle.xcode specifies i386 and ppc for its ARCHS, resulting in a universal build.  This is not necessary in our build system, which expects to control its own single-architecture or cross-build stuff.  This change to ARCHS is harmless for all other Xcode projects in the Mozilla tree.

Everything is set up so that Sparkle always builds in Release mode.  Stuart and I think that this is fine for us, since we push our compiler flags in from the make build system anyway.

This patch also includes my suggested Makefile change to properly support objdir builds.

I haven't tested this with CaminoStatic.

Comment 43

[Mark Mentovai]

We should also talk about stripping non-English localizations from the framework we ship in the English-only version.  Probably best left for a followup bug.

Comment 44

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #43)
> We should also talk about stripping non-English localizations from the
> framework we ship in the English-only version.  Probably best left for a
> followup bug.

Follow the train to bug 401017 for that.

Comment 45

[Mark Mentovai]

Comment on attachment 285627 [details]
new general prefs nib

Fix that tab chain!

Comment 46

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #32)
> - This does not address the EULA issue; I suggest we leave that for a follow-up
> bug, since we're not sure what the solution will be yet and it doesn't impact
> any of this code.

And to bug 401021 for that.

Comment 47

[Chris Lawson (gone)]

I've been talking with Andy a bit the last couple days trying to figure out that crasher in Sparkle (which is now fixed in trunk), and he says, for the record:

me (23:58:42): Is there a compelling reason to use Sparkle 1.1 rather than the latest trunk?
Andy (23:58:58): No.
     (23:59:04): You shouldn't.
     (23:59:06): It has known bugs.

We may have our own compelling reasons, but I thought it was worth mentioning this here seeing as there hadn't been any discussion in this bug of what version of Sparkle we'd actually be using.

Andy also says of the approximately 400 apps using Sparkle, about half are using 1.1, about one-fourth are using trunk, and about one-fourth are (still) using 1.0 or earlier.

cl

Comment 48

[Stuart Morgan]

Attachment: prefs nib, v2

You wanna tab chain? I got yer tab chain right here.

Comment 49

[Mark Mentovai]

Comment on attachment 286337 [details]
prefs nib, v2

I'd tighten up those bounding boxes a bit, but that's a preexisting problem.

Comment 50

[Stuart Morgan]

Attachment: update code, v2

Addresses comments, doesn't include the build stuff that's now its own patch.

Comment 51

[Stuart Morgan]

Comment on attachment 286055 [details] [diff] [review]
Build patch for Sparkle

Awesome, thanks for figuring this out :)

Comment 52

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 286055 [details] [diff] [review]
Build patch for Sparkle

sr=pink

Comment 53

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 286337 [details]
prefs nib, v2

rs=pink

Comment 54

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 286486 [details] [diff] [review]
update code, v2

+  NSString* manifestURL = !baseURL ? @"" : [NSString stringWithFormat:@"%@?os=%@&arch=%@&version=%@&intl=%d",

do we also want to report a client-side UUID so we can count unique pings?

sr=pink

Comment 55

[Stuart Morgan]

Comment on attachment 286055 [details] [diff] [review]
Build patch for Sparkle

We need both trunk and branch approval for the /config portion of this patch (everything else is within the /camino tree). Mento's explanation of this change is reproduced below; this should have *no impact whatsoever* for Firefox.

(In reply to comment #42)
> This patch includes a safe change to mozilla/config/config.mk, to get it to
> pass an ARCHS argument to xcodebuild at all times.  Currently, ARCHS is only
> passed for cross compilations, because it's assumed that none of the project
> files specify their own ARCHS and will thus default to building for the native
> architecture in the absence of ARCHS.  Sparkle.xcode specifies i386 and ppc for
> its ARCHS, resulting in a universal build.  This is not necessary in our build
> system, which expects to control its own single-architecture or cross-build
> stuff.  This change to ARCHS is harmless for all other Xcode projects in the
> Mozilla tree.

Comment 56

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

Comment on attachment 286055 [details] [diff] [review]
Build patch for Sparkle

a=beltzner for after the M9 freeze; if for any reason that takes more than a couple of days from now, though, holler again.

Comment 57

[Daniel Veditz [:dveditz]]

Comment on attachment 286055 [details] [diff] [review]
Build patch for Sparkle

approved for 1.8.1.10, a=dveditz for release-drivers

Comment 58

[Samuel Sidler (old account; do not CC)]

Since we're using an approval queue on the trunk and Camino would like this patch to be able to land soon, I'm added checkin-needed to this bug. I've also talked to Reed and added it to his list of non-blockers to checkin.

The instructions I'm giving are to checkin just the mozilla/config/config.mk change in attachment 286055 [details] [diff] [review]. Since that change can go in without the rest of the patch and gets the core part of this out of the way, it should be safe. This will probably land sometime over the weekend.

http://wiki.mozilla.org/Firefox3/Beta2CheckinQueue#Non-Blockers

Again: The checkin-needed keyword only applies to the mozilla/config/config.mk change in attachment 286055 [details] [diff] [review]. A Camino dev with check in the rest.

Comment 59

[Reed Loden [:reed]]

Checking in config/config.mk;
/cvsroot/mozilla/config/config.mk,v  <--  config.mk
new revision: 3.377; previous revision: 3.376
done

ss confused me, and I typoed the patch author/reviewer. Filed bug 403165 to fix it.

Comment 60

[Samuel Sidler (old account; do not CC)]

Thanks Reed!

Comment 61

[Stuart Morgan]

Attachment: combined branch patch

Landing on branch is blocked on bug 403273, but here's a combined code patch that applies against branch for when it's landable (and for sanity testing on 10.3.9 in the meantime; my test manifest mentioned above is still available).

If anyone wants to land bug 403273 and this (or just this on trunk) before I get back next week, you have my blessing to do so.

Comment 62

[Daniel Veditz [:dveditz]]

Comment on attachment 286055 [details] [diff] [review]
Build patch for Sparkle

will have to wait for next time

Comment 64

[Samuël]

It seems it takes a really long time to fix something like this. Can't it just be added?

Comment 65

[Chris Lawson (gone)]

As it says in the whiteboard, read comment 27 before commenting here.

Furthermore, please read 

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

before commenting further.

Comment 66

[Stuart Morgan]

One thought that just occurred to me: do we want to bounce the update check through a mozilla.org URL with a redirect, to protect against any potential issues that could arise down the road with the cb.o domain/site?

Comment 67

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Yeah, we probably do; all our in-client URLs work like that.

Comment 68

[Samuel Sidler (old account; do not CC)]

I'm not sure we can do https redirects through mozilla.org, but even if we can, I'm leaning toward making everything go directly to caminobrowser.org. We're now at a stable host that is providing us a free and consistent service (as they do for adiumx.com). I don't think we'll be plagued with the downtimes we've had in the past.

Comment 69

[Daniel Veditz [:dveditz]]

Comment on attachment 286055 [details] [diff] [review]
Build patch for Sparkle

approved for 1.8.1.11, a=dveditz

Comment 70

[Stuart Morgan]

I'm not going to have as much internet access this weekend as I had hoped; if anyone else has time and wants to check this in (or at least the config part for branch, so we don't miss another branch approval window) please do.

Comment 71

[Nick Kreeger]

(In reply to comment #70)
> I'm not going to have as much internet access this weekend as I had hoped; if
> anyone else has time and wants to check this in (or at least the config part
> for branch, so we don't miss another branch approval window) please do.
> 

Done...

Checking in mozilla/config/config.mk;
/cvsroot/mozilla/config/config.mk,v  <--  config.mk
new revision: 3.337.2.12; previous revision: 3.337.2.11

Comment 72

[Stuart Morgan]

Landed on MOZILLA_1_8_BRANCH. Yay!

Leaving open for trunk landing.

Comment 73

[Stuart Morgan]

Landed on trunk!

Please file any specific issues as follow-up bugs.