Monthly Archives: May 2009

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.

I have been meaning to make this post for the last week and a half. I have been so occupied getting everything set up and visiting San Fransisco. The internet alone required about 4 trips to get set up. Even then we had to have a service call. Anyway, here is the story of my first week as a Mozilla intern!

I flew on an Air Canada A320 going from Toronto to San Fransisco. Apart from circling around San Fransisco for a while in a cloud, it was a very boring flight. That being said, a flight should never be interesting! After landing we needed to take the seemingly hundred mile cab ride to Oakwood Apartments in Mountain View, CA. This was the most scary cab ride of my life. I had to show him how to work the van and we weaved all over the Bayshore Freeway. Eventually, it all worked out and we made it to Oakwood Appartments safe. I am very impressed by the accommodations so far aside from the internet connection. We have decided to set up Comcast cable internet in our appartment. Setting up Comcast required us to make about four trips, including one half way to San Fransisco

On the Monday of the first week, we all met in front of Oakwood where we were greeted by Julie who gave us the cars. I am driving the Nissan until Nino heads back for Toronto when I am going to switch with him for the Jetta.After arriving at the office we were given the grand tour and the IT talk. During this talk we were each given a Macbook Pro and we had the internal network specifics explained to us. My original Macbook Pro was giving me random kernel panics. I spoke to Sean who swapped it for a new one. The new one so far has been running really well for me. I find that the 2gb of ram that this machine has is very constraining as it limits me to running one VM and being very selective about which programs I am running.
After the IT meeting all of us interns met with our managers. My manager is John O’Duinn and my mentor is Aki Sasaki. I spent some time with them while they showed me around. We did the weekly Mozilla Foundation call where John introduced me on the video feed. This was done in our big meeting area. Really though, this area is much more useful for watching movies!
Over the next few days John and Aki spent a bunch of time explaining our current build system and went over some areas where I could do work. It is really nice to know that the projects they are putting me on are of actual value instead of being busy work! My first project is to work on getting TryServer to work for Maemo. Maemo is the Linux based operating system that runs on Nokia’s internet tablets. The bug I am working on right now is limited in scope to trying the build and not running unit tests. Because of the low power in the actual tablets I am cross compiling fennec using my Linux VM. This is done with scratchbox. Scratchbox is a cross compilation environment for Maemo. In order for the unit test’s to execute they need to be run on actual devices. This means that I would have to hook up the completion of the try build to a unit test run on device. When I get unit tests to work I may get to work with the n810 cluster Aki has on his desk
I am using Aki’s Wince Try Server patch as a basis for my Maemo try work. Wince is the other Fennec platform we are working on right now. Wince has a much easier build environment as it does not require file path manipulation as much as Maemo does. I will put this in its own blog entry as I don’t want it to get lost.

Anyway, last week was hectic but also a ton of fun. I am really looking forward to a challenging summer!