This past couple of weeks saw a lot of Debian and Ubuntu work from me in (hopefully) equal measure. For Debian, I whipped up new versions of robotour, xshisen, libmemcache, and gtklp; robotour finally installs in /usr/games as it should be; xshisen acks NMUs and finally has a sane source package (well, a little bit tipsy still, but at least it’s now fixes the NMU source b0rkage;) libmemcache’s -dev now installs its headers to the right location; and gtklp bumps to a new upstream, with touch-fu replacing AM_MAINTAINER_MODE for seamless build. Thanks a lot to my wonderful sponsors Margarita Manterola, Sylvain Le Gall, and Andreas Metzler for the uploads! On the other hand, opendchub has migrated to testing, and its initscript failed (not to mention missing a manpage) I’ve fixed the latter, but I still have to figure out how to fix the former; I’ll probably have to consult the reference and add an unprivileged opendchub system user and configure the daemon to use that, or fix the source and allow flexible redefinition of opendchub’s working/configuration directories (currently hardcoded to $HOME/.opendchub). Either way, I have to touch the source and make patches; and I would appreciate it very much if my dearest readers can help out On the lighter (or heavier, depending on your POV) side, I noticed that Steve McIntyre posted an RFH for cvs, and I’ve decided to help out a bit. Seeing the source, I was pleasantly surprised as the age (and design) of this package, and it would be a blast for me to study this (and fix bugs, prepare patches, and release new versions while at it. It would also prepare me better for NM as well. As for my Ubuntu work, I’ve upgraded my Breezy Badger desktop to Dapper Drake last Monday (just in time for Flight 4,) and I’m quite amazed at the new features of this release. Like many folks I just loved xchat-gnome’s notification feature (especially when you’re moving in between workspaces very often) and was very much pleased with the speed of Gnome 2.13.91 (so much so that I’ve departed from my normal Ion3 desktop without regretting it. But of course, since Dapper Drake is the latest development branch, there were some snags that I got to encounter. One particular bug was with masqmail, because the 0.2.21-1ubuntu1 version created a /var/run/masqmail directory, but since /var/run is mounted as a tmpfs in Dapper, masqmail will complain the next time it restarts. Another (probably cosmetic) bug(?) was with tuxpaint, since it placed a couple of launchers in the Gnome Applications menu, one on Education and the other on Graphics. I’ve yet to see if tuxpaint’s is a genuine bug or just a design decision, but I’ve fixed masqmail’s, and 0.2.21-1ubuntu2 should be on Dapper now, thanks to Daniel Holbach. So far I’m loving the new Ubuntu release, and with FeatureFreeze finally here that means I’ll have to drag my desktop box again to the local internet cafe to do yet another aptitude dist-upgrade. Gaah, I need a laptop!

Scroll down a bit here and there are some photos of GTK+ running on a prototype Palm device. Very cool, hopefully they get the development kits out this year. It should also be known that Richard Purdie is currently my hero. I can't say why at the moment, you'll have to come to FOSDEM to find out why! NP: Modus Operandi, Photek

During the last two months, the Debian Catalan localisation team has seen two of their major milestones completed, after some tough work. The group managed to release Sarge with a completely translated installer, but failed to provide a translation of the Install Manual, which was a regression for us, as it had been available in Woody. We didn't give up, and thanks to the stubborness of Miguel Gea and braindmg we slowly started translating the Sarge manual months after the release, so it could at least appear in the website. But progress was too slow, so we planned an online meeting for the beginnings of the year to try to complete the translation doing a whole lot of translations during a weekend. Soon after we learned that joeyh, fjp and the d-i team wanted to terminate Sarge d-i manual support in svn RSN, as they would start to make changes to the docs to reflect etch changes, but fortunately Frans agreed to give us a slightly extended deadline, if we agreed to finish the job by January 14th:

20:37 < CIA-7> debian-installer: fjp d-i * r33721
               /sarge/installer/doc/manual/ca/: Add Catalan translation as
               translators would like to finish it for Sarge and have promised
               to do so 14 Januari 2006 at the latest

I really didn't think we would be able to make 100% in just 10 days, but the team, assisted by a large number of minionsnew contributors that volunteered on #debian-catalan, managed to do it I believe a few days before the deadline. Guillem announced it on our list. Releasing etch with an up to date Catalan manual will be a lot easier, if we try to maintain it up to date as etch development carries on. The second milestone was yesterday's completion of the Catalan translation for all five levels of the etch debian-installer, after a year of no translation activity on that front, and months of braindmg bugging me to do my chunk of work. Although it's now showing a shiny 100%, there's a lot of review work to do, and polishing it should be our focus for the next release. I seem to have recovered some of my interest in translations. That's good, because GNOME 2.14 is around the corner, and it wouldn't be fair for Josep if he ends up doing all the job. :) Also, I've been quietly working with a group of people at Softcatal in a project that will probably have lots of press in our community. It's not public yet though, but I hope that it'll be announced in the next few weeks.

Thursday, February 9th
My digital camera starts acting up, having strange behavior with the buttons.
Friday, Feb. 10th
I use HP’s web-based e-mail support to appeal for help with the borkenness.
I receive a response back in less than an hour giving a suggestion as to what to try.
I try this and it doesn’t work, so I respond with more information.
I am quickly informed that it may be a hardware problem and am offered a free replacement under warranty.
Sunday, February 12th
I receive a second reply because I hadn’t yet responded to the last one (busy that weekend).
Monday, February 13th
I respond with information at 4:08 PM and am called 20 minutes later for credit card information (in case I don’t ship the broken camera back).
Wednesday, February 15th
HP ships the replacement from Texas.
Monday, February 20th
The replacement arrives. Now all I need to do is drop the broken camera off at the UPS pick-up station at Staples and be done with that. Even has a pre-paid label. <3 HP.

As I told before, I’ve been working for a few days on a way to display japanese characters on a web page when you don’t have japanese fonts locally. That involved taking japanese characters from a font file, and turning it into a png image. So I just wrote a small and simple program using libpng and freetype. Which works quite well. But that’s not the point. During this “development”, I lost 2 or 3 days trying to understand what was wrong with my code that made it work properly from a shell command and fail halfway when wrapped in a php script. I still don’t know what’s wrong with php, but it works well with a perl cgi wrapper, and it still fails if I raise the php memory limit. Interestingly, other libpng tools (such as pngtopnm) fail in the same way. It wouldn’t surprise me if it was libpng’s fault. The first thing i did to understand why it’d fail, was to run the program under valgrind. And what I saw was not encouraging. A lot of “Conditional jump or move depends on uninitialised value(s)”. I tried different combinations of code, using png_write_image or png_write_row, with large or small buffers… It turns out libpng can’t write a png file with a width smaller than 148 pixels without those “Conditional jump or move depends on uninitialised value(s)”, which happen, as the stack trace shows, in the zlib, called by png_write_row, but i doubt it to be a zlib issue. You would think it would be a buffer size issue, but if you use a larger buffer for each line you call png_write_row for, you still get the errors. If anyone has a clue, please leave a comment. Update: Thanks Mark for your comment, though I don’t get how it can be safe to have such accesses to uninitialized memory. Deuce, the php issue can’t be a timeout issue, the program runs in fractions of a second.

I've bought a USB keyboard today. The one with 88 keys.It's called M-audio keystation 88es, full-sized lightly-weighted keys.Auto-detected with ALSA usb-audio driver, and *it just worked*.Nice.

You decide! Seen floating past my eyes in my freshmeat "new releases" feed this morning is "PhpMyPixelPage", "a pre-packaged PHP Web site for creating a [...] page which mainly contains a large array of small squares where each square can be sold as advertising space." First thing here is: the original "Pixel Page" was a cute gimmick done by a clever British University student, called "The Million Dollar Home Page". He did it to finance his studies (if he's not studying marketing, he should be), which worked really well -- he got his US$1 million, and now has plenty to spend on warm beer and grotty kebabs while getting his degree. The concept has since been copied a billion times, to (presumably) nowhere near the same effect. So a pre-built site generator isn't likely to be raking in the dough for anyone -- there's just too many copycats out there. The real cause for the title of this post, though, is the licence. According to the Freshmeat item, the licence is "Free for non-commercial use". Can anyone think of a non-commercial case of selling advertising? No, neither can I. The mind boggles.

My Top Five Reasons as to why I don't update the information for Sound Juicer in GnomeFiles often:

1. No programmatic way of uploading new versions. Freshmeat has a XML-RPC interface and sample implementation, freshmeat-submit. This means I could integrate posting new versions into my make release script, which also uploads source tarballs to ftp.gnome.org and puts the latest DOAP file on burtonini.com. Ideally GnomeFiles will let me specify a DOAP URL and the server will fetch it regularly, updating the information when it changes.
2. When adding a new version I need to fill in the download location field from scratch. For every Sound Juicer release this is going to look like http://ftp.gnome.org/pub/gnome/source/sound-juicer/2.[something]/sound-juicer-2.[something].tar.gz. It's a good assumption that if one version was at some URL, the next version will be at a very similar URL, so why not pre-fill that field with the previous version's URL? Freshmeat does this, and it turns typing in a long URL into changing a single number.
3. I need to fill in the file size of the file at the URL. Why can't the server do that? If the download is over HTTP it could do a HEAD request and extract the Content-Length header.
4. No support for branches. There are two branches of Sound Juicer development at any moment: stable and development. I have to pick one of these to publish, so am either publishing only the stable release, or the development releases. People who want to know about the other releases can't find this information out.
5. This one is petty, but it bugged me. Description of the file to download eg. "Binary" or "gnomefiles.org Server". One of those is a description of the file, the other is a description of the site.

NP: Black Diamond, Angie Stone

No news for almost 3 months.. well, I am back now. Some things that happened during this time:

• new root server I bought a server from Hetzner. It's called weedy.perldition.org and now hosts my personal page as well as some other things.
• Net::SSLeay maintaince I already maintained this Perl module for Debian a while, got some bug reports, forwarded them to the upstream author and nothing happened. Also the last release happened years ago in 2003. Therefor I asked the author if he may needs help or if he wants to pass the maintainership to someone else. He did so and I'm now maintaining Net::SSLeay together with Mike McCauley. The project is now hosted on http://alioth.debian.org/projects/net-ssleay. Please use our Mailing List if you have any questions.
• Geek Tour I'm planing to make a geek tour in middle europe in the next weeks. I'll visit FOSDEM, GPW, CLT and an Amsterdam.pm meeting. Wanna join? Mail me!
• Some events During the last months I visited some exciting events. I took some pictures and put them here.
• Bug squashing I worked a bit on my Debian packages and managed to fix almost all important bugs. The only missing ine is #346474, which is at least forwarded to upstream.
• I'm on the planet I'm now part of Planet Debian.

I'm sure I've missed important things, but that's it for the moment. I hope I'll manage to do more frequent updates in the future.

Our Chair of Software Engineering at the ETH Zurich is addicted to the Eiffel programming language. Thus, a PhD student is working on an Eiffel Multimedia Framework, named EiffelMedia, and I'm doing the Debian packaging. After working the second year with Eiffel stuff now, I can say that packaging Eiffel programs (not the language itself) is a major PITA, with respect to the following two aspects: Eiffel is different

• Build tool is an Ant clone written in Eiffel, called geant (part of Gobo Eiffel).
  
  
• Paths are not hardcoded into the binaries, they are set by environment variables. You guessed it right - it's not a bug, it's a feature.
  
  
• There is no Eiffel compiler, just Eiffel-to-C wrappers which then issue the compilation to objectcode by a C compiler. Generating executables from Eiffel sources takes longer than from any other language.

Eiffel is non-free

There are not one... not two... but three incompatible Eiffel compilers arround. Oh yeah...

• EiffelStudio, developed by Betrand Meyers company Eiffel Software (formerly known as Interactive Software Engineering) reflects the reference implementation of the Eiffel language. Last summer, Eiffel was accepted as ECMA standard 367. Version 5.6 of EiffelStudio released back in fall 2005 does implement this standard.
  
  EiffelStudio is proprietary software (speaking of EiffelStudio means actually EiffelStudio Free Edition). Last year, I bitched Eiffel Softwares employees for about 3 month continuously to change the EULA for allowing non-modified redistribution. Thanks to be not ignored by Larry Miller from Eiffel Software, in the beginning of 2005 the EULA was changed and I could provide packages publicly. Theoretically, I could have moved them over to Debian non-free, but it's quite a large piece of software (190MB, source and binary packages) and the important parts (compiler and IDE) are still provided binary-only (so the archive would have to carry three arch specific version, makes 570MB in total per revision), thus no upload was considered. Additionally, EiffelStudio is available on Linux only for the i386, powerpc and amd64 architectures. All other platforms where Linux runs on are not supported.
  
  Another annoying problem with EiffelStudio is its nasty disclaimer flooding allover the buildlogs. It's built into every binary and displayed as the first 19 lines of every output of those:
  

  This program has been produced with a demo or non-commercial version
  of ISE EiffelStudio, the full lifecycle object-oriented development
  environment from Eiffel Software.
  This version is reserved for non-production use of Eiffel. Any other
  use requires purchase of a license.
  Eiffel Software offers commercial and academic licenses and
  support/maintenance contracts covering diverse needs.
  For more information please contact
  Eiffel Software at the address below or consult the Eiffel products page
  at http://www.eiffel.com/products/.
          Eiffel Software
          356 Storke Road
          Goleta CA 93117 USA 
          Telephone 805-685-1006, Fax 805-685-6869
          E-mail sales@eiffel.com
          http://www.eiffel.com
  

  This could have been "designed" a bit more discreet. However, as I do have to use wrapper scripts anyways for all binaries in the packages of any Eiffel program, I stripped that out by the occasion.
  
  
• Visual Eiffel developed by Object Tools was a proprietary Eiffel IDE and compiler suite. In November 2004, the compiler and the standard library were made free and are licensed under GPL.
  
  Unfortunately it was never fully compatible to EiffelStudio, actually years behind. It's not suprising that the project seemed never to be alive. Because it's still stuck with an old Eiffel language specification, it's even less useful today than it ever was.
  
  
• SmartEiffel (formerly know as SmallEiffel), developed by the LORIA Laboratory is a GPL licensed Eiffel compiler.
  
  But SmartEiffel does not and will not implement the recently published Eiffel ECMA standardization (roumors has it that they fork the Eiffel language in some essential parts caused by some technical and/or personal missunderstandings between Bertrand Meyer and the leader of the development team of SmartEiffel, they know each other from earlier).

Except from some fundamental programs like Gobo Eiffel or the Eiffel Wrapper Generator (they support both all three compilers), nearly all programs are written according to the current Eiffel specifcation. So there is no real alternative to the proprietary EiffelStudio. Beeing binary-only is a major drawback too: EiffelStudio on Linux/powerpc is dynamically compiled against glibc-2.3.5, but Sarge has glibc-2.3.4. So one needs a backport of glibc, which taints the system in an unneccessary and stupid way. Please: Eiffel Software, if you are reading this, open the sources of EiffelStudio now and turn it into free software, for the greater good of us all. Make additional ports to other architectures possible and allow us, the packagers and upstreams of Eiffel programs, to drop the cumbersome support for other ancient Eiffel compilers. Let's focus us to one, single implementation and improve it.

Joel Spolsky: “Listen, I know that everybody is saying that the cool thing to do these days is Ship Early and Often, but when you ship half-baked ajax calendars that don’t do much and then get Scoble to go nuts about how great they are, well, you’re going to have a lot of people like me checking it out and realizing that, for example, no thought whatsoever has gone into printing, which is fine, it’s a 1.0 release, but you know what? I’m not going to look at 30 Boxes again — I’ve spent enough time evaluating it. G’bye. I’ve talked about this before — it’s the Marimba phenomenon — when you get premature publicity, lots of people check out your thing, and it’s not done yet, so now most of the people that tried your thing think it’s lame, and now you have two problems: your thing is lame and everybody knows it.” “Release early, release often” is a strategy that works because it allows for incremental improvement—you don’t have these “big bang” releases every few years where you try to anticipate what your users will want, because your users are telling you what they want every step of the way while the thing is coming together. That said, Joel makes some very good points, and companies following the “release early, release often” formula would do well to consider them. In short, for “release early, release often” not to backfire, its proponents need to do a better job differentiating between the users that want to actively participate in the development of a new product and the users that are simply looking to solve a problem, because that latter group is ultimately going to be disappointed if the thing isn’t fully baked.

Last week, some friends and I played a very exciting and long (6 hours) game of Risk. At the end, I thought: Too bad we can’t rewind the game and play it fast forward, just see how the tides of colors are waging.Well, on Sunday, I though, why not, and started writing “RiskRecorder”. It is my first larger project with python and gtk+, and I am quite content with both of them. The map is stolen from JRisk, and with that the idea of a gif file that maps pixels to countries. The RiskRecorder is meant to be used during a game of regular risk, to - well - record the moves. As a side benefit, you don’t have to calcuate the number of units you get anymore, as the RiskRecorder can tell you that. You can then save the whole game for later review.It should be in a usable state by now, but I plan to add more features sometime, like better animations and graphs showing development of the game.To try it yourself, you need the program itself (one file so far), then get at least the board.map, board_map.gif and board_pic.jpg from the jrisk CVS repository (you can open any other JRisk map in RiskRecorder, too). You might need to download the python bindings for gtk and cairo, too. On debian, I assume that apt-get install python-gtk2 python-cairo will get you what you need.As always, comments, bugreports and patches are welcome. To follow development, have a look at my svn repository.

Gotta love Debian sometimes. ;) My beloved mutt seems a little broken in unstable currently. I’m in the market for a new AM. 3rd time lucky? Ok, so I am packaging Aaron’s web.py library and so I check the license with debian-legal. “Vorlon”, the omnipresent and omniscient got back to me pretty quickly, saying no. Goddam! ;) I’m no legal expert and my brain hurts thinking about these distribution clauses, GPLv3 issues and controversies. I hope debian-legal reaches some agreement. At about 6pm I noticed the Ubuntu crowd were in Seoul. I emailed hastily asking about a meetup or something. Probably too late. Damn. I’m feeling quite alone in my Linux usage here in Korea. I see Mark has been in Japan. I have fond memories of Japan and the debian guys out there. Yeah, if any Korean devs are reading this, get in touch. Part asked me to get in contact with some mail administrators in order to curtail some of the massive amounts of spam coming out of Korea.

\documentclass article
\usepackage pstricks
\begin document
\pagestyle empty
\begin pspicture (-5,-5)(5,5)
\newrgbcolor tuomoblue .6 .6 .6667
\pscircle[fillstyle=solid,fillcolor=tuomoblue](0,0) .7
\rput(0,0) \Huge$i^+_3$
\end pspicture
\end document
Details in the ion wiki. I like this logo.

The nomination period for the Debian Project Leader is on again. This means that the Finnish winter is at its worst, and indeed, as I write this, it is -22 degrees Celsius outside. The sun went down about six hours ago; I woke up quite late, so I only saw half the sunset. Back in November, while vacationing, I spent some time thinking about what the role of the DPL is, and now seems a good time to say it. The actual work of developing and maintaining Debian is done by package maintainers, translators, a handful of infrastructure teams or other special purpose teams, bug reporters, and others. It is not the job of the DPL (in their role as DPL) to take charge of the actual development: the DPL is not expected to administer debian.org machines, to fix RC bugs themselves, or to make decisions about release management. Instead, the DPL's job is to help everyone else do those things. If some part of project isn't working well due to resource shortage, or personality conflicts, or other issues, it is ultimately the DPL who needs to facilitate, mediate, or otherwise deal with it. This is not uniquely the DPL's job: any Debian member could step into a situation and help, but the project does need someone whose job it is to do that if no-one else will or succeeds. Another important job of the leader (again not uniquely) is to provide inspiration. Our leaders in the past few years have provided fairly little of that. I would like us to have a DPL that inspires the project into setting and achieving goals that make us happy and make Debian the best operating system ever. The important thing is to inspire, not to force, cajole, or otherwise unilaterally decide. Not quite sure now how that should happen. Perhaps the Finnish military saying that "leading is best done at the front" is applicable: an inspiring DPL is one who by his own work, and his own behavior, shows by example what a good, productive member of the Debian development community is like. A third important job of the leader is to be the project's public face to the rest of humanity. Again, not uniquely, we have other members who are often prominently in the public eye, such as release managers or security people, but the DPL is the main such public face. And finally, the fourth important job of the leader is to do the tasks assigned to him in the Debian Constitution. These are not daily tasks, but they're important, and these, at least, are uniquely the DPL's domain.

I'm a fan of the unix tools philosophy, but I sometimes wonder if there's much room for new tools to be added to that toolbox. New programs that fully partake of the philosophy (like rename, netcat, par, bloxsom, grepmail, and xwit) are fairly few and far between compared to all the new programs that don't. I've always wanted to come up with my own general-purpose new unix tool. vidir doesn't quite qualify as a real unix tool, since it doesn't (normally) operate on stdio, but it's as close as I've gotten, and it does seem to fill in a nice hole in the toolbox. The idea is very simple, it just displays the files that are in a directory as lines in a text editor, then you can make any changes you like, and when you quit the editor it renames and/or deletes files to match your changes. No need to worry about quoting issues and the full ad-hoc editing power of a good text editor make cleaning up messy directories fun. Like any good utility, there is plenty of obvious room for improvement, it would be nice if it had a --recursive switch to edit whole directory trees at a time. And it needs to have some support added for swapping pairs of filenames. I challange others to try to make general purpose unix tools..

My development machine passed an overnight memtest86+ and seems to be running stable for the time being, so I was able to produce the updated dgap packages. Packages version 1.3.3-1, based on the 1.3-3 RPMs published by Digi, are available at the usual location. The 1.2 packages are still available in the pool, under the old directory; APT should be able to install them too, in case you need to downgrade to the previous version. The packages are built for Sarge and should work flawlessly on Sid and Etch too. For Woody, you’ll need to rebuild them by yourself.
APT source: deb http://debian.technologeek.org/ sarge non-free To upgrade, apt-get update, apt-get upgrade, build and install the modules with module-assistant, then:
/etc/init.d/dgap stop
/etc/init.d/dgap start Note that this version seems to be a pre-release. The changes compared to the previous version are pretty light, mainly bug fixes and changes to accomodate the newest kernels. Also, the sysfs interface is disabled for kernels < 2.6.15, so you may want to hold back on the upgrade if you depend on the sysfs interface. Bug reports and comments welcome, as usual.

I'd been looking for a fairly secure way to store an increasing number of passwords. There's a large number of methods one can use. While the most secure might be an encrypted file on a system that has no network access, I do want to have access to the information over a network while I'm traveling. Remote access makes using a graphical client a poor choice. After a moderate search and trying a number of candidates, I settled on Console Password Manger (CPM) written by Harry Brueckner. It's close to an ideal match to my needs: it's console-based, had an emphasis on security and uses my existing GPG key for encryption. The program is maintained and I've had no issues while using the last three beta versions of the program. Thanks, Harry for the very good tool. Recommended.

I got a mail this week asking for an update of the Digi AccelePort drivers packages for Debian, which I maintain out of Debian due to license restrictions on the firmware files (if somebody from Digi reads this post, please get in touch with me so we can fix this — you only need to explicitly grant permission for redistribution). It seems there’s a new (beta?) version out which builds on kernels >= 2.6.13. If you need to use the drivers on such a kernel, unpack dgap-source.tar.gz, do the changes to the code, and repack it. Then use module-assistant to build the modules as usual and it’ll work just fine. I’d happily provide the patch, but my development machine holding my spare AccelePort Xem died yesterday evening, and I can’t get it to work reliably for more than about 30 minutes. I’ll package the newest version of the drivers as soon as I’ll have a replacement for this machine, which should happen RSN. The packages can be found on http://debian.technologeek.org PS: planet readers, sorry for the flood, my last post was my first post since I upgraded to WP 2.0. It seems to be unavoidable, crappy blogging software.