Archive for August, 2005

I've been playing a bit with xen the last few days, and it really rocks. It's been quite tricky to put up, though. I've been following two different guides, but they were missing some stuff for what i wanted to try.

I wanted to build the most generic kernel possible, so that it would be easily useable on most installations, like the generic debian kernels. Well, it has been quite painful. Trying to build in a sid chroot, I hit the first issue : while the xen patch doesn't apply to linux 2.6.12, linux 2.6.11 doesn't build with gcc 4.0. You get build errors in I2C, generic serial, and much more other stuff. Then, a bunch of drivers can't be built because of being unsupported.

When you finally succeed in building the kernel as a generic debian one, i.e. with an initrd, you realize the generated package (built with make-kpkg) doesn't build the initrd for you, and doesn't correctly build the modules dependencies (which prevent the initrd to be any useful), even though everything is (supposedly) correctly set-up.

So, after solving all these, I finally was able to boot on a generic xen system and to run some virtual machines. Main issue remaining : xen doesn't want to find an IRQ for the firewire controller, so i can't access my external hard-disk...

I'll try to finalize a clean generic kernel package that does all it is supposed to do, but in the meanwhile, here are the hints if you want to build your own domain 0 kernel :

• install kernel-source-2.6.11 and kernel-patch-xen, and decompress /usr/src/kernel-source-2.6.11.tar.bz2
• copy /boot/config-2.6.11-1-686 in /usr/src/kernel-source-2.6.11/.config
• add CONFIG_XEN=y and CONFIG_XEN_PRIVILEGED_GUEST=y in it (otherwise, a whole bunch of modules get disabled)
• run the following command in the kernel source directory : MAKEFLAGS="CC=gcc-3.4" PATCH_THE_KERNEL=YES make-kpkg --arch xen --append-to-version xen0 --revision 1 --initrd --config menuconfig kernel_image
• adjust your configuration if you need (you might want to disable network and block device frontends for the dom0 kernel)
• install the generated kernel
• run depmod 2.6.11xen0 and check your /lib/modules/2.6.11xen0 is correct
• run mkinitrd -o /boot/initrd.img-2.6.11xen0 /lib/modules/2.6.11xen0
• add the following to your /boot/grub/menu.lst file:
  

  title Xen 2.0 / XenLinux 2.6
  kernel /boot/xen.gz dom0_mem=131072
  module /boot/xen-linux-2.6.11xen0 root=/dev/hda1 ro
  module /boot/initrd.img-2.6.11xen0

  (adjust the root device and the dom0 memory size if necessary)

And you might be able to get a working xen kernel...

That is so typical from you Daniel. 2 sentences, no argument... and comments closed. Just brilliant.

You got 31 of 37 (83.8%) right. What about you ?

I really enjoy when my wife is chatting with my parents on the phone. Her speaking french is so cute.

So, a few days ago, I kinda forced my wife to use gaim instead of using both MSN Messenger and ICQ on her computer. While it has the advantage of integrating every protocol she was using (plus the bonus of having access to jabber, now), it has some flaws on UI usability, and, more importantly, for japanese transmissions.

One could argue about this choice, but well, this is the only multi-protocol and jabber client I know that has been ported to Windows. Besides, it's the one I use on my Debian desktop.

I knew that gaim had some issues with mojibake, because I experienced them. One of them is when you receive messages while offline. The messages coming at login time are all mojibake. While it can be annoying, it doesn't happen that often, so...

But here, there was one I never experienced, for a simple reason : I don't use MSN. And here is the big problem : everything in MSN is just mojibake, which is, well, very annoying.

There I was, forcing people to use free software that doesn't work like expected. But hey, I told my friend Google something like "gaim MSN 文字化け", and guess what ? I found a patch, addressing some mojibake issues, including the MSN one, and some other japanese related issues (such as shortcuts conflicting with input methods keys...) !

Next step was to actually build the stuff. Pervert as I like to be, I tried to used cygwin under wine to cross-compile it. Didn't do the trick... bash doesn't even want to start. Since I didn't really want to spend that much time to figure out all the possible ways to cross-compile for windows under linux, I just went to the easy solution : building directly under Windows, following the build instructions. If you want to do it by yourself, be aware that you have to use the standalone MinGW, even the one provided with cygwin won't work, believe the build instructions.

If you can't or don't want to build gaim for Windows by yourself, you can get the installer for the patched version. And if you're a Debian user, you can also get the package.

The strange thing about this patch is that it's being maintained for a long time, and never got applied upstream to fix these mojibake issues. Why ? Maybe they just never heard of it... I'll try to drop them a note.

I finally got seriously into the xulrunner packaging today (see ITP) and managed to get something that is able to run the MyBrowser sample XUL application (provided that you change the MaxGeckoVersion in the application.ini file in the mybrowser directory) and to gracefully let mozilla-browser run, while we override quite a few of its libraries.

As the long term plan for xulrunner is to be the XUL runtime for some (all?) mozilla.org applications, I moved all its libs to /usr/lib, overriding mozilla-browser's libnss3 and libnspr4. Upstream has this special feature that it doesn't support libraries versioning, so that it is usually a mess, but they are supposedly trying to freeze the API, which will hopefully fix a lot of the current issues with mozilla releases.

Anyways, xulrunner provides its own libnspr4 and libnss3 packages (actually, libnspr4.6 and libnss3.10), while diverting the original mozilla-browser files into /usr/lib/mozilla, and provides a libmozjs package providing spidermonkey, and a libsmjs1 compatibility package. The standalone spidermonkey package will have to be removed, it's outdated and redundant.

While libnspr4 and libnss3 from mozilla-browser could be removed and mozilla-browser could use xulrunner's ones, the contrary is not possible for libnspr4 because of some missing symbols. libnss3 is fine, though, maybe I'll allow xulrunner to use it. On the other hand, xulrunner's libmozjs makes mozilla segfaults...

When everything will be ready, I'll make an upload to experimental and will ask galeon, epiphany and other maintainers to check out if they can build their browser with the libgtkembedmoz provided by xulrunner, which is IMHO, the thing we'll have to do some day.

... when you :

• close the wrong bug in your changelog,
• close again the wrong bug when trying to actually close the good one,
• send a mail asking what to do in such case, considering the changes to the BTS... to the wrong adress.

Enough Debian work for today.

Update [2005-08-14 19:07:33+0200]: ... and can't add the correct feed address into Planet Debian on the first try.

There's nothing more annoying, when you want to send mail, than to receive the a "550-rejected because some.ip.add.ress is blacklisted at some.random.crap.rbl".

Actually, there is something more annoying : setting up an email alias to an external address and realize some weeks later that the server dealing with the external address does use such rbl. In such cases, senders get an error message and no way to warn about the problem. And the message is not queued.

So, I was wondering if there was a way, with exim (default mail server on debian, and suitable for my needs), to have a "conditional smarthost", something like "if when trying to deliver a mail, you get an rbl rejection from the remote server, try to send it through my ISP's smarthost".

Why not just use ISP's smarthost all the time ? The answer is simple : I don't see why i should do that while it just works the way it is most of the time.

And now for the irony : when trying to send a message to the exim-users mailing-list to ask for hints, what can have happened ?

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:

exim-users@exim.org
SMTP error from remote mail server after RCPT TO:<exim-users@exim.org>:
host sesame.csx.cam.ac.uk [131.111.8.41]: 550 Access denied - x.y.z.t listed by rbl-plus.mail-abuse.ja.net -

Rhââââââââââ

Currently rolling on Planet Debian