I've said it before: I think MySQL is a toy, and I want as little to do with it as possible. Unfortunately, since the KDE PIM suite depends on akonadi, which depends on a database, which was initially implemented against MySQL, not having MySQL installed on a Debian machine if you want to use the KDE PIM suite, for the longest time, wasn't even possible. Today it is, but it requires some manual steps:

sudo apt-get --purge install akonadi-backend-postgresql akonadi-backend-mysql-
akonadictl stop
rm -rf .config/akonadi
rm -rf .local/share/akonadi
cat > .config/akonadi/akonadiserverrc <<EOF
[%General]
Driver=QPSQL
[QPSQL]
Name=akonadi-wouter
Host=
Options=
StartServer=false
EOF
createdb akonadi-wouter

Change "akonadi-wouter" for a suitable database name. And now it should work. Note that this requires you run PostgreSQL system-wide and create a system-wide database in that server. It should, in theory, be possible to have akonadi run its own private PostgreSQL instance, much like how the MySQL backend does things, but a) I couldn't get that to work, and b) I don't think having each user run their own database server instance is a good idea to start with, so honestly I didn't try very hard. And there, pronto! I now no longer have toy databases on my laptop. Word.

For those interested in Sympa, version 6.1.4 has been uploaded to squeeze-backports. This version fixes around two dozen bugs since the version present in squeeze (6.0.1). I strongly recommend to use this version with squeeze as it fixes some very annoying bugs. How to install it: For squeeze users Be sure to have squeeze-backports repository enabled in your sources.list as explained on Debian Backports website then:

apt-get -t squeeze-backports install sympa

For lenny users For lenny users with a running sympa installation who plan to upgrade to squeeze and use sympa from squeeze-backports, it is recommended to upgrade directly from the version 5.3.4 (lenny's version) to 6.1.4. To do so, you just need to add some apt pinning in /etc/apt/preferences (see below) and then dist-ugprade normally.

Package: sympa
Pin: version 6.1.4*
Pin-Priority: 500

Sympa 6.1.6 is already out and should be uploaded in unstable soon, it should also be backported to squeeze-backports if all goes fine. Special thanks to Gerfried (rhonda) and Alexander (formorer) for their work on Debian Backports.

I recently bought a Simtec Entropy Key. It's a hardware randomness generator encapsulated as a USB device, the size of a flash drive. It's good for any host or cluster that uses a lot of kernel-provided random numbers (/dev/random), or does things that cause the kernel to use a lot of random numbers. Opening a lot of network connections, or generating session keys for public key encryption. That kind of stuff. If the kernel has too little entropy available to generate good random numbers, things will stall until it gets some more. The ekey gives you real random bits, not just software-produced pseudo-random numbers. In other words, it's some kind of magic. I got the device in a DVD box, with a leaflet explaining how to install stuff, a CD with the software, an envelope with a secret key, and the actual device itself. I read the leaflet, which said to install the ekeyd daemon first. I ignored the CD, since a) my laptop has no optical drive and b) the software is in Debian stable (squeeze) anyway, so apt-getting it is easier and faster. I was utterly disappointed with the software. I didn't have to edit a single hard disk sector, or do a BIOS upgrade, or anything. Utterly, totally, boring. I had reserved an afternoon and evening for this, but I had to find something else to do instead. After plugging in the device in a spare USB port, I opened the envelope and ran a command to specify the secret key. The key and host processors use encryption to make sure nobody can eavesdrop on the randomness -- that would give them an edge in cracking SSL and GPG encryption, I guess. Here's an example of how it works. Before I plug in the device, the kernel has some, but not too much entropy available:

liw@havelock$ cat /proc/sys/kernel/random/entropy_avail 
1053

A few seconds after the ekey is inserted:

liw@havelock$ cat /proc/sys/kernel/random/entropy_avail 
3968

And here's the kicker: pretty much regardless of what I do, the entropy stays at about 4 kilounits (I don't know if it's bits or bytes, and I'm too lazy to check). In the end, the only thing I can really complain about is the typography and layout of the leaflet. The text is clear enough, but it's laid out too densely. It needs more whitespace. Some pictures of bunnies or kittens would be nice, too.

This was the second most rainy day of the year, so far. 28 hours of solid rain and counting. Good time to take stock of the water situation here at the cabin after a year's experience. The springs were as seasonal as I'd feared. After running strongly all Spring, the main spring ebbed and died in the Summer months. By mid-July there was no remaining source of potable water. If I had not been away so much over the summer it would have been worse. As it was, I needed only twenty gallons of water hauled from neighbor Lee's well. The large cistern was filled in a single night during the most rainy period this Spring, and provided wash water for two months of the summer, and that only lowered it by a quarter. So I could have been less sparing with it, and not relied so much on rain water catchment for supplimental wash water. Today I replaced the pump, so I can use the pressure tank and have running water in the house. I could have done this earlier, but what can I say; I enjoy hauling buckets of water, when it doesn't involve breaking ice. In the winter when there's firewood to haul instead, I'll enjoy the indoor plumbing. Also today, I may have finally fixed the pipe to the large cistern properly, so it won't only fill at the heaviest rain times. Along with the ability to cross-pump water from the small to the large cistern, it should be easier to keep it filled, and I might be able to reduce the turbidity enough that it's potable eventually. Will see. I don't live in a dry region, but this is a relatively dry place for the area. It's been interesting to get a taste of what it'd be like to live somewhere where water is actually scarce.

It took longer than usual, but I believe it's worth.

I just released Cupt 2.2.0~rc1 to Debian experimental. To experimental, because there are important changes and I would appreciate "in-field" testing before final 2.2.0.

Here are the major changes since 2.1.x:

• Dpkg action sequencer improvements. There are multiple improvements, both in quality and speed.


• Repository index deltas. Or, in APT terminology, "PDiffs". Finally, there is an initial support for them. They are switched on by default (if you have Recommends disabled, make sure you have 'ed' package installed). To switch off, set the option 'cupt::update::use-index-diffs' to 'no'.


• Action override options. New console front-end's options '--install', '--remove', '--purge', '--satisfy', '--unsatisfy' allow to mix any of corresponding actions to the single command. See the tutorial and the man page for examples and details.


• Logging. By default, system changes are now logged to /var/log/cupt.log. Refer to the tutorial section 'Logging' for tuning.

Enjoy and send the bug reports.

This is just a quick post to remind myself in the morning, as soon as I've made it I intend to turn my computer off and leave it off until I can re-organize my office. I've been using mutt for my email for the past few years. Nothing compares to the flexibility of procmail/sieve for organizing server-side mail, and then mutt is ideal for reading them. With the addition of the mutt-patched sidebar mode you can even go for a few days before realizing you're not in a graphical environment. But one thing I do long for is the ability to execute scripts at various times. Thus far I've not actually planned what I'd like to do, but as a starting point imagine being able to execute a hook when new mail arrives? Or when you send a message matching a pattern in some fashion? There are some things out there, such as the various hacks which are designed to abort sending a message if you mention "See attachment" in a message body but fail to add one before sendign the message. These hacks generally abuse the sendmail configuration such that they're extremely ad-hoc and hard to chain/nest. I've mellowed out over the years and I have no interest in attempting to write a mail-client (though at the same time how hard can it be? Just restrict yourself to using inotify on ~/Maildir and offload delivery to exim and you're almost done? I guess the hard part is the UI, though I do like the mutt + sidebar layout. Write the whole thing in some scripty language?) I'll re-examine notmuch and gnus over the next week or two, but I suspect both will continue to disappoint in various ways. Anyway, for the moment I'm just pondering. But threading is an obvious concern. Most current mutt hooks relate to the local folder, or the local message. If I were viewing a message in one directory and a new mail notification fired for a delivery to both ~/Maildir and ~/Maildir/.people.foo I'd need to either serialise them or thread them. Ponder ponder. In other news I've been doing more photography recently. Nothing cohesive except for my recent experiment with shooting a "street-girl" outdoors in falling light, but that was an interesting challenge and the results were sufficient to make me want to try shooting outdoors in an organized fashion again. (Some random images have been linked to from my wee twitter page.) ObFilm: "She doesn't get eaten by the eels at this time " - The Princess Bride

I'm in the middle of setting up new build machines for the armhf port (see the wiki for more details). We'll shortly have six machines set up in the machine room here at ARM in Cambridge:

• harris as a porter box
• hartmann, hasse, hebden and henze running buildd software
• hoiby as a hot spare

All of these machines are Freescale i.MX53 Quickstart (aka "loco") development boards. They include a 1GHz i.MX53 CPU (based around the ARM Cortex A8, one of the ARMv7-A family). They have 1GB of RAM and native SATA. They're lovely little machines, measuring just 3 inches square. To mount them usefully in a machine room, I've mounted each board with a 320GB notebook hard drive and the necessary cabling onto a small perspex card as you can see here. Then we can fit 6 such machines and a normal PC-style ATX PSU into a 3U mini-rack. Well, it almost fits - the power supply pokes out a little so we'll need 4U of space when we come to mount it. The Quickstart boards have been sponsored by Linaro, and ditto my time setting up these machines. Thanks! As is common with new development boards, these machines are not quite fully supported in Debian yet. The kernels we're using are locally-built, using the sources supplied by Freescale. For now, that means a heavily-patched "2.6.35" kernel but we're expecting to be able to switch to mainline very soon. The .config I'm using is kernel.config, and I've built it natively on harris using fakeroot make -j2 deb-pkg DEBEMAIL=93sam@debian.org DEBFULLNAME="Steve McIntyre" KDEB_PKGVERSION=1buildd1 Similarly to the setup for the armel machines, for now I've tweaked things when installing the kernel:

• depmod:
  • Need to make sure that depmod is run so the new kernel can find and load modules at boot. Added trivial script in /etc/kernel/postinst.d/depmod to do this.
• initramfs-tools:
  • Needed to copy the file /etc/kernel/postinst.d/initramfs-tools into place from my amd64 machine; I'm guessing this would be there automatically on a new-enough version of initramfs-tools on the armel machines, but we're still using Lenny as a base system for now even if I'm using a Squeeze-based kernel.
• flash-kernel:
  • Add support for these boards
  • #550584: kernel postinst hook script (/etc/kernel/postinst.d/zz-flash-kernel) to create uImage and uInitrd files from the kernel zImage and the initramfs.

Finally, I've tweaked the uboot config on the machines to use the uImage and uInitrd files that are generated by flash-kernel:

MX53-LOCO U-Boot > setenv loadaddr 0x70800000
MX53-LOCO U-Boot > setenv initrdaddr 0x71000000
MX53-LOCO U-Boot > setenv bootargs_sata set bootargs \$\ bootargs\  root=/dev/sda2 rw rootwait
MX53-LOCO U-Boot > setenv load_sata_kernel ext2load sata 0:1 \$\ loadaddr\  /uImage
MX53-LOCO U-Boot > setenv load_sata_initrd ext2load sata 0:1 \$\ initrdaddr\  /uInitrd
MX53-LOCO U-Boot > setenv load_sata run load_sata_kernel load_sata_initrd
MX53-LOCO U-Boot > setenv bootcmd_sata sata init\; run bootargs_base bootargs_sata load_sata\; bootm \$\ loadaddr\  \$\ initrdaddr\ 
MX53-LOCO U-Boot > setenv bootcmd run bootcmd_sata

And I've added extra config into uboot to use the pre-installed Ubuntu system on the micro SD card as a fall-back:

MX53-LOCO U-Boot > setenv bootcmd_rescue sata init\; run bootargs_base bootargs_sata\; mmc read 0 \$\ loadaddr\  0x800 0x1800\; bootm

I'm not very good with dates. For the last two years now, Joshua's anniversary has snuck up on me and caught me by surprise. I don't think that I'd really appreciated until this year that we lost him on the Labor Day long weekend. I'll have to remember that for next year so I don't forget. I don't know what my problem was this year. I just didn't realise that it was this early in September that we lost him. Last year I was just too exhausted from dealing with a new baby to realise when his anniversary was, and I felt terrible for missing it. This year, I just felt terrible for not realising when it was, but at least Sarah pointed it out before the fact. For added irony, the 4th of September this year is Father's Day in Australia. Yesterday, I was looking at photos of Joshua to remember him, and Gallery gave me a random photo of Zoe in the corner. That was something. I'm not sure what. I feel like Zoe being a wonderful child is some sort of consolation prize from the universe for taking Joshua, but I often wonder what Joshua would be like today if he were almost four.

Went to see One Day yesterday. As I usually do after watching a movie, I next went to wikipedia to read up more about it. Was shocked to read that it received 'mostly negative' reviews. I thought it was pretty good. After reading a few of the aforementioned reviews, I understand what the problem is, and though I disagree with the resulting negativity in the review, I can see where it's coming from. You see, One Day is a novel-turned-movie. As with most movies that were sourced from a novel, the movie is a disappointment to those who read the book, mainly because there's always going to be more material in the book, and therefore some of your favourite passages from the book are going to be removed, or changed so that they'll lose some of their original goodness. This is even true for beyond-feature-length movies sourced from novels; for instance, when I saw the horse whisperer after reading the book, I found it a disappointment too, even if my brother and sister who saw it at the same time as me did like it. Ignoring that, there's a second problem; while it's a love story, I don't think it qualifies as a 'romantic comedy'. For it to be a romantic comedy, you'd expect 'happily ever after', and you'd expect a story about two people quickly (or slowly, as the case may be) falling in love with eachother, overcoming some problems that stand in the way of their relationship. Most importantly, you'd expect it to be lighthearted and funny you'd expect it to be a comedy. One day doesn't deliver that; if you go see it, expecting a romantic comedy, you'll be sorely disappointed. But if you accept the fact that it isn't a romantic comedy, it's still a very interesting film. It's not lighthearted, but that doesn't mean there isn't a laugh or a cry in there. And, without wanting to spoil the plot, while the movie doesn't bring 'happily ever after', it does still come up with a believable, emotional, and very compelling ending. The plot takes you through the 15th of July in the lives of the two main characters, every year for two decades. Sometimes they're spending that day together, sometimes they're not. Sometimes they're calling, sometimes they're fighting, sometimes they're kissing. The days shown are snapthots of both their lives; this adds an interesting angle to the plot, as much of the story, much of what is going on, can't actually be shown on-screen, since it happened in between the two 15ths of July. While, as said, I wouldn't describe the movie as a romantic comedy, I think it can be accurately described as a romantic drama. It's not going to be a legendary movie, a must-have-seen, one which you'll grow to hate over watching it on every TV station's prime time over the next few years. But it's a charming, novel, and interesting piece of drama. Did I like it? Definitely. When I go to the movies, sometimes I want a silly movie, some action flick that I can have a bit fun laughing at; but sometimes I want a movie that touches my heart and makes me reflect on my own life while feeling for the characters. When I went to see The Expendables, I have a lot of fun for one night, and then promptly forgot about it. But 'One Day' rang true with me on an emotional level; and for that alone, I can recommend it. Even if that wasn't the reason why I chose to pay 8 for this movie rather than anything else. I'll be perfectly honest: Anne Hathaway. Good actress, and sporting the most interesting pair of bright eyes you've ever seen; what more could one want? A film that allows these two eyes, and acting talent to shine, of course. And One Day delivers.

Both Bash and Zsh use several startup scripts: profile, bashrc, zlogin, zshrc, etc. The existence of several startup scripts exists to allow you to apply specific actions for interactive or login shells. For instance, you may want to set up a fancy colour prompt or to enable a powerful completion system for interactive shells only, as it would be pointless to apply it to non-interactive shells (that is, for shell scripts). Or you may want to display a joke and the weather forecast at login, but not each time you spawn a shell by other means.Common Both Bash and Zsh first execute a system-wide file, then the corresponding user-specific one. For instance, /etc/profile then ~/.profile. For simplicity I shall only mention the files' base names. Bash At startup, depending on the case:

• run as a login shell (or with the option --login), it executes profile;
• run as an interactive, non-login shell, it executes bashrc (the system-wide version is called bash.bashrc).

At exit, it executes ~/.bash_logout (no system-wide version). Note the funny (read: insane) non-login condition for executing bashrc: it is often worked around by having the profile execute bashrc anyway. Zsh Zsh always executes zshenv. Then, depending on the case:

• run as a login shell, it executes zprofile;
• run as an interactive, it executes zshrc;
• run as a login shell, it executes zlogin.

At the end of a login session, it executes zlogout, but in reverse order, the user-specific file first, then the system-wide one, constituting a chiasmus with the zlogin files. Summary

Bash

		login
		yes	no
interactive	yes	profile	bashrc
	no	profile	-

Zsh

		login
		yes	no
interactive	yes	zshenv zprofile zshrc zlogin	zshenv zshrc
	no	zshenv zprofile zlogin	zshenv

I personally find the Zsh process much saner. To be honest I should rather say that I find Bash's behaviour insane, with an absurd process (bashrc for interactive, non-login shells ) that needs to be worked around, and an inconsistent naming and search convention (~/.bashrc vs. /etc/bash.bashrc, no system-wide version of bash_logout).

This post is a small follow-up on yesterday's post about the Linux graphics stack. I'm still keeping to high level stuff and won't dig too deep, but a few questions arose (others reached me by e-mail), so, here we go. Gallium3D is a framework, initially developed by Tungsten Graphics, which were bought by VMware. The idea behind Gallium3D is, that many functions can be shared between drivers for different GPUs and that the effort to support a new platform/system is for classic drivers pretty high. With Gallium3D you just need a state tracker and a target. The state tracker is code, that gives the pipeline of Gallium3D drivers access to a platform/system, like OpenGL or X on various operating systems. A target is the required as glue between a state tracker and the actual driver. For example: there is a state tracker for video playback acceleration (the recently added g3dvl). The state tracker itself offers the interface and common functions (with some help from the auxilliary stuff) between the Gallium3D pipeline and the userland libraries like libvdpau1. Targets like vdpau-[DRIVER] glue the driver and the state tracker together. The winsys part of Gallium3D is a similar concept but it abstracts the windowing system on the target platform away (e.g. Wayland, X or GDI). I didn't write about the proprietary drivers yesterday, as I don't consider them a real part of the Linux graphics stack, more like parasites, and didn't want to encourage anyone to use them (yes, I know, there are some cases in which you might be better off with them, but generally I'd avoid them). Anyway, I got some questions about those (some by e-mail, the other I'm aware off, can be found behind the link at the beginning of this entry). So, where do the proprietary drivers come in? They are basically the entire stack in a closed form, plugging into the public interfaces of the Kernel (whether that's legal is disputed), some other parts like X (by building a DDX) and building their own libGL. Especially the last part can be a cause for a lot of pain, when you don't use the proprietary driver packages offered by the distribution (e.g. Debian's fglrx packages divert the libGL and restore the default one on unistallation, with the vendor build scripts and tools this is not really guaranteed, which might leave you with a broken OpenGL setup). Another question was, why Mesa was lacking support for a recent OpenGL version (i.e. 4.x). In my opinion there are a few reasons, though I don't really feal like the best person to answer this. The first are design issues by some internal representations (e.g. missing integer support in the intermediate representations). The second is the available number of developers being able to implement new OpenGL functions. Apart from a not all too clear specification the Mesa code base is huge (even if you ignore most of the drivers), which makes it difficult for new developers to start coding away. Then you need an understanding of how modern GPUs operate to find good solutions for the problems faced. If you want to get an idea for this, take a look at Zack Rusin's or Alex Deucher's blog. Then, there is a sad split of developers, on the one hand we've got the Gallium3D-using developers on the other we've got the ones staying with the classic driver model. This means, that you have to implement e.g. GLSL extensions for TGSI and Mesa's IR respectivly. There might be other reasons, I'm totally missing, but this should give you some insight into why it takes so long, to get current OpenGL versions supported. I hope this clears some of the remaining questions, if not, feel free to write me an e-mail, but please remember, that this is not an in-depth analysis.

Thanks to the awesome patent situation (if you're unaware of what I'm talking, you can catch up by listening to PRI's This American Life episode about patents, reading Florian Mueller's write-ups about the patent wars (current focus: mobile devices) or by having a look into my posts with the "patent-mess" tag), Debian will most likely be unable to distribute Mesa packages with ARB_texture_float enabled (if you want to build mesa yourself with this extension enabled, just add --enable-texture-float to confflags-dri in the Mesa source package's debian/rules). But some programs really like to have this extension, thus I started building Mesa myself. The resulting packages can be found on dev.carbon-project.org. Big fat warning: please check, whether you're affected by the US patent #6,650,327 (i.e. if it's a valid patent in your jurisdiction) before you use the packages. If in doubt, consult with your lawyer. By the way, if you're not working in an area where knowledge of the specifc claims/content of the patent might be harmful, you have some time on your hands and you want to learn, what's "patentworthy" these days, have a look at the claims of the patent. Otherwise the three links from the beginning must do. Before I end this post, just one more remark about my Mesa packages: they'll follow upstream's Git and thus might have problems from time to time. If Debian's Mesa packages suffice your needs, stay with them. If not, feel free to use my packages or use them as a base for your own packages.

The Modern OpenGL tutorials series continue - now with a first section on lightning, covering the different kind of lights (sun, hemi, spot, etc.) using a simple diffuse model and clear code.

http://en.wikibooks.org/wiki/OpenGL_Programming#The_lightning_arc

This one is derived from the excellent set of Blender GLSL tutorials by Martin Kraus. As usual, the documentation is CC-BY-SA/GFDL, and the code is in the public domain. We're also expecting another tutorial on scientific visualisation.

Am I online or not? There is a summary at the end for the quick readers. It is in many modern applications important to be able to more or less gracefully handle if the application user is online or not. For example, there is no need to try to fetch emails if the device (computer, phone, tablet, laptop, ) doesn t have network (wifi, cable, umts, ip over avian carriers, ..). KDE has of course made nice functionality for this, and here I will try to describe how to make your app network status aware and what to be aware of in the process. Solid background All this is going on in Solid, using two parts of Solid and a bit of KDE s infrastructure:

• libsolid
• networkstatus KDED module

The networkstatus KDED module is trying it best to gather information from the computer to see if one is connected or not. It has the possibility to gather information from various sources, and handle changes and such. The as of writing available sources that the networkstatus module gathers information from is

• Network Manager
• wicd
• asking the linux kernel thru the abstraction layers ntrack and libnl
• connman might be work in progress

Collecting from different sources is important, because some people might have configurations like Manage wireless thru wicd , manage umts dongle with Network Manager and manage wired network with /etc/network/interfaces and all of it needs to be combined. Solid reports, if wicd thinks online , and network manager thinks offline that the user is Connected.. Solid States There is a enum with 5 values in Solid to describe the current state of the network:

enum Status
Unknown,
Unconnected,
Disconnecting,
Connecting,
Connected
;
Connected is the easy state. Here, Solid knows that you are having some kind of connection according to at least one of the sources. But it might just be a local network connection, and not actually a internet connection. So one here should handle connection failures gracefully. Unconnected is a similar easy state. Here, Solid knows that you don t have any internet connection according to the sources it knows about. One should here not try to do any networking. Connecting and Disconnecting is that a state change is happening, so that you can prepare to react on it. Solid also has the state of Unknown, used for cases where Solid doesn t have the required data to actually know it. A example could be a system without any of the data providers. You should here probably try to connect, and be able to handle failures gracefully. Also described as Proceed with caution . The bright reader might here notice that one both in the Unknown and Connected case actually should do the same. Querying for network status At any given time:

Solid::Networking::Status currentStatus = Solid::Networking::status();
if(currentStatus==Connected currentStatus==Unknown)
//try to do networking things
else
//mark application as offline.

Here, we first query Solid for current status, and then if the state is Connected OR Unknown, then we proceed. Getting notified Maybe you don t want the roundtrip of asking (resulting in a dbus rountrip each time) when you need to know the state changes. Then you of course can get notified. class MyNetworkAwareClass : public QObject
Q_OBJECT
public:
MyNetworkAwareClass();
void doNetworkActivity();
private Q_SLOTS:
void networkStatusChanged(Solid::Networking::Status newstatus);
private:
Solid::Networking::Status m_current_state
; MyNetworkAwareClass::MyNetworkAwareClass : m_current_state(Solid::Networking::Status())
connect(Solid::Networking::notifier(), SIGNAL(statusChanged(Solid::Networking::Status),this,SLOT(networkStatusChanged(Solid::Networking::Status)));

void MyNetworkAwareClass::networkStatusChanged(Solid::Networking::Status newstate)
m_current_state = newstate;
void MyNetworkAwareClass::doNetworkActivity()
if(m_current_state == Unknown m_current_state == Connected)
//try to do network activity


I guess this should be pretty self explaining. Summary

• Ask Solid::Networking::status() for network status
• Connect to statusChanged(Solid::Networking::Status) from Solid::Networking::Notifier to be aware of changes
• Treat the states Unknown and Connected the same way.

Oh. And I m out looking for a job.

While other people are squashing RC bugs I was using this week to fix (or investigationg) some more kFreeBSD issues -- mostly looking at failed build logs and trying to fix the problems and after some nice fish for dinner writing things up.

• First issue this week was #639178 a build failure in tar I had reported earlier and didn't manage to process the response. After sending some findings to the bug I noticed Petr was faster and did actually find out a lot more detail. Short story: success in that test suite requires linux behavior and the failure on kfreebsd is covered by what POSIX allows
• #640156 multiarch related changes resulting in a nonfunctional ldd breaking clutter-gst build
• #640012 postfix is hard-coding kFreeBSD versions up to 7 and therefore won't build on a 8.2 kernel. It also doesn't handle absence of NIS on Hurd and kFreeBSD #545970
• #640159 iozone3 just needed a bit of massaging to combine the FreeBSD backend with the linker flags needed for kFreeBSD
• Installing the build depends for openjdk-* resulted in a installation failure for some time. Looking closer it turned out a minimal testcase was installing menu and python2.6 together. Turned out dash's test builtin wasn't working #640334 because it was relying on the intuitive but not POSIX mandated behavior of the faccessat syscall #640325
• #640341 ed decided not to build on kfreebsd-i386 in the 40 minutes between -2 and -3 upload. Without any actual source changes. Just trying agan tricked it to build again but probably someone should look what went wrong actually
• #640378 leveldb needed enabling the FREEBSD_OS kind of build with the linux style of linker flags (additional -lrt)
• #640385 owfs was failing to some symbol difference (but otherwise building although being a *fs ;))
• the gcc family of packages still has some heisenbug repeatedly failing when doing regular builds on the buildds. Independent which one. Multiple times in a row. Building on my test VM or my notebook doesn't show that problem (but takes ~10h). Building on the same buildd in the same chroot with the same sbuild flags and it's still building fine.

I bought a new PC a few weeks ago and I then decided to renew a bit my Desktop, my Mutt and my Irssi setup. I ve been spending several hours cleaning up old scripts, logs and configuration files but the result definitely seems to reward me the right way. But here they come a few screenshots: Desktop Irssi Mutt If you liked all the above and would like to reproduce everything yourself, you should consider having a look at my GitHub s repository. See you on the next blog post!

[UPDATE 2011-09-05]I received some questions (or saw them), which I tried to answer with a follow-up entry.[/UPDATE] As I tried to explain this a few times in the past to others and had trouble myself, when I started using Linux, I thought I take some time today and write down what parts comprise the Linux graphics stack and how they interact. I'll ignore some parts which aren't too interesting to an average user at the moment, to keep this post as consise as possible. Apart from that, I hope I'm able to put all the relevant data into one spot. Let us start our little journey in the kernel. There, in a directory named gpu you'll find the drm directory, which contains all DRM drivers. In this post, we'll focus on those. The drivers in that directory are the kernel side of the Direct Rendering Infrastructure (DRI) and are responsible for managing concurrent access to the graphics hardware. They also provide interfaces to pass commands and data to the GPU. The DRI wiki explains the three main purposes of the DRM modules. The DRM module is also the part that decides whether KMS or UMS is used. Other acronyms you might hear with regard to graphics acceleration on Linux and are referring to the Kernel part are:

• GEM: an Intel-developed memory management system for GPUs.
• TTM: refers to the memory management system used by almost all non-Intel drivers (e.g. AMD's Radeon drivers). The TTM interface is "GEM-ified", meaning it offers the same API as GEM.

Apart from that, every driver has its hardware-specific parts like utilizing power-saving functions of the respective GPUs, loading firmware, if required, etc. Now we move from Kernel space to user land. We'll ignore any non-X and non-Mesa parts (like acceleration for TTYs). That means, that our next GPU specific part is most likely the DDX. (Please note, that the classic DDX might be replaced by a Gallium3D state tracker, currently that would be the xorg state tracker, but xorg will be replaced by XA. This is only an option if the Gallium driver for your GPU supports one of those state trackers, see the Gallium status page for further details.) The DDX for your GPU offers plain (2D) X acceleration on your hardware. The respective DDX' are generally named xf86-video-[NAME], where [NAME] is replaced by e.g. ati or intel. The DDX decides which X acceleration paths are available. Acronyms you might hear, referring to the DDX part of the graphics stack, are:

• EXA: even though it looks like an acronym, the X.Org wiki Glossary defines it as:

  acceleration architecture with no well-defined acronym

  EXA superseded the older XAA and offers 2D acceleration, often in conjunction with XRender.
• UXA: more or less EXA for Intel GPUs.
• GLX: actually not a part of the DDX, but an extension for X. It provides a way to draw with OpenGL into an window managed by X.
• XRandR: An extension for X which needs to be supported by the DDX to work. It offers a standardized way to set up (multiple) heads (e.g. resolution, position, rotation, etc.).

We're almost through: the last important part is the 3D acceleration offered by a Mesa driver. Mesa drivers come in two flavours: classic (e.g. all Intel drivers which are supported by Intel) and Gallium3D-based (like the drivers for Radeon chips from the R300 onwards). The difference here is, that the Gallium3D drivers try to share as much code as possible (and thus simplify writing a new driver supporting many platforms, systems and technologies), while the classic drivers are specific to certain platforms, chips, and technologies. They share much less code among each other. All parts of Mesa need direct access to the graphics hardware (DRI) The Mesa drivers use the 3D pipeline of the GPUs for accelerated drawing, even for non-3D applications like video acceleration (recently VDPAU, XvMC and VA support were added to Gallium3D, driver support followed quickly). Otherwise the Mesa drivers are mainly used for OpenGL acceleration. Users of OpenGL include scientific programs, CAD and of course games. This concludes our little journey through the various parts of the Linux graphics stack. I hope it helps in understanding the building blocks.

Another cat posting, about 100 KiB worth of images embedded so follow to the main article to read it, I don t want Planet readers to suffer from traffic overuse.

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (91.44 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Dpkg work When I came back from Debconf, I merged my implementation of dpkg-source --commit (already presented last month). I continued some work on the hardening build flags but it s currently stalled waiting on Kees Cook to provide the required documentation to integrate in dpkg-buildflags(1). Following a discussion held during DebConf, Michael Prokop has been kind enough to setup a git-triggered auto-builder of dpkg (using Jenkins). You can now help us by testing the latest git version. Follow those instructions:

$ wget -O - http://jenkins.grml.org/debian/C525F56752D4A654.asc   sudo apt-key add -
$ sudo sponge /etc/apt/sources.list.d/dpkg-git <<END
deb http://jenkins.grml.org/debian dpkg main
END
$ sudo apt-get update && sudo apt-get upgrade

On the bug fixing side I took care of #640198 (minor man page update), #638291 (a fix to correctly handle hardlinks of conffiles), #637564 (the simplification logic of union dependencies was broken in some cases) and #631494 (interrupting dpkg-source while building a native source package left some temporary files around that should have been cleaned). WordPress update I released WordPress 3.2.1 in unstable (after having taken the time to test the updated package on my blog!) and fixed its RC bug (#625773). In the process I discovered a false positive in lintian (I reported it in 637473). Gnome-shell-timer package From time to time, I like to use the Pomodoro Technique. That s why I was an user of timer-applet in GNOME 2. Now with the switch to GNOME 3, I lost this feature. But I recently discovered gnome-shell-timer, a GNOME Shell extension that provides the same features. I created a Debian package of it and quickly filed some bugs while I was testing it (two usability issues and an encoding problem) QA Work During DebConf I met Giovanni Mascellani and he was interested to help the QA team. He started working on the backlog of bugs concerning the Package Tracking System (PTS) and submitted a bunch of patches. I reviewed them and merged them but since they were good, I quickly got lazy and got him added to the QA team so that he can commit his fixes alone. It also helps to build trust when you have had the opportunity to discuss face to face. Vacation That s not so much compared to usual but to my defense I also took 2 weeks of vacation with my family. But somehow even in vacation I can t really forget Debian. Here s my son:
Thanks See you next month for a new summary of my activities.

3 comments Liked this article? Click here. My blog is Flattr-enabled.

As written about here earlier, cats have a nice life. I walked into my home seeing three cats in a row, all black: two lazing around, the third (with white spots, and belonging to a different neighbour from the other two) ambulating. I went up and got my PocketPC with the already mentioned camera application to take a shoot. Sadly, the more shy cat went away, but I got some pictures of the other two here they are, internet photo stars follow the hyperlink to get a large version. Later I came back from geocaching (2 GC.COM-only, 1 OC-only *yay!* found, one not found due to not taking any hardware with me) the bigger guy lazed around in the bush next to where I usually park my bike. Lucky