Archive for the 'debian' Category

So, after having dumped Mozilla Suite, the Mozilla Foundation is now pushing Thunderbird out to pursue its goal of an "open web" (understand: MoFo only cares about Firefox).

Why is it called the Mozilla Foundation, again ?

... is that more than one are likely to have the same crazy ideas.

When I started to play with xulrunner, which according to my oldest post in the xulrunner category would be near 2 years ago, I had this crazy idea (and here, when I say crazy, I almost think dumb) that it would be neat to have a window manager based on libxul, being able to display both "native" windows and XUL or HTML windows.

Indeed, it would be neat, as in web-2.0-hype or i-can-use-gmail-directly. But that would be so much impossible to secure, and introduce so many different new ways to compromise users...

Guess what... It now exists.

Update: Waw, the GUADEC keynote slides are really full of crap. My favorite ones are about "The Fox" : Good engineering practices and Small, extensible core.

After Camino and Seamonkey, Epiphany is joining the let's have a dumb UA club.

Instead of actually fixing the problem at its root by forcing stupid people not to try to match Firefox, by totally removing Firefox in Firefox's UA, which would definitely have had a good result, they go the opposite direction.

If I see that crap coming in Debian in either epiphany, galeon or kazehakase, or any other browser based on libxul, I promise I'll hack the thing that puts the user-agent together so that it suppresses all occurrences of Firefox from it.

If only people at mozilla were as thoughtful as Robert Kaiser...

I've been using svk for xulrunner maintenance since the first test packages. And I've been thinking about switching to git for a while now. I did some testing in march, which led to my post about diffing. I went a bit further today by actually trying to convert my svk repository. And I got both interesting and surprising results.

The repository is (only) about 250 revisions in svk, and includes 15 upstream releases (or CVS pulls). I had to reorganize the svk repository so that git-svnimport could do its work properly.

[ Note: these tests have been done on a 5 years old laptop ]

The first surprise is the time it took for the conversion : almost half an hour. Dumping (svnadmin dump) and reloading (svnadmin load) the svk repository takes a bit more than 3 minutes, in comparison... I guess git-svnimport is very ineffective.

The second surprise is that the svk repository is actually almost twice as small as the git equivalent: 116MB for svk vs. 224MB for git.

On the other hand, git is amazingly fast. One of the most common things I do on this repository is a diff between the upstream branch and the trunk. I create the .diff.gz file I give pbuilder this way. It's much quicker than doing a real dpkg-source, especially considering pbuilder does one itself.

After dropping caches (echo 3 > /proc/vm/sys/drop_caches), such a diff takes about 50 seconds with svk and... a little more 2 seconds with git. Without dropping caches, it gets down to 38 seconds with svk and... 0.05s with git. That is pretty damn fast !

Update: after a git repack -d, the git repository is down to 61MB.

The good thing about not being able to attend Debconf is that you can still watch the talks online. Well, when you can find the videos.

While it's pretty easy to find the video streams, that, when you're a working european, are pretty much of no use, I couldn't find a single link to the video archives that were supposed to be available the same day.

Why oh why does the debconf7 homepage lack such an important link ? Why does video.debconf.org show a phpmyadmin login form ?

Anyways, for those who, like me, haven't found a link, here's one : Video archives for Debconf 7.

A loooong ago, someone on planet debian described mail patterns. What was this one again ?

A week ago, I started the long overdue task of triaging bugs reported on iceape/mozilla. When I started, the count was 364, duplicated excluded.

I'm still not halfway through the bug list, but already the bug count is down to 263, as of today. That is about a hundred bugs closed or merged. I can't believe there were still bugs so old but yet not merged to even older occurrences of the same bugs.

Since it is easier to appreciate the effort with nice colors, I started graphing the bug counts for iceape.

Sune Vuorela started some similar things for kde a while ago, so, thinking this could be useful for a whole lot more people than KDE and Mozilla maintainers, I also started graphing the bug counts for all packages. There is not enough backlog to have more than the last week, though. I'm a bit concerned about the fact that the RRD updates take a lot of time and may induce some load on gluck... Please DSA hit me if you want it to be moved elsewhere.

Anyways, back to iceape bugs, the oldest bug I closed was #80787, which was actually fixed as soon as I first uploaded xulrunner a year ago. On the other hand, the oldest I didn't close is #78654. There are some other winners that I'm amazed they've not been treated upstream in the last 6 years.

Now, while I tried to correctly and conveniently tag these oldest bugs, I didn't take the required amount of time to track them in upstream bugzilla. So if you, dear reader, have a little bit of time, I would really appreciate if you could go through the list of bugs* that are tagged upstream, but not yet forwarded and either find them in upstream bugzilla, or file them if they don't exist there.

* strangely enough, the raw=yes argument to the BTS doesn't seem to work properly. You can get a raw list (with no ordering by status or severity) through the LDAP gateway with the following command line:

ldapsearch -p 10101 -h bts2ldap.debian.net -x -b dc=current,dc=bugs,dc=debian,dc=org '(&(debbugsSourcePackage=iceape) (debbugsTag=upstream) (!(debbugsState=forwarded)) (!(debbugsState=done)))'

Note the LDAP query is probably not optimal. You can add debbugsID at the end of the command line if you're only interested in the bug numbers.

There has been quite some talk about init systems on the planet, recently, but I saw noone talk about the policy stuff we have.

It annoys me that, while we have an existing policy-based system to enable or disable services, yet all rc scripts I know of that disable themselves do it through a pref in /etc/default/service_name. It also annoys me there is near to zero documentation on how you are supposed to write your policy script, and that there is no bundled policy that would help getting rid of the NO_START or whatever variables in /etc/default/*.

Erich, the Gecko version number is pretty meaningless.

With mozilla releases, the date reflects when the build was done. Which means if you build Firefox 1.5 today, it will get a Gecko/20070410 string.

With Debian releases (except icedove), the date reflects the date for the client.mk in the source tarball, which is one of the last file upstream touches before a release. This helps having the same date for all 11 architectures (even after a binNMU) and is somehow more significant, but still not that much.

There are, at the moment, 3 main branches for Gecko-based code: MOZILLA_1_8_0_BRANCH, MOZILLA_1_8_BRANCH and HEAD. The latter currently contains Gecko 1.9 alpha, Firefox 3.0 alpha, etc., and will eventually be branched to a MOZILLA_1_9_BRANCH or something similar when going in beta. The other branches are respectively for Gecko 1.8.0.x (Firefox 1.5.0.x, Thunderbird 1.5.0.x, Seamonkey 1.0.y, Xulrunner 1.8.0.x) and Gecko 1.8.1.x (Firefox 2.0.0.x, Thunderbird 2.0.0.x (not yet released), Xulrunner 1.8.1.x).

[ In Debian Etch, we have Iceweasel 2.0.0.3 (Gecko 1.8.1.3), Iceape 1.0.8 (originally Gecko 1.8.0.10 but patched at version 1.8.0.11), Icedove 1.5.0.10 (Gecko 1.8.0.10 ; changes from version 1.8.0.11 didn't make it, but they don't affect the mailer code), and Xulrunner 1.8.0.11 (Gecko 1.8.0.11). The latter is used by kazehakase, galeon and epiphany. ]

Whenever a new security release for Firefox 1.5.0.x and other products from the Gecko 1.8.0.x branch are done, the Gecko date obviously changes, and doesn't reflect the fact that it's an older Gecko than that of Firefox 2.0.0.x...

Now if you take a closer look to the user agent string, you'll see something that is actually more significant than the Gecko date, i.e. the Gecko revision, such as "rv:1.8.0.11" in "Mozilla/5.0 (X11; U; Linux i686; ja_JP; rv:1.8.0.11) Gecko/20070324"