February 5th, 2010

broken_arch -= 2

The xulrunner test suite now passes on sparc, involving a fix for an existing bug, and a new bug report.

Next target is powerpc, where, interestingly, the test suite only failed 3 tests on the porterbox, where the buildd failed 58… And contrary to sparc, the failures don’t involve crashes.

Update: powerpc is now fixed, too, with a little help from luck and good timing: the 3 failing tests had all the same origin, and it was fixed a few months ago in upstream trunk.

2010-02-05 19:40:25+0000

xulrunner | No Comments »

February 4th, 2010

xulrunner 1.9.1.6-2 diff stats

As part of preparing xulrunner 1.9.2 (which would lead to Iceweasel 3.6), I have gone through all the patches currently applied to the latest xulrunner release, to keep track of what should be upstreamed, what needed feedback, what patches I needed to update in upstream bugzilla, etc.

As I have talked about our differences with upstream on a few occasions already, and as I was doing this grunt work anyway, I thought it would be nice to make the results public.

First, a few reference numbers (excluding changes to generated configure files):

  • Changes between upstream 1.9.0.1 and Debian release 1.9.0.1-1: 85 files changed, 1163 insertions(+), 644 deletions(-)
  • Changes between upstream 1.9.0.16 and Debian release 1.9.0.16-1: 86 files changed, 1177 insertions(+), 634 deletions(-)
  • Changes between upstream 1.9.1 and Debian release 1.9.1-1: 70 files changed, 770 insertions(+), 363 deletions(-)
  • Changes between upstream 1.9.1.6 and Debian release 1.9.1.6-1: 76 files changed, 796 insertions(+), 380 deletions(-)
  • Changes between upstream 1.9.1.5 and upstream 1.9.1.6: 165 files changed, 3094 insertions(+), 1387 deletions(-)
  • Changes between upstream 1.9.1 and upstream 1.9.1.6: 1263 files changed, 64322 insertions(+), 67376 deletions(-) (though more than half of that relates to upstream bump of sqlite3 and the vorbis stack)

A few observations on the above data:

  • There are less changes between upstream and Debian than between two consecutive upstream versions.
  • Debian changes only account for changes to the xulrunner package, i.e. it excludes changes to Iceweasel itself, or to nspr or nss, but these are far less important in number.
  • The number of changes applied decreases when switching to a new upstream branch. This is mostly due to patches getting applied upstream.
  • Debian patches on a given branch are pretty stable. In other words, most of the work is done on the first release of the branch.

The latter used to be true, but is not anymore: xulrunner 1.9.1.6-2 added a lot of changes and is now up to: 98 files changed, 1107 insertions(+), 517 deletions(-).

What happened ? will you ask me. A lot happened: the test suite, attempts at correctly installing C++ headers and IDL files, bug fixes. Work has also been done such that make clean/distclean doesn’t leave stuff around and that xulrunner can be properly built twice in a row.

Differences between 1.9.1.6-1 and 1.9.1.6-2 look like this: 31 files changed, 341 insertions(+), 167 deletions(-).

Some were stolen from bugzilla (13 files changed, 162 insertions(+), 70 deletions(-)):

Many others were sent:

A few others were filed without a patch, as I felt a proper upstreamable patch needed discussion (3 files changed, 16 insertions(+), 3 deletions(-)):

A few changes are related to the way we build and how we run the test suite (5 files changed, 35 insertions(+), 18 deletions(-)):

  • Disable python-xpcom tests for now.
  • Disable javaxpcom tests at build time when DEB_NO_JAR is unset.
  • Synchronize config/rules.mk and js/src/config/rules.mk for check-sync-dirs.py (we used to localize the changes required in each config/rules.mk, but as we now run make check they need to be synchronized)
  • Workaround for https://bugzilla.mozilla.org/show_bug.cgi?id=455238

Finally, a few were related to the Debian changes history (2 files changed, 1 insertions(+), 26 deletions(-)):

  • Remove –enable-system-lcms check, which somehow resisted merges with upstream
  • Properly clean xulrunner/installer/*.system.conf

Going through the rest of the changes between upstream and the latest Debian release, we can split in 5 categories of changes:
Those that were picked from upstream, or sent and eventually applied in 1.9.2 or trunk (12 files changed, 68 insertions(+), 41 deletions(-)):

Those that were picked from bugzilla or sent there, but are not applied upstream for various reasons (29 files changed, 138 insertions(+), 209 deletions(-)):

Those that were reported but for which I wanted feedback for a proper fix, yet a patch was applied in Debian because this was necessary (6 files changed, 22 insertions(+), 13 deletions(-)):

Those that are yet to be sent to bugzilla (15 files changed, 111 insertions(+), 54 deletions(-)):

  • xulrunner-config: Give more appropriate cflags and libs
  • Install applications in /usr/local/lib instead of /usr/lib
  • Unhide release notes link in about: but only if app.releaseNotesURL is defined
  • In about:, Don’t put an about:blank link when there is no vendorURL defined
  • Don’t use static strings when setting environment variables
  • Exec instead of uselessly forking in xulrunner launcher script
  • Disable optimization on alpha for the url-classifier component (this will probably wait for the test suite failures on various architectures to be fixed)
  • Build js shell and xpcshell against system libreadline
  • Don’t export js_SetTraceableNativeFailed, which is only used internally
  • Increase stability and performance on mips and mipsel

And finally, the changes that are either Debian specific or not deemed upstreamable (30 files changed, 460 insertions(+), 77 deletions(-) ; this can sound huge, but see the details below):

  • Feature changes:
    • Disable APNG support when system libpng doesn’t support it (6 files changed, 71 insertions(+), 10 deletions(-) ; mostly #ifdef’ing parts of the code related to animation)
    • Use application.ini from where the xulrunner-stub lies (1 files changed, 14 insertions(+), 3 deletions(-) ; This one may be dropped and replaced by something totally different, possibly upstreamed)
    • Don’t register plugins if the MOZILLA_DISABLE_PLUGINS environment variable is set (1 files changed, 25 insertions(+), 0 deletions(-) ; very useful to isolate plugin-related crashes ; I don’t think it’s worth upstreaming considering the upcoming plugin-in-separate-process work)
    • Remove (un|)registering system (1 files changed, 0 insertions(+), 43 deletions(-) ; xulrunner versions that are installed by a package manager don’t need to be registered, since the package does it already ; a variant that conditionally removes it may be upstreamable)
  • Preferences changes:
    • Set javascript.options.showInConsole (1 files changed, 1 insertions(+), 0 deletions(-))
    • Set DPI to system settings (1 files changed, 1 insertions(+), 1 deletions(-))
  • Cosmetic changes:
    • Install loading_16_grey.gif in classic.jar, and add an override for loading16.png (1 files changed, 2 insertions(+), 0 deletions(-) ; Since we don’t support APNG, we replace the most used one by its (ugly) GIF equivalent)
    • Add links for about:bugs and about:README.Debian in about: (3 files changed, 19 insertions(+), 0 deletions(-) ; I’d like to make that something living in debian/extra-stuff)
  • Integration changes:
    • Add another preferences directory for applications: defaults/syspref (1 files changed, 2 insertions(+), 0 deletions(-))
    • Add an rpath to libpyloader.so and _xpcom.so (2 files changed, 2 insertions(+), 0 deletions(-) ; allows python xpcom to work out of the box)
    • Forward-port nsIBadCertListener from 1.8 (4 files changed, 266 insertions(+), 1 deletions(-) ; This is necessary for at least galeon and kazehakase, because the new interface is useless for embedding applications)
  • Build-related changes:
    • Allow to override the PYTHON_SO variable (1 files changed, 1 insertions(+), 1 deletions(-))
    • Put the crmf library before the NSS libraries (1 files changed, 1 insertions(+), 1 deletions(-))
    • Allow to build java jar files in 2 pass (2 files changed, 8 insertions(+), 2 deletions(-))
    • Avoid libxpcom being excluded from linked libraries by -Wl,–as-needed (1 files changed, 2 insertions(+), 0 deletions(-))
    • Ignore system libjpeg, libpng and zlib version checking (1 files changed, 3 insertions(+), 3 deletions(-))
    • Force to not use -fshort-wchar (1 files changed, 1 insertions(+), 1 deletions(-))
    • Add soversion to libmozjs (2 files changed, 19 insertions(+), 2 deletions(-) ; useful for couchdb, libjavascript-perl and others)
    • Don’t build example component (1 files changed, 0 insertions(+), 1 deletions(-))
    • Don’t install system profile (1 files changed, 0 insertions(+), 2 deletions(-))

Note, the numbers in the various diff stats obviously don’t add up, since some changes overlap.

All that information doesn’t account the few additional components added in debian/filemonitor and debian/extra-stuff, that account for nearly 600 lines (excluding licensing boilerplate), but I’ll talk about these in another post.

This analysis also helped spotting another harmless merge error (the first one was spotted a few weeks ago and just left the –enable-system-lcms around, without any effect): a variable replacement in a Makefile that doesn’t have any effect, since the 2 variables have the same value. Only a pointless 1 line change.

2010-02-04 12:52:14+0000

xulrunner | No Comments »

February 3rd, 2010

Sad reality

One of the major changes in the latest xulrunner upload was to enable a great part of the test suite.

The result is stunning: crashes on alpha, armel, powerpc and sparc.

Update: Also failed on mips. (though interestingly, it worked on mipsel)

2010-02-03 08:05:09+0000

xulrunner | 3 Comments »

January 30th, 2010

Feeling alone

The EFF is running an experiment to see how you can be identified with your web browser, without the use of cookies nor your IP address.

I’m apparently currently the only Iceweasel 3.5.6-1 amd64 (with an english locale) user who participated.

I feel alone. One in 268977 so far. That’s more than 18 bits of entropy.

2010-01-30 10:21:43+0000

firefox | 7 Comments »

January 27th, 2010

Ubuntu switches default search engine. Will Google react ?

Many have commented on the event.

As I noted in a reply to Romain Beauxis’s post, the only reason Google was the default search engine in Ubuntu, and is still in other distros is because Mozilla has a revenue deal with Google. Which means that actually, Mozilla might be getting money from Debian, Ubuntu and other distros’ users actions on the Google search engine. (maybe not from Debian, though, because of the search url including iceweasel instead of firefox). Now, at least, Ubuntu will be the one getting the money.

One has to know that these revenue deals probably don’t cost a dime to Google and Microsoft (through Yahoo), because they may be “transferring” revenue they get from the extra advertising revenue they can get from these users being using their search engine as default.

Anyways, much more interesting to know is how Google is going to react on other services: some core functionalities of Firefox (geolocation, safe browsing) are based on Google services. These are actually a possible problem for Debian, depending on the agreement between Mozilla and Google, and I have yet to address the RC bug I filed on my own package about these.

Now, since Google is going to get less advertising revenue from Ubuntu users in favour of one of its competitor, why should they provide the geolocation and safe browsing to these users ?

2010-01-27 17:02:41+0000

firefox | 8 Comments »

January 20th, 2010

ssh root@guitar

After the coffee machine, would you have expected to be able to login on a guitar ? Well, now, you can, on the Misa digital. It is not only a digital guitar, but it runs (Gentoo) Linux, and… an ssh server.

2010-01-20 17:14:48+0000

miscellaneous, p.d.o | 2 Comments »

December 31st, 2009

About names and international affairs

Christian writes about the nightmare of using the proper name for people in an international context. I’ll add that even in the same country/culture, you can have a hard time, because of another factor: the generational context.

People don’t necessarily address other people from their generation the same way as they would address people from different generations. And these “rules” may also vary when people age. Even people from the same generation can have different ways to address people.

All in all, naming someone is complicated everywhere, though it is more complicated in international context.

I’ll also add that there are at least two persons involved in a conversation, and that while it is nice that the sender tries to make an effort to address a person the proper way, the recipient should also not take it bad when someone from far away uses the wrong name, and don’t make a fuss about it. That’s called tolerance.

To give an example that is not about names, but about such tolerance, President Obama recently made a visit to the Japanese Emperor, and bowed before him. If you are living in the US, you probably heard about that, because the media there made a fuss about the US president bowing. It so appears that by japanese standards, he indeed did bow too deeply. But the japanese didn’t care much. He’s not japanese, he doesn’t have the cultural background, and therefore can be wrong. At least he tried. What actually made news in Japan is the US news making a fuss about it.

2009-12-31 09:33:58+0000

p.d.o | 1 Comment »

December 19th, 2009

Iceweasel bug triaging

I’ve spent a few hours going through all the unclassified important bugs assigned to iceweasel. This resulted in

  • 6 confirmed bugs,
  • 16 where the reporter is asked for something,
  • a few merged,
  • another few reassigned to other packages,
  • and around 50 bugs closed.

In the closed bugs, there were several kind of bugs:

  • the bug log shows that the bug eventually disappeared or was not a bug, but the bug was still opened,
  • the bug has been known to be fixed for a while,
  • the reporter is unreachable and the bug is unreproducible,
  • the bug has been spammed by several different and unrelated “me too”s, leading the bug to being a huge mess where you don’t know what was the problem to begin with (there were 2 such bugs, if I recall correctly), in which case I closed the bug, copying everybody and inviting to file individual bugs after confirming with newer versions.
  • not a bug at all.

It will feel good when it will be visible on the bug graph.

Still 500+ to go… *sigh*

Who wants to jump on the bandwagon ? ;)

2009-12-19 21:34:30+0000

firefox | 6 Comments »

December 9th, 2009

VMware + X.org + gnome-screensaver + strong password = FAIL

Guess what happens when you use software that can fuck up your keyboard mappings (VMware Remote Console), in combination with software that uses these mappings to be able to switch back to a text console (X.org) and a screen saver that locks your screen (gnome-screensaver, but that would worl equally well with xlock or anything else similar) ? A recipe for FAIL.

It so happens that VMware Remote Console, and apparently other VMware products such as Player or Workstation not only are unable to do anything useful with special keys (try installing Debian without the arrows keys, for example), but they are also able to remap keys (such as ctrl, shift and caps lock) to nothing.

It also happens that X.org uses its keyboard mappings when dealing with the ctrl+alt+Fn key combinations that allow to get back to a text console. Yes, that means you can’t switch to a text console after VMware fucked up your keyboard mappings.

On top of all that, add a X session locking program, that won’t allow you back until you type your password, and a password that, well, you just can’t type without shift of caps-lock, because it is somehow strong. The X session locking program won’t allow you to fix your keyboard mappings, you can’t switch to a text console either, and you can’t unlock for obvious reasons.

The only solution that didn’t involve a reboot or losing everything under the X session was to ssh in, change the password to one that can be typed without shift and unlock.

It is said on the interwebs that adding “xkeymap.nokeycodeMap = true” in the ~/.vmware/config file solves the issue. At least, it works for the arrows. I’ll see if it also prevents the special keys to be remapped.

2009-12-09 00:13:15+0000

miscellaneous, p.d.o | 5 Comments »

December 2nd, 2009

Removing a VMFS extent

Until vSphere 4, the only way to add space to an existing VMFS was to add an extent. This means creating a new partition, most of the time on a new LUN, and extend the VMFS there (vSphere 4 is now able to resize a partition on a grown LUN). This is somehow equivalent to adding a physical volume in a volume group under LVM. But contrary to LVM, once you added an extent to a VMFS, it is impossible to remove it.

Well, until now, it was.

I just pushed my lvm branch of vmfs-tools (get a git snapshot tarball), which includes a new tool named vmfs-lvm, allowing to just do that. For the moment, the tool is not cluster-safe, which means you’d better run it on an offline VMFS (i.e. make sure no server is using it). Data should not be at risk because the tool checks the removed extent doesn’t contain any data, but it also assumes the filesystem is in a consistent state beforehand.

The command line to remove an extent looks like the following:

# vmfs-lvm extent0 extent1 ... extentn remove

This will remove the last extent.

Update: There was a bug when setting some values at volume level. The git snapshot link above has been updated accordingly.

2009-12-02 16:40:55+0000

vmfs-tools | No Comments »