Archive for April, 2007

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.

Jörg, you can significantly reduce the number of commands to type by using some of the useful svk shortcuts.

First, you can create the mirror and check it out with a simple one liner:

svk cp svn+ssh://joerg@svn.debian.org/svn/debconf-data/ /chekout/directory


It will ask you the base URI to mirror (in case you'd actually want to mirror svn+ssh://joerg@svn.debian.org/svn/, for example), and then the depot path for the mirror and the local svk copy. The checkout will then be available in /checkout/directory.

Then, to get updates from svn:

svk up -sm


And you can also push your changes into svn with

svk push


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"

Easter this year is huge :

• Sam is elected DPL,
• Sarge r6 is released,
• and more importantly Etch is released.

Happy Easter !

PS: If FTP masters could push the number of packages in NEW down, that would be even greater.

"google keywords" - being the top search !
"ca passe" - ça passe pas
"i've got married" - congratulations
"blitzer blog" - not here
"how to gzip vmdk files without powering off vm" - wow, that's courageous
"cat and mice codes" - is it related to spaghetti code ?
"php script rm *.*" - what are you expecting to do ?
"should i use ubuntu or debian" - debian !
"why sucks is not scientifically correct" - yes, why ?
"drop laptop crash" - try and tell me what happens
"ext3rminator" - work in progress