Author Archive

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 ? ;)

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.

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.

This release should have occurred much earlier, but I wanted to work on a test suite before. Seeing how that was not going to happen any soon, I decided to defer the test suite to 0.3.0 and released 0.2.0 today.

It adds a basic support for MBR-style partition tables as they are usually found on VMFS containing LUNs (i.e. a single 0xfb typed partition), a basic fsck tool which only does a few checks and no corrections, and a better debugvmfs shell (but still with the same commands, which ought to change in 0.3.0). It also supports loading a multiple extents VMFS with missing ones (except the first one, which contains everything).

This new release has also been tested to build and work on FreeBSD 7.2, Opensolaris 2009.06 and Cygwin 1.5.25.

Chrome OS has been announced today, and from a quick look at this video, it very much looks like it is some kind of Coreboot (formerly LinuxBIOS), X and Chrome combination. As such, it seems it's not something you're going to fully enjoy on any computer.

Update: Apparently, they use their own firmware and a Linux 2.6.30 kernel. If they went the custom firmware route, and wanted a fast boot, I wonder why they didn't start with Coreboot, instead.

Iceape 2.0 is going to hit unstable in a few days, and as such, the few packages that are only compatible with Iceape 1.x will stop working. I therefore asked for removal of cascades, checky and tabextensions, 3 packages I've been maintaining for a little while.

Actually, 2 of them are my two very first Debian packages: cascades and checky. A page is turned.

Some rant, others don't. I'm more with Zack, here, though there has been one @ubuntu maintainer that puzzled me: ubuntu-mozillateam@lists.ubuntu.com.

I'm still wondering how I should be taking it.

I finally started the xulrunner 1.9.1 transition in unstable, and uploaded Iceweasel 3.5.3 there.

One of the nice additions to the latest xulrunner (which has actually been in experimental for a couple weeks) is a dh_xulrunner script that adds the proper xulrunner package to shlibs:Depends, which means we are getting nearer to being able to handle xulrunner transitions with binNMUs only. We are still far from it, but it is a step closer. At least, transitions should get a bit easier. The way it works is very hackish, but it apparently works well enough for the packages that currently depend on xulrunner-dev. I also added a "xulrunner" dh sequence, for the dh users.

Anyways, as a side effect of the starting transition, I ended up fixing 4 RC bugs on a single package:

• Outdated dependencies: rebuilding is enough to get the proper dependencies
• A segmentation fault at startup that I guess happened because the package didn't depend on xulrunner-1.9. With the transition patch, it does depend on xulrunner-1.9.1, now.
• Missing build dependencies
• Oudated build dependencies

Another package with 3 RC bugs is impacted by this transition, but it looks like a good candidate for removal. That's 7 RC bugs adressed by this transition, while not directly related to xulrunner.

Hi lazyweb,

I'm wondering if there a lot of demand for such a feature, being to be able to install 2 (or more) major releases of iceweasel on the same computer. If there is a strong demand, I may consider allowing it. Please reply in the comments on this blog with your feelings, for or against the implementation of this co-installability.

Thanks.

PS: you may also forward this query to other sites and send people back here to leave their opinion.

Jumping on the vrms meme-wagon. I actually got it fooled.

# vrms
No non-free or contrib packages installed on jigen! rms would be proud.


$ ls /lib/firmware/
iwlwifi-3945-1.ucode iwlwifi-5000-1.ucode r5u870_1830.fw r5u870_1835.fw r5u870_1870.fw
iwlwifi-3945-2.ucode iwlwifi-5000-2.ucode r5u870_1832.fw r5u870_1836.fw
iwlwifi-4965-1.ucode iwlwifi-5150-2.ucode r5u870_1833.fw r5u870_183a.fw
iwlwifi-4965-2.ucode r5u870_1810.fw r5u870_1834.fw r5u870_1870_1.fw

$ ls ~/.mozilla/plugins/
libflashplayer.so