Today the final patch to enable TryServer to do mobile builds (Fennec for WinCE and Maemo) landed. This is needed because changes to mainline Mozilla code are breaking the mobile browser. When this happens it ends up wasting a lot of the mobile team’s time and effort. Building Fennec is different from the usual Firefox build because it is cross-compiled for both platforms and requires two mercurial repositories (mozilla-central and mobile-browser).

WinCE try builds override the standard WinCE build factory with different checkout, mozconfig and upload steps and adds some try related processing and patching. Maemo, however, uses a very different build environment. To do builds for Maemo, Nokia has developed something called scratchbox. Scratchbox is basically a chroot environment which has all the required binaries and libraries to do a full fennec build. The Maemo build factory had to be modified with special regard for where the actual build took place. Normally, there is a directory under the buildbot slave’s main directory where a build happens(e.g./builds/slave/sendchange-wince-hg).

For maemo, the build had to take place under the scratchbox root because the standard folder wouldn’t be visible to scratchbox in the chroot. Maemo uses /scratchbox/users/cltbld/home/cltbld/build instead. Each command that needs to be run to build software is prefixed with scratchbox -p -d followed by a path to the working directory and the command to run. This will start up the scratchbox environment, execute the command then exit.

Because of the way try server is designed it is not possible without some redesigning to have two repositories with their own patches. The mobile-browser repository is inside the mozilla central directory. Because of this, it should be possible to get one patch to encompass changes to both repositories. To do this I have a hypothesis which involves mangling a mobile-browser patch with
sed 's/^--- a\//--- a\/mobile\//; s/^+++ b\//+++ b\/mobile\//'
You would also need to merge your mozilla-central and mobile-browser patches together, something I am not entirely sure how to do. I have tested this command and it applied cleanly with patch -p1 in the mozilla-central checkout directory, but I also didn’t want to waste build farm time by submitting this patch. If it works for you please let me know and I can take a look at making this a part of the sendchange interface. This is possible because the patching process uses patch instead of hg import.

There are two small issues with mobile try builds right now. The first is that there is no mail notifications on the completion of a try build and the second is that mobile try builds are in a different directory than the Windows, Linux and Mac OS builds. Patches are written and waiting for review over at Bug 465039. The rest of this post will be about how I wrote the patch and what I learned. Feel free to stop reading ;)
I started with a patch that Aki had written for WinCE try builds. There were a couple issues which had prevented this patch from being accepted and used. My first task was to understand how the try server system worked. I was already somewhat familiar with buildbot but I had never seen a configuration quite so large. It was really interesting to figure out how the configurations had been constructed. Eventually I figured my way around after a couple false starts. I am used to being able to have a completely self-hosted instance of whatever I am working on. During this project I learned a ton of valuable lessons.

I learned that it is critical to think everything through completely before writing it. One of the biggest sources of trouble I had was writing code without completely understanding what was going on. Part of this was because I wasn’t familar with the Mozilla configurations and part was because I was writing a patch without being able to test on a live system. This has taught me to be less ’selfish’ with my coding style. I need to spend more time when writing the patch so I can spend less time in the testing environment.

Actually putting the patch into production involved one semi-major hiccup. Because I had made changes to the regular Wince and Maemo build factories I had broken when they get their configuration step. I didn’t spot this in staging because it only showed up on a clobber build. After a writing a patch very quickly the problem was solved and the builds are now working in production again.

  • Print this article!
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Twitter