Author Archive

Or, if you really want to, be careful that, if /usr/lib/iceape/chrome is a directory (and not a symbolic link), your working directory is /usr/lib/iceape/chrome, or you will end up with the content of your current directory in /usr/share/iceape/chrome, which may be a big issue if you run apt-get from /.

If /usr/lib/iceape/chrome is a symbolic link, no worry, just ignore this message.

Thank you for your attention, and very sorry :(

Update : That's in such cases that you'd like special crafted tools to rebuild packages without the need to rebuild the whole thing when it comes to just change maintainer scripts (pre/postinst, pre/postrm...). Fortunately, I have pbuilder configured with ccache, but that doesn't help the buildds with their build job.

I don't know if I should be proud of this...

Yeah, I know, I wrote it in the first place, but still...

I finally gave a try to my pervert solution.
Using unionfs led to a kernel oops on the service console (which means it brought VMs down, too).
funionfs, as a fuse filesystem, could not lead to the same result, but i had some issues with it:

• result of lseek() being put in an int variable while _FILE_OFFSET_BITS is set to 64... impossible to seek at more than 2GB of data, which ext3 recovery needed to do...
• when opening read/write a file (which the loopback device does), it attempts to open read/write the original file on the read-only directory, which leads to EBUSY when the file is opened elsewhere (i.e. by VMWare ESX Server).

Once these issues solved, it ... doesn't work. The problem is funionfs doesn't handle files that are partially written to: it creates a new file in the r/w directory, and writes exactly what has been requested, creating a sparse file. On subsequent reads, it gets the data from that sparse file. This means most of the data, except data that has been written, is zeroed.
I'm afraid there's nothing better to do than take a somewhat arbitrary chunk size, write to the sparse file by chunks (reading missing data from the original file if necessary), and keep a bitmap of the chunks that have been written to the new file...
I should check what the original unionfs does with this.

During the past month, I've been working on migrating some servers onto a VMWare ESX Server. I did test VMWare Workstation a long time ago, and have had a VMWare Server on my work laptop since it has been freed (as in beer), but ESX Server is something else.

It seems to me, though, that except it can run unmodified OSes without VT/Pacifica technology, it is not technically superior to what you can do with Xen and other free software. For instance, it may be possible to do better virtual switching setups with "standard" linux bridges and ebtables. But from the administrator perspective ESX Server has the advantage of its administration console. I'm still waiting to see a nice and featureful free (as in speech) configuration software for Xen (or maybe, dear lazyweb, could you show me some good urls I missed).

We don't have the full VMWare Infrastructure, though, so I can't speak of VMotion or VMHA, but that sounds neat, on paper. I never tested Xen migration either, so, I won't say it's better :)

Anyways, VMWare ESX Server is a pretty good product, but there are quite a few quirks, or even really painful misfeatures:

• Sometimes, the console shows more items than what the user is supposed to see. Though you still can't act on these, you wouldn't expect them to show up (for example, I sometimes see items that are only supposed to appear if you have a Virtual Center, which we don't have).
• If you rename a virtual switch, you have to go through all the VMs that were connected to it to change their network configuration accordingly.
• You now have to edit the settings to connect/disconnect the CD drive or the network. That used to be less annoying with the console software in version 2.5.
• You can't display more than an hour of performance graphs without a Virtual Center. Pretty painful when you only have one ESX server. (also known as the "buy more of my products business plan")
• VMFS doesn't maintain coherency between readdir() and stat(). The d_ino readdir() returns in its struct dirent and st_ino in stat()'s struct stat don't match. This is especially annoying with Legato Networker, which checks that coherency and doesn't save files that "changed inode". To circumvent this misfeature, I installed fuse and slightly modified libfuse and the fusexmp_fh example so that I can mount a mirror of /vmfs with coherent inodes. Now VM disks can be safely saved.
• It's impossible to create a loopback device on a file residing on VMFS. The filesystem doesn't accept the LOOP_SET_FD request. This means that, while the VM disks files are basically raw disk images, you can't directly mount the filesystems on the service console with a loopback device. Again, with the modified fusexmp_fh program, this is now possible.
• While there was a (quite broken, as in kernel freeze) way to mount filesystems from VM disks with ESX server 2.5 (which we also tested before upgrading to version 2) with vmware-mount, the only "official" way I found to do this with version 3 is to use vcbMount, which requires a VMWare Virtual Consolidated Backup server (not really free neither as in speech nor as in beer ; seems to be another instance of the "buy more of my products business plan"), and an extra server connected to the SAN.
• ...

As said above, we can now setup a loopback device on the VM disk files (which needs a little trickery with offsets to get the partitions positions right, but that's not very hard). While it's possible to mount filesystems from an offline disk this way, it's not a good idea to mount an ext3 filesystem from a running VM, because the filesystem is flagged for recovery, and the service console kernel would want to replay the journal, which may have nasty side effects. I don't know for NTFS yet.

There may be a solution to "cleanly" mount filesystems from an online disk, though (not yet tested):

• Snapshot the VM which the disk is on. After that, the -flat.vmdk file is frozen (only if it's the first snapshot).
• Use an unionfs or funionfs (over fuse) to keep the real -flat.vmdk file readonly but still can write on it, so that the service console kernel can replay the journal on the writeable part of the unionfs.
• Loopback mount partitions from the image in the unionfs.

That would be pretty pervert (ext3 over loopback over unionfs over vmfs), but should just work. I'll post a detailed procedure.

Today, Sun Microsystem announced that Java is going to be free, released under the GPL. That's amazing news, but I'd like to talk about another thing here.

Duke, the Java mascot, is also being freed, under BSD license. Sun Microsystems is proving here that a trademarked logo can be free as in speech.

The Mozilla Corporation could take a lesson, here.

Joey, I can tell you such people exist (people whose power was cut in order to limit the impact), because I am one of them. No power for something like 45 minutes in all the neighbourhood at least, for what I know, and press reported 5 millions people without electricity for France alone. ADSL came back some 30 minutes after electricity, so everything was back to normal by 23:30 GMT+1. We also had a 'micro-blackout' earlier the same day, a bit before mid day, if I recall correctly, which made the external hard drive connected to my server be stuck during an I/O. Fortunately, powering it off and on solved the problem, and the filesystem is okay. The server itself being an old laptop, it didn't lose its uptime, but without network, it was quite useless...

I was preparing security updates for all the Mozilla® products in stable and needed some feedback from their security team...

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  security@mozilla.org
    SMTP error from remote mail server after RCPT TO:<security @mozilla.org>:
    host dm-mail02.mozilla.org [63.245.208.176]: 554 5.7.1 Service unavailable; Client host [xx.yy.zz.tt] blocked using dnsbl.sorbs.net=127.0.0.10;
+Dynamic IP Addresses See:
    http://www.sorbs.net/lookup.shtml?xx.yy.zz.tt

Damn. And my ISP relay decided to reject my mail. Do we have a relay for DDs in need somewhere ?

Update: It seems retrying was enough, there might be a problem with one of my ISP relay servers...

or How Mozilla® Corporation is FUDing on Debian. Again.

This time, Christopher Beard, Mr Mozilla® Marketing is talking about Firefox® in Ubuntu, that it's great, Ubuntu is a good boy, that it cooperates with Mozilla®, and that by cooperating, it can use the great Firefox® name and logo.

To be honest, I don't care that Ubuntu calls Firefox® Firefox® instead of Iceweasel or whatever. I don't care that Ubuntu doesn't care about freedom as much as Debian does. I could not care less.

But, indeed, I do care about (yet other) false claims about Firefox® in Debian.

Let's see what Christopher has to say about it:

I understand that Ubuntu is based upon Debian. Is that the same or different than the IceWeasel browser that Debian is shipping with their latest release?
It's different. The patches that Debian applied to the Mozilla source code (which then resulted in their IceWeasel product) are more significant in scope than those in what Ubuntu is shipping (and branding as an official Mozilla Firefox release). Firefox in Ubuntu represents a somewhat more modest set of divergences from original Mozilla source code.

Let's check out what it is about. And as I don't want people to doubt my words, I'll give you, readers, the ability to check for yourself what it is all about.

First, please download the latest currently available patch for Firefox® 2.0 beta 2 in Debian. It has been in experimental for some weeks now. It is a bit different from the patch I described earlier, so I'll also tell you what has been changed since this 2.0b2 patch:

• security/coreconf/rules.mk is not patched for the perl dependencies thing any more because the patch (taken from bugzilla #325148) has been applied in Firefox® 2.0rc1
• The patch from bugzilla #336056 has been applied because the directory in which we would build the 2.0rc1 version contained a ~ character, which would make the build fail because of this bug.
• The patch from bugzilla #294879 has been applied for obvious reasons. It has been applied later in the Firefox® 2.0 release process.

(Also note that another change has been done since then, which is actually reverting a previous patch on gfx/src/gtk/mozilla-decoder.cpp, that was adding code that became dead code when we changed the way to fix the bug.)

Next, please download the official and supported Firefox® diff from Ubuntu.

Uncompress both these diff files, and create two directories (let's call them ubuntudiff and debdiff) which will contain the individual patches for each file. To fill these directories, please use the following commands:

$ filterdiff --strip=1 firefox_2.0+0dfsg-0ubuntu3.diff > ubuntu.diff
$ filterdiff --strip=1 firefox_1.99+2.0b2+dfsg-1.diff > deb.diff
$ cd ubuntudiff
$ splitdiff -d -a ../ubuntu.diff
$ cd ../debdiff
$ splitdiff -d -a ../deb.diff


If you don't have the splitdiff and filterdiff utilities, you can get them from the patchutils tools (you will also need another of these tools later).

Now, let's have fun with these split patches...

Files that are only patched in Debian: (excluding any file that would be in the debian subdirectory, that contains maintainer scripts for build and installation)

$ LANG=C diff -ru debdiff/ ubuntudiff/ | grep "^Only in deb" | grep -v debian | wc -l
6


So, that's 6 files that Debian patches that Ubuntu doesn't. Let's check what they are:

$ LANG=C diff -ru debdiff/ ubuntudiff/ | grep "^Only in deb" | grep -v debian

(reordering result for convenience)

Only in debdiff/: browser_base_content_aboutDialog.xul

Adds rows=5 to the user agent textbox so as to display the user agent string uncut by default

Only in debdiff/: content_html_content_src_nsGenericHTMLElement.cpp
Only in debdiff/: content_html_content_src_nsHTMLInputElement.cpp
Only in debdiff/: dom_src_base_nsGlobalWindow.cpp

It's a patch I submitted in bugzilla #343953 and that got applied in Firefox® 2.0. No surprise the patch is not applied on Ubuntu.

Only in debdiff/: extensions_reporter_Makefile.in

Patch I submitted in bugzilla #354413 and that got applied in Firefox® 2.0.

Only in debdiff/: security_coreconf_rules.mk

Patch from bugzilla #325148 that got applied in Firefox® 2.0 (see above), and a small patch to build the NSS library with debugging symbols (put -g in CFLAGS).

That leaves only 2 small patches : CFLAGS = -g added to security/coreconf/rules.mk and rows=5 to browser/base/content/aboutDialog.xul

Files that are only patched in Ubuntu: (same exceptions as for Debian)

$ LANG=C diff -ru debdiff/ ubuntudiff/ | grep "^Only in ubuntu" | grep -v debian | wc -l
45


Yes, that's right, that's 45 files that Ubuntu patches that Debian doesn't. Most are windows sizes and similar things that upstream can't get right because they are values adapted to Windows, but that also includes some changes to the code and some other things.

Let's now check differences in files that are patched in both. It's a bit of shell black magic, but you can check by hand that it does nothing wrong :

$ LANG=C diff -ru debdiff/ ubuntudiff/ | filterdiff -p1 -x configure -x debian"*" | lsdiff --strip=1 | while read f; do diff -u debdiff/$f ubuntudiff/ | awk "! /^---|^\+\+\+|^ |^[-+]*\@\@/ { print \"$f\"; exit}"; done

That gives a list of patch files that have more differences than line numbers changes, and that do not apply to the debian directory or the configure script (which is generated from configure.in), which is what we really want to compare here. You can take this list and run interdiff between these files from the ubuntudiff and debdiff directories. I'll explain for you what these differences are:

• Makefile.in: Ubuntu adds a line in order to install the NSS include files,
• browser_app_Makefile.in: Patch from bugzilla #314927 applied by Debian
• browser_app_profile_firefox.js: (interdiff fails because the changes apply to different versions of the file) Ubuntu changes the homepage, and sets profile.allow_automigration to false,
• config_autoconf.mk.in: Ubuntu changes includedir and idldir,
• configure.in: Ubuntu changes MOZ_APP_DISPLAYNAME, and adds some echos,
• gfx_src_gtk_nsFontMetricsXft.cpp: Ubuntu sets FC_ANY_METRICS to some patterns,
• intl_lwbrk_src_nsJISx4501LineBreaker.cpp: Patch from bugzilla #161826 applied by Debian for sparc64, which is not an architecture supported by Ubuntu,
• modules_libpref_src_init_all.js: Ubuntu changes some default fonts from serif to sans-serif, while Debian changes fonts for serif, sans-serif and monospace (setting to generic names instead of Times, Helvetica and Courier) ; I think both should be applied in Debian, actually. Ubuntu also sets dom.event.contextmenu.enabled to false,
• security_nss_lib_freebl_unix_rand.c: (interdiff fails because the changes apply to different versions of the file): both patches have the exact same effect, but are different due to changes to original file between 2.0rc1 and 2.0 final.

Overall, Ubuntu applies the same set of patches as Debian, plus some more. A somewhat more modest set of divergences, huh ?!?

For what it's worth, Ubuntu, like Debian, builds its Firefox® with flat chrome and pango enabled.

What's different in the shipping Ubuntu version of Firefox than the proposed Debian version of Firefox (that didn't ultimately ship)?
Technically, changes include fixes to the User Agent string and the feed preview, a well as addressing issues of coherent branding. More significant than any specific difference in code, however, is Ubuntu's commitment to work together with Mozilla and our community on releases going forward to insure product quality and integrity.
Why are you working with Ubuntu when you wouldn't work with Debian?
We did try to work with Debian and would prefer a situation in which we work together. Ultimately, Debian took a position that was consistent with their own policies, and not compatible with some of the exceptions to Mozilla trademark policies that we offered. While we understand and respect their decision not to work with us under our branding guidelines, Mozilla believes that brands like Firefox are important for consumer protection. In any event, Ubuntu developers are working closely with Mozilla developers to insure product quality and features that are what users expect when they use Mozilla Firefox, which means that they'll ship (and will continue to ship) a fully branded version.

Reading between the lines, that means Debian is not working with Mozilla. It's not like we're submitting patches. No. Never. Ever. I'm also glad to hear from Asa Dotzler, in comments to Mr Beard's article, that this great collaboration with Ubuntu will lead to patches applied to Firefox® (I guess the paid Canonical employees having more time to deal with Mozilla® than the volunteer Debian maintainers may have helped, especially considering they didn't have to do all what we already prepared). Anyways, it's not like some of the patches we sent got applied.

So, while I'm at it, here is an exhaustive list of the bugs where we took or sent the patches that are applied to Iceweasel: #51429, #161826, #252033, #258429, #273524, #287150, #289394, #294879, #307168, #307418, #314927, #319012, #322806, #323114, #325148, #326245, #330628, #331781, #331785, #331818, #333289, #333308, #343953, #345077, #345079, #345080, #345413.

These don't cover the following patches (see the rationale for these in my previous article):

• security/manager/Makefile.in, security/nss/cmd/shlibsign/Makefile: Don't build the shlib signatures, see the rationale in my previous article,
• security/nss/cmd/shlibsign/manifest.mn: Don't build the mangle utility,
• browser/app/Makefile.in: Force linking against libxpcom.so despite -Wl,--as-needed,
• browser/app/profile/firefox.js, gfx/src/gtk/fontEncoding.properties, modules/libpref/src/init/all.js: Preferences changes,
• browser/base/content/aboutDialog.xul: That's one of the patches that Debian applies that Ubuntu doesn't. See above,
• config/autoconf.mk.in: Remainings of an old patch for pangocairo, which is now useless, and setting of mozappdir,
• config/rules.mk, configure.in: Patch from Thiemo Seufer to increase stability and performance on mips, useless upstream until bugzilla #258429 is fixed, but on my to_send list,
• extensions/inspector/Makefile.in: Something that should be added to #331785, but well, it's WONTFIX, anyway,
• layout/build/Makefile.in, layout/build/nsLayoutModule.cpp: Change to the Gecko string,
• modules/libpref/src/nsPrefService.cpp: Add a preferences directory for /etc/firefox/pref,
• widget/src/gtk2/nsWindow.cpp: Extended mouse buttons support, on my to_send list,
• configure.in, xpcom/reflect/xptcall/src/md/unix/Makefile.in: Basic patch for bugzilla #343975,
• configure.in: Check for pangoxft.

It's so great to spend a great amount of time on a package, send patches, try to understand how things work to get patches applied, and yet, see such denial and false claims about our work. So please, Christopher, Asa, and the others, just stop talking about Debian, it will be better for everyone.

PS for Rob in comments out there: No, ColorZilla won't work on Ubuntu, because of the ABI incompatibility I explained in my previous entry, that Mozilla® doesn't seem to care much about.

Interestingly, I see in my apache logs quite some hits from Iceweasel, even though we haven't uploaded an Iceweasel package yet. A few are coming from the gnuzilla Iceweasels, but some others obviously come from people changing their User-Agent string on purpose:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061003 IceWeasel/2.0
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060830 Iceweasel/1.5.0.7 (Debian-1.5.dfsg+1.5.0.7-2)
(...)