Closed Bug 445191 Opened 16 years ago Closed 15 years ago

Build XULRunner nightlies from mozilla-1.9.1 & mozilla-central

Categories

(Release Engineering :: General, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mfinkle, Assigned: catlee)

References

Details

(Keywords: fixed1.9.1)

Attachments

(5 files, 5 obsolete files)

2.21 KB, patch
bhearsum
: review+
catlee
: checked-in+
Details | Diff | Splinter Review
7.68 KB, patch
bhearsum
: review+
catlee
: checked-in+
Details | Diff | Splinter Review
1.79 KB, patch
ted
: review+
Details | Diff | Splinter Review
4.24 KB, patch
bhearsum
: review+
catlee
: checked-in+
Details | Diff | Splinter Review
7.34 KB, patch
bhearsum
: review+
catlee
: checked-in+
Details | Diff | Splinter Review
We need XULRunner 1.9.1 nightlies built from mozilla-central (hg) in addition to the 1.9.0.x nightlies built from CVS
Component: Release Engineering → Release Engineering: Future
Priority: -- → P3
Any thoughts on an ETA for this? I know Ben talked about making some changes to the build code so we could build 2 different things from the same tree or something like that)
I've still gotta re-factor master.cfg/config.py for this :(. It's not a big patch, and I can likely do post-3.1b1. Is that OK?
Depends on: 445794
Yep. Thanks
Blocks: tomtom
Since FF3.1b1 has been released, we are seeing some extension developers looking for xulrunner SDKs, so they can upgrade their binary components.

We need some nightly xulrunner 1.9.1 runtimes and SDKs ASAP, so we can not block add-on upgrade progress.
For TomTom HOME 2.5 release (which will be based on XULRunner 1.9.1b1) we have to link to the Firefox source code on our MPL page - this is rather ridiculous but at least Firefox source code and XULRunner source code are identical. And there is a XULRunner bug that we cannot report because we are not sure that it happens in official builds without our patches - simply because there are no official builds. Yes, this issue is something that should be resolved ASAP.
OS: Mac OS X → All
Hardware: PC → All
Assignee: nobody → bhearsum
Status: NEW → ASSIGNED
Priority: P3 → P2
I'm sorry but I won't be able to get to this as soon as I thought - other things have taken priority.
Assignee: bhearsum → nobody
Status: ASSIGNED → NEW
Priority: P2 → P3
bhearsum, can you outline what's needed for this?
joduinn / bhearsum - any idea on when we could move forward on this bug? at this point we have 1.9.1 and trunk to worry about.
I'm happy to work on this but I'm deferring prioritization to joduinn.
I'm really hoping to see these builds soon - would love to start testing our XULRunner 1.9.0 based application on 1.9.1b2.
joduinn - Any idea on when we could move forward on this bug? at this point we have 1.9.1 and trunk to worry about.

We really need an SDK. I am willing to do as much work as possible on this. I think bhearsum wanted to do some foundation work first.
Summary: Build XULRunner 1.9.1 nightlies from mozilla-central → Build XULRunner nightlies from mozilla-1.9.1 & mozilla-central
(In reply to comment #12)
> joduinn - Any idea on when we could move forward on this bug? at this point we
> have 1.9.1 and trunk to worry about.
> 
> We really need an SDK. I am willing to do as much work as possible on this. I
> think bhearsum wanted to do some foundation work first.

That work ended up getting done when we branched for 1.9.1. I didn't think to dupe the dependent bug though :(
(In reply to comment #13)
> (In reply to comment #12)
> > joduinn - Any idea on when we could move forward on this bug? at this point we
> > have 1.9.1 and trunk to worry about.
> > 
> > We really need an SDK. I am willing to do as much work as possible on this. I
> > think bhearsum wanted to do some foundation work first.
> 
> That work ended up getting done when we branched for 1.9.1. I didn't think to
> dupe the dependent bug though :(

So what is the status of this bug now? Is there any plans for anyone from build to work on it and of not is there an overview on what others can do to fix it?
(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #12)
> > > I think bhearsum wanted to do some foundation work first.
> > That work ended up getting done when we branched for 1.9.1. I didn't think to
> > dupe the dependent bug though :(
> So what is the status of this bug now? Is there any plans for anyone from build
> to work on it and of not is there an overview on what others can do to fix it?

Not sure what's left to do here, so dont even know what to explain for others to do. 

bhearsum: can you clarify where you left things, and whats left to do??

mfinkle: depending on whats left to do, and if the rest of our Q1 goals come together ok, we might get time to squeeze this in before end of Q1. Obviously, if you want to help, any help is always great, but lets see whats actually left to do first?
We'll need at least the following to do these builds:
* 'make upload' support for XULrunner - not sure if the current target will "just work" (http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/installer/packager.mk#508)
* MercurialBuildFactory (or a subclass thereof) support for XULrunner. This will be made easier once https://bugzilla.mozilla.org/show_bug.cgi?id=478229 lands. (http://hg.mozilla.org/build/buildbotcustom/file/tip/process/factory.py#l220)
* Enable them in config.py/master.cfg (http://hg.mozilla.org/build/buildbot-configs/file/tip/mozilla2-staging)
* Install the xrbld key on all slaves
* Install the chown script on all Mac slaves

There might be more to do, I'm not sure.
I believe we will also need to add a make upload-sdk target or similar to push the x86 and ppc sdks up to the server
Nick + Rey -

We talked about this at the Evangelism meeting today.  People use these builds to build binary extensions so getting them out the door to people is going to help with extensions compatibility.  So this is pretty important.
I'm on it. I've already chatted with MFinkle and SSidler to see how to get a build out and emailed Nick to get him in the loop.
In addition to binary extension developers, there are those of us with stand-alone applications built on XULRunner. We use the binaries as well and would love to be able to test against the latest beta.
Was thinking exactly the same as Dan. Working on two XULRunner apps right now, and would love to integrate the latest into them.
John O'Duinn: Any way we can get this out of RE:Future and onto someone's radar for the next few weeks? I plan to bring this up at the next delivery meeting as well.
Assignee: nobody → catlee
Component: Release Engineering: Future → Release Engineering
Priority: P3 → P2
Attached patch Add upload target for xulrunner (obsolete) — Splinter Review
Attachment #369378 - Flags: review?(ted.mielczarek)
Attachment #369378 - Attachment is obsolete: true
Attachment #369381 - Flags: review?(ted.mielczarek)
Attachment #369378 - Flags: review?(ted.mielczarek)
Attachment #369381 - Flags: review?(ted.mielczarek) → review+
(In reply to comment #6)
> And
> there is a XULRunner bug that we cannot report because we are not sure that it
> happens in official builds without our patches - simply because there are no
> official builds.

(You can't just build without your patches?  Building XULRunner isn't hard if you've already got a build setup that you know builds XULRunner!)
This also adds 'make-sdk' and 'upload' targets to client.mk.  We will then do 'make -f client.mk upload' to upload both arches on Mac.

This needs to land on both mozilla-central and mozilla-1.9.1 before we can start doing builds.
Attachment #369381 - Attachment is obsolete: true
Attachment #369575 - Flags: review?(bhearsum)
Attachment #369576 - Flags: review?(bhearsum)
Comment on attachment 369575 [details] [diff] [review]
Add xulrunner build to staging master

The contents of this patch are mostly OK, but we have to upload the XULRunner builds with the xrbld key (which can be found on xr-linux-tbox).

We also need to fix up the directories in /home/ftp/pub/xulrunner/nightly. Currently, latest-trunk is still cvs builds...which should become latest-mozilla1.9.0. You'll need to update mozilla/tools/tinderbox-configs/xulrunner (CVS) to fix that up, I believe.

The NightlyBuildFactory should push the 1.9.1/m-c builds properly to latest-mozilla-1.9.1 and latest-mozilla-central and we should symlink latest-trunk to latest-mozilla-central, as we do for Firefox.

Does that all make sense?


Also, Mossop, can you have a look at the mozconfig files and make sure they're OK. They're basically copied from the CVS ones with unnecessary options removed AFAICT.
Attachment #369575 - Flags: review?(dtownsend)
Attachment #369575 - Flags: review?(bhearsum)
Attachment #369575 - Flags: review-
Comment on attachment 369576 [details] [diff] [review]
Add options to build and upload sdk for xulrunner builds

>             self.addFactoryArguments(objdir=objdir)
>+            self.addFactoryArguments(inifile=inifile)
>+            self.addFactoryArguments(section=section)

I think you only want to call this once and pass all three to it.

The rest of this seems fine. r=bhearsum with that change but please don't check it in until we're deploying in production.
Attachment #369576 - Flags: review?(bhearsum) → review+
(In reply to comment #29)
> (From update of attachment 369575 [details] [diff] [review])
> The contents of this patch are mostly OK, but we have to upload the XULRunner
> builds with the xrbld key (which can be found on xr-linux-tbox).

This is just for production, right?  Or also for staging?

> We also need to fix up the directories in /home/ftp/pub/xulrunner/nightly.
> Currently, latest-trunk is still cvs builds...which should become
> latest-mozilla1.9.0. You'll need to update
> mozilla/tools/tinderbox-configs/xulrunner (CVS) to fix that up, I believe.
> 
> The NightlyBuildFactory should push the 1.9.1/m-c builds properly to
> latest-mozilla-1.9.1 and latest-mozilla-central and we should symlink
> latest-trunk to latest-mozilla-central, as we do for Firefox.

If post_upload is run with --release-to-latest, and --release-to-dated, like we do for the firefox nightlies, will that work?
(In reply to comment #25)
> (You can't just build without your patches?  Building XULRunner isn't hard if
> you've already got a build setup that you know builds XULRunner!)

We can do everything - but it takes a lot longer than downloading a build, and for that particular minor issue it's just too long.
Comment on attachment 369575 [details] [diff] [review]
Add xulrunner build to staging master

Yeah I don't believe there is any need to change the config from cvs to 1.9.1.
Attachment #369575 - Flags: review?(dtownsend) → review+
(In reply to comment #31)
> (In reply to comment #29)
> > (From update of attachment 369575 [details] [diff] [review] [details])
> > The contents of this patch are mostly OK, but we have to upload the XULRunner
> > builds with the xrbld key (which can be found on xr-linux-tbox).
> 
> This is just for production, right?  Or also for staging?
> 

We should do the same thing in staging so it matches production as close as possible IMHO. We'd want to generate a different xrbld key for staging, of course.

> > We also need to fix up the directories in /home/ftp/pub/xulrunner/nightly.
> > Currently, latest-trunk is still cvs builds...which should become
> > latest-mozilla1.9.0. You'll need to update
> > mozilla/tools/tinderbox-configs/xulrunner (CVS) to fix that up, I believe.
> > 
> > The NightlyBuildFactory should push the 1.9.1/m-c builds properly to
> > latest-mozilla-1.9.1 and latest-mozilla-central and we should symlink
> > latest-trunk to latest-mozilla-central, as we do for Firefox.
> 
> If post_upload is run with --release-to-latest, and --release-to-dated, like we
> do for the firefox nightlies, will that work?

Yeah, sorry, I was just stating the obvious in that last paragraph. The only thing we actually need to do about this is update the tinder-config.pl files (http://mxr.mozilla.org/mozilla/source/tools/tinderbox-configs/xulrunner) and fix latest-trunk.
Attachment #369659 - Flags: review?(bhearsum) → review+
Comment on attachment 369659 [details] [diff] [review]
Update tinderbox configs to upload 1.9.0 builds to latest-mozilla1.9.0

Looks good. If you modify the CLOBBER file in these directories when you check this in you can trigger a nightly to make sure the new builds end up in the right place.
I moved latest-trunk to latest-mozilla1.9.0 and updated mozilla/tools/tinderbox-configs/monitoring/XULRunner_trunk.txt. Further on we can add checks for m-1.9.1 and m-c.
Attachment #369659 - Flags: checked‑in+
Comment on attachment 369659 [details] [diff] [review]
Update tinderbox configs to upload 1.9.0 builds to latest-mozilla1.9.0

Checking in linux/CLOBBER;
/cvsroot/mozilla/tools/tinderbox-configs/xulrunner/linux/CLOBBER,v  <--  CLOBBER
new revision: 1.7; previous revision: 1.6
done
Checking in linux/tinder-config.pl;
/cvsroot/mozilla/tools/tinderbox-configs/xulrunner/linux/tinder-config.pl,v  <--  tinder-config.pl
new revision: 1.10; previous revision: 1.9
done
Checking in macosx/CLOBBER;
/cvsroot/mozilla/tools/tinderbox-configs/xulrunner/macosx/CLOBBER,v  <--  CLOBBER
new revision: 1.8; previous revision: 1.7
done
Checking in macosx/tinder-config.pl;
/cvsroot/mozilla/tools/tinderbox-configs/xulrunner/macosx/tinder-config.pl,v  <--  tinder-config.pl
new revision: 1.9; previous revision: 1.8
done
Checking in win32/CLOBBER;
/cvsroot/mozilla/tools/tinderbox-configs/xulrunner/win32/CLOBBER,v  <--  CLOBBER
new revision: 1.8; previous revision: 1.7
done
Checking in win32/tinder-config.pl;
/cvsroot/mozilla/tools/tinderbox-configs/xulrunner/win32/tinder-config.pl,v  <--  tinder-config.pl
new revision: 1.14; previous revision: 1.13
done
This uses a separate ssh key for the xulrunner build.
Attachment #369575 - Attachment is obsolete: true
Attachment #369662 - Flags: review?(bhearsum)
Comment on attachment 369662 [details] [diff] [review]
Add xulrunner build to staging master

You need a STAGE_USERNAME_XULRUNNER, too - we'll be uploading as 'xrbld'. r=bhearsum with that change.
Attachment #369662 - Flags: review?(bhearsum) → review+
I've manually spun some builds for XULRunner 1.9.1b3, available from here: http://tinyurl.com/dkqyms
Comment on attachment 369572 [details] [diff] [review]
Add upload target for xulrunner, and upload SDK if it exists

test
Attachment #369572 - Flags: review?(ted.mielczarek) → review+
Comment on attachment 369572 [details] [diff] [review]
Add upload target for xulrunner, and upload SDK if it exists

+make-sdk::  $(OBJDIR)/Makefile $(OBJDIR)/config.status
+	$(MOZ_MAKE) sdk

Please make this just "sdk" to match the objdir target.

r=me with that fix.
Attachment #369572 - Flags: checked‑in?
Attachment #370048 - Flags: review?(ted.mielczarek) → review+
Attachment #370048 - Flags: checked‑in+
Comment on attachment 370048 [details] [diff] [review]
Add upload target for xulrunner, upload SDK if it exists, and add 'sdk', 'upload' targets to client.mk

Pushed to m-c:
http://hg.mozilla.org/mozilla-central/rev/a5556353ba2c
We need to special case mozilla-central for now, until the upload target exists in client.mk on our other branches.
Attachment #369576 - Attachment is obsolete: true
Attachment #370238 - Flags: review?(bhearsum)
Comment on attachment 370238 [details] [diff] [review]
Add options to build and upload sdk for xulrunner builds

>-        self.addStep(SetMozillaBuildProperties,
>-         objdir='build/%s' % self.objdir
>-        )
>+        if self.productName == 'xulrunner':
>+            self.addStep(GetBuildID,
>+             objdir=self.objdir,
>+             inifile='platform.ini',
>+             section='Build',
>+            )
>+        else:
>+            self.addStep(SetMozillaBuildProperties,
>+             objdir='build/%s' % self.objdir
>+            )

Can you file a followup to get these unified? I think the *only* property we use since 'make upload' landed is the BuildID, and we can probably do this in a more robust way. Won't block you on this though.


>+        # Temporary workaround until all branches have the upload target in client.mk
>+        if self.branchName == 'mozilla-central':
>+            self.addStep(SetProperty,
>+             command=['make', '-f', 'client.mk', 'upload'],
>+             env=uploadEnv,
>+             workdir='build',
>+             extract_fn = get_url,
>+            )
>+        else:
>+            self.addStep(SetProperty,
>+             command=['make', 'upload'],
>+             env=uploadEnv,
>+             workdir='build/%s' % self.objdir,
>+             extract_fn = get_url,
>+            )
> 

Fine for now, please make sure to fix this once the client.mk patch lands on branch (and tracemonkey merges).

Patch looks good overall.
Attachment #370238 - Flags: review?(bhearsum) → review+
Attachment #370048 - Flags: approval1.9.1+
Comment on attachment 370048 [details] [diff] [review]
Add upload target for xulrunner, upload SDK if it exists, and add 'sdk', 'upload' targets to client.mk

Pushed to 1.9.1:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/078881d9b8e6
Attachment #370252 - Flags: review?(bhearsum)
Comment on attachment 370252 [details] [diff] [review]
Add xulrunner build to production master

>diff --git a/mozilla2/config.py b/mozilla2/config.py
>--- a/mozilla2/config.py
>+++ b/mozilla2/config.py
>@@ -12,8 +12,10 @@
> STAGE_USERNAME = 'ffxbld'
> STAGE_SERVER = 'stage.mozilla.org'
> STAGE_BASE_PATH = '/home/ftp/pub/firefox'
>+STAGE_BASE_PATH_XULRUNNER = '/home/ftp/pub/xulrunner'
> STAGE_GROUP = None
> STAGE_SSH_KEY = 'ffxbld_dsa'
>+STAGE_SSH_XULRUNNER_KEY = 'xrbld_dsa'
> AUS2_USER = 'cltbld'
> AUS2_HOST = 'aus2-staging.mozilla.org'
> DOWNLOAD_BASE_URL = 'http://ftp.mozilla.org/pub/mozilla.org/firefox'
>@@ -94,6 +96,8 @@
> BRANCHES['mozilla-central']['platforms']['linux-debug']['builds_before_reboot'] = None
> BRANCHES['mozilla-central']['platforms']['win32-debug']['builds_before_reboot'] = None
> BRANCHES['mozilla-central']['platforms']['macosx-debug']['builds_before_reboot'] = None
>+# Enable XULRunner / SDK builds
>+BRANCHES['mozilla-central']['enable_xulrunner'] = True
> # Enable unit tests
> BRANCHES['mozilla-central']['enable_unittests'] = True
> BRANCHES['mozilla-central']['unittest_build_space'] = 5
>@@ -278,6 +282,8 @@
>     'SYMBOL_SERVER_SSH_KEY': "/Users/cltbld/.ssh/ffxbld_dsa",
>     'TINDERBOX_OUTPUT': '1',
>     'MOZ_CRASHREPORTER_NO_REPORT': '1',
>+    'CHOWN_ROOT': '~/bin/chown_root',
>+    'CHOWN_REVERT': '~/bin/chown_revert',
> }
> BRANCHES['mozilla-central']['platforms']['linux-debug']['env'] = {
>     'MOZ_OBJDIR': OBJDIR,
>@@ -348,6 +354,8 @@
> BRANCHES['mozilla-1.9.1']['platforms']['linux-debug']['builds_before_reboot'] = None
> BRANCHES['mozilla-1.9.1']['platforms']['win32-debug']['builds_before_reboot'] = None
> BRANCHES['mozilla-1.9.1']['platforms']['macosx-debug']['builds_before_reboot'] = None
>+# Enable XULRunner / SDK builds
>+BRANCHES['mozilla-1.9.1']['enable_xulrunner'] = True
> # Enable unit tests
> BRANCHES['mozilla-1.9.1']['enable_unittests'] = True
> BRANCHES['mozilla-1.9.1']['unittest_build_space'] = 5
>@@ -522,6 +530,8 @@
>     'SYMBOL_SERVER_SSH_KEY': "/Users/cltbld/.ssh/ffxbld_dsa",
>     'TINDERBOX_OUTPUT': '1',
>     'MOZ_CRASHREPORTER_NO_REPORT': '1',
>+    'CHOWN_ROOT': '~/bin/chown_root',
>+    'CHOWN_REVERT': '~/bin/chown_revert',
> }
> BRANCHES['mozilla-1.9.1']['platforms']['linux-debug']['env'] = {
>     'MOZ_OBJDIR': OBJDIR,
>@@ -570,6 +580,8 @@
> BRANCHES['tracemonkey']['platforms']['linux']['upload_symbols'] = True
> BRANCHES['tracemonkey']['platforms']['win32']['upload_symbols'] = True
> BRANCHES['tracemonkey']['platforms']['macosx']['upload_symbols'] = True
>+# Disable XULRunner / SDK builds
>+BRANCHES['tracemonkey']['enable_xulrunner'] = False
> # Enable unit tests
> BRANCHES['tracemonkey']['enable_unittests'] = True
> BRANCHES['tracemonkey']['unittest_build_space'] = 5
>diff --git a/mozilla2/linux/mozilla-central/xulrunner/mozconfig b/mozilla2/linux/mozilla-central/xulrunner/mozconfig
>new file mode 100644
>--- /dev/null
>+++ b/mozilla2/linux/mozilla-central/xulrunner/mozconfig
>@@ -0,0 +1,11 @@
>+export MOZILLA_OFFICIAL=1
>+export JAVA_HOME=/tools/jdk
>+
>+ac_add_options --enable-application=xulrunner
>+ac_add_options --disable-tests
>+
>+CC=/tools/gcc/bin/gcc
>+CXX=/tools/gcc/bin/g++
>+
>+# Enable parallel compiling
>+mk_add_options MOZ_MAKE_FLAGS="-j4"
>diff --git a/mozilla2/macosx/mozilla-central/xulrunner/mozconfig b/mozilla2/macosx/mozilla-central/xulrunner/mozconfig
>new file mode 100644
>--- /dev/null
>+++ b/mozilla2/macosx/mozilla-central/xulrunner/mozconfig
>@@ -0,0 +1,9 @@
>+. $topsrcdir/build/macosx/universal/mozconfig
>+
>+export MOZILLA_OFFICIAL=1
>+
>+ac_add_options --enable-application=xulrunner
>+ac_add_options --disable-tests
>+
>+# Enable parallel compiling
>+mk_add_options MOZ_MAKE_FLAGS="-j4"
>diff --git a/mozilla2/master.cfg b/mozilla2/master.cfg
>--- a/mozilla2/master.cfg
>+++ b/mozilla2/master.cfg
>@@ -85,6 +85,8 @@
>             unittestBuilders.append('%s unit test' % base_name) 
>         if branch['enable_codecoverage'] and platform in ('linux',):
>             weeklyBuilders.append('%s code coverage' % branch['platforms'][platform]['base_name'])
>+        if branch['enable_xulrunner']:
>+            nightlyBuilders.append('%s xulrunner' % branch['platforms'][platform]['base_name'])
> 
>     # Currently, each branch goes to a different tree
>     # If this changes in the future this may have to be
>@@ -423,6 +425,44 @@
>              }
>              c['builders'].append(mozilla2_shark_builder)
> 
>+        if branch['enable_xulrunner']:
>+             mozilla2_xulrunner_factory = NightlyBuildFactory(
>+                 env= pf['env'],
>+                 objdir=pf['platform_objdir'],
>+                 platform=platform,
>+                 hgHost=HGHOST,
>+                 repoPath=branch['repo_path'],
>+                 buildToolsRepoPath=BUILD_TOOLS_REPO_PATH,
>+                 configRepoPath=CONFIG_REPO_PATH,
>+                 configSubDir=CONFIG_SUBDIR,
>+                 profiledBuild=False,
>+                 productName='xulrunner',
>+                 mozconfig='%s/%s/xulrunner' % (platform, name),
>+                 stageServer=STAGE_SERVER,
>+                 stageUsername=STAGE_USERNAME,
>+                 stageGroup=STAGE_GROUP,
>+                 stageSshKey=STAGE_SSH_XULRUNNER_KEY,
>+                 stageBasePath=STAGE_BASE_PATH_XULRUNNER,
>+                 codesighs=False,
>+                 uploadPackages=uploadPackages,
>+                 uploadSymbols=True,
>+                 nightly=True,
>+                 createSnippet=False,
>+                 buildSpace=buildSpace,
>+                 clobberURL=BASE_CLOBBER_URL,
>+                 clobberTime=clobberTime,
>+                 buildsBeforeReboot=pf['builds_before_reboot'],
>+                 packageSDK=True,
>+             )
>+             mozilla2_xulrunner_builder = {
>+                 'name': '%s xulrunner' % pf['base_name'],
>+                 'slavenames': pf['slaves'],
>+                 'builddir': '%s-%s-xulrunner' % (name, platform),
>+                 'factory': mozilla2_xulrunner_factory,
>+                 'category': name,
>+             }
>+             c['builders'].append(mozilla2_xulrunner_builder)
>+
> ####### STATUS TARGETS
> 
> from buildbot.status import html
>diff --git a/mozilla2/win32/mozilla-1.9.1/xulrunner/mozconfig b/mozilla2/win32/mozilla-1.9.1/xulrunner/mozconfig
>new file mode 100644
>--- /dev/null
>+++ b/mozilla2/win32/mozilla-1.9.1/xulrunner/mozconfig
>@@ -0,0 +1,10 @@
>+export MOZILLA_OFFICIAL=1
>+export JAVA_HOME=/d/jdk1.5.0_10
>+
>+ac_add_options --enable-application=xulrunner
>+ac_add_options --enable-jemalloc
>+ac_add_options --disable-installer
>+ac_add_options --disable-tests
>+
>+# Enable parallel compiling
>+mk_add_options MOZ_MAKE_FLAGS="-j4"
>diff --git a/mozilla2/win32/mozilla-central/xulrunner/mozconfig b/mozilla2/win32/mozilla-central/xulrunner/mozconfig
>new file mode 100644
>--- /dev/null
>+++ b/mozilla2/win32/mozilla-central/xulrunner/mozconfig
>@@ -0,0 +1,10 @@
>+export MOZILLA_OFFICIAL=1
>+export JAVA_HOME=/d/jdk1.5.0_10
>+
>+ac_add_options --enable-application=xulrunner
>+ac_add_options --enable-jemalloc
>+ac_add_options --disable-installer
>+ac_add_options --disable-tests
>+
>+# Enable parallel compiling
>+mk_add_options MOZ_MAKE_FLAGS="-j4"
>diff --git a/mozilla2/win32/tracemonkey/xulrunner/mozconfig b/mozilla2/win32/tracemonkey/xulrunner/mozconfig
>new file mode 100644
>--- /dev/null
>+++ b/mozilla2/win32/tracemonkey/xulrunner/mozconfig
>@@ -0,0 +1,10 @@
>+export MOZILLA_OFFICIAL=1
>+export JAVA_HOME=/d/jdk1.5.0_10
>+
>+ac_add_options --enable-application=xulrunner
>+ac_add_options --enable-jemalloc
>+ac_add_options --disable-installer
>+ac_add_options --disable-tests
>+
>+# Enable parallel compiling
>+mk_add_options MOZ_MAKE_FLAGS="-j4"
Attachment #370252 - Flags: review?(bhearsum) → review+
Comment on attachment 369662 [details] [diff] [review]
Add xulrunner build to staging master

changeset:   1049:d5f99de9c9b6
Attachment #369662 - Flags: checked‑in+
Comment on attachment 370252 [details] [diff] [review]
Add xulrunner build to production master

changeset:   1050:4eced28e6d3f
Attachment #370252 - Flags: checked‑in+
Comment on attachment 370238 [details] [diff] [review]
Add options to build and upload sdk for xulrunner builds

changeset:   237:2d307103b608
Attachment #370238 - Flags: checked‑in+
Nightly XULRunner builds are now being produced for mozilla-central and mozilla-1.9.1 repositories.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
I just added a latest-trunk -> latest-mozilla-central symlink on /pub/mozilla.org/xulrunner/nightly on surf to match Firefox.
Depends on: 486400
The new nightly mac installers don't work captured here: 486493
Keywords: fixed1.9.1
Blocks: 607775
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.