I haven t been using ATM on Linux for some six years now. I neither have access to an ATM network any more nor do I have ATM hardware any more. Therefore, I plan to remove ATM support from ifupdown-scripts-zg2 in the next release which will be done in the next few weeks. If anybody does still use ATM on Linux in conjunction with my scripts, you might want to offer help with the package if you want to have continued ATM support in ifdown-scripts-zg2. I cannot test the code any more and therefore cannot maintain it in the future.

I've previously mentioned my plans on redoing my blog. Well, I've settled down on some design issues already (posts will be stored as mini Atom feeds, which makes the generation of Atom feeds for the blog and categories trivial, and gives me maximum flexibility. I already have a working converter for my existing blog to Atom posts.)Generating static HTML pages from that will be easily possible using an XSTL transformation (for example), and I got the feedback that I could just use Google AppEngine for blog comments, so my actual blog could remain static-only (and thus much more secure and reliable). Any attack/spammer/bot can then only kill the comment functionality, not my own site.Which brings me to another design consideration: the editing widget. Either for the blog comment application, for writing my own blog entries (via a https protected script or whatever) or maybe for a small CMS I've been thinking about - having a reliable HTML in-browser editing widget is something I could use every now and then (well, I'm not doing much Web stuff anymore these days).Geniisoft has a good overview over in-browser (aka: Through The Web, TTW) editors. The top candidates seem to be:

• FCKeditor
• TinyMCE
• Xinha

I've heard before of FCKeditor and TinyMCE; I think I've been on the Xinha page before, too. However, comments on them have not always been good.To some extend they all seem to have (to some extend) feature creep which usually is a bad sign - most often this means that there are security issues in one or another module or plugin.TinyMCE for example has been described as "a bit of a pain" and "a tad clumsy" on the GSoC mailing list. I have had less fights with it than with the Debian Wikis (MoinMoin) markup language though.I'm not looking for anything as big as these - I just need an editor that allows for some basic formatting (bold etc., links) and that produces reasonable XHTML output. I'll be feeding the output through some custom cleanup script anyway, which will kill disallowed code. So I don't want any editor which allows the user to create code that will then be killed afterwards.Any personal experiences with any of these, or an important alternative that I might have missed (no PHP involved, please!) - email me (no comments on blog) at erich AT debian org.Update: I've received a couple of pointers. Please don't send me links to projects that are not actively maintained anymore - I don't want to care about having to fix bugs in the editor widget myself.One link I've received twice is actually quite impressive: WYMeditor. It doesn't try to look like a word processor, but actually is more of a semantic editor. Much more what I'm looking for than any of the others. I've also received a link to the Yahoo! UI Library Editor, which is quite clutter-free, but in the default setup at least very text-formatting oriented, not very semantic (that doesn't mean you couldn't change it that way, I guess you can). I was also pointed to Dojo, but that framework is totally feature creep (which also explains why it loads so slowly I guess), and the last time I looked at it's source code, I had some WTF moments - code quality at least outside of core doesn't seem to be very high (Yes, that code implements the "mod 7" operation using list shifts instead of a simple arithmetic operation).Looks like I'll give the first try to WYMeditor. Update #2: the code seems to be rather ... complex. I'm looking for something neat and clean; it doesn't need to bring along yet another XHTML schema and validator ... Maybe I should try one of the others first?

So, we are still mostly able to keep our release each two weeks promise. For this release we have two big additions to the support side of the project: translations support, and gtk-doc support. The former is made of the usual makefile rules used by gettext-enabled projects with a rework to fit in the non-recursive build process of WebKitGTK+. The later is not as well integrated yet, so you have to go manually to WebKit/gtk/docs and type make, but not before editing WebKit/gtk/webkit/webkitprivate.cpp and adding a call to g_thread_init(NULL); to webkit_init(). You get the idea, we need help in polishing this one. As for code, Xan Lopez has been doing some serious work on accessibility support, using ATK. After the a11y hackfest he landed a number of patches moving forward in this direction. It looks like we will be able to meet the requirements for becoming blessed for use by GNOME. We also got a nice printing API, that allows applications to stop using the nasty hack that would send a print() call through javascript. They are also able to control/monitor the print process, or automate it, so that no print dialog is shown, if they wish. That s it, come join the party =D. Now, for 1.1.6, I m hoping Diego finishes the spelling check patch, and it would be awesome to have Jan s proper error reporting!

Do you listen to the radio? I don t, and there are multiple reasons for that: First and foremost, I don t like the music they play these days. Even though there are stations which will occasionally play a more eclectic tune, the Swiss government does not, to my knowledge, dictate any quota, like New Zealand actually requires stations to broadcast New Zealand music at least 20% of the time. The result is music made by producers, who stand pop icons with little clothing in front of microphones, instruct them to move their bodies in obscene ways, and coach them to croak songs someone else wrote en masse in some basement somewhere. All those songs sound alike. To ensure a constant supply of pop dolls, they hype television shows with titles such as Germany s seeks the next superstar , when most of Germany actually couldn t care less, and only those with vacuous brain capacity follow with excitement, because they wouldn t know what else to do. Second, I don t have the time or energy to listen to discussion rounds on the radio, especially not when topic are about society , which noone can define in the first place. Wittgenstein always had it right. The same goes for most commentaries. If I don t have anything to do, I prefer to listen to birds in the trees, rather than someone s polished opinion. The scariest aspect is that those people actually believe that they have something worthwhile to say, and so do their producers and the other staff, when in most cases, they don t. At least not worthwhile to people who have other things occupying their minds. I also don t like someone to make a pre-selection of news and squash that into 5-15 minute time slots, to be read out by dull-sounding speakers. I d rather skim over articles, and the Web ensures that I get the information I want much quicker than the radio stations can transmit them. And sports over the radio waves makes me come close to aural epileptic seizures. I am painting the sky black a bit. I am fully aware that there exist people with thought-provoking arguments, that some stations play interesting music I would otherwise never discover, and that the radio is a source of entertainment in the lives of thousands of other people who are less privileged than me. But when the Billag rang my doorbell today and wanted CHF 14,10 per month for posession of any device capable of turning radio waves into sound, including those radio waves broadcast over the Internet these days, I got a bit furious. In the past, they concentrated only on actual radio and TV receivers. When I moved into my previous flat in Zurich in 2002, they wanted money because my stereo had a tuner button. I refused to pay, opened the device, unsoldered the radio coil, and sent it to them with an angry letter of refusal; they let me off the hook. Since then, they changed the law in 2007 (but haven t actually updated the forms they force you to sign) to include audio players, cellular phones, and computers, which are all radio-capable. I d really prefer if they used their funds to revert that trend, or at least remove the loudspeakers from all mobile phones. But instead, this morning, I skid right into their claws. As I said before, the radio is also a social support system, and as such I have less of a problem to subsidise it. However, given that I strongly disagree with the quality level broadcast, I would prefer to direct my money towards causes I consider more useful, and with which I could better identify. Unfortunately, the whole system is governmentalised to the point where this choice is taken away from me. The Billag website helpfully offers answers to the common questions, including one along the lines of quality. They suggest that you get in touch directly with the programme directors to complain about their content, and offer suggestions. Shortly after I moved to Zurich, Radio Lora offered me a radio show. Radio Lora is a private station, but they also receive subsidies from the monies exacted by the government, so I am using them as an example here. I suggested that I concentrated only on progressive and psychedelic rock from the sixties and the seventies. They refused the show in the end, claiming that this would not be what their listeners want. So instead I now get to pay for content that is deemed more appropriate. I can only imagine the pains I d have to go through to be able to host a radio show concentrating on eclectic tunes on one of the public radio stations. And even if I succeeded (without becoming a full-time public radio broadcaster), then I could only contribute a few hours a week to that content. If you ask me, the Swiss government is overstepping its competencies a bit. NP: Mono: Hymn to the Immortal Wind

SSH is really the Swiss Army pocket knife of sysadmin tools. When I needed to periodically synchronize log files from an old server (old as in customer-would-never-update-it-or-install-anything-new), I built a simple and secure solution using rsync and ssh. This is what I did: (I will call remote the system where the logs I want to retrieve are, and local system where I want them to be copied to) First I created an account with a restricted shell (ideally this should be a system account, but we ll get there!):

remote# adduser --ingroup nogroup --shell /bin/rbash rlogs

Then locally, I created a new, password-less ssh key pair, copying it to my remote system:

local$ ssh-keygen
>>> When asked where to save it, I chose a different name, like .ssh/rlogs
local$ ssh-copy-id -i .ssh/rlogs.pub rlogs@remote
...
>>> You can delete the password of user rlogs, so it, effectively,
>>> cannot log-in with it (almost like a system user).
remote# passwd -d rlogs

Now you should be able to run password-less rsync already (note that I use -e option to point to a different key):

local$ mkdir logs
local$ rsync -av -e "ssh -i $HOME/.ssh/rlogs" rlogs@remote:"logs/" logs/
receiving file list ... done
./
file1
file2
...
fileN

But even with a restricted shell, I wanted even less possible things to happen. That s what command= directive is for It will only allow that command to be run in a session started by that key. Since rsync translates a lot of its command-line options, I run it again with a dirty ps-in-a-loop in the remote host, just to see what running rsync locally causes remotely:

remote$ while 1; do ps wp $(pgrep rsync); sleep 1; done
...
local$ rsync -av -e "ssh -i $HOME/.ssh/rlogs" rlogs@remote:"logs/" logs/
>>> in the remote loop you should be able to get the command:
  PID TTY      STAT   TIME COMMAND
 6183 ?        Ss     0:00 /usr/bin/rsync --server --sender -vlogDtpre.i . logs/

Here comes the authorized_keys magic. At the remote host I edited .ssh/authorized_keys to add a command= line with what I found out in my dirty loop. Also, I added a couple of directives to restrict it even further (they are pretty self-explanatory):

rlogs@remote$ cat .ssh/authorized_keys
command="rsync --server --sender -vlogDtpre.i . logs/",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa (...) myuser@local

Now everything is set. I just added the rsync command to the local crontab and it s done.

I've started to develop awesome more than 18 months ago, and somehow I feel it's time to stop a bit and think where we come from and where we are going to. The motivation I never though I'd be written a window manager one day. That seems kinda stupid when you see how many window manager there's around. As many people, I've tested and have been using tons of window manager: Window Maker, Fluxbox, etc. In August 2007, I was using fvwm since 2004 and was quite happy with it. I used the famous fvwm-crystalhttp://www.fvwm-crystal... as a configuration starter and then rewrote lots of stuff. Digging into fvwm configuration files was boring, and since I'm lazy, I never really configured it to fit entirely my needs. The thing is that, in July 2007, my workstation died. I bought a new one based on the amd64 architecture. Too bad, with this new box, fvwm decided that it will not longer runs and was segfaulting almost every time I logged in. I was really upset. Another failure in the window manager world. So I decided to get the yearly ride of testing many window managers. I went on the no more developed stuff like the *boxes, ion3, etc but well, I did not like them, there were not powerful enough, too bugged or upstream was insane. Then I found xmonad. The Haskell configuration file format made my cry. I did not want to learn Haskell, it seemed too obfuscated to me. At that time it was even not packaged for Debian, so I gave up. But I found dwm in the meantime, and I loved it. It was simple, and the source code was almost understandable and easy to hack. I subscribed to the dwm mailing-list, in order to participate to its development, etc But I got really disappointed. No patch were welcome and the development seemed to be almost finish in this sight. People patches were lying around, but no one really care. Each user was managing its own set of patches. That's not what I learnt and what I love in free software. So, as many users, I began to maintain my patches in my corner. But I began to have more ideas The jdwm I just added a 'j' in front of dwm and started to hack it days and nights to add many feature I missed, like multi-head, etc On 5th September 2007, I created a git repository to host my code. That's gonna be awesome. Five days later, on 10th September, I finally found a name for my new pet: awesome, borrowed from Barney Stinson who heavily uses and abuses this word. The 1.x branch The first releases until December were noted 1.x. It was just a better dwm with a simple flat configuration file.. The configuration file used libconfig, but it was a very poor choice. And I was not able to put in into Debian because of name clash. The 2.x branch The 2.x branch came in January 2008 with a brand new configuration file format based on libconfuse, which was a bit more powerful. Many concepts and features that have been added in this branch are still used in the current 3.x branch. At this time, between December 2007 and April 2008, the community was growing smoothly. But as I said, awesome 2 was based on a flat configuration file. That raised a problem very soon: users expectation were growing and the development team (me and a couple of regular contributors) was unable to cope with them. One of the event that started to change my mind was the support for titlebars. When I've added titlebar support, it was minimal. It was on top of a window, with the window title. Dot. Then I've started to add a lot of options, like the application icon drawing, the position (left, right, bottom) etc. And then users started to ask for more, like: "add titlebar on windows only when the window is floating". That's ok, but that's complicated: that's again another option to do some stuff conditionally. And then, why don't add titlebar on windows when <insert random events here>? The 3.x branch Why At that time, around April 2008, I'd totally stopped development. I was trying to find a solution which was simple and powerful. But after 2 weeks of thinking, I was not able to find anything else than: use a real language for configuration. So, I've started prototyping awesome 3 using Lua. The choice was not obvious, and despite the problem Lua might suffer, it's one of the easiest language to integrate into an existing application. There's still a video of a first version here. But, let's go a little back: in January 2008, Arnaud Fontaine contacted me because he was interested to use awesome as one of its school project. He decided to port awesome from Xlib to XCB, a modern asynchronous X library. His work took some time, but in May 2008, Arnaud did finished to port git master version of awesome to use XCB. Consequently, I decided to start a new major branch, using XCB instead of Xlib (no change for users in this regard) and Lua instead of our previous flat configuration file format. Development It took me a while to get from here to there, but in September 2008, it was ready. We had a simple Lua API, and the XCB port was working perfectly. It took us some time to release and have something totally working, because we had to work on XCB and contribute back to the project. It was really not ready to use by an application, but we did great work in this area and it's now really fine. We're still here Releases continue to happens, 3.1 around December 2008, and 3.2 around March 2009. 3.3 should be here in June. One of the drawback we had, is that we moved many stuff from C to Lua. Why? Because writing things in Lua is quicker and easier to maintain than C, and makes thing more configurable for the user. For example, the layout algorithm used to organize window were written in C until 3.2 came out. At that time, users had no choice than using a set of predefined layout to organize their windows. Starting with 3.2, if they have minimal knowledge about geometry, they can start writing a layout function organising windows on the screen. But this kind of API changes was a bit rough for users, since they had to port some part of their configuration file to the new API. The thing is that the project was still a teenager at that time, not really knowing were it will go. But I'm happy to announce that API breakage are more and more rare (so far only one minor between 3.2 and 3.3), and anyway always for the Good. But I admit that it built a bad reputation around awesome 3.x during its first month of existence. Future direction I am currently working on 3.3 development. We have still many things to do. Time passing, we get more idea, and more users. And more users bring more ideas. We also have many more contributors, and some guys are even taking maintainer-ship of some code area. Conclusion My post title is "Taking the other direction" because I feel this way. I've got that feeling that some approaches in projects like GNOME are sometimes bad. Please don't misread me, I know we are not playing in the same yard. When adding a key shortcut for starting an application makes you dig into gconf, I wonder how this is a win for the user. Well, it's probably a win for the end-user, but I surely am not one of them. And I don't intend to target them with my software, anyway. And now, when I hear things like GNOME 3.0 and the "desktop shell" approach, that makes me smile. Guys, it was time, but have luck. What I see from here, is that any desktop control interface is wrong somehow, and that there's no approach that can fulfill all users wishes. I think that we, the awesome development team (no pun intended) took the direction of building a frame-work window manager rather than a solution written in marble. We (partially) solved the issue of UI ergonomic by not writing one and allowing the user to write his own. I don't say that's easy to do for most of users, but it's doable. And I think it's worth it: I use window managers since I use Linux, around 1998. If something like awesome came 5 years ago, I'd be using it so far, because you can write Fluxbox or WindowMaker using awesome in a hundred of Lua code. And you can write your own version of it. And it starts in less than 3 seconds, supporting almost all standard desktop specification (ICCCM, EWMH, XDG, system tray, message notification, D-Bus, etc), whereas many of the window mangers do not. You can even write and play space invaders. Finally, I'm happy about the the road we took so far, and hope we will continue into that direction. The rants I read about our project are not that big, compared to the kudos we received.

I've started to develop awesome more than 18 months ago, and somehow I feel it's time to stop a bit and think where we come from and where we are going to. The motivation I never though I'd be written a window manager one day. That seems kinda stupid when you see how many window manager there's around. As many people, I've tested and have been using tons of window manager: Window Maker, Fluxbox, etc. In August 2007, I was using fvwm since 2004 and was quite happy with it. I used the famous fvwm crystal as a configuration starter and then rewrote lots of stuff. Digging into fvwm configuration files was boring, and since I'm lazy, I never really configured it to fit entirely my needs. The thing is that, in July 2007, my workstation died. I bought a new one based on the amd64 architecture. Too bad, with this new box, fvwm decided that it will not longer runs and was segfaulting almost every time I logged in. I was really upset. Another failure in the window manager world. So I decided to get the yearly ride of testing many window managers. I went on the no more developed stuff like the *boxes, ion3, etc but well, I did not like them, there were not powerful enough, too bugged or upstream was insane. Then I found xmonad. The Haskell configuration file format made my cry. I did not want to learn Haskell, it seemed too obfuscated to me. At that time it was even not packaged for Debian, so I gave up. But I found dwm in the meantime, and I loved it. It was simple, and the source code was almost understandable and easy to hack. I subscribed to the dwm mailing-list, in order to participate to its development, etc But I got really disappointed. No patch were welcome and the development seemed to be almost finish in this sight. People patches were lying around, but no one really care. Each user was managing its own set of patches. That's not what I learnt and what I love in free software. So, as many users, I began to maintain my patches in my corner. But I began to have more ideas The jdwm I just added a 'j' in front of dwm and started to hack it days and nights to add many feature I missed, like multi-head, etc On 5th September 2007, I created a git repository to host my code. That's gonna be awesome. Five days later, on 10th September, I finally found a name for my new pet: awesome, borrowed from Barney Stinson who heavily uses and abuses this word. The 1.x branch The first releases until December were noted 1.x. It was just a better dwm with a simple flat configuration file.. The configuration file used libconfig, but it was a very poor choice. And I was not able to put in into Debian because of name clash. The 2.x branch The 2.x branch came in January 2008 with a brand new configuration file format based on libconfuse, which was a bit more powerful. Many concepts and features that have been added in this branch are still used in the current 3.x branch. At this time, between December 2007 and April 2008, the community was growing smoothly. But as I said, awesome 2 was based on a flat configuration file. That raised a problem very soon: users expectation were growing and the development team (me and a couple of regular contributors) was unable to cope with them. One of the event that started to change my mind was the support for titlebars. When I've added titlebar support, it was minimal. It was on top of a window, with the window title. Dot. Then I've started to add a lot of options, like the application icon drawing, the position (left, right, bottom) etc. And then users started to ask for more, like: "add titlebar on windows only when the window is floating". That's ok, but that's complicated: that's again another option to do some stuff conditionally. And then, why don't add titlebar on windows when <insert random events here>? The 3.x branch Why At that time, around April 2008, I'd totally stopped development. I was trying to find a solution which was simple and powerful. But after 2 weeks of thinking, I was not able to find anything else than: use a real language for configuration. So, I've started prototyping awesome 3 using Lua. The choice was not obvious, and despite the problem Lua might suffer, it's one of the easiest language to integrate into an existing application. There's still a video of a first version here. But, let's go a little back: in January 2008, Arnaud Fontaine contacted me because he was interested to use awesome as one of its school project. He decided to port awesome from Xlib to XCB, a modern asynchronous X library. His work took some time, but in May 2008, Arnaud did finished to port git master version of awesome to use XCB. Consequently, I decided to start a new major branch, using XCB instead of Xlib (no change for users in this regard) and Lua instead of our previous flat configuration file format. Development It took me a while to get from here to there, but in September 2008, it was ready. We had a simple Lua API, and the XCB port was working perfectly. It took us some time to release and have something totally working, because we had to work on XCB and contribute back to the project. It was really not ready to use by an application, but we did great work in this area and it's now really fine. We're still here Releases continue to happens, 3.1 around December 2008, and 3.2 around March 2009. 3.3 should be here in June. One of the drawback we had, is that we moved many stuff from C to Lua. Why? Because writing things in Lua is quicker and easier to maintain than C, and makes thing more configurable for the user. For example, the layout algorithm used to organize window were written in C until 3.2 came out. At that time, users had no choice than using a set of predefined layout to organize their windows. Starting with 3.2, if they have minimal knowledge about geometry, they can start writing a layout function organising windows on the screen. But this kind of API changes was a bit rough for users, since they had to port some part of their configuration file to the new API. The thing is that the project was still a teenager at that time, not really knowing were it will go. But I'm happy to announce that API breakage are more and more rare (so far only one minor between 3.2 and 3.3), and anyway always for the Good. But I admit that it built a bad reputation around awesome 3.x during its first month of existence. Future direction I am currently working on 3.3 development. We have still many things to do. Time passing, we get more idea, and more users. And more users bring more ideas. We also have many more contributors, and some guys are even taking maintainer-ship of some code area. Conclusion My post title is "Taking the other direction" because I feel this way. I've got that feeling that some approaches in projects like GNOME are sometimes bad. Please don't misread me, I know we are not playing in the same yard. When adding a key shortcut for starting an application makes you dig into gconf, I wonder how this is a win for the user. Well, it's probably a win for the end-user, but I surely am not one of them. And I don't intend to target them with my software, anyway. And now, when I hear things like GNOME 3.0 and the "desktop shell" approach, that makes me smile. Guys, it was time, but have luck. What I see from here, is that any desktop control interface is wrong somehow, and that there's no approach that can fulfill all users wishes. I think that we, the awesome development team (no pun intended) took the direction of building a frame-work window manager rather than a solution written in marble. We (partially) solved the issue of UI ergonomic by not writing one and allowing the user to write his own. I don't say that's easy to do for most of users, but it's doable. And I think it's worth it: I use window managers since I use Linux, around 1998. If something like awesome came 5 years ago, I'd be using it so far, because you can write Fluxbox or WindowMaker using awesome in a hundred of Lua code. And you can write your own version of it. And it starts in less than 3 seconds, supporting almost all standard desktop specification (ICCCM, EWMH, XDG, system tray, message notification, D-Bus, etc), whereas many of the window mangers do not. You can even write and play space invaders. Finally, I'm happy about the the road we took so far, and hope we will continue into that direction. The rants I read about our project are not that big, compared to the kudos we received.

Last night, I stayed up late reworking the avionics bay in my Giant Leap Vertical Assault kit. This is the rocket I set my personal best altitude to date of 14,141 feet above ground level with. The Missile Works RRC2 mini will move to a lesser airframe to keep it below 10k feet AGL since it's an early unit with the supposedly-buggy early firmware. In its place, I've mounted a PerfectFlite MiniAlt/WD to handle primary deployment duties... and serial number 1 of TeleMetrum! Meanwhile, Keith has completely rewritten the guts of the firmware in the last few days to eliminate FreeRTOS since it turns out to just be too heavy for our needs on this project. My board is now running a snapshot of his latest work, and in bench testing I've confirmed that it can do launch detect, log sensor data until the non-volatile memory chip is full, and dump the raw data over USB for analysis after a flight. Weather has been an issue in Colorado recently, but as soon as we get a decent launch day (maybe as early as this weekend?), I'm looking forward to flying this rocket on one or all of the Cesaroni I205, I540, and J285 currently in my box to get some initial flight data recorded. Keep your fingers crossed for me that the storm front headed towards us clears out by the weekend!

Gammu 1.24.0 is out! It does not bring any new outstanding features, just small optimizations in SMSD, documentation improvements and various bug fixes. Full list of changes:

• Better detect Bluetooth ports on Samsung (bug #862).
• Ignore security errors on AT init (needed for Huawei).
• LUID reading requires IrMC profile.
• Locations for GlobeTrotter 3G+ start at 0 (bug #847).
• More verbose logging of delivery reports (bug #824).
• Increase default DeliveryReportDelay (bug #824).
• Fixed handling of SMS locations (bug #853).
• PostgreSQL backend now supports IDs for RunOnReceive.
• RunOnReceive is started through shell not directly.
• Fixed reading of empty phonebook entries from Samsung (bug #809).
• Reread messages if CMGL shows them corrupted (bug #691).
• Added support for vNote files.
• Properly detect Nokia 6220 Classic (bug #840).
• Fix writing of phonebook on Motorola V8 (bug #827).
• Detect daemon on FreeBSD.
• Ignore charset errors on AT init as some phones might need PIN.
• Optionally use MT for phone phonebook for AT phones.
• Added support for quick dial numbers on AT phones.
• Fixed decoding of Samsung memory entries.
• Properly handle corrupted messages from Nokia phones (bug #811).
• Fix parsing of calls from Alcatel C701 (bug #831).
• Fixed handling of error states with -len and -autolen parameters.
• Fixed possible crash in DBI engine.
• PostgreSQL engine properly uses sequences instead of reinventing.
• MySQL engine properly uses auto increments instead of reinventing.
• Fix escaping of field name in PostgreSQL engine.
• Better SMSD files logging.
• Added testing of SMSD files engine.
• Increase timeout for AT settings SIM card SMS storage.
• Fixed date formatting in PostgreSQL SMSD service.
• Add option to install without documentation.
• Add -textutf8 option for TEXT sms.
• Fix crash when some lines in config are too long.
• Make smsdrc example better looking by removing obsolete docs.
• Make dku2 connection types work on Linux (alias to fbususb).
• Better calculation of signal percent.
• Fixed getting of memory status for some Nokias (bug #836).

You can download from usual place: http://cihar.com/gammu/, Debian users will find packages in unstable soon, SUSE, Fedora and Mandriva users can check repository in OpenSuse Build Service and Ubuntu in my PPA.

... finally I'm tiling too! Short story: I've just switched to xmonad as my window manager of choice within a Gnome desktop environment; I give some tips on how to achieve that quickly on a current Debian/unstable machine. /me and tiling window managers I switched to Gnome a long time ago. The benefit of that over good old window managers is enjoying an integrated environment and a workplace that you can find on other machines (e.g., the netbook you installed for your mother, the office desktop, the student lab machines, ...). Still, I've never been particularly happy about Gnome's default window manager: metacity. The feature I was missing the most is the ability to configure windows programmatically so that they appear where and how I want by default; sadly enough, the Gnome session mechanism is not yet able to do that properly. Hence, I've tried various time switching to a tiling window manager, imposing the extra requirement that it should integrate with Gnome. The coolest guy on the block of that area seems to be awesome and I gave it a try some months ago. I liked most of its (sometime revolutionary) principles, like window tagging, but I equally hated various aspects of it:

• Documentation back then was horrible, starting from the manpage speaking of mod 1,2,3,4,5 without giving a hint about where the heck they are mapped to by default, ranging to the lack of references manual about what you can call from LUA configuration files. ... use the source, Luke ...
• Community was mainly composed by super-users, which is good if you want to do some super-configuration. ... but is deeply bad if you are trying to get hints on how to make awesome cope with Gnome. I remember having been treated as a total luser on IRC, with people more interested in convincing me that I should stop using Gnome than in helping out achieving what I wanted to.

People nowadays tell me that awesome works fine with Gnome, so maybe I've just been unlucky back then, but sometime the first impression does count. I've never considered seriously xmonad, thinking (with no sound reason, apparently) that it was a project of the series: "I'm a fan of programming language $LANG, all my apps should be written in $LANG, my window manager is no exception", with LANG=haskell. Then two things happened:

1. a couple of weeks ago I stumbled upon the xmonad wiki and documentation, and I was impressed by the average quality of the information shipped there. It is not something you usually find in "language showcase" projects.
2. Patrick blogged about its switch to xmonad + Gnome, with enthusiastic feedback. If that's not a sign I don't know what it can be

Getting started with xmonad + Gnome on Debian There is a page explaining how to use xmonad with Gnome in the xmonad wiki, but a handful of additional tips will help you get started in Debian, even if you know (almost) nothing about Haskell (yet).

• You should install packages xmonad and libghc6-xmonad-dev. Without the latter you will not be able to configure your xmonad; in particular you will not have access to the Gnome configuration library, which offers sane defaults for using xmonad with Gnome. (See below for a rant on the disk usage of installing the second package ...)

The (crazy) way in which xmonad works is that you create your config file as ~/.xmonad/xmonad.hs. That file is a full fledged Haskell program, which gets compiled to obtain your own xmonad executable which you run as your own window manager. /usr/bin/xmonad is the executable you initially run, but is just a wrapper around the compilation + run mechanism

• Since you have installed libghc6-xmonad-dev, you have access to a module pre-configuring xmonad for Gnome, just use the following as your starting xmonad.hs:

  import XMonad
  import XMonad.Config.Gnome
  main = xmonad $ gnomeConfig  
           modMask = mod4Mask
          
  
  

The modMask setting means that ALT will get delivered to applications, while all xmonad commands are delivered via the infamous windows key: no more conflicts between apps and WM \o/.

• At this point you can configure xmonad as your Gnome window manager. Disable re-spawning of metacity in your session option, and run somewhere killall metacity ; xmonad & . For the next session runs you will have to remember the running xmonad in your Gnome session, as usual.

The default Gnome configuration is quite nice: you can retain your Nautilus desktop (in spite of what is written on the wiki), mod-p will get you a gnome-run dialog box, and appropriate padding for the (upper!) Gnome panel. The only glitch is that you will get 9 desktops which can clutter your workspace switched. My solution is to have the appler show workspaces on 2 rows but beware of bug 524065, which is really annoying.

• Compositing works as well, by the means of xcompmgr. Just install it and register in your session the result of running xcompmgr -c &. No wonder that it is way faster than compositing manager support in metacity.
• Finally, you can configure window placement in your xmonad.hs by doing something like the following (it already includes the shorter snippet given before):

  import XMonad
  import XMonad.Config.Gnome
  myManageHook = composeAll [
                  (className =? "Pidgin" <&&> title =? "Buddy List") --> doFloat
                 , (className =? "Gnome-panel" <&&> title =? "Run Application") --> doFloat
                 -- , (className =? "XEyes") --> doShift "7"
                 ]
  main = xmonad $ gnomeConfig  
           modMask = mod4Mask
         , manageHook = myManageHook <+> manageHook gnomeConfig
          
  
  

The above example will make the pidgin buddy list and run application dialog box float by default. The commented line is an example of how to deliver specific windows to arbitrary workspaces. To find out window properties on which match in your xmonad.hs, my magic command is xprop egrep "CLASS NAME". Note that you don't need to care about panel placement because it is already taken care of by the default gnome config. Still beware of not using myManageHook as your only management hook, you should update the default one using the <+> monad as I did above. xmonad rant So, what's wrong with xmonad + Gnome in Debian? Well, the fact that it will take about 200 Mb of disk space on amd64 by default. o_O Why so? Because xmonad is affected by the static linking hell which seems to be shared by modern statically typed functional languages, including in the category both Haskell and my beloved OCaml. In short, applications written for those language link statically code written in the implementation language in most cases; they rely on legacy shared libraries only for bindings to C libraries. For xmonad that means that if you are fine with the default configuration you will get a cheap 2 Mb binary package. If you are not, you will need to write your conffile ... which is a Haskell program ... using several contrib libraries ... and needing ghc6 to be compiled and run as your own window manager executable. This is plainly dumb and induces all the usual problems of static linking, like disk consumption due to non-shared (Haskell) code, and worries about staying up to date with the latest library release in case of fixes (including security fixes) need to be propagated to user executables. Truth to be said, /usr/bin/xmonad does a wonderful job in hiding all this to the final user, but still the design choice is an unpleasant one.

I've been largely offline for the last few weeks as I've just bought a flat. This means I haven't been able to do much Debian work. Although I am now back online, I have a lot of other things to be catching up on, so I've decided to to take a break from Debian stuff until 15th May. I will still do some bug work (reporting and following up) and if I somehow find the time I may well do some Debian work regardless. I just feel that having an explicit break (rather than an implicit or imposed one) will make me feel a little bit more in control of things, and hopefully when I return I will have some new positive energy.

The monthly board meeting of Software in the Public Interest will take place on irc.oftc.net #spi tonight (Wed 15 April) at 20:00 UTC. The meeting announcement was posted, but a bit late, so there s another discussion about that going on behind the scenes. The frustrating thing is that fixing the announcements doesn t really need selling out to Google or anything complicated - simply using at on a server to schedule the email would work I know, because that s pretty much what I do at TTLLP for routine member emails. Only the secretary has posted any report at the time of writing and there are no discussion items. There are two sets of minutes up for approval, but one contains at least one error which I ve already described by email. Should be a short meeting, though. Once again (aren t Wednesday evenings awful for me?), I may be without a stable network connection during the meeting. Even so, watch the comments below this article for a link to the summary when posted.

Consider the following mod_rewrite configuration :

RewriteCond % REQUEST_URI !^/FR/fr
RewriteCond % REQUEST_URI !^/common/
RewriteCond % REQUEST_URI !^/favicon.ico$
RewriteRule ^(.*)$ /FR/fr$1 [PT,L]

The need here, is to get anything that wouldn t begin with /FR/fr from $DOCROOT/FR/fr (through, possibly, any other module rules, which was important in the setup where these rules were), except if they begin with /common/ or is /favicon.ico. Depending on the requests pattern, reordering the RewriteConds can be better. Anyways, the case at hand was to massively duplicate this setup over different countries and languages. Basically, domain.fr/foo/bar would need to come from $DOCROOT/FR/fr/foo/bar, domain.co.uk/foo/bar from $DOCROOT/GB/en/foo/bar, while anydomain/common/foo/bar would come from $DOCROOT/common/foo/bar. In such a case, you have a lot of possible solutions, each of which has its pros and cons.

• Create a virtual host per domain, duplicating all the rules in each of them.
  

  <VirtualHost *:80>
ServerName domain.fr
RewriteCond % REQUEST_URI !^/FR/fr
RewriteCond % REQUEST_URI !^/common/
RewriteCond % REQUEST_URI !^/favicon.ico$
RewriteRule ^(.*)$ /FR/fr$1 [PT,L]
</VirtualHost> <VirtualHost *:80>
ServerName domain.co.uk
RewriteCond % REQUEST_URI !^/GB/en
RewriteCond % REQUEST_URI !^/common/
RewriteCond % REQUEST_URI !^/favicon.ico$
RewriteRule ^(.*)$ /GB/en$1 [PT,L]
</VirtualHost>
( )

  Pros: quite efficient for execution time. Cons: Doesn t scale very well for humans : a lot of virtual hosts and rewrite rules to maintain ; if the list of urls that don t need rewrite increases, all set of rules need to be updated.
• Put all the rewrite rules into a single virtual host, adding a condition on the SERVER_NAME:
  

  <VirtualHost *:80>
ServerName domain.fr
ServerAlias domain.co.uk RewriteCond % SERVER_NAME =domain.fr
RewriteCond % REQUEST_URI !^/FR/fr
RewriteCond % REQUEST_URI !^/common/
RewriteCond % REQUEST_URI !^/favicon.ico$
RewriteRule ^(.*)$ /FR/fr$1 [PT,L] RewriteCond % SERVER_NAME =domain.co.uk
RewriteCond % REQUEST_URI !^/GB/en
RewriteCond % REQUEST_URI !^/common/
RewriteCond % REQUEST_URI !^/favicon.ico$
RewriteRule ^(.*)$ /GB/en$1 [PT,L] (...)
</VirtualHost>

  Pros: are there ?. Cons: Doesn t scale very well : a lot of rewrite rules to maintain ; rewrite rules being executed sequencially, the more domains there are, the more checks are done for the last domains ; if the list of urls that don t need rewrite increases, all set of rules need to be updated.
• Same as above, refactoring the common parts.
  

  <VirtualHost *:80>
ServerName domain.fr
ServerAlias domain.co.uk RewriteCond % REQUEST_URI ^/common/ [OR]
RewriteCond % REQUEST_URI ^/favicon.ico$
RewriteRule .* - [L] RewriteCond % SERVER_NAME =domain.fr
RewriteCond % REQUEST_URI !^/FR/fr
RewriteRule ^(.*)$ /FR/fr$1 [PT,L] RewriteCond % SERVER_NAME =domain.co.uk
RewriteCond % REQUEST_URI !^/GB/en
RewriteRule ^(.*)$ /GB/en$1 [PT,L] (...)
</VirtualHost>

  Pros: gives a canonical place for urls that don t need rewrite. Cons: Doesn t scale very well : a lot of rewrite rules to maintain ; rewrite rules being executed sequencially, the more domains there are, the more checks are done for the last domains.
• Use a RewriteMap.
  Pros: Scales better ; gives a canonical place for urls that don t need rewrite. Cons: a separate file to maintain ; can be tricky to setup.

The main problem with mod_rewrite is that there is no way to use variables or back references in the test patterns. In our case, we d like to be able to do something like this:

RewriteMap l10n txt:l10n.map # switch to dbm when necessary
RewriteCond % REQUEST_URI !^$ l10n:% SERVER_NAME
RewriteCond % REQUEST_URI !^/common/
RewriteCond % REQUEST_URI !^/favicon.ico$
RewriteRule ^(.*)$ $ l10n:% SERVER_NAME $1 [PT,L]

Or

RewriteMap l10n txt:l10n.map # switch to dbm when necessary
RewriteCond $ l10n:% SERVER_NAME ^(.+)$
RewriteCond % REQUEST_URI !^%1
RewriteCond % REQUEST_URI !^/common/
RewriteCond % REQUEST_URI !^/favicon.ico$
RewriteRule ^(.*)$ %1$1 [PT,L]

The map file would have on each line a domain name followed by the corresponding url start (/FR/fr for domain.fr, etc.). Unfortunately, the above setup is not possible. A way around this lack of functionnality is to use some nice perl regexp trick.

RewriteMap l10n txt:l10n.map # switch to dbm when necessary
RewriteCond $ l10n:% SERVER_NAME ^(.+)$
RewriteCond %1% REQUEST_URI !^(.+)\1
RewriteCond % REQUEST_URI !^/common/
RewriteCond % REQUEST_URI !^/favicon.ico$
RewriteRule ^(.*)$ %1$1 [PT,L]

As you can see, only the second RewriteCond differs. What we really want to test is whether the % REQUEST_URI begins with the proper url start or not. Let s say we re considering domain.fr and the map gave us /FR/fr. Following the first RewriteCond, %1 contains /FR/fr. At the second RewriteCond, if % REQUEST_URI begins with /FR/fr then %1% REQUEST_URI begins with /FR/fr/FR/fr. Otherwise, it will only begin with /FR/fr. What we can test, then, is whether this %1% REQUEST_URI aggregate contains a repeating pattern at its beginning. This is exactly what the perl regexp does: it captures at least one character at the beginning of the tested string (^(.+)), and wants to find this captured string again (\1). It is worth mentioning that this obviously falls flat when the url start itself contains a repeating pattern (e.g. /fr/fr instead of /FR/fr). As we want the RewriteRule to work only when our % REQUEST_URI does not begin with /FR/fr, we negate the regexp, which means nothing will actually be captured, such that %1 in the RewriteRule will still be the last captured text, from the very first RewriteCond. Note that if all the tested url starts are the same length and/or pattern, it may be worth changing the regexp to be more precise (and faster to match or not). Such as ^(/../..)\1 in our present case.

This is a short summary of how I'm currently experimenting with dpkg to generate, check and install TDebs in a pbuilder chroot. Do NOT use my modified version of dpkg outside a chroot!. Also, I don't expect any of this to be useful or usable by anyone not running Debian sid. If you're reading this via an aggregator other than planet.debian.org, please don't try this on your own systems. (Comments complaining that it breaks Ubuntu will be deleted - I'll have good fun laughing at you but the comments will still be deleted.)

The code (such as it is) lives at git.debian.org and it's safe to build the package on the normal system, as long as you install it in the chroot. I actually use a --prefix to allow

sudo make install

to copy the executables into the right places in the chroot. I find that quite simple to do via the terminal plugin in Anjuta.

Building a TDeb for the first time:
I expect lots of comments here, this probably won't be entirely workable initially, but the idea is to get the source for a package that has translations, that is easy and quick to build, few build dependencies and one with which you are already familiar. Adapt that package to support a TDeb by adding the relevant Package: to debian/control. All you need to include is: XC-Package-Type: tdeb and ensure that the new package is Architecture: all. Current convention is to call it $sourcepkg-tdeb. (Yes, although TDebs are initially going to be for debconf support in Squeeze+1, initial experimentation is with program translations because it's easier.)

/usr/share/emdebian-tools/dh_gentdeb (from the emdebian-tdeb package in Debian) can help prepare the translation files by creating the debian/$sourcepkg-tdeb/ directory hierarchy but you could also do the same by installing all /usr/share/locale/ content in the tdeb package in debian/rules or debian/foo.install. Remember to remove the translation files from any other package.

Building the TDeb should be as simple as:

dpkg-deb --tdeb -b debian/pilot-qof-tdeb ../pilot-qof-tdeb_0.1.7-1_all.tdeb


You do not need to build the source itself but you may want to do that for other reasons. You can then view the contents using:

dpkg-deb -c ../pilot-qof-locale_0.1.7-1_all.tdeb

or

ar -t ../pilot-qof-locale_0.1.7-1_all.tdeb

Install (dpkg -i ../pilot-qof-locale_0.1.7-1_all.tdeb --lang vi) used to work but I've messed up something there, so any ideas on what I've done wrong would be appreciated.

Subverting git with subversion

Yes, I'm a git phobe. Don't flame me and any comments about my git foo by the git fanboy contingent will also be deleted.

I have to use git for this because the dpkg maintainers like git. That doesn't mean I have to like it or even use it. So, I use a local SVN repository. I do all my development work against that (because it's more friendly) and make local commits to it. Then, when I'm reasonably happy with the results, I copy the files across into git, fake a git commit message that more or less covers the real changes and use a script to "push" git to do what I intended. If (more likely, when) git decides to be all unfriendly and throw a completely unintelligible error message, I simply rm -rf git/path/, check out a fresh git, copy the real stuff from SVN and send the lot back as a single commit to git. Hah!

(For those who are not so blinded by their git obsession that they may actually care about my process, I can only say that local SVN is blisteringly fast and never, ever, fails.)

At some point I might document my current e-mail setup, but for now, here's the bit that caused plenty of frustration on Friday. Many howtos for postfix and dspam will tell you that if you embed user IDs in the signature with PgSQLUIDInSignature on (or the MySQL equivalent, you can do something like this for retraining, and set it up to receive spam@example.com:

# master.cf
dspamretrain unix -     n       n       -       10      pipe
  flags=R user=dspam argv=/usr/bin/dspam --user dspam
      --class=$ nexthop  --source=error
# mailbox_transport map
spam    dspamretrain:spam
notspam dspamretrain:innocent

in which --user dspam names an arbitrary user (dspam will extract the uid from the signature and switch from "dspam" to the correct user, but the command line argument is still required, for no particular reason). I said it named an arbitrary user, but actually that's a lie. The things to be careful of are:

• the dspam user must be listed in your database (e.g. in dspam_virtual_uids for postgres users with the default setup)
• if you're running dspam in opt-in mode, dspam must have opted in (so create /var/spool/dspam/opt-in/local/dspam.dspam)

Having failed at both of those, my retrain address wasn't working, and sadness ensued.

Stephen Marenka wrote to the debian-68k list lately:

So you may have noticed the following in your buildd logs for python-
depending packages.

dpkg: regarding .../python-docutils_0.5-3_all.deb containing python-docutils:
package uses Breaks; not supported in this dpkg
dpkg: error processing /srv/chroot/sid/var/cache/apt/archives/python-docutils_0.
+5-3_all.deb (--unpack):
unsupported dependency problem - not installing python-docutils

That's right, our old etch-m68k dpkg doesn't support Breaks.

The options I can think of are.

Option 1: backport dpkg to etch-m68k
Yuck. etch-m68k is old and likely insecure. Who knows what
back-porting dpkg would look like.

Option 2: lenny-lite
Build lenny with base, build-essential, and buildd-required
packages. I can probably do this one myself if there's
interest. I'll probably include anything required for d-i
too.

Option 3: lenny
Go ahead and try to do a lenny release. I think we have
nearly all the binary packages, but how to shove them into
an archive intelligently? I'm willing to help if anyone
knows how and can direct or is otherwise willing to lead.

Option 4: throw in the towel
Say it's time to retire m68k on debian. We have an ancient
glibc with borked threads. gcc-4.3 is fairly broken. A
number of packages need some bugs fixed, others need some
porting. Not so many helpers these days. Funny thing is with
aranym we have plenty of horsepower (although we need to fix
the fpu emulation) and with d-ports our buildds won't get
locked out of wanna-build. Kernel's probably in the best
shape it's been in a long time.

peace,

stephen

--
Stephen R. Marenka If life's not fun, you're not doing it right!

Yes, it's true... the Vancouver proposal seems to be a true success in killing the m68k port. Stephens mail is just a written example of what I've been thinking about for several weeks as well: does it still make sense to run my Amigas after being kicked out by Debian?

Luckily there were some new users appearing on the list asking for how to install Debian on their m68k machines, which shows that there's still interest in the port and need for a Debian on m68k. This makes me more confident in still supporting the m68k port for me by running several buildds 24/7. But as Stephens mail shows the m68k port is in trouble. It would be nice if there were more porters helping in actually porting software or fixing bugs. There are some open issues like NPTL support and such. See the list archive or the Debian wiki for more information.

Despite all the bad luck with being kicked off by Debian, the port did made some progress in the past: we're not bound by real m68k hardware anymore. Thanks to Aranym every interested developer can now contribute by running the emulator on his/her fast i386 machine. There are crosscompilers available as well.

But there's still work to do. For example to Coldfire inclusion seems to got stuck somehow. And I don't think that it makes much sense to try to build all of Debian >>6000 packages for m68k, but to concentrate on maybe below 2000 packages. So if you want to help to m68k port staying alive, please join us at debian-68k mailing list! :-)

It's been a long time since I've done any reasonable work on X stuff, so it's also been a long time since I've blogged. But Julien and Brice* just finished off the major task of getting 7.4 in to unstable, and I've been trying to help out with some of the inevitable fallout from that. Overall, the transition has been relatively smooth, although we've had a few major classes of bugs that have popped up. Since dealing with the BTS is rather complicated and doesn't lend itself to simple summaries, I created this wiki page for the team to track the major classes of bugs currently plaguing unstable. This isn't meant to track every bug (that's what the BTS is for), but for major regressions or problems with new features, we'll be trying to use this page to give ourselves and users a way to easily see what's going on with some of the more recent problems. And yes, this does include the infamous hal depends bug, which we are currently discussing, and will deal with accordingly.

* Edit: Removed by request

I have found myself, at least on a few occasions, talking to a person whose relationship to the Internets is much thinner than my own, trying to explain the nature of certain Internet memes. I find this a pretty tough task to pull off as I tend to make memes sound really infantile (and perhaps that is just what they are). To explain this world to the uninitiated, I either: 1) very quickly give up and move onto some other less obscure 2) go into semi-professorial lecture mode and give a mini-low down on memes, some of the early examples, a small theory of self-referential irony, 4chan, rickrolls, encyclopedia dramatic etc etc and then show a bunch of memes as really you can t do it justice without the audio visul component. Now, I can just point people to the Meme Factory to three youngish guys from Brooklyn who put together a **fantastic show**** a few weeks ago on, yes, Internet Memes. It was a dazzling ride into the (sometimes very obnoxious) territory that is memeology, addressing and displaying both the happy-cheery-cute side of memes as well as its darker side. The video they have on their site documents their presentation and the word is out that they will soon craft something more like a stand-alone video-essay about Internet memes. As we wait for this next step in their project, this video is an amusing watch (though the interesting stuff starts about 3 minutes in).

I have found myself, at least on a few occasions, talking to a person whose relationship to the Internets is much thinner than my own, trying to explain the nature of certain Internet memes. I find this a pretty tough task to pull off as I tend to make memes sound really infantile (and perhaps that is just what they are). To explain this world to the uninitiated, I either: 1) very quickly give up and move onto some other less obscure 2) go into semi-professorial lecture mode and give a mini-low down on memes, some of the early examples, a small theory of self-referential irony, 4chan, rickrolls, encyclopedia dramatic etc etc and then show a bunch of memes as really you can t do it justice without the audio visul component. Now, I can just point people to the Meme Factory to three youngish guys from Brooklyn who put together a **fantastic show**** a few weeks ago on, yes, Internet Memes. It was a dazzling ride into the (sometimes very obnoxious) territory that is memeology, addressing and displaying both the happy-cheery-cute side of memes as well as its darker side. The video they have on their site documents their presentation and the word is out that they will soon craft something more like a stand-alone video-essay about Internet memes. As we wait for this next step in their project, this video is an amusing watch (though the interesting stuff starts about 3 minutes in).