Development continues apace on the native rewrite of Firefox for Android, with the emphasis being on smartphones for the moment. In the meantime the XUL-based builds are recommended for tablets, and from a few days ago they started updating to the next XUL nightly (instead of swapping back to the native one).
For quite a while now Release Engineering has been publishing information about Firefox compile and test jobs in JSON form, for example
- a builds-4hr.js.gz file which has all the jobs from the last 4 hours
- similar files for each day, Feb 23rd is at builds-2012-02-23.js.gz
- lists of running and pending builds, which are used by tbpl.mozilla.org
The system that has been generating that data has been outgrown by the tasks given to it, so Chris AtLee has been working on moving it from http://build.mozilla.org/builds/ to http://builddata.pub.build.mozilla.org/buildjson/.
If you use this data please update your code to use the new location, as the old one won’t be updated any more.
- 39b192706927, 20110916030907
- f4d78560721a, 20110916071142
You can check what you have by loading about:buildconfig, or evaluating navigator.buildID in the Web Console.
The solution is to download the latest Nightly build from http://nightly.mozilla.org.
Applications like Thunderbird and SeaMonkey are probably also affected.
When someone pushes into a mercurial repository like mozilla-central the resulting Firefox builds end up on the ftp server, in a <branch>-<platform> directory (eg win32 optimised, win32 debug). Since early February we’ve been keeping those builds for 30 days, up from 1 day, which makes for much more fine-grained regression searches than using nightlies.
We now have a universal build that contains 32 and 64-bit binaries for Intel CPUs, instead of PowerPC & Intel 32-bit. This is for all branches except Firefox 3.5 and 3.6, and is based on all the work Josh Aas et. al. have done getting the 64-bit build working nicely, plus the decision to drop PowerPC support for Firefox 4.0.
The new universal build defaults to running 32-bit on Leopard (10.5), and 64-bit on Snow Leopard (10.6). Anyone who has been getting nightly updates for the old universal and also has an Intel processor will be moved over to the new one.
For those of you paying attention to TinderBoxPushLog there is no longer a B for OS X opt, and the B for OS X64 opt is where the new universal build is happening. We do talos and optimized unittest on the new universal build, running it 32-bit on 10.5 and 64bit on 10.6. There are still two debug builds – OS X debug is 32-bit and the unit tests run on 10.5, while OS X64 debug is a 64-bit build tested on 10.6. The debug mochitest-other for the 32-bit build has been disabled due to a packaging problem, but we still have the 64bit equivalent which is green.
Chris AtLee has blogged about RelEng’s move to Buildbot v0.8.0 to control the many compilation and test slaves that serve the Firefox codebase, and about the database backend which will allow us to better track build progress and results. We’re working on making more of that information available for people to use, for example in TBPL.
As a first step, we’re now publishing data on jobs which are running and waiting for service in JSON format. There are also HTML versions if you’d like to view the information in a table form: running, pending. The JSON is broken down by branch and revision with the following data:
- buildername – as appears on the top of the tinderbox waterfall column and TBPL display for a build
- submitted_at – timestamp for when the job was added to the database
- start_time – timestamp for when the job started running
- last_heartbeat – timestamp for the buildbot master confirming the job is still running
All the timestamps are seconds since the Unix epoch, and the data is refreshed every 5 minutes.
Note that the data currently covers a subset of all the jobs that run, in particular the unit and talos jobs running on ‘Rev3 …’ builders are not included. We’ll close that gap when the farm of minis migrates to buildbot 0.8.0. In the meantime we have all the compile jobs for mozilla-central and other branches, some unit tests, about half of mobile, and all of try. The graphs for pending builds does track all jobs, if you were wondering.
Let us know what you think.
And if you are one of the lost souls who have a Firefox 4.0a1pre build from March – May 2008, when mozilla-central used that version before dropping down to 3.1a1pre, then welcome to 2010 and all the great changes in mozilla-central since 2008.