Archive for the 'debian' Category

Installing Iceweasel 5.0a2 on Debian GNU/Linux

  • Go to the Debian Mozilla Team page.
  • Select the Debian version you are running, “Iceweasel” and the version, “5.0”.
  • Follow the instructions.
  • Profit.

Only amd64 and i386 packages are available. Note that there is another Iceweasel “version” available there: “aurora”. Currently, this is the same as “5.0”, but whenever Firefox 5.0 will reach the beta stage, “aurora” will be 6.0a2. Please feel free to use “aurora” if you want to keep using these pre-beta builds.

2011-05-02 19:00:42+0100

firefox | 20 Comments »

Coming soon

2011-04-23 10:31:59+0100

firefox | 20 Comments »

A good reason to keep patched source in $VCS

There are a lot of different workflows to maintain Debian packages under a Version Control System. Some people prefer to only keep the debian directory, some the whole source. And in the latter category, some prefer the source tree to be patched with Debian changes, while others prefer to keep it unpatched and exclusively use debian/patches.

It turns out the former and the latter don’t work so well in one specific case that any package may hit some day ; and that day, you realize how wrong you were not tracking the entire patched source. That happened to me recently, though instead of actually going forward and switch to tracking the patched source, I cheated and simply ditched the patch, because I didn’t strictly need it.

In all fairness, this is not only a case against not tracking patched source, but also a case of the 3.0 (quilt) source format being cumbersome.

In my specific case, I cherry picked an upstream patch modifying and adding some test cases related to a cherry-picked fix. One of the added test cases was a UTF-16 file. UTF-16 files can’t be diff’ed nor patch’ed except in the git patch format, but quilt doesn’t use nor support that. The solution around this limitation of 3.0 (quilt) format is to include the plain modified file in the Debian tarball, and add its path to debian/source/include-binaries.

On the VCS side of things, it means you have to modify the file in the source directory, and fill debian/source/include-binaries accordingly. Wait. Modify the file in the source directory ? But the other files aren’t ! They’re tracked by patches !

So here you are, with all of your modifications exclusively in debian/patches… except one.

2011-03-06 10:27:33+0100

debian | 5 Comments »

More graphs for the Debian Bug Tracking System

I have been maintaining Debian Bug Tracking System graphs for a few years, now, though not very actively. They initially were available on, but there have been some recent changes.

A while ago, I started experimenting with brand new graphs on, and when merkel was announced to be dying a few months ago, I got in touch with the QA team to know what to do with them, and it was decided we’d put them on I unfortunately didn’t follow up much on this and only recently actually worked on the migration, which took place 2 weeks ago.

The result is that the graphs have officially moved to, and links on the Package Tracking System have been updated accordingly. There is now also an additional graph tracking all open bugs in the BTS, across all packages:

Today, I added a new feature, allowing to consolidate data for multiple arbitrary packages in a single graph. Such graphs can be generated with the following URL scheme (please don’t over-abuse of it):,name1,name2,etc.png

As an example, here is a graph for all the bugs on the packages I (co-)maintain:,diggler,iceape,iceweasel,libxml2,libxslt,livehttpheaders,mozilla-dom-inspector,nspr,nss,pyxpcom,venkman,vmfs-tools,webkit,xulrunner,zfs-fuse.png

And here are the bugs affecting Mozilla-related packages:,icedove,iceowl,iceweasel,nspr,nss,xulrunner.png

I guess the next step is to allow per-maintainer consolidation through URLs such as

Update: per-maintainer consolidation has been added.

(Hidden message here: please help triaging these bugs)

2011-03-05 14:21:31+0100

debian | 5 Comments »

Yet another clarification about Iceweasel

I’m glad that 5 years after the facts, people are still not getting them straight.

The Firefox logo was not under a free copyright license. Therefore, Debian was using the Firefox name with the “earth” logo (without the fox), which was and still is under a free copyright license. Then Mozilla didn’t want the Firefox name associated to an icon that is not the Firefox icon, for trademark reasons. Fair enough.

Although at the time Debian had concerns with the trademark policy, there was no point arguing over it, since Debian was not going to use the logo under a non-free copyright license anyway.

Now, it happens that the logo has turned to a free copyright license. Request for a trademark license was filed a few weeks after we found out about the good news, and we are still waiting for an agreement draft from Mozilla to hopefully go forward.

It is still not certain that this will actually lead to Debian shipping something called Firefox some day, but things are progressing, even if at a rather slow pace, and I have good hope (discussions are promising).

By the way, thank you for the nice words, Daniel.

2011-02-07 20:42:47+0100

firefox, p.m.o | 7 Comments »




#appmenu-toolbar-button {
  list-style-image: url("chrome://branding/content/icon16.png");
#appmenu-toolbar-button > .toolbarbutton-text,
#appmenu-toolbar-button > .toolbarbutton-menu-dropmarker {
  display: none !important;


2011-01-15 16:22:43+0100

firefox | No Comments »

Replacing the Iceweasel button with an icon

Recent Iceweasel betas allows to replace the menu bar with a Iceweasel button. This is not enabled by default, but right-clicking on the menu bar allows to disable the menu bar, which enables the Iceweasel button.

The button is not exactly very appealing, and takes quite a lot of horizontal space on the tab bar. But with a few lines of CSS, this can fortunately be changed. Edit the chrome/userChrome.css file under your user profile, and add the following lines:

#appmenu-toolbar-button {
  list-style-image: url("chrome://branding/content/icon16.png");
#appmenu-toolbar-button > .toolbarbutton-text,
#appmenu-toolbar-button > .toolbarbutton-menu-dropmarker {
  display: none !important;

This what Iceweasel looks like, then:

2011-01-15 15:49:20+0100

firefox | 20 Comments »

Debian Mozilla組のAPTリポジトリの変化



deb experimental iceweasel-4.0


# apt-get install -t experimental iceweasel


Debian Lenny向けのIceweasel 3.6のbackportも配布します。インストールするには下記のAPTのソースを追加してください:

deb lenny-backports iceweasel-3.6


# apt-get install -t lenny-backports iceweasel


2011-01-14 17:36:41+0100

mozilla | No Comments »

Changes to the Debian Mozilla team APT archive

I made some changes as to how packages from the Debian Mozilla team that can’t yet be distributed in the Debian archives are distributed to users. Please update your APT sources and now use the following for 4.0 beta packages:

deb experimental iceweasel-4.0

You’ll also need the experimental repository in your sources, but the overall installation is much easier now:

# apt-get install -t experimental iceweasel

This should work for squeeze and unstable users.

I also added Iceweasel 3.6 backports for Debian Lenny users. For these, add the following APT source:

deb lenny-backports iceweasel-3.6

You’ll also need the lenny-backports repository in your sources. As for the experimental packages above, installation should be as easy as:

# apt-get install -t lenny-backports iceweasel

If your APT complains about the archive key, please check the instructions to add the key to your APT keyring.

2011-01-14 10:25:48+0100

mozilla | 27 Comments »

The measured effect of I/O on application startup

I did some experiments with the small tool I wrote in previous post in order to gather some startup data about Firefox. It turns out it can’t flush directories and other metadata from the page cache, making it unfortunately useless for what I’m most interested in.

So, I gathered various startup information about Firefox, showing how page cache (thus I/O) has a huge influence on startup. The data in this post are mean times and 95% confidence interval for 50 startups with an existing but fresh profile, in a mono-processor GNU/Linux x86-64 virtual machine (using kvm) with 1GB RAM and a 10GB raw hard drive partition over USB, running, except when said otherwise, on an i7 870 (up to 3.6GHz with Intel Turbo Boost). The Operating System itself is an up-to-date Debian Squeeze running the default GNOME environment.

Firefox startup time is measured as the difference between the time in ms right before starting Firefox and time in ms as returned by javascript in a data:text/html page used as home page.

Startup vs. page cache

Average startup time (ms)
Entirely cold cache (drop_caches) 5887.62 ± 0.88%
Cold cache after boot 3382.0 ± 0.51%
Selectively cold cache (see below) 2911.46 ± 0.48%
Hot cache (everything previously in memory) 250.74 ± 0.18%

The selectively cold cache case makes use of the flush program from previous post and a systemtap script used to get the list of files read during startup. This script will be described in a separate post.

As you can see, profiling startup after echo 3 > /proc/sys/vm/drop_caches takes significantly more time than in the normal conditions users would experience, because of all system libraries that would normally be in the page cache being flushed, hence biasing the view one can have of the actual startup performance. Mozilla build bots were running, until recently, a ts_cold startup test that, as I understand it, had this bias (which is part of why it was stopped).

The Hot cache value is also interesting because it shows that the vast majority of cold startup time is due to hard disk I/O (and no, there is no page faults number difference).

I/O vs CPU

Interestingly, testing on a less beefy machine (Core 2 Duo 2.2GHz) with the same USB disk and kvm setup shows something not entirely intuitive:

Average (ms)
Entirely cold cache 6748.42 ± 1.01%
Cold cache after boot 3973.64 ± 0.53%
Selectively cold cache 3445.7 ± 0.43%
Hot cache 570.58 ± 0.70%

I, for one, would have expected I/O bound startups to only be slower by around 320ms, which is roughly the hot cache startup difference, or, in other words, the CPU bound startup difference. But I figured I was forgetting an important factor.

I/O vs. CPU scaling

Modern processors do frequency scaling, which allows the processor to run slowly when underused, and faster when used, thus saving power. It was first used on laptop processors to reduce power drawn from the battery, allowing batteries to last longer, and is now used on desktop processors to reduce power consumption. It unfortunately has a drawback, in that it introduces some latency when the scaling kicks in.

A not so nice side effect of frequency scaling is that when a process is waiting for I/O, the CPU is underused, making the CPU usually run at its slowest frequency. When the I/O ends and the process runs again, the CPU can go back to full speed. This means every I/O can induce, on top of latency because of, e.g. disk seeks, CPU scaling latency. And it actually has much more impact than I would have thought.

Here are results on the same Core 2 Duo, with frequency scaling disabled, and the CPU forced to its top speed :

Average (ms)
Entirely cold cache 5824.1 ± 1.13%
Cold cache after boot 3441.8 ± 0.43%
Selectively cold cache 3025.72 ± 0.29%
Hot cache 576.88 ± 0.98%

(I would have liked to do the same on the i7, but Intel Turbo Boost complicates things and I would have needed to get two new sets of data)

Update: I actually found a way to force one core at its max frequency and run kvm processes on it, giving the following results:

Average (ms)
Entirely cold cache 5395.94 ± 0.83%
Cold cache after boot 3087.47 ± 0.31%
Selectively cold cache 2673.64 ± 0.21%
Hot cache 258.52 ± 0.35%

I haven’t gathered enough data to have accurate figures, but it also seems that forcing the CPU frequency to a fraction of the fastest supported frequency gives the intuitive results where the difference between all I/O bound startup times is the same as the difference for hot cache startup times. As such, I/O bound startup improvements would be best measured as an improvement in the difference between cold and hot cache startup times, i.e. (cold2 - hot2) - (cold1 - hot1), at a fixed CPU frequency.

Startup vs. desktop environment

We saw above that the amount of system libraries in page cache directly influences application startup times. And not all GNU/Linux systems are made equal. While the above times were obtained under a GNOME environment, some other desktop environments don’t use the same base libraries, which can make Firefox require to load more of them at cold startup. The most used environment besides GNOME is KDE, and here is what cold startup looks like under KDE:

Average startup time (ms)
GNOME cold cache 3382.0 ± 0.51%
KDE cold cache 4031.9 ± 0.48%

It’s significantly slower, yet not as slow as the entirely cold cache case. This is due to KDE not using (thus not pre-loading) some of the GNOME core libraries, yet using libraries in common, like e.g. libc (obviously), or dbus.

2011-01-03 16:59:17+0100

firefox, p.m.o | 4 Comments »