blino's website

Free software developer and more

The "psb" Poulsbo driver from Intel was broken on X server 1.7, because of API changes notably.

But after some love, here it is, starting your X again!

First, upstream Xorg removed some stubs in server 1.7 (xfree86: Remove loader symbol list ABI stubs), and the psb driver was still calling them. Just removing the calls from the psb driver was enough about that.

The Fedora package ships a patch for server 1.7 that contains fixes about includes and libpciaccess, which I reused.

After this, it built fine, but the psb driver could not be loaded from X, because it was not linked with the internal "libmm" library, and failed finding its symbols. Building without -Wl,--as-needed made it link fine with libmm.so, but it is just a workaround.

In addition, some non-existent functions like mmListEmpty() were called from the internal libmm library. Previously, this has been workarounded by passing -Wl,--no-undefined as linker flags so that the library can be linked fine, and everything was fine at runtime as long as nothing used the symbol. But now, it seems libmm can't be loaded this way by dlopen(), even with lazy binding, it complains about the undefined symbols. So, I finally fixed it the proper, by adding back -Wl,--no-undefined, and removing the code calling the non-existent functions, which was unused anyway.

It also exposed an undefined assert() symbol as well, caused by a missing assert.h include...

Then, X still failed loading because it couldn't find mmCreateDRM(), which should be in libmm. That's because we build our Xorg with "hidden" visibility. It was enough patching and fixing libmm already, so a quick fix was to build with -fvisibility=default. This also fixes the linking of psb_drv.so with libmm.so, and allows to use -Wl,--as-needed again when linking the driver.

The final touch is the make the Xpsb proprietary extension usable again. The only issue was that the empty xf86AddModuleInfo() function has been removed upstream. Adding this empty function back in psb_driver.c directly is dirty, but makes it usable again :)

As bonus, I also fixed my patch setting MigrationHeuristic option to "greedy" by default, as it seems to lower the odds of a random crash.

There are still some unrendered pixmaps issue, and segfaults when playing with libva, but at least X is starting fine now, and 3D as well as accelerated video are working :)

(in recent Mesa releases, another issue appears in the proprietary dri driver, because of _glapi_set_warning_func() removal upstream, calling for another workaround /o\)

Enjoy this in Mandriva Cooker, it's already available in our contrib packages!

Other distros, you're welcome in cherry-picking our psb patches.



Sometimes, Firefox freezes when drag'n'dropping a tab. The mouse cursor keeps the drag'n'drop icon, and the Firefox window becomes unresponsive, as well as my desktop.

To escape from this trap, a way is to enter the Firefox menu, by typing Alt+F \o/

(this also occurs in epiphany and galeon, and pterjan can confirm the workaround works as well for galeon)



image

After having met Marcus Bauer, the author of tangoGPS , at FOSDEM 2009, I decided to package this nice GPS software.

By default, it uses maps from the OpenStreetMap project, and it can work as a map viewer without a GPS device.

The package is now available in Mandriva Cooker, enjoy!



I've finally uploaded a fusion-icon package in Mandriva Cooker and 2008.0 (backports). fusion-icon (wiki) (git) is a panel applet that allows to start/stop compiz on the fly, and to change the window decorator.

It may not play very nicely with all compositing manager setups (Xgl?), because we do not use the same integration methods in Mandriva. But it can be quite useful for now, since I've not yet added the ability to enable/disable compositing desktops on the fly in our drak3d configuration tool...



While syncing our initscripts source code with the RedHat 8.60 version, I experienced a weird unsupported special file type error message with the svn merge command:

$ svn merge \
    svn+ssh://svn.mandriva.com/svn/soft/initscripts/tags/rh_last_merge \
    svn+ssh://svn.mandriva.com/svn/soft/initscripts/branches/RedHat
U    sysconfig.txt
[...]
svn: In directory '.'
svn: '.svn/tmp/tempfile.10.tmp' has unsupported special file type '2007-05-15'
$ head -n 1 .svn/tmp/tempfile.10.tmp
2007-05-15  Bill Nottingham  <notting@redhat.com>

It was actually trying to merge the ChangeLog file from the RedHat branch with the ChangeLog symlink in our checkout, which does not work (upstream bugs 2472 and 2692). Still, the error message could probably be improved, not to specify the file content as file type :-)

As a side note, I have also removed a workaround in our network-up service, which was unconditionally waiting (and blocking boot) at least 6 seconds. This was added because the link beat reported by some network drivers could not be trusted during a short period right after the module loading (#18986 and #31864), but we'd better fix the drivers if possible.



Today, we (Mandriva) have announced a partnership with TurboLinux, initiating our new Manbo-Labs. It is not just a press release to make some buzz, we have actually been working for a few months with TurboLinux employees. Shinji and Kiichiro (from TurboLinux) even stayed in our office in the meantime! \o/

The initial goal is to merge our basesystems components, so that we can share these same basesystem packages between Mandriva and TurboLinux. For example, the merged kernel package includes the Tomoyo security framework, and the TurboLinux installer already uses some of the merged packages (mkinitrd, bootloader-utils, ...). We are also working on merging rpm, udev, glibc and the build chain (notably gcc).

However, this joint lab does not mean that we share the agreement with Microsoft, Mandriva still tries to stay as free and open as possible, as Anne explained on the cooker ML.

It's been very nice contributing with our TurboLinux teammates, and we will undoubtedly have a whole bunch of new adventures together in the near future. Actually, we have not just been merging packages, but also food culture, and it would be quite villain not to share Surströmming with them ;-) (Oden told us that our cans would be lethal by now, but well...)



gsynaptics is now available in cooker. It's a GNOME configuration tool for Synaptics touchpads (the KDE equivalent being ksynaptics).

It will be automatically installed with GNOME desktops when Synaptics touchpads are detected.



iotop is a python tool that shows how much I/O happens on the system. It's a lot more interesting than the vmstat 1 command, since it can display per-process I/O, thanks to the per-task storage I/O accounting feature in latest kernels (commit).

I've upload an iotop package in cooker, but our cooker kernels don't have TASK_IO_ACCOUNTING enabled, maybe we could have it in one of our contrib kernel packages.



My computer keeps crashing because of some hardware issue, which is not really nice when I'm typing long messages on Facebook. It would have been quite painful to lose the hundreds of words just waiting to be submitted.

Mozilla Firefox has a nice session store feature, which constantly saves open tabs as well as data in forms, allowing to restore them easily after a crash.

But somehow, my saved form was not restored correctly, while it was present in the ~/.mozilla/firefox/*/sessionstore.js session state file. Fortunately, I was able to find the form content in the sessionstore.bak file. Though, my writing was URI-encoded (RFC 2396) in the state file, it required some trickery to paste back in the Firefox form.

Thanks to the encode and decode url strings Perl howto, I found the URI::Escape module that can decode such strings. It worked almost out of the box, I just needed an additional call to utf8::decode to handle the UTF8 characters:

$ perl -MURI::Escape -Mutf8 -e 'my $s = uri_unescape(<>); utf8::decode($s); print $s'
j'ai%20mang%C3%A9%20une%20ch%C3%A2taigne

j'ai mangé une châtaigne


So, we want to have a better dkms support in 2008.0, to make kernel updates happen smoothly regarding external kernel modules (mainly proprietary video drivers), as detailled in #30907.

A part of this long endeavor is to make dkms packages (both source dkms and prebuilt dkms) have kmod(<modname>) rpm Provides, so that other packages, install and configuration tools can request a specific module.

I patched rpm-mandriva-setup some weeks ago to automatically generate these kmod provides (heavily based on Danny's work). But this requires all dkms packages to be resubmitted, since a part of this automatic provides scripts acts on the dkms.conf files, which are part of the dkms source packages.

I used the new mdvsys features to do that:

mdvsys update --message "rebuild for kmod provides" <package list>

It mostly worked, but a perl operator priority bug prevented my message argument to be used, and will make me a fool in the changelogs (they read "update to new version").

I (dearly) hate guillomovitch for that.

After some usual build system troubles, I finally got most of the source dkms package rebuilt, only a few don't build, as my (clearly not optimized) scriptlet shows:

$ for p in /RPMS/{main,contrib,non-free}/release/dkms-*; do \
   rpm -qp --provides $p | grep -q kmod || rpm -qp --qf '%{SOURCERPM}\n' $p \
   | perl -ne '/^(.*)-[^-]+-[^-]+/ and print "$1\n"'; \
  done | sort -u | grep -v '^dkms$'
cluster
openc

At this point, it only means that the packages containing the module source code are fine, and not that the source code inside will build fine...

For example, while testing some 56k modems, I noticed that hsfmodem/hcfpcimodem did not build anymore. An upgrade to the upstream versions was not enough, it fixed some build issues, but not the weirdest one... The kernelcompiler.sh scripts that tried to detect the gcc version what running gcc -v and tried to make it match some pattern. But well, it didn't work very well with french locale :-p (using LC_ALL=C fixed it).

On the next laptop I tried, there was a modem on top of HDA (High Definition Audio) bus, with a Si3054 codec. It does not work with the proprietary slamr modules, and may work with the ALSA snd-hda-intel one. While looking for user reports, I stumbled upon a patch from Claudio: Slmodem: period size 48 not supported. It was worth being committed in the distro, I wonder why Claudio didn't :-/

Still, no luck with this particular modem, we'd need to investigate more.

The scanModem utility (from Linmodems support) proved to be very useful for these tests, it detects a lot of modem chipsets, which helps to find the correct dirver. But unfortunately, its license is unclear, I can't package it in the distro right now.

Anyway, I'm not done with my quest yet (and it's only the "rebuild packages" part of it...). Our source dkms packages have to be rebuilt for each of our kernel packages, so that users can install prebuilt dkms packages, without requiring the whole toolchain to build kernel modules.

To accomplish that, I still need to baby-sit Warly's powerful Iurt (the rebuild bot), and probably fight against the build system some more times /o\



I've been recently playing a bit with VirtualBox to debug my One live systems, and got a bit involved in VirtualBox packaging in the meantime. Our Mandriva package was missing the guest additions, so I added them recently (the packages are x11-driver-input-vboxmouse, x11-driver-video-vboxvideo, dkms-vboxadd, dkms-vboxvfs and virtualbox-guest-additions). They basically allow a better integration of mouse and X11 (clipboard) with the host, and to share files more easily, thanks to a vboxvfs module and a vboxfs mount helper.

But the vboxadd kernel module required some integration, since /dev/vboxadd was not created automatically. Upstream has an initscript to create it, but it's quite a weird trick to parse /proc/devices to get the major and create the device "a la main" with mknod.

A better solution is to make the kernel module send an uevent (with kobject_uevent()) when the device is registered in the kernel module, so that udev creates the device node automatically.

This can be done through the device_create() function (from drivers/base/core.c), but it requires a kernel class as argument, and we don't necessarily need to create one for vboxadd.

A simpler solution is to replace the original char device creation, register_chrdev() (from fs/char_dev.c), by using a misc character device. misc_register() (from drivers/char/misc.c) takes care of the character device registration and of sending the uevent to userspace.

#include <linux/miscdevice.h>

...

static struct miscdevice vbox_dev =
{
    .minor      = MISC_DYNAMIC_MINOR,
    .name       = "vboxadd",
    .fops       = &vbox_fops,
};

...

    if (vbox_major > 0) {
        err = register_chrdev(vbox_major, "vboxadd", &vbox_fops);
    } else {
        err = misc_register(&vbox_dev);
    }

...

    if (vbox_major > 0) {
        unregister_chrdev(vbox_major, "vboxadd");
    } else {
        misc_deregister(&vbox_dev);
    }

The final touch is to make the device node reachable by end-users, which is made easy since Mandriva uses pam_console. pam_console_apply is called for every device node created by udev, so we just need to add a rule to make vboxadd devices owned by the console user (i.e. the user physically logged on the system).

$ cat /etc/security/console.perms.d/60-vboxadd.perms
<vboxadd>=/dev/vboxadd*
<console> 0600 <vboxadd> 0600 root


When multiple display modules matching the same device are loaded at startup by udev coldplug, we can get in a situation where X doesn't start (#32030). This can happen when different versions of nvidia modules (nvidia, , nvidia96xx, nvidia71xx) are installed, which is the case on our live CDs.

To prevent all these modules from being loaded by udev, we can explicitely exclude devices from the display PCI class, like we do for storage controllers:

# modprobe pci devices on cold plug except for:
#  PCI_BASE_CLASS_STORAGE          0x01
ACTION=="add", SUBSYSTEM=="pci", ENV{STARTUP}=="1", SYSFS{modalias}=="?*", \
        ATTRS{class}!="0x01*", \
        RUN+="/sbin/modprobe %s{modalias}"

But adding another match to exclude the display class (PCI_BASE_CLASS_DISPLAY is 0x03 in /usr/include/pci/header.h) did not always work: ATTRS{class}!="0x03*" fails on PCI-Express devices.

That's because the ATTRS{class}!="value" rule walks every parent devices to check that each of them has a class different from "value", while one could think it would match if only one of them has a different value. Thus, when the tested device has a parent device, like with PCI Express devices, the negative ATTRS check is likely to fail.

So, the solution is to use ATTR{class}!="value", which checks only the current device, without walking the parent tree.

To debug this, I built udev with DEBUG=true, and added a ENV{FOO}=BAR operation in the rule I tested, to know quickly if it mached (in the output of udevmonitor --env).

# udevd --daemon --debug-trace --verbose &>udevd-debug.log
# udevcontrol log_priority=debug
# udevcontrol env STARTUP=1
# udevmonitor --env

Then, testing the rule of my video adapter device is just a matter of writting in the uevent file in sysfs:

$ lspci | grep VGA
01:00.0 VGA compatible controller: ATI Technologies Inc Unknown device 94c3
# echo 1 > /sys/devices/pci0000:00/0000:01:00.0/uevent


For a few releases, auto-mount of LUKS devices has been broken in Mandriva (bugs #27259 and #30115), because we had the following udev rule as default:

KERNEL=="dm-[0-9]*", OPTIONS="ignore_device"

This rule existed because lvm2 setup got broken when udev tried to run vol_id on dm devices (see Let udev play with snapshots thread on linux-lvm ML). This has been fixed ages ago (in lvm2-2.02.13) with the following change: When adding snapshot leave cow LV mapped device active after zeroing (commit).

So, the "ignore dm devices" workaround has been removed from our udev rules, and LUKS devices should now be auto-mounted by default on modern desktops \o/ (GNOME users, enjoy)



Since we use HTML in our first time desktop wizard (and in the new first boot wizard), it may be useful to use standard translations methods such as xgettext and po files.

intltool comes handy here, since it can handle XML files (Translating Custom XML). This also works with HTML files, it just requires translatables strings to be enclosed in tags with an '_' prefix.

$ cat > foo.html.in
<html>
<head><_title>Oy</_title></head>
<body><_span>w00t</_span></body>
</html>

$ intltool-extract --type=gettext/xml foo.html.in 
Generating C format header file for translation.
Wrote foo.html.in.h

$ mkdir po
$ xgettext -a foo.html.in.h -o po/foo.pot
$ cp -a po/foo.pot po/fr.po

$ emacs po/fr.po # edit po/fr.po

$ intltool-merge --xml-style -m po foo.html.in foo.html
Merging translations into foo.html.
CREATED fr/foo.html
CREATED foo.html

$ cat fr/foo.html
<?xml version="1.0" encoding="UTF-8"?>
<html>
<head><title xml:lang="fr">Moyoto</title></head>
<body><span xml:lang="fr">\o/</span></body>
</html>


While trying to reproduce and debug UnionFS bugs with VirtualBox, I needed to extract a copy of the call traces.

Screenshots are not easily usable, so I tried the "serial ports" feature of VirtualBox.

An "Host Pipe" mode is available, to redirect serial port output to a pipe. But it didn't work by using a named pipe, created with mkfifo. Actually, if set to create the pipe, VirtualBox will create a UNIX local domain socket.

$ file /tmp/vbox-pipe 
/tmp/vbox-pipe: socket

The "pipe" name is a bit ambiguous, it's easy to understand it as a fifo, not a socket (and actually, the Windows implementation uses a named pipe in VirtualBox...)

This is all explained in VirtualBox's manual (PDF) (section 3.7.9: Serial ports), which even mentions the nice socat utility.

So, to get serial output to stdout, one can use:

socat /tmp/vbox-pipe -

Or to keep serial output in a log file:

socat -u /tmp/vbox-pipe GOPEN:vbox.log
tail -f vbox.log

Sometimes, the connection to the socket fails with ECONNREFUSED, so it can be better to create it with socat, before starting the virtual machine:

socat unix-listen:/tmp/vbox-pipe -

Or this way not to close the pipe everytime the virtual host is shut down:

socat unix-listen:/tmp/vbox-pipe,reuseaddr,fork -

Now, I just need to add console=ttyS0 as kernel command line option when booting my live system, and I have no excuse not to report the bugs. I could even try to fix them.



Since recent compiz updates in cooker, we have a "small" issue: the window decoration plugin is not enabled correctly if the gconf plugin is loaded in compiz, which we do by default (#32251).

Actually, it's a bug in the compiz part that initializes plugins. It maintains a list of loaded plugins, and fills it at startup after each successful plugin load. The problem is that the gconf plugin also updates this list when initializing.

It happens this way: compiz first loads the glib plugin, adds it to the plugins list, then loads the gconf plugin, which reads GConf settings and notably loads the active_plugins GConf key in the plugins list. And since the gconf plugin is loaded, compiz adds it to the plugin list, but to the wrong place: it doesn't handle the fact that a plugin could have modified the current plugins list (more details in my post on the compiz ML).

I wrote a quick patch (see previous link) to make compiz handle the fact that a plugin modifies the active plugins list, and it makes compiz loads the decoration plugin fine. It has an unfortunate side effect: the gconf plugin is not added in the active plugins list anymore, and it make compiz segfaults when it is stopped.

To debug it further, I would have made gdb not stop on the SIGINT signal and allow it to pass the signal to the debugged program (gdb doc about signals):

(gdb) handle SIGINT nostop
(gdb) handle SIGINT pass

But I wasn't really able to catch the segfault this way, so I kinda gave up. Anyway, this bug is not much important, we used to load the gconf plugin by default, to make the default plugins stored in gconf and to use the deprecated gset-compiz frontend. Now, the default plugins list has been added by coling in the core.xml file, so this is not very useful anymore. (Hey, no, this wasn't a waste of time!)

Ok, there is a bug and I haven't issued a proper fix, but well, it won't obsess me much. Furthermore, my Asperger Quotient is only 14, I'm not even up the so-called "average women" quotient. So, why bother with this buglet? :-p

At that time, yesterday night, I thought that my day at the office was offer, and that I could gently modify the compiz package from home, not to load the gconf plugin by default. So, a bit later, I leisurely updated my laptop at home with latest cooker, and prepared to test my update package.

That was kinda naive, I should have known by now that the world is full of bugs, and that they have a special kinship with me. Of course, compiz didn't start correctly. Worse, it made my system hard lock.

A quick look on freedesktop's bugzilla shows a bug with a close description: r300 DRI misrenders 3D objects (bug 11380). In this report, the bug impacts blender. Ok, it's maybe a really long shot. This bug seems to involve gcc and the -O2 build optimization, especially the -ftree-vrp one (upstream gcc bug 32544). Yep, building with -O0 solves my bug \o/

Still, I couldn't let this miscompilation with -O2 unsolved. So, the day after (today), I had a closer look to the incriminated Mesa source code (src/mesa/drivers/dri/r300/r300_state.c). Let's try the -fno-tree-vrp option mentionned in the bug report. It works as well \o/

I extracted the code of the r300SetupPixelShader() function in a separate r300_pixelshader.c file to make debugging easier, since Bero already noticed it was the culprit (in the gcc bug report).

First, the preprocessed files are the same:

gcc -O2 <options> r300_pixelshader.c -E -o r300_pixelshader.i
gcc -O2 -fno-tree-vrp <options> r300_pixelshader.c -E -o r300_pixelshader.notreevrp.i

Then, we can compare the generated assembly code (using -fverbose-asm to get some hints):

gcc -fverbose-asm -O2 <options> r300_pixelshader.c -S -o r300_state.s
gcc -fverbose-asm -O2 -fno-tree-vrp <options> r300_pixelshader.c -S -o r300_state.s

It differs, maybe -fno-inline could have helped as well to reduce the diff, but here I'm lost (see preprocessed diff on the freedesktop bug report).

Strangly enough, building with the -O3 optimize option instead of -O2 also makes the r300 driver run fine. According to the gcc manpage, -O3 is equivalent to -O2 -finline-functions -funswitch-loops -fgcse-after-reload A quick look at gcc's source code (decode_options() in gcc/opts.c) seems to confirm that, but actually, a lot more options are enabled. For example, some bits of loops unroll (from tree_complete_unroll() in gcc/tree-ssa-loop.c) are enabled if optimize level is greater or equal to 3. Building with -O2 -finline-functions -funswitch-loops -fgcse-after-reload -funroll-loops also made it work.

By the way, the code also runs fine when built with gcc 4.3. This is all very interesting, but it does not help to find what's breaking it between -00 and -O2, and it does not change the fact that I'm lost /o\
Pixel, our beloved gcc maintainer in law, has helped me a lot so far, and we were able to extract a not so big code portion (the assembly diff is about 150 lines) that triggers the bug. So let's give him the hot potato ;-)

Now, I'm sort of out of the loop, Pixel handles this fine. He has a very small testcase (dozen of lines) that involves union variables and Value Range Propagation (VRP) on trees, which can be debugged using -fdump-tree-vrp, and gdb...

For now, I'm uploading a Mesa package built with -fno-tree-vrp in cooker, we'll get a proper fix later if possible. I can now focus on "desktop" features, expect a new drak3d soon!



This week-end, I decided to buy a new PCI-E video card, with a passive cooling solution, since the default ATI fan of my ASUS EAX550 was really noisy. So, it took my rollers to go rue Montgallet and find a silent one. The first shop tried to sell me the exact same card as silent, but of course, I didn't "bought" it :-p

Most shops only had passive cooling cards from Nvidia, but I preferred to get an ATI one, since they're usually better supported by free-software drivers. Finally, I bought a cheap (55 euros) MSI RX2400PRO card, with a big heat sink, but also with 256MB of memory and a lot of HDTV features that I'll probably never use...

Though, at first boot, harddrake automatically configured the card to use the fbdev driver, which was not a good sign regarding support in free-software drivers /o\

X didn't start with the free radeon driver, and it even failed with ATI's proprietary fglrx driver (8.39.4). Adam's post on cooker reminded me about the avivo driver. It supports r5xx chipsets only, while mine is a r610 HD 2400 chipset (device ID 0x94c3). According to the avivo developpers, it should be possible to make this driver support r6xx cards (daniels post).

This post also mentions how to further debug the driver, using these tools:

  • avivotool
  • xresprobe (hacked by airlied)
  • valgrind (hacked version), (it has to be patched to build with glibc-2.6, for example with a rediffed version of the gentoo patch)

An article on Phoronix (AMD Radeon HD 2000 Series & Linux) showed that it won't be that easy to get r6xx support in avivo. Following the same track, I patched the avivo driver to list my chipset device ID, but I got the same error message when starting X:

xf86MapVidMem: Could not mmap framebuffer (0xb0000000,0x0) (Invalid argument)

So, I hopped in the #dri-devel channel to bug the driver developpers (mainly Jerome Glisse). The initial advice was that the radeon memory size register was not at the same offset in the BIOS anymore. Eek. And that I could grep for the memory size in a BIOS dump. Eek.

Actually, I just had to use the radeondump tool (radeondump HOWTO), and search for my memory size in the registers. It appeared to be in kB, so I grepped 0x00040000 (256*1024, since the card has 256MB) in the dump. It gave a few hits, and 0x168 was apparently the correct offset.

(II) avivo(0): No connector table in BIOS
(EE) avivo(0): No valid modes.

Trying ./avivotool/avivotool romtables shows the same No connector table in BIOS error message (after fixing avivotool check for mmap() return code). Even if the BIOS header reads ATOM, it seems that the format is different from other r4xx/r5xx chipsets. So, a new video BIOS format, fun in prospect!

I saved the BIOS rom in a file to make debugging easier:

$ lspci | grep VGA
01:00.0 VGA compatible controller: ATI Technologies Inc Unknown device 94c3
# cp /sys/bus/pci/devices/0000:01:00.0/rom r610.rom
# ./avivotool/avivotool romtables r610.rom

Besides the source code of avivotool, I used some other Radeon BIOS dumps (r420, r520, r530, r580) as examples to guess the BIOS format, and notably to find where the connector table is hidden in my BIOS. The HowVideoCardsWork article from Xorg wiki was quite handy to get basic information about CRTC and connectors, since I'm a total n00b here.

I had to do some hex maths, so I used bc as hexadecimal calculator (tips about base modes) (more tips about hexadecimal). Maybe I could have used emacs-calc, or pixel's hexedit, but anyway I ended writting a lot of debug code to show hex numbers in the format I wanted to guess connectors offset. But so far, I have not found any relevant pattern :-/

Yesterday, I knew nothing about all this stuff, and here I am, parsing hex numbers (and again following warly's steps :-p)... I can't believe me, I should really take a break. Someday.



I wish this week had been as fun as the previous one, which included RMLL meetings + some other (really nice) meetings. But it seems I'm now kinda out of luck or cursed, core system tools are now haunting me :-/

This week-end, it was splashy that was bothering me again. Since we are considering its inclusion in Mandriva Linux 2008.0, to replace the bootsplash kernel patch, I had to try it.

The version I packaged in Mandriva Cooker was not really functional (it segfaulted...), so I had to debug it. The initial segfault was quite easy to debug (after making splashy not fork at startup), a couple of checks about directfb initialization were missing (patch).

That was rather not a good sign, splashy really needs DirectFB to work. Looking further in the execution with gdb showed that dfb_system_lookup() failed to find a directfb "system". Actually, the direct_modules_explore_directory() does not even bother to look in the modules directories when statically build (i.e. when built with -DPIC, passed by libtool), which seems logical.

So, how does it works with static builds? Actually, each directfb system uses a macro in its source code to register the module at program initialization, using a constructor attribute, which allows to run functions before even entering main():

#define DFB_CORE_SYSTEM(shortname)                          \
__attribute__((constructor)) void directfb_##shortname();   \
void directfb_##shortname() {                               \
     direct_modules_register( &dfb_core_systems,            \
                              DFB_CORE_SYSTEM_ABI_VERSION,  \
                              #shortname, &system_funcs );  \
}

For this to work, splashy need to be linked with at least with one directfb system, which is not included in the main directfb static archive. So, to use fbdev, I've added --system=fbdev to the directfb-config call in the Makefile.

But, again, it's not that simple when linking with static archives, objects from an archive are not used if they don't resolve any symbol (mail on gcc-help). A trick is to force a symbol contained in an object to be resolved, by marking it unresolved using the -u option of the ld linker. In my case, I added -Wl,-udirectfb_fbdev in the Makefile to pick the fbdev directfb system at linking.

That's better, but splashy still does not work. It needs a few more systems to be initialized, and it was a pain to debug with gdb, because directfb does not build with -O0, and building with -O1 makes it a bit more difficult. Eventually, I found out that directfb required a few more modules to be started correctly, such as a keyboard one and a wm one. Adding -Wl,-udirectfb_keyboard and -Wl,-udirectfbwm_default made the trick (final patch).

And finally, it starts \o/

Now, we need to integrate splashy in our initscripts, which should just be a matter of calling splashy_update "progress <percent>". We also have to provide a solution to keep background in tty (like the bootsplash kernel patch provided). A small daemon using directfb could do the trick. Hopefully.



I'm currently working on an upgrade DVD that will allow to upgrade a Mandriva Flash 2007 4G to Mandriva Flash 2007 Spring. Sounds great, right?

But it's not as easy as it seemed, I had a bunch of i18n-related problems. For example, OpenOffice.org would only "see" the English language. Quite bad for a distribution that aims to support as many languages as possible.

So, what's wrong? Missing packages? Missing files? I'm doing some not-really-kosher things with the rpm packages, breaking the rpm database by splitting files from the same rpm in different compressed loopbacks, it could explain. But no, everything looks ok.

I tried to reproduce with a Mandriva One 2007 Spring live CD, but there was no problem there. Stracing it (strace -e file) showed that it runs stat("/live/distrib/usr/lib/ooo-2.1/share/registry/modules/org/openoffice/Setup/Langpack-fr.xcu") at some point. Which is fine in the One live CD, since there was only one loopback containing all compressed files (mounted as /live/distrib), mounted by UnionFS together with a writable tmpfs. But in the new Flash version, we have split lang files into different loopbacks, to easily build different regions of Mandriva Flash. So, for example, the french translation files are mounted in the /live/modules/i18n-fr root, which obviously is not contained in /live/distrib.

But why is it looking in the /live/distrib root, shouldn't that be plain /? Looking for first occurence of this root in strace output shows that readlink("/proc/self/exe") returns /live/distrib/usr/lib/ooo-2.1/program/soffice.bin. Actually, there is a known misfeature in old unionfs, it does not handle /proc/self/exe correctly.

Hmm, but who tries to do that with /proc/self/exe? Let's see OpenOffice source code. Our rpm source package looks weird, it contains plenty of tarballs (and a unowinreg.dll file ??), and untaring them takes a dozen of minutes. But no luck grepping for /proc/self/exe in the code...

After looking more closely at strace output, it shows that right after using /proc/self/exe, it runs access("/etc/ld.so.preload"). Ok, so it's a glibc thing. (excuse-me someone? I just wanted to have translations in OOo!)

Grepping through glibc source code shows that the "culprit" is _dl_get_origin() from sysdeps/unix/sysv/linux/dl-origin.c. So, someone is trying to use the $ORIGIN DST (which reminds me I have to write some notes about Dynamic String Tokens), substituted by the glibc ELF loader.

Back to OpenOffice source code, we can find that most Makefiles for Unix set LINKFLAGSRUNPATH*=-Wl,-rpath,\''$$ORIGIN'\' as link flags. Oh, brilliant.

$ objdump -p /usr/lib/ooo-2.2/program/soffice.bin | grep RPATH
RPATH       $ORIGIN

But you don't exactly need a rpath here, since the /usr/lib/ooo-2.1/program/soffice wrapper already exports LD_LIBRARY_PATH to its basename. Let's check that by removing the rpath:

chrpath -d /usr/lib/ooo-2.1/program/soffice.bin

At this point, I could have expected quite more trouble, but finally some luck here, OpenOffice gets translated \o/

God (if you exist), what did I do to deserve this? I mean, seriously?!



So, yet another Mandriva Flash version \o/

This time, we've build one for GUADEC 2007, where Mandriva offers 2GB Flash USB keys to GNOME developers. And like for aKademy, it's quite a neat key, with a lot of new things.

First, it runs GNOME (it's the first Mandriva Flash with a non-KDE desktop ever), we obviously don't want to mess with excited GNOME developers discovering a KDE desktop :-p The full distribution is customized with a special GUADEC theme, and the USB keys are tagged with a GUADEC logo (keep them safe, they're collector!).

Besides some videos/demos/code/tools (svn) from GUADEC sponsors, this Flash edition contains some special apps, such as the gstreamer-enabled version of totem, and Fluendo's Elisa media center.

Oh, and it's also the first Mandriva Flash version running 2007 Spring, our latest distribution (non-GNOME users, don't worry, a classical Flash 2007 Spring version is on its way).

We already have some nice posts about Flash on Planet GNOME, I hope everyone enjoys it, between some patches/beer reviews :-p

Thanks to Bastien for taking care of the project on the GNOME side, and to fcrozat for the Mandriva part! (but did you really need to test it that much? I'm totally burnt-out now!)

Happy GUADEC meeting GNOME guys and gals! (and hi fcrozat, pterjan, Sara \o/)



OpenArena version 0.7.0 is now available in cooker, with a bunch of new maps and models \o/

Ok, there was some initial flounderings in the packaging, because files were moved from the openarena package to the new openarena-data package and a directory was replaced by a symlink to make it smooth. But rpm failed to do the upgrade with a "cpio failed" error (#31885), it can't upgrade a directory to a symlink. This pointed out a small bug in urpmi, it exits with success code and removes the rpm file from cache if cpio fails (#31907).

A "tiny" hack (rpm-devel discussion) in a %pretrans scriptlet allows to workaround the directory to symlink conversion, by doing it "à la main"(!) before rpm extracts the new package:

%pretrans
if [ -d %{gamelibdir}/baseoa ]; then
   mv %{gamelibdir}/baseoa{,.rpmsave}
   ln -s baseoa.rpmsave %{gamelibdir}/baseoa
fi

And now, just come hurt me plenty!



So, some weeks ago, we have switched to modular IDE in the cooker kernel.

The spadework was mostly done for tmb kernels, since mkinitrd was already able to cope with modular IDE. Though, it's quite a premiere for our DrakX installer.

Last week, Pixel added some support in our bootloader-config utility that is called in kernel post-install. Now, it automatically adds an ide-controller alias (actually, an install directive) in /etc/modprobe.conf if needed. Titi also made the installer automatically load the IDE modules on the fly.

Nice, but it turns out it's not enough, and both of Pixel and Titi left on vacations... And now I have the QA team (excuse me, I meant "Enabling" team) on my back, especially my dear Damien /o\

After all, it shouldn't be that difficult. Arnaud mentionned that we have to load the ide-disk module (of course, we really want to use the disks), it should be a piece of cake. Ok, so make the ide-disk module included in drakx-installer-images, then make the stage1 part load the ide-disk module (in the rare case the installer uses ISO images or mirror tree from disk), and finally make the installer load the ide-disk module when probing IDE controllers.

That's it, I'm done. It's about minor modifications, don't even bother test them, just submit! No?

Grmpf, it does not build. Our init-like part of the stage1 installer used a minilibc (borrowed from Redhat a long time ago), which made use of _syscallX() macros, allowing to wrap system calls. But these have been hidden from user view in upstream kernel, and then completely removed, userspace applications having to use the syscall() function.

But it's quite different when you're buidling a libc... And RedHat|Fedora's Anaconda does not use minilibc anymore. Ok, I don't want to reinvent the wheel, some other minimal libc such as uClibc and dietlibc have an implementation of the syscall() function (commit of _syscallX() removal in uClibc).

And since we already use dietlibc in the plain stage1, that was the way to go. Even if we are losing 6K in the resulting binary, poor of us ;-) Then we just need to link with libcompat.a to use the syscall() function:

-static inline _syscall3(int, syslog, int, type, char *, bufp, int, len);
-static inline _syscall3(int, reboot, int, magic, int, magic2, int, flag);
+#include <sys/syscall.h>
+#define syslog(...) syscall(__NR_syslog, __VA_ARGS__)
+#define reboot(...) syscall(__NR_reboot, __VA_ARGS__)

I also used the occasion to update our dietlibc package to 0.30. It didn't build out of the box, because of a small typo (patch from ALT Linux, seriously?).

Finally, a day and a half after the initial rants, IDE disks can be used in the Cooker installer \o/

(and I don't mention the other projects I'm working on, neither the other installer build problems caused by new kernel headers, new glibc, new whatever, current buildsystem, whatever...)

Oh, and that was the "trivial" part, I expect migration to libata PATA drivers to be a lot more fun!



Now that the Mandriva kernel has both legacy IDE and libata PATA drivers enabled (and modularized), we may experience some issues because of PCI coldplugging, which is enabled by default in Mandriva. It would load both IDE drivers, probably leading to strange things.

Thus, I've modified our udev rules to ignore IDE controllers at coldplug. These controllers can be matched by their PCI class (PCI_CLASS_STORAGE_IDE is 0x0101, from <pci/header.h>). To differentiate between coldplug and hotplug (ok, not very likely for IDE controllers), the STARTUP environment variable is set by /sbin/start_udev before calling /sbin/udevtrigger.

The new udev rule for automatic PCI modules loading looks this way:

# modprobe pci devices on cold plug except for:
#  PCI_CLASS_STORAGE_IDE           0x0101
ACTION=="add", SUBSYSTEM=="pci", ENV{STARTUP}=="1", SYSFS{modalias}=="?*", \
        SYSFS{class}!="0x0101*", \
        RUN+="/sbin/modprobe %s{modalias}"
# modprobe pci devices on hot plug
ACTION=="add", SUBSYSTEM=="pci", ENV{STARTUP}!="1", SYSFS{modalias}=="?*", \
        RUN+="/sbin/modprobe %s{modalias}"

It can be easily tested this way:

rmmod <some pci module>
/sbin/udevcontrol env STARTUP=1
udevtrigger
udevsettle
/sbin/udevcontrol env STARTUP=
head /proc/modules

For the record, here's the crazy command line I used to list IDE modules (requiring ide-core) and their matching class (from modaliases), just out of curiosity:

egrep
  `grep ide-core /lib/modules/$(uname -r)/modules.dep
   | perl -ne 'print join("|", map { m|([^/]*).ko| && $1 ne "generic" ? $1 : () } <>) . "\n"'`
  /lib/modules/$(uname -r)/modules.alias
| grep -v 'bc\*'

(yes, I'm insane)

It's a little step that was necessary for current Cooker, but it can also help to switch to PATA drivers in a simple way (by just modifying the driver in our pcitable). And we will probably do so soon, as Alan Cox's libata PATA status looks quite encouraging.



Lately, I've been quite busy building a lot of various Mandriva Flash versions.

We recently offered Mandriva Flash keys to KDE developpers, and this was a special version of the latest Flash 2007, not just a random one that we got on stock :-p

Of course, it contained a special Mandriva/aKademy theme (background images and bootsplash), but this is not the more exciting feature.

This Flash key can be extended to run a KDE4 desktop, by putting an additionnal KDE4 module on the key. It contains a KDE4 desktop snapshot (basically alpha 2) with Nepomuk features. It is roughly made of KDE4 packages from Cooker rebuilt for 2007.0, with only a few hacks, and a custom background (our logo with drop shadows, using gimp which now works on Cooker!).

This was quite the first time that we did such an additionnal module (there is already some support for lang modules in the next Flash 2007 Spring version, but that's secret :-p). To make it short, creating this module was about mounting the Flash loopback and a temporary directory using unionfs, chroot inside the union, install KDE4 packages, cleaning a bit, and compress the temporary directory into a new squashfs loopback.

Nothing really extra-ordinary, but I was amazed by how fast we did it, the KDE4 packages from Helio (almost) worked out of the box, and the build process of the Flash module went quite smoothly.

So, thank you KDE hackers for all your work, I hope you have enjoyed aKademy 2007 as well as our special release!



This week-end, I wanted to edit a chestnut image, to put some brightness on this blog (and I love doing chestnut things). So, I fired up cooker's gimp. But I didn't really expect this marathon...

First, gimp 2.317 is not really usable, as explained on the release notes, mainly because of a segfault on selection copy. So, I backported revision 22643 patch from Gimp, and rebuilt the package. It still again. After the backport of several more patches that make proper use of g_slice, gimp still failed to run properly.

But this time, it was because of a mysterious Xlib error. On IRC, Liam pointed me to an upstream report that incrimates Xlib. The crash appearing in the latest 1.1.2 libX11 release.

So, I had to run a bisection on about 24 commits. I did that by rebuilding a snaphost of each revision and the rpm package (adding automake -a and autoheader calls to build from raw tarball).

$ git clone git://anongit.freedesktop.org/git/xorg/lib/libX11
$ cd libX11/
$ git-bisect start
$ git-bisect bad
$ git bisect good libX11-1.1.1

# (note to self, do not forget the trailing slash in prefix...)
$ git archive --format=tar --prefix=libX11-1.1.2/
 f93849dcc68bd5042ea0884e5190dc7c35b31d68 | bzip2 >
 /home/blino/vc/mandriva/packages/cooker/libx11/SOURCES/libX11-1.1.2.tar.bz2
$ git bisect good f93849dcc68bd5042ea0884e5190dc7c35b31d68
# try next suggested commit
$ git archive --format=tar --prefix=libX11-1.1.2/
 95523387d619af5b400748898d722e080b5ce1a6 | bzip2 >
 /home/blino/vc/mandriva/packages/cooker/libx11/SOURCES/libX11-1.1.2.tar.bz2
$ git bisect bad 95523387d619af5b400748898d722e080b5ce1a6
# and so on...
$ git bisect good 605d357074d556a05a3fba2e85cbea36a3204248
 a48386ce6b5f8fd2d9dc11a966c9bf5da59f3831 is first bad commit
 commit a48386ce6b5f8fd2d9dc11a966c9bf5da59f3831
 Author: Magnus Kessler <Magnus.Kessler@gmx.net>
 Date:   Tue May 1 15:20:08 2007 +0200

   Switched function definitions from K&R to ANSI style.

 :040000 040000 78bcf3e9c54ff02d77c2e590e10d36bbe00610b4da6cdb57564533f1084b2ea2b9888c12884b151e M      src

Unfortunately, this "codestyle" patch was about 3000 lines long, let's go for another bisection round...

$ git log -p a48386ce6b5f8fd2d9dc11a966c9bf5da59f3831 >
 /home/blino/vc/mandriva/packages/cooker/libx11/SOURCES/libX11-1.1.2-codestyle.patch

# revert patch on libX11 1.1.1
(cd BUILD/libX11-1.1.2/; patch -p1 < ../../SOURCES/libX11-1.1.2-codestyle.patch)
# edit patch and remove some hunks, using manual bisection /o\
(cd BUILD/libX11-1.1.2/; patch -R -p1 < ../../SOURCES/libX11-1.1.2-codestyle.patch && make -j4) &&
  bm -l -i   --short-circuit && bm -l -b --short-circuit
# try testcase

After half a dozen of tries, I found the culprit, where XGetMotionEvents() arguments order was not corrected during the codestyle update.

The fix was a trivial patch that I submitted in an upstream bug report.

Finally, gimp works \o/ but my initial photograph is barely usable, the poor chestnuts being incomplete or too dark :-/ (and I was too tired to proceed with crafty tactics...)

I also submitted a 2.3.17 gimp package with my backports in cooker, but the build system was borked (for a change). And gimp 2.3.18 has been released in the meantime, gee!



Yesterday, Intel released the PowerTOP utility. It allows to monitor closely the power consumption and to diagnose what software is using the most power.

It requires (at least) a 2.6.21 kernel with /proc/timer_stat (enabled through CONFIG_TIMER_STATS, [commit]).

I've just made this tool available in Mandriva Cooker, in the powertop package. I'm afraid it will unearth some very bad habits from net_applet... (will try as soon as we have a 2.6.21 kernel ready for Cooker)



/blog/mandriva Media days Sat, 12 May 2007

These days, there have been quite some media occurences about my contribution in Mandriva.

First, there was my interview for the 01net article about compiz/beryl merge (which seems to happen as planned, expect packages soon!)

My early technical specs for Mandriva 2008 also got me some nice quotes in DistroWatch Weekly, Issue 200, 30 April 2007 and LWN.net Weekly Edition for May 3, 2007 (as well as in Beranger's blog \o/)

Next, we have been interviewed at Mandriva by a Radio Canada TV crew, about Mandriva Flash and its (hopefully brilliant) future.

Finally, my articles about Mandriva 2007 Spring have been published in a new magazine, Linux Identity's Mandriva 2007 Spring Kit. This includes:

  • 3D desktop environments in Mandriva [PDF article (in French)]
  • System virtualization technologies: VirtualBox, VMware, Xen and QEMU with KVM
  • Laptop support: enhanced power management, stand by and hibernation modes
  • Package management: installation, deinstallation and updates

Looks very much like Spring announces Mandriva's revival \o/



Basesystem

udev

  • do PCI coldplug
  • drop udevstart and use udevtrigger (+ Fedora's start_udev)
  • migrate conf.d hooks in start_udev
  • migrate (and merge?) sound and alsa services in udev rules
  • use upstream helpers for persistent rules (net + block), port useful features from our scripts in these helpers and send upstream

mkinitrd

  • maybe switch to mkinitramfs (see with Luca Berra)
  • allow to use initrd scriptlets in a hooks directory (for live initrd generation)

Hardware detection

  • drop most of pcitable and use modalias + pci.ids for modules detection (need to modify ldetect and drakx's detect_devices)
  • drop usbtable by auto-extracting modaliases from pre-built dkms packages, and merging them in an additionnal modalias file (maybe /etc/modprobe.d/dkms-aliases.conf)

Kernel drivers

  • use dkms packages for most thirdparty drivers (mostly thinking about network drivers such as ndiswrapper, ralink and rfswitch modules, but also lirc, lufs)
  • create virtual -latest packages for pre-built dkms drivers (to allow auto-upgrade of these pre-built drivers)

Graphical splash

Power management

  • push pm-utils modifications upstream
  • better splash integration
  • hybrid suspend mode (disk + RAM)

Network

Drivers

  • use iwlwifi for Intel Wireless 3945ABG
  • consider switching to rt2x00 drivers

Tools

  • WPA-EAP support in drakx-net (login + pass, certificates)
  • finish network-center

Live

  • use squashfs + lzma (requires a special squashfs kernel module), it allows live CDs to be about 100 MB smaller
  • use readahead + loopback ordering to speed up boot ("reloaded" spec), maybe use a kernel module to log file access order (code is already written)
  • improve modules detection ("reloaded" edition as well) not to bruteforce by loading all modules anymore: could be done using either drakx's stage1, or some a la udevstart detection ("a la main" in /sys, or ship udevd + udevtrigger in initrd)
  • allow to select packages and langs to be installed during live install
  • maybe allow to run live from Windows (through qemu)

3D desktop

  • come along potential compiz + beryl merge
  • consider input transformation applications

Games

  • SecondLife: add OpenAL support (by coding it)
  • Wiimote: use new cwiid features (per-application configuration) and integrate it in games packages
  • create a drakjoy joystick calibration tool

Virtualization

  • improve Xen packaging (fix network issues, automate initrd creation, maybe merge xen0 and xenU kernels)

drakvirt

  • consider relying on virt-manager for guest creation functions
  • add basic features such as installing to a device or running a random install (not only Mandriva)
  • copy /lib/modules/<version> in the installed guest if needed
  • network configuration support
  • allow to run a graphical Xen VM
  • qemu support


This week, I've been interviewed (together with Vincent Guardiola and Frederic Crozat) by the 01net online magazine about 3D desktops in Mandriva, especially about the ongoing compiz and beryl merge.

Here it is (in French): Les interfaces 3D de Linux ne font plus qu'un



Lately, I experienced some freezes during night, which revealed to happen when a cron job rotated the apache logs and tried to restart httpd with an USR1 signal.

This makes Apache 2.0 run "internal dummy connection" sub-requests on its child processes:

127.0.0.1 - - [07/Apr/2007:04:07:39 +0200] "GET / HTTP/1.0" 200 8145 "-"
"Apache/2.2.4 (Mandriva Linux/PREFORK-6mdv2007.1) (internal dummy connection)"

In my case, I use the Prefork MPM, and there were hundreds of sub-requests triggered in a few minutes, my home page being handled by blosxom and running a perl interpreter for each request... After a few minutes, this internal DoS made my box quite unresponsive, and never came back to normal (maybe there's also a bug in my 2.6.17 kernel).

A workaround has beeen to use a mod_rewrite rule to use static content for /, as suggested on the upstream ML and by other users:

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} internal\ dummy\ connection
RewriteRule ^/$ /static/style.css [L]

A solution is being worked at upstream, it could be using an OPTIONS * request instead of GET /, but it seems it has not been implemented yet...



On Thursday, we launched a new 4GB version of Mandriva Flash.

It is not only twice bigger than the first version, but it also add some useful features, such as the ability to resize the system space at first boot. You can choose to allocate from 150M to 3GB to the system space (which includes /home and modifications to the root filesystem), the remaining space on the FAT partition being used to share documents with other operating systems.

Of course, it also includes all the 2007.0 bugfixes available at the build time of this new image, and some additional Flash-related fixes: the infamous Xkb bug under Xgl is no more (the patch was roughly a chmod 1777 /var/tmp), and the loopback filesystem check at boot is more automated. Furthermore, the new Flash will fallback to a tmpfs filesystem if the ext2 loopback happens to be corrupted.

To conclude, I'll let myself quote myself from the press release :-)

"On this upgraded Mandriva Flash version, the space allocated to the system files can be chosen at first boot. This makes possible to install more updates and additional packages, in response to user feedback we got on the initial version"



This week, one of the most critical bug left in our 2007 Spring release candidate was about the fglrx proprietary driver for ATI cards. It made the screen turn black when resetting an Xsession, making the system unusable locally (#29550).

Worse, during the first boot of a Mandriva One after installation, it made the first X session unusable...

To workaround this, we used the same workaround that had to be used in Mandriva 2007.1 for repeat logins with AIGLX, which is to restart the X server instead of resetting it. I've patched our DrakX libs so that harddrake and XFdrake set the correct options in kdm and gdm configuration files when the fglrx driver is used.

Maybe the 8.35.5 release of the fglrx driver would solve that, the changelog shows a bugfix for a similar issue, but we were to close from release to switched to a new fglrx driver.

Too bad we still need proprietary drivers for high-end ATI cards :-/



Next Thursday, Mandriva is organizing a party in Paris, mostly about Mandriva and free software, together with Libre en fete.

For example, we will play the DDR game StepMania, demo the 3D creation suite blender (that will remind me very old souvenirs), and show a lot of free-software releated videos.

Of course, it wouldn't really be a Mandriva event if it wasn't totally open, so you will be able to enjoy an open-bar (no kidding!), as well as a nice buffet.

It's taking place at the Jet Lag, a nice restaurant in the very center of Paris, and it's 25 euros for the whole party (open drinks + meal + total fun). And we will have the whole restaurant for us \o/

Hurry up, it's March 22, next week!

Please see LibreEnFete on Club for more info about the party and subscription details. And thanks Emilie for the organization :-)



After a buzzy idea storm, Dell is starting a survey about Linux.

It still does not include Mandriva, even after some popular Mandriva requests on their Digg-like blog.

Well, this time, there is an entry box to specify your preferred Linux distribution, don't forget Mandriva :-)



image

Today, we got a linutop box at Mandriva, it is a small Linux-based diskless computer. It comes with a 1 GB USB key, containing a Xubuntu distribution (thus running XFce).

Without surprise, it is Mandriva compatible, since your Mandriva Flash USB key boots smoothly on it.

The boot process is a bit slow, probably because of the Geode processor, but once KDE is loaded, it looks usable (provided you don't run OpenOffice :-p).

I'll try to get the AMD Geode Xorg driver in the 2007.1 release before the freeze (which is now /o\).



Maniadrive, a cool racing game that unfortunately uses php, has been broken recently in cooker, because of the suhosin php hardening solution.

It did not break because suhosin is enabled, that is not a problem, but because it tried to hook functions and call them even if NULL... A simple patch fixes it.

I love hardening "features" (RSBAC, anyone? :-p)



It's not spring yet, even if it's getting warmer these days, but you can get a preview of what it's gonna be in Mandriva Cooker.

After having fought with the warly's legacy in the mandriva-theme package, I've successfully merged the neat artwork from Hélène in our theme packages.

MandrivaSpring

Some "hibernation" images are included as well, they will soon be integrated in the splash scripts to be used during hibernate.



The KDE window decorator for compiz is now built in the cooker package. Decorators have been splitted in their own sub-packages (compiz-decorator-gtk and compiz-decorator-kde), so that KDE libs are not pulled if KDE is not installed.

A compiz-window-decorator wrapper auto-selects the most suitable window decorator, based on the running desktop and on the available decorators.

This will notably fix the famous Alt+F2 bug in KDE desktops (even if I have a pending fix to automatically adjust this shortcut for older versions of compiz).



So, that's it, warly is gone (from Mandriva).

Tonight, we had his departure party, which was really nice, it's probably the best celebration we have done for months: almost all the company was here, even sage gurus and missed co-workers that left the company came back to "celebrate" the event with us.

warly prepared a lot of food and drinks (actually more than reasonable), and his most dedicated right hand men baked some nice (well, maybe not so nice for mine) delicacies. Too bad everybody was frightened to open the surströmming we've kept growing for years now (thanks oden!).

As usual, it was also a lot of fun! We even played DDR, thanks to the Gaming DVD I prepared earlier for the Club. It has been a bit tricky to get additionnal (non-free) songs, but we managed to do it, live. Congratulations to leeloo who defeated me and most of the people more than we would have hopped! Sylvie is still an awesome competitor as well :-p

Still, it's sad to imagine that next week I won't see warly again in front of my desk, while he has been my boss for more or less 3 years. I think all the company will miss him, both professionally and personally.

He has often been blamed (by contributors, co-workers) for many things. But if we have a look at the big long-term picture, his decisions were quite always sensible, and he helped us by making compromises. warly was sort of our super-jack-bauer guy :-)

We used to rely a lot on him, probably too much, and it will be different (not to say hard) to prepare the next Mandriva release without him. warly has done a lot in his final weeks at Mandriva to share his knowledge, explain his projects, and distribute his workload among co-workers, so it's up to us now. Though, don't worry too much, we will all work hard(er) to build an amazing realease, with more features, a stable core basesystem, and neat artwork.

I'd like to thank warly for all the things he did for Mandriva, and me in particular. I owe my job pretty much to him (and Fred), and he has always been a brilliant leader, very valuable, strong, wise, understanding (and weird enough for us :-p).

We had great moments together: roller rides, strange culinary artistic experiences (some would say experimentations), trips abroad, enjoying reads, and much more... His departure does not make our friendship over, and I guess we will have a lot of occasions to outperform all that :-)

Well, good bye dear manager dude, the family will miss you.



Lately, Helio and I fixed bluetooth pairing by backporting a patch from kmobiletools that allows the sample passkey agent to run a user helper on D-Bus events, and by starting it at X11 session startup (#24359).

I got broken in Cooker recently, during the switch to Bluez 3.9 (#28555), but it should now be back to normal.

Hopefully, this will help to get bluetooth dial-up networking work out-of-the-box for both GPRS and CDMA in next beta release ;-)



blosxom Optimised for standards.
Olivier Blin (2005)