There are a couple of bugs that really would need more attention. I started a short list here, if you want to find more - just look at http://bts.turmzimmer.net/.

• 364038: evolution: message moved from one imap server to another vanish under certain circumstances
• 370186: hal: HAL keeps CD drive spinning constantly
• 202488: isdnvboxserver: Spool directory incorrectly renamed on upgrade
• 330084: xawtv-plugin-qt: segfaults on start recording
• 379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition (also as parted-bug, #380226, partman-partitioning, #379835)

Ok so I have added a check to my blah.pl because it seems that sometimes it emitted event in a loop, causing irssi to segfault with a 600 MB core dump. What a shame, you now know why I have been disconnected 3 times from IRC today.

So, last week was a bit bumpy since I was sick for a couple of days, and then had a power outage on Friday and Saturday, thus not being able to keep up with my daily RC bug fixing, but I've been catching up since then. I've uploaded patches done by Arjan Oosting, for packages that wouldn't compile with autoconf2.6: #379812 (kde-style-polyester), #379813 (kxmleditor) and #379815 (klog).

I uploaded a patch by Mart n Ferrari for lilo: #374477 (use MAKEDEV instead of mknod at postinst), and another patch by Mart n for courier-authlib #378571 (fixing the permissions of /var/run/courier/authdaemon).

I uploaded a patch by Andreas Jochens for ntlmaps: #379700 (fixing the build-dependency). A patch by Luca Bruno for predict: #379495 (fixing a change of location of forms.h). And a patch by Mike O'Connor for stardict: #379152 (fixing a misuse of size_t that made it fail in 64bit architectures).
Stardict had a problem with rpath that made me get to know the LIBTOOL_IS_A_FOOL hack, and I had to apply that, so that the binaries were not screwed up.

I also uploaded a fixed version of yacas, that included patches from Arjan Oosting (fixing #379261 and #379895) and Braun Gabor (fixing non-RC #295413). However, it's not like the only thing I've done is upload patches done by others. I've also done some patches myself:

• #379275, fixing fillets-ng's FTBFS.
• #379486, fixing a bashism in cbuild.
• #379200, changing PWD for CURDIR so that sudo works for building bluez-utils.
• #377781, fixing monotone so that it builds with the latest gcc, although it took a new upstream release for it to build in hppa.
• #378173, adding some checks for NULL, so that the new libsdl1.2-image does not make programs segfault
• #381248, dropping PAGE_SIZE in favour of sysconf(_SC_PAGESIZE) in libsdl1.2 so that it builds in powerpc

The amount of bugs currently affecting the next release is 247. It's not a secret that we are a bit behind the schedule (we should be at less than 200 bugs by now). But it's also totally possible to get back on track if we work together on fixing the current bugs and we stop uploading unneeded new releases that trigger new transitions.

A new multifunction device (a Samsung SCX-4200) was recently bought at home. It “supports” Linux via a proprietary, binary-only driver that does not let you scan except as root. A normal user receives a Segmentation Fault. Of course, the installer “fixes” it by adding a setuid wrapper to xsane… As I didn’t like that “solution” very much, I investigated a bit and learned that the Segfault happened after “scanimage -L” called the iopl() syscall. That call is used to be able to access I/O ports directly, and can only be called by a process running as root. That driver’s name was “Unified Driver blah, blah, blah". That means that it “supports” a lot of multifunction devices, among them several that run plugged into the parallel port, and the driver was trying to detect a parallel port device by accessing the parallel port directly, and that’s why it called iopl(). After a couple of hours (I don’t do it every day, mind you) trying objdump and gdb and a hex editor (biew, which helpfully includes a disassembler too to guide you in your hex editing adventures) I managed to disable the parallel port check and make the driver a bit less insane (now I only need to make users who need to use the scanner members of the “lp” group). I guess that it means that you don’t really need source code to modify your drivers and firmware (picture yourself a tongue well stuck to my cheek). To be helpful I made the modified version, with instructions and HOWTO, available at http://jacobo.tarrio.org/Samsung_SCX-4200_on_Debian. Copyrights be damned, I shouldn’t have had to do it.

So, in my previous blog post, I mentioned that Enlightenment, bug-ridden as it is, is the only application I've seen thus far that implements edge flipping the right way. Since it's been a long time since I last used the only windowmanager that actually implements it the right way, I've been able to give it quite some thought by now. Here's my take at it: The central thing to remember is that the edge flipping interface will trigger accidentally. No matter how well you implement your interface, sometimes a user will accidentally move his or her mouse, or he/she will want to click somethin near the edge of the screen and touch it. Therefore, there are two things an implementer should do:

1. Make every effort to avoid accidental edge flipping where possible, and
2. Make it as easy as possible for the user to correct an accidental triggering of the interface.

The best way is to make sure your interface has the following characteristics:

• The code should not trigger if the mousebutton is pressed down. The reason for this is that many people like to maximise their windows, and that many interfaces keep their scrollbars near the edge of the window. Scrolling is often accomplished by moving the mouse over the scrollbar; and since human beings are not machines, it's usually impossible for them to move their mouse in a straight line. It's fair to say that when you're holding your mouse down, you're usually not interested in edge flipping. GNOME's brightside gets this wrong, which makes it a horrible nightmare.
• The code should not trigger immediately. When you move your mouse, it's fairly common to touch the edge of the screen. Thus, edge flipping should only happen after a delay. However, when it is happening, it should continue to do edge flipping until the mouse has not touched the edge anymore before another delay has passed (otherwise moving two or three workspaces at once takes too much time). While I haven't seen any implementation get this horribly wrong, I've seen implementations get this wrong in their default configuration (again, brightside).

Getting the above two right will ensure that accidental edge flipping is reduced to a minimum. This is the first step, and one that only Enlightenment and IceWM got right. The final step, however, is something that IceWM does not get right; and this is what makes Enlightenment's edge flipping implementation such a natural thing to do:

• After edge flipping, warp the mouse to the opposite side of the screen, just far enough away from the edge so that it will not immediately flip back again.

Some people will find that last point evil, I'm sure. I'll admit it took me a while to get accustomed to it as well. But it's the only natural thing to do. You should think of your virtual workspaces as one large desktop; if you're using four workspaces next to eachother, that means one large desktop four workspaces wide. When you move the mouse one quarter to the left, it's normal that it ends up about the same place on that same desktop. In other words, warp the mouse. Additionally, the mouse warping will have the effect that it makes recovery from accidental edge flipping easy and fast. If the mouse stays where it was after edge flipping (as in the case of brightside and IceWM), then if I accidentally hit my mouse, by the time I've moved my arm towards the mouse and started moving it back, I've moved away three workspaces from where I was already (because of the second bullet point in this post). If, however, the mouse does warp to the opposite side of the screen (i.e., the side where it was coming from), then going back to where you were is just a matter of moving the mouse a few millimeters in the opposite direction. Very easy to accomplish, that... Oh, and finally, you also shouldn't segfault at random. Again something that brightside did not get right when I used it—did I mention that brightside is crap? Well, I did now. Hopefully it's changed for the better in the mean time. Back in my Enlightenment days, I used workspaces a lot, because Enlightenment made it so natural with its excellent edge flipping implementation, and with the help of the pagers which would always, at any time, give me a snapshot of all my workspaces, helping me to remember where this or that application was running. IceWM doesn't replace that, but it sure gets close.

I had been an Enlightenment user for a long time—halfway the Summer of 2000 up to the early fall of 2004—before someone finally decided to pick up the pieces where they were left somewhere around 2000 and restart its development. Unfortunately, that also meant causing #219925, which was irritating me more and more each day. Eventually, in the early fall of 2004 (almost a year after I filed that bug), I gave up and started looking for something else. The problem, of course, was that I'd grown so accustomed to using Enlightenment and its way of doing things that I felt at a loss. I wanted to be able to move windows above the upper edge of my screen again. I needed focus-follows-mouse. I was having a hard time without edge-flipping. Eventually I found that there was functionality for all of the above, but it wasn't flawless. Especially not the edge flipping—GNOME implements that in a truly horrible way¹. Not to mention the fact that brightside, the application which implements edge-flipping for GNOME, segfaulted on me an annoyingly high number of times, sometimes even taking away my entire session with it. Even Enlightenment never did that; it would just misbehave instead. Apart from that, of course GNOME also had some extra annoyances that I didn't get rid of. The fact that it insists on mucking with my keyboard settings, to name just one example. Even so, I used it for about nine months. Then, slightly after DebConf5 in Helsinki, I realized what the true horror of GNOME is: not the fact that they hide away features or try to make the desktop void of superfluous options; the fact that they remove features that are critical to some of its users. I know I was horrified to find out that something I really used a lot had been removed in that new release. I kept using it for three more months before I threw in the towel and tried something totally different. Ion3. After coming from the mostly mouse-oriented interfaces that GNOME and Enlightenment were, ion3 was truly different. I liked it at first; it was a welcome change from what I'd previously been doing. Eventually, though, I found that the ion way of doing things just wasn't my way. The fact that, by default, it puts new windows right in front of the window you're working on was rather offputting. Any serious attempt at configuring the thing involves learning lua which, though supposedly not hard to do, is not something I ever found the time for. In the end, I discovered that I disliked working with ion, as I often felt that it gave me a fragmented and tunneled view on the world, and that it was working with me instead of the other way around. In short, it was getting the fun out of computing for me. Which wasn't good, at all. So that's when I started looking for something else again. When I'd made the decision to move way from ion3, I didn't want to keep using that "until I'd found something else"; instead, I quickly installed IceWM instead—which I still knew from back when I had a Yopy YP3000—and used that until I had found something better. Little did I know the beaty of IceWM. I've decided, by now, that it does all I need, and more: By default, it tries the best it can to put a window on your screen so that it overlaps with as little other windows as possible. I can have it not focus a new window by default. I does focus-follows-mouse, if enabled. It even does edge-flipping. Of course it's not perfect—the edge-flipping, though not as horrible as the GNOME implementation, can still use some improvement. As if to prove my point, I accidentally closed the window in which I was writing this very post before it had been written to disk, the cause of which could be described as an interface problem in IceWM (though it's more likely an example of PEBMAC (Problem Exists Between Mouse And Chair). But, all in all, using IceWM feels like finally coming home. Thanks, Marko and Mathias, for a truly wonderful piece of software. ¹ I know that there are a lot of people who dislike edge-flipping. I am 99% sure that this is because they've never seen it implemented right. Edge-flipping is great, if done right; it's nightmare if done wrong. GNOME does it horribly wrong. IceWM does it better, though not perfect. The implementation in Enlightenment is perfect. I'll discuss the details in another post.

www.hoehenmeter.com is interesting. I can check there how often I went snowboarding this winter with my season ticket, how many times I used which lift on a specific day and - as the domainname suggests - meters in altitude per run and day. I was pleasantly surprised that I had managed 25 days although my season was cut short due to scribed (but not completely torn) ligaments in my ankle joint. See below one of my longer days.

29.01.2006 Damüls

time	location	minutes	meters in altitude
09:15	Uga Bergfahrt	5	448m
09:29	Hasenbühel	6	512m
…
15:30	Walisgaden	3	163m
total			10247m

Update: More data here.

I would like to highlight some of the more important changes about sarge r2. They have been placed in the official announcement not as noticeable as I would have hoped.

Notable Changes
---------------
Sudo has been changed to not propagate all environment variables to
subsequent programs to avoid security risks.  This change might affect
software that uses sudo.  Please see /usr/share/doc/sudo/README.Debian
for more details.
Miscellaneous Bugfixes
----------------------
This revision adds important corrections to the following packages.
Most of them don't affect the security of the system, but may affect
data integrity.
	affix-kernel           Fix build failures with sarge's kernel
	
	backuppc               Fix possible backup archive corruption and
			       possible data loss when changing the
                               configuration file
	
	cernlib                License problems, repackaged
	
	cyrus-imapd            Don't remove mail data on package purge
	
	cyrus21-imapd          Note cyrus-imapd data loss on package purge in
                               upgrade documentation
			       
	evms                   Fix address stack corruption leading to possible
			       data loss when activating degraded RAID-5
                               volumes
			       
	exim4                  Fix mail delivery problems to hosts with AAAA
                               DNS records and unbalanced DNS
			       
	f-prot-installer       Adjusted to work with recent releases
	
	fai                    Fix setup of lo device, replaced hardcoded name
			       of debian distribution in fai-cd, add missing
                               packages when calling fai-mirror
	glibc                  Update timezone data, fix NPTL for x86_64 (amd64)
	
	leafnode               Fix security issue (CVE 2005-1911)
	
	libchipcard            Don't remove user account on package purge
	
	mutt                   Fix possible attachments data loss
	perl                   Fix problem with utf-8/taint interaction
	                       Fix possible malloc-to-death bug, #227621
	rssh                   Fix security issue (CVE-2005-3345)
	slune                  Adjust to security fix in py2play, #326976
	sodipodi               Fix segfaults on 64-bit architectures
	tar                    Fix inability to work with remote devices
                               on non-i386, #356657

If you're using Debian unstable on powerpc and haven't done your update today yet, might I suggest you hold off on that for a few days?

apr 13 09:14:28 <Yoe>	xorg 7 also seriuosly messed up fonts
apr 13 09:14:48 <Yoe>	"display" from imagemagick doesn't work anymore, and neither does rxvt-unicode
apr 13 09:15:02 <Yoe>	so how am I supposed to do *anything* useful, now? ;)
apr 13 09:15:04 <simonrvn>	i've been using 7 from experimental, so i had to change my fontpath in xorg.conf
apr 13 09:15:10 <simonrvn>	was
apr 13 09:15:19 <Yoe>	oh?
apr 13 09:15:36 <simonrvn>	/usr/share/fonts/X11
apr 13 09:15:39 <Yoe>	is that documented somewhere?
apr 13 09:15:42 <Yoe>	ah
apr 13 09:15:55 <simonrvn>	might be, not sure
apr 13 09:16:16 <Yoe>	hmm
apr 13 09:16:16 <simonrvn>	though don't remove the old ones, add those, since some of the packages still use the old path
apr 13 09:16:26 <Yoe>	well, not here, aparently
apr 13 09:16:36 <Yoe>	my FontPaths all point to /usr/lib/X11/fonts/misc,
apr 13 09:16:37 <simonrvn>	if it is, either BTS or one of the READMEs
apr 13 09:16:44 <Yoe>	s/misc//
apr 13 09:17:06 <Yoe>	and /usr/lib/X11/fonts is a symlink to '../../share/fonts/X11'
apr 13 09:17:11 <Yoe>	which does not exist.
apr 13 09:17:27 <ejka>	Yoe: dpkg -l xfonts-base
apr 13 09:17:41 <Yoe>	that's installed
apr 13 09:17:53 <Yoe>	... but still the 6.9.0 version
apr 13 09:17:53 <ejka>	Yoe: version
apr 13 09:18:04 <simonrvn>	l /usr/share/fonts/X11/75dpi: -rw-r--r-- 1 root root 4.1K 2006-04-11 00:32 charB08.pcf.gz ....
apr 13 09:18:41 <Yoe>	ah
apr 13 09:18:51 <Yoe>	xfonts-base depends on xfonts-utils, which isn't available (yet)
apr 13 09:18:59 <Yoe>	so I s'ppose I'll need to wait another day
apr 13 09:19:02 <Yoe>	(powerpc here)
apr 13 09:20:25 <ejka>	Yoe: for now you can add fontpaths /usr/X11R6/lib/X11/fonts/ misc,... 
apr 13 09:20:49 <simonrvn>	xfonts-utils *just came in to ppc today (sid)
apr 13 09:20:55 <simonrvn>	*just*
apr 13 09:21:10 -->	gismo (i=luca@129.194.56.110) has joined #debian-devel
apr 13 09:21:37 <Yoe>	right
apr 13 09:21:42 <Yoe>	brb, restart X server
apr 13 09:21:43 Tcl interface unloaded
apr 13 09:21:43 Python interface unloaded
**** LOGGEN GESTOPT OM Thu Apr 13 09:21:43 2006

Hah.

wouter@country:~$ startx
bash: startx: command not found
wouter@country:~$ X
X: cannot stat /etc/X11/X (No such file or directory), aborting.
wouter@country:~$ su -
Password: 
country:~# apt-get install xserver-xorg
Reading package lists... Done
Building dependency tree... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
Since you only requested a single operation it is extremely likely that
the package is simply not installable and a bug report against
that package should be filed.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
  xserver-xorg: Depends: xserver-xorg-core but it is not installable
                Depends: xserver-xorg-video-all but it is not going to be installed or
                         xserver-xorg-video but it is not installable
                Depends: xserver-xorg-input-all but it is not going to be installed or
                         xserver-xorg-input but it is not installable
E: Broken packages
country:~# apt-get install xserver-xorg-core
Reading package lists... Done
Building dependency tree... Done
Package xserver-xorg-core is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package xserver-xorg-core has no installation candidate
country:~# apt-get build-dep xserver-xorg-core
Reading package lists... Done
Building dependency tree... Done
E: Build-Depends dependency for xserver-xorg-core cannot be satisfied because no available versions of package libxmuu-dev can satisfy version requirements

Believe me, it's painful to have no X server available. Update: okay, by getting packages from experimental I've been able to get myself a somewhat working X again. Except that xkb doesn't load my modified keymap, which is horrible, and setxkbmap refuses to do anything when I say "setxkbmap wouter" and, on top of that, quits by segfault for good measure. I'm hoping that's fixed in the version that's been uploaded to unstable, but I can't check that—at the time of writing,buildd.debian.org doesn't even have a log file for some of the xorg stuff yet. Though some parts are in the building state at this very moment...

Joe muses about Xlib and connection aborts. Two things:

Yes, libX11 is going away. It's unfixably broken (not only is the implementation utterly horrendous, but the concept is exactly what toolkits don't want), and we can't change existing behaviours because libX11 is just one of those API/ABIs you cannot break.

Yes, the ability to recover from connection aborts is essential. D-BUS is broken in the exact same way, yet some people feel inclined to defend it (e.g. mandating reboots when either of the D-BUS daemon, or libdbus, are upgraded; advocating segfaults in client applications when the bus dies as the right thing to do?!?). I don't think either behaviour is in the least bit sensible, and it would be really keen if both could be fixed (by using XCB in toolkits for the former, by fixing libdbus to be less obnoxious for the latter).

Last weekend I found myself looking for something to hack on that wasn't something I see during my work day. I took a look at <a href="http://www.hula-project.org/Hula_Project">Hula</a>. I've wanted something like this for use at home. It would be nice if <span class='ljuser' style='white-space: nowrap;'><a href='http://auzure-skies.livejournal.com/profile'><img src='http://stat.livejournal.com/img/userinfo.gif' alt='[info]' width='17' height='17' style='vertical-align: bottom; border: 0;' /></a><a href='http://auzure-skies.livejournal.com/'><b>auzure_skies</b></a></span> and I could see one another's calendar, have our own Jabber server, and have easy access to our email through a local client or through webmail.<br /><br />There seem to be a steady stream of commits to Hula's SVN, but almost no discussion on the mailing list. I've sent in <a href="http://forge.novell.com/modules/xfmod/maillist/archbrowse.php/hula-dev/2006-March/001012.html?id=1613&amp;prjname=hula&amp;mlname=dev">one patch</a> to the Makefile so that make dist would run (<a href="http://forge.novell.com/modules/xfmod/maillist/archbrowse.php/hula-dev/2006-April/001014.html?id=1613&amp;prjname=hula&amp;mlname=dev">accepted</a>), and sent <a href="http://forge.novell.com/modules/xfmod/maillist/archbrowse.php/hula-dev/2006-April/001013.html?id=1613&amp;prjname=hula&amp;mlname=dev">another</a> asking for design information (No answer yet). In general, the codebase seems crufted with a bunch of legacy NetWare concepts. It's written in at least four languages (C, C , C#, and Python) and doesn't seem to have a testsuite. The code also currently doesn't run on powerpc without segfaulting.<br /><br />Ah well. Anyone know if there's another project that has similar aims and goals? Basically some sort of server software that will handle almost all of what evolution can hand to it, plus some sort of extensible interface so that it's reasonably easy to add things like Jabber servers, RSS/Atom Aggregators, etc.

Please do not hide the arguments given to the compiler from me.

It's hard to realize something is going wrong if you do not see what is happening. If the argument list is too long, do something against that instead of hiding it.

Make sure you follow policy when packaging software

Debian packages should be compiled with -Wall -g, but more and more do not. Please check you do, but check at the correct place. Do not look into the debian/rules file, but in the build log. If the Makefile sets a default with a single equal sign ("="), running 'CFLAGS="-Wall -g -O2" make' will not suffice. Try 'make CFLAGS="-Wall -g -O2"' instead. (Actually, there is no good reason to put them before the command. Always try to put things as arguments first, both with make or with ./configure)

It really makes everyone's live easier if those options are set.

Keep the argument list tidy.

Many argument lists are longer than necessary. If there is some -I/ in the argument list on a Debian system, there is something fishy. (It's not the universial collection of different stuff all going whereever it wants, after all). Common cases are:

- buggy scripts to add -I/usr/include

Better fix those scripts. Also make sure they do not cause other problems, like linking your program against libraries your program does not use directly. (Possibly causing funny segfaults when those libs link against other versions of those libraries)

- -I/usr/X11R6/include

For upstream packages this might perhaps be useful to support older operating systems and people unable to give it to CFLAGS themselves. But for FHS systems, this is not needed at all, as it mandates this handy /usr/include/X11 -> /usr/X11R6/include/X11 symlink. And newer X directly puts the headers in the correct place.

- packages working around upstreams breaking compatibility

Life would be too easy if upstream would not break APIs. But if they make a new incompatible version, and even change the library name for that, would it have been that difficult to also change what programs written/ported for that new incompatible API have to place in their #include line?

- plainly broken upstreams

putting stuff in $ PREFIX /include/subdir/ and #include'ing other files from that subdirectory without the subdir deserves application of some large LART.

- oversight

often it is just not necessary, and everything gets much more readable and easier if left away.

Other things makeing things unreadable are large armounts of -Ds generated by ./configure. AM_CONFIG_HEADER can help here a lot with non-path stuff. Stuff containing paths is suprisingly often not used at all.

Mono 1.1.8.1 was uploaded to Debian/Unstable on Wednesday and is now waiting in the NEW queue (because of the new packages like mono-classlib-1.0/2.0 which I blogged already about).
I also uploaded the packages to debian.meebey.net (versioned as preview packages), which are the same packages, so if you can't wait use the preview repository please. I just filed all removal requests that are needed to get Mono into Debian/Etch, when those are processed, it should go in. Also the CLI Policy draft is almost complete to be official, it defines basic rules now which are required for an user friendly, unified and stable CLI integration in Debian with Mono (and other CLRs like dotGNU) and CLI applications.
With the CLI Policy and Mono in Debian/Etch soon, the Mono Debian Plan is almost complete, only backports for Debian/Sarge are left then. On those I will work when the 1.1.8.1 packages are in the archive and some other packages are updated to the latest version (like Gtk# 1.0.10 and MonoDoc 1.0.7). Currently the following CLI applications are in Debian/Unstable:
MonoDevelop, MonoDoc, Muine, Blam, F-Spot, Tomboy, Nant, Kurush and last but not least IKVM Upcoming CLI applications going in Debian soon or later:
NUnit, NDoc, GFax, Sonance, Beagle and Smuxi Ready to use preview packages we have for:
GFax and MonoDevelop with Boo support
They are on debian.meebey.net, you can use:
deb http://debian.meebey.net/$package ./
or to get all:
deb http://debian.meebey.net/ ./ I personally think this is a big list of CLI applications being in Debian already (or go in when the packages are ready), it shows that Mono/CLI/C# is accepted in the opensource development community!

I am back from Chemnitz, at work now, feeling a bit tired but otherwise okay.
How it was:

• Great event!
• Superb organisation, everything went smoothly, no problems whatsoever. All our "extra-wishes" were fulfilled within minutes. Wow! Thank you, CLT Orga-Team!
• Really nice food, too. Especially the buffet on Saturday. Wow again. Thank you, too, CLT Catering-Team!
• Met lots of nice people. Many irc nicks now finally have a face.
• Brought my camera but didn't take pictures. Nobse did.
• asciijump is biiiig fun!! (But segfaults in stable.)
• Jonas is now me (or at least carries my name tag).
• This was my first Linux event without a laptop. Pain!
• My talk went well. Lots of good feedback and some good ideas for further improvement.
• Publicly humiliated myself by "solving" a (simple) problem with the demo machine through reboot. Booo!
• To my surprise there wasn't a single linux merchandise vendor. Aaaw :( Good for my finances though. I think the only thing I spent money on this weekend was a bus ticket.
• Such a lot of snow!
• Yay, Vita Cola!
• Tolimar can magically disappear within 9 secs straight.
• See you at CLT 2007

It looks like I’ve earnt another ID: CVE-2005-4720 - Firefox 1.0.6 segfaults on this malformed .html page. Still no news about the security bounty though. I’m tempted to prod people .. but I haven’t managed to get round to it yet. On the one hand it’s bad to push for things like that. On the other hand there is no way I’d cash the cheque, and it would look lovely hanging on my wall…. Nothing much to say about the Debian Project Leader election yet. I think it is pretty clear to me that the idea of a “team DPL” was a failure. (At least I saw nothing happen any different.) I hoped the current/previous DPL would do great things, but to be honest didn’t see much evidence of it. (I know that personal issues came up, which is understandable, but it was disappointing to see the lack of promised status reports.) I also utterly refuse to vote for anybody who mentions in their platforms “we’re all social disfunctional”. I’m not. I’m good with people, animals, and myself. I don’t need somebody reinforcing geek stereotypes in even the smallest way. I did have the vague hope we’d have a female DPL, but alas that doesn’t look like it will happen for a while longer. Something to think about for the next year perhaps? Ummm .. I’m not sure how valid people would consider my opinions given that I’ve been mostly driven away from Debian mailing lists, and have never been a big IRC users .. so I will stop commenting now!

As part of the on-going project to get some useful DeMuDi-Debian repository merge,I tried running fmit on powerpc.It didn't work. It dies with segfaults and error messages on 'free'.It doesn't work on amd64 either. If it works on other platforms, is it a platform specific bug?

Je reposte sur mon blog une r ponse que j'ai faite sur le blog de Ma tre Eolas vu sa longueur : Le probl me des transmissions de donn es est r elle. Vous parlez des 45tours ou VHS que vous ne savez sans doute plus lire, ou des livres trop vieux pour qu'ils vous int ressent. Vous avez raison, il y a des 100aines de gens comme vous (moi le premier). Mais il y a aussi des "geeks" du patrimoine qui ont tout le mat riel pour faire la conversion des VHS vieillisantes vers des divx (avec tous les filtres pour nettoyer les bandes), ou des gens qui ont fait l'acquisition num rique de leurs vieux vinyls, etc... Et on se retrouve avec une migration d'anciens contenus vers de nouveaux stockages. Le patrimoine est sauv . Surtout avec les outils comme google qui permettent de trouver tout m me s'il n'y en a qu'un seul exemplaire. Dans le cas de DRM comme ceux envisag s par DAVDSI, les seuls propri taires des versions originales non prot g es seraient les majors dans le cas de la musique par exemple. M me pas forc ment les artistes eux m me (certes, eux peuvent rejouer les morceaux -- et encore, pour une impro jazz a ne sera plus la m me par d finition -- mais leur vie est par d finition limit e). Du coup, pour que ces oeuvres perdurent, il faut faire confiance au majors pour avoir les protections n cessaires pour ne pas perdre les oeuvres. M me apr s un d p t de bilan (si si, m me Sony peut mourir un jour. Agfa l'a bien fait !). Il faut aussi leur faire confiance pour mettre dans le domaine public les oeuvres qui sont plus vieilles que la dur e l gale de la protections des droits d'auteurs (quoique gr ce Disney cette dur e tende vers l'infini ;p). Personnellement, je trouve que c'est mettre tous ses oeufs dans le m me panier, et dans un bien mauvais panier. Les majors sont dirig es par le besoin de gain imm diat, pas humanistes (et je ne dis pas ca m chament, c'est dans leur nature, c'est inscrit dans la loi du march , c'est juste un fait). Bien sur, je crois que les gens ne prennent pas trop au s rieux la perte d'un morceau de musique. Mais quid d'un film d'auteur ? ou pire ... d'un livre ! Oui un livre peut tre un contenu num rique : PDF, ebooks, ... existent depuis des ann es. Les livres de science fiction o il y a un objet electronique avec des pages (parce que il n'y a pas dire l'ergonomie d'un livre, ca ne peut que se copier, difficilement s'am liorer) dont le contenu est lu sur une puce lectronique et affich sur des pages cran souple (ca commence exister, et je crois vraiment que notre g n ration conna tra ces outils). Ca veut dire que si ces livres ont des DRM, apr s l'avoir lu, pouf, fini. Et l encore ce seront les maisons d' dition qui auront les originaux. M me les biblioth ques ne l'auront pas. elles auront juste une licence avec les diff rents diteurs avec des "ebooks readers" sp ciaux qui auront acc s tout ou partie du catalogue, moyennant license, bien sur renouveler. Et l encore, ca serait se reposer sur la bonne sant de ces diteurs et leur honn tet pour ne pas perdre tout le patrimoine culturel qu'ils ont entre les mains. etc... OUI je comprends vos arguments. Mais mon avis, un des r les de l' tat est d'assurer la transmission du patrimoine culturel (et de tout autre patrimoine en fait) de la nation (voir m me des autres en fait) qu'il gouverne. Une telle loi, si ca n'est sans doute pas la seule n cessaire pour arriver l'enfer que je d cris (quoi que ...) est un pas non n gligeable au del d'un point de non retour o la transmission du patrimoine ne POURRA PLUS tre control e par l' tat, parce que le patrimoine appartiendra des multinationales apatrides, qui ne seront plus du tout sur le sol Fran ais et ne r pondront donc plus de la juridiction de la France. Personnellement, je pense que DAVDSI a un vice bien plus profond que ce que les gens lui reprochent le plus souvent : c'est l'amorce d'un d sengagement in luctable de l' tat de taches qui lui incombent en propre. Il y a sans doute un parall le faire avec le service public... Si le service public est obligatoire, c'est parce que le tout priv am nerait les gens de la Creuse ne pas avoir le t l phone (ou bien des prix d mesur s) peine l' lectricit ou l'eau courante. Si l' tat privatise certains tablissement (EDF tant sans doute le prochain candidat) il ne renonce pas passer des contrats avec ces entreprises leur obligeant de respecter un service minimum. Ceci est possible parce que ces entreprises sont fran aises, et vivent parce que l' tat le permet. Et de toute facon, c'est sans doute l' tat qui financera le manque gagner d'EDF ou d'autres exemples (FT, la Poste, ...) sur les zones non rentables. Peut on faire la m me chose pour le patrimoine ? je pr tends que non. Je vois mal quels seraient les arguments de la France face la RIAA, Sony, Universal, ... Bien sur IANAL, et je dis sans doute un tas de b tises que vous corrigerez sans doute (ou peut- tre pas si il y en a trop). Mais tant informaticien, et voyant le mal que font les DRM notre profession (je ne fais allusion qu' des DRM sur des document PDF, et qu'on ne peut lire que sur un seul poste Windows -- DRM oblige -- et que nous ne pouvons pas imprimer. autant dire que dans ce cas on prie pour que l'ordinateur n'aie pas tre r install !!! parce que au prix du PDF en question, une start-up ne pourrait pas se permettre de le racheter ind finiment) je ne peux pas rester sans rien dire.

Yesterday I had the frustrating experience of trying to configure a machine so I could use the internal soundcard while simultaneously recording sound from a USB iMic. While ALSA appears to fully support this setup, I discovered quite a few annoyances about what should be trivial:

• There appear to be no GUI sound recording apps that support ALSA directly.
• KDE's artsd normally provides good ALSA support, but it provides neither a systemwide nor an app-specific way to select either the recording or the playback source with ALSA.
• Some apps appear to use Jack, but configuration of it is extraordinarily complex and it seems to die in subtle and odd ways from time to time.
• ecawave segfaults on start, every time.
• audacity doesn't even support anything other than OSS! (A shame from what's otherwise a great program)
• The mechanics of OSS support in ALSA are anything but clear. There is the aoss LD_PRELOAD wrapper, and then there is also a kernel module, which appears to be rather under-documented. For whatever reason, ALSA is managing only one PCM device under /dev, despite having two PCM cards in the system.

Now this is probably no worse than the situation in Windows, but it is certainly not where we should be, and isn't where MacOS X is either. Note that most of these problems are with the apps not supporting the second audio source *at all*.

I just fixed some RC bugs in my packages to get my ass not kicked.
I uploaded a small update for apt-build. I tried to use it, and it seems to be totally dead. Trying to build blackbox (my reference test, this is historical), make died with a segfault, and at the end, apt-build died with a segfaults. Yee-pee ! And I don't know why, this is weird. I also asked the removal of torsmo (superseded by conky) and orphaned manderlbot, since I have no skill in Erlang. I also find out why I could not fix the f****** FTBFS on svnmailer. And it was because the -I.svn option of dpkg-buildpackage I used, skipped the svnmailer.conf.example file, obviously... Raaahhh, bad shell alias configuration => headache !