Author Archive

There have been quite some comments on the Iceweasel case all over the planets, and I saw several assertions, especially from the Mozilla® camp, that I, as the Firefox® co-maintainer, the xulrunner maintainer, and (soon) Seamonkey™iceape co-maintainer, have to rectify.

They broke the --enable-official-branding flag
Half-true. We just replaced Bon Echo/Deer Park with Firefox® at the appropriate places in the build tree so that we could have Firefox® with the "unbranded" logo instead of the official logo, as Gervase Markham gave us authorization for. You're still free to enable the official branding, except that since the logos and stuff are non-free, we removed the other-licenses/branding/ directory from the original tarball, thus yes, the flag is half broken.

Firefox® logos being subject to trademarks, Debian thinks they are not free.
Trademark and copyright are different things. Mozilla® has unnecessarily given a non-free license to "clarify" the trademark situation, but that is not required. To make it clear: Debian thinks the logos are not free because they are not free. Period.

Debian isn’t properly collaborating with Mozilla®, sending unusable 100000-lines patches for validation just before releases (as seen on Lucas Nussbaum's blog)
Let me take the firefox_2.0~rc1+dfsg-1.diff.gz file, strip the debian directory from it (it only contains maintainer scripts, our set of icons and some debian specific searchplugins), and strip the configure diff that is generated by autoconf due to some changes in configure.in... that's exactly 2654 lines of diff. Very far from the 100000-lines patches they are claiming.

The Mozilla people talked about Debian-specific changes that changed frozen APIs, breaking extensions (from Lucas's blog again).
So, let's dig into our firefox_2.0~rc1+dfsg-1.diff.gz:

• Changes to disable application upgrade (we want that to happen through apt-get) and change some other default preferences,
• Changes to fix "make distclean" so that it really cleans the build directory,
• Change not to build the "mangle" utility,
• Change not to call netstat to generate entropy, which is useless on linux,
• Changes to make Firefox® build and work on architectures such as hppa, mips, mips64, m68k, ia64, sparc64, alpha, and arm, which the Mozilla® guys don't seem to care much for,
• Change to add a preference directory so that users can put their set of customized preferences in /etc/firefox/pref,
• Change to allow to build flat chrome without the zip utility,
• Change to allow to use system library for myspell, instead of statically linking the bundled one,
• Changes to allow to build s390 binaries on s390x host with s390 toolchain (same applies with x86 binaries on amd64 host with x86 toolchain),
• Changes to work around bugs with the hidden visibility pragma on gcc,
• Changes to make the pango backend actually build correctly,
• Changes to avoid some error messages while trying to create Makefiles from inexistant Makefile.in's,
• Change to install in /usr/lib/firefox instead of /usr/lib/firefox-x.y,
• Change not to build useless chromelist.txt files,
• Changes to make helper applications with parameters work,
• Changes to allow builds against GTK 2.8,
• Changes to work around an Xrender bug,
• Changes to make the Gecko/yymmdddd string taken from preferences instead of being half-hard-coded (you could change it with preferences, but it would still be set to the hard-coded value at start time ; and you could change it again with preferences...),
• Change to allow mice extra buttons to act as something else than a left button,
• Change to allow to build with -Wl,--as-needed to avoid linking against a whole lot of useless libraries, without losing the link on libxpcom.so which is required by some extensions' components,
• Changes not to shlibsign the NSS modules at build time, since we're stripping the binaries afterwards, thus breaking the signature. We do build the signatures later, within the maintainer scripts.

That's not that many changes, and most of them were taken from either some Mozilla® CVS trunk or the Mozilla® Bugzilla™. And most of those that were not taken from there have been sent, except those that really don't make much sense outside Debian. So, where are these frozen API changes ?

And we're not properly collaborating, huh ?

The Mozilla® project started by coming to a (admittedly uneasy) agreement with Debian for use of the name, but the Debian version diverged even further from the official version, so the permission was revoked. (from comments on Matthew Garrett's blog)

That one is really interesting, because between the time we got this understanding with Gervase and now, we are actually less diverging from the official version than by then. The main difference by that time was the extensions manager, which, in Debian, needed a lot of changes to actually act as it should, especially with globally installed extensions. I'm not saying the Debian one was perfect, it also had its own problems, but that was a whole lot less than the blatant crap that was the official one, obviously written for Windows without any thoughts for unix, and especially linux distributions.

The only main difference now, between the official Firefox® and ours, is that our build has the pango backend enabled, which we chose over the Xft backend for several reasons I won't explain here. The others differences are that we use system libraries where possible, instead of the bundled libpng, libjpeg, libtiff, libmyspell and libcairo. We also build a flat chrome, instead of having everything in .jar files.

Now, a little bit about differences the Mozilla® guys don't seem to care about while they really should: distributions build the Mozilla® products with gcc 4.x, while the official binaries are built with gcc 3.4, as well as the extensions distributed on addons.mozilla.org. Fortunately, not a lot of extensions make use of binary components, and not a lot are linked against the standard C++ library, but when that happens (like with colorzilla), you get a component linked against libstdc++5 to load on a Firefox® that is linked against libstdc++6. You are lucky if that setup doesn't crash.

Little extra from comments in Lucas's blog:
Is it possible for the Debian Firefox maintainers to create an installer package for contrib which will install the vanilla FireFox from Mozilla’s site.
How great would it be to have a package for one architecture instead of 12, and with a dependency on libstdc++5, that almost no other package uses any more.

Update:
Debian is going to replace Firefox® with a GNU fork called Iceweasel
Half-true. For the etch release, Iceweasel will only be Firefox® with a different branding. We are taking the Iceweasel name because it was already know as a possible alternative name for Firefox® when the trademark concerns have been raised more than 2 years ago (thanks Nathanael Nerode for this nice name, by the way). It appears that the GNU guys decided to start a fork with this name... that's quite unfortunate, actually. Anyways, the plan is to get in touch with them to see what we can do together, but with the etch release approaching, we can't and won't do more than a rename for the moment.

Update 2:
We (Mozilla®) presently have working relationships with most of the major Linux distributions, including Red Hat, Novell, and Ubuntu (As seen in several posts from people of the Mozilla® Corporation or Foundation)
Very interesting. Ubuntu uses the same set of patches as Debian, with some more of their own, and even releases beta software in their official releases. But when it's Ubuntu, it's fine. Sorry, I forgot Debian is lame, and DDs are frustrated fanatic integrists, on top of being bloody fanatic assholes.

Update 3: Added some precisions about other differences with the official binaries, and a small patch I somehow forgot.

Reading about the future of the (now) Adobe Flash Player plugin for Linux on the Penguin.SWF blog, I came to the conclusion that the plugin API for browsers (NP Runtime) just sucks.
Why on earth do a plugin need to depend on openssl, while the browser already deals with SSL and associated certificates. That also means plugins will deal very badly with client-side certificates.
I guess plugins also have to implement HTTP requests themselves...

Thanks to David Nusinow, Thierry Reding, Kristian Høgsberg and Michel Dänzer to have made this possible.

It's really nice looking, but damn, this is soooooooooooooo slooooooooooow. I already tweaked my X configuration, so that GL applications would be fluid, and they are, but compiz is so much slower than all the rest of the GL applications that I really wonder what's going on. Is it so much more difficult to display 3 windows than to display the full earth with plenty of textures ?

As a bonus, for an unknown reason, it cuts the nautilus desktop window at a width of 1024 instead of 1280., which makes the right of the screen a warp zone...

(For the record, I have a Radeon Mobility 9200 with the x.org drivers ; I should try with the proprietary ones)

Update : The slowness might be related to this message:
libGL warning: 3D driver claims to not support visual 0x4b

Update 2 : According to this comment from Michel Dänzer, the above message is only cosmetic.
I solved my slowness problem ! I just needed to switch back to XAA instead of EXA as an acceleration method (Option "AccelMethod"). There still remains the geometry problem... even fullscreened windows are limited to a width of 1024, though the gnome panel is correctly at the right-most of the screen (I use a vertical panel on the right of the screen).
There is also a cosmetic problem when switching from "normal" use to GL use (like cube rotation, window moving with wobbly, etc.): the window contents are kind of blured, but there's nothing we can do about that, except have the windows blured in the same way in the first place.
Ah, and scrolling in windows is more sluggish, now.

Update 3 : After some tracing of compiz, and some reading of the source code, it appears that the width limit problem is indeed due, as suggested by Hez in the comments, to GL_MAX_TEXTURE_SIZE being 1024 (you can display it with glxinfo -l | grep GL_MAX_TEXTURE_SIZE). I wonder if, as suggested by erich, there is really an environment variable to change that...

I'm back from Japan. Time went too fast... Met a lot of people we hadn't seen for a while, had a great time. Only problem is that I'm totally jetlagged. Woke up at 3am this morning, and decided to actually do something after trying to sleep some more for an hour.

The downside of holidays is the 4000+ mails (excluding spam) that got in my mailbox. I've already gone through most of the new bug reports and have been able to vote for the last GR that was issued while I was away.

One of the most annoying problem that was raised during my vacation is this Firefox trademark issue. We've been avoiding to change the package name for a while. We got agreements to use the Firefox name when we had to drop the "Mozilla" part of "Mozilla Firefox", and now it seems they (again) changed their mind.

I really think we should go with the iceweasel name because this name is already widespread as the "debian may rename firefox this way" name. It is even in wikipedia.

On other news, we bought a MacBook and a Nikon Coolpix S6 for Miki, and a (already broken) PSP as well as some books for me. I'll write more on these in coming posts.

I'm leaving for Japan in a few hours.

I have been careful not to leave too much mess in my packages for this vacation period, so all should be running just fine until I come back.

Closing all comments and trackbacks to avoid spam.

Yesterday, I uploaded Firefox 2.0b2 in experimental. Please give it a try and checkout if some of the bugs in firefox are fixed by this new release. Same kind of help welcome with the version in unstable. When the bug count is more than 200, it gets painful to do bug triage, so any help on that matter will be very much appreciated by Eric and I.

In other news, work has started on seamonkey. Unfortunately, I'll be away for a little while, so I'll have to leave quite an amount of the work to Alexander Sack, but I'm pretty sure he'll be able to handle it. Anyways, we hope to be able to work out a full featured package for etch so that people using mozilla on sarge will get a correct upgrade path.

I also uploaded yesterday a new xulrunner release that (finally) provides some of the NSS tools, so that administrators can handle keys/certificates databases for mozilla products. It is still in NEW, but should reach unstable soonish (let's just hope the ftp-masters won't reject the new package).

The metros from the world I've used:

Actually there are some cities listed on the original site I've been to, but didn't take the subway, like Toulouse, Rennes, Amsterdam, Barcelona, Stockholm, Fukuoka, Sendai...

Kernel being dumb by being smart

Memory cache is a good thing to speed up a computer, but it's a PITA when it comes to stopping playing a DVD or a big video file.

The kernel usually keeps in memory cache data that has been read from the hard drive so that it can get it faster next time the same data is accessed. I don't know exactly on what grounds fragments are decided to be kept or not, but observation shows that playing a DVD or a Xvid file makes the cache grow more than significantly. Moreover, while playing the video, the other software from the desktop (nautilus, for example), is not used, thus, the kernel decides it can swap it to disk virtual memory.

Then, when you stop reading your video and want to come back to normal activity, your desktop is damn slow for some long seconds. That makes the experience a real pain.

Overuse of network bandwidth

I noticed that when I switched from a samba network share to an apache based DAV one: reading a video file from the DAV share with totem-gstreamer filled my apache logs very quickly. It seems gstreamer/gnomevfs seeks a lot in the file to play the video. Instead of making one HTTP request, it does several thousands, each time requesting again data it already received.

As a result of that, it usually takes up to 1 mega byte per second to play a video that has a bitrate of 1 mega bit per second, with a nice effect of network congestion when the bit rate grows for detailed sequences.

Do you find it normal that it takes 5 minutes to download a 45 minutes file at 2~3 MB/s, and 1MB/s for 45 minutes to play it directly from the network ?

Well, now, gstreamer 0.10 doesn't even support reading from HTTP/DAV, but the problem remains the same when reading via sftp with gnomevfs.

After quite some work on packaging it, Firefox 2.0b1 is finally being uploaded to experimental.

It is linked to the system libmyspell instead of the bundled one, and can use system dictionaries like Thunderbird already does. I'm also working on using the system libsqlite3, but it first requires some build changes in the debian sqlite3 package and some more work to see if it's really feasible... you see, they like to take external libraries and modify them so much as adding symbols, changing some internals... and these changes only exist in the mozilla codebase... (the 2 main examples of that being expat and sqlite3)

It also includes a working DOM Inspector which upstream didn't include in their release because they are in the process of moving the component in the core.

I also had to fix some more the build system so that some things would be installed by make install (they tend to forget it), others would just be installed (mistakenly removed rules...) or make clean would do its work: cleaning (they tend to forget to flag files for removal when they create it in a Makefile). All that makes me wonder what their review/super-review thing is worth.

Anyways, please give it a try, especially if you reported a bug on earlier versions, it would be helpful if you closed bugs that are fixed by this release (don't forget the 'Version:' in the closing message so that the BTS version tracking would do its work).

Update: Upstream Firefox 2.0b1 has a working DOM Inspector. It only appears it just doesn't build correctly the way we build Firefox... might be some missing changes to the Makefiles. Again. *sigh*

Update 2: It was trickier: missing something to make the inspector symbols public instead of having a hidden visibility...

Update 3: It was actually my fault. /me goes hiding under a rock. And I managed to remove a comment to this post when removing spam... *sigh*. I think I need to take a break.

Then, help spread Firefox and get creditted in Firefox 2. Now, what I think is really amazing is how much effort they spend to credit those helping to spread Firefox, but not those helping to fix it.
Don't get me wrong, I don't care about being creditted myself for the several patches I sent and more, but I'm pretty sure a lot of people who sent patches like me are not creditted either.
It's already a PITA to get patches applied (some patches are still waiting to be reviewed or applied)...

Update: At least, they credit in the CVS logs.