HCoder.org

It’s been a couple of years now since I have been a digiKam user. I have been mostly happy with it (actually I don’t even use a lot of its features as my needs are not particularly advanced), but from time to time the Flickr would fail for no reason. Some time ago I needed to upload a lot of pictures and it started failing again, so I looked for some alternatives.

Apart from other apps I knew already and didn’t particularly like, I found dfo (Desktop Flickr Organizer), a GNOME application. It was nice, and it was easy enough to upload pictures to Flickr with it, but it felt weird. What I would like to have is some application to manage my gallery, with some option to upload certain pictures to Flickr. However, this applications is more like a local Flickr mirror with synchronisation options. I don’t want all my pictures in Flickr, even marked as private. I just don’t care, and I don’t want to wait for all synchronisation between the app and Flickr. Moreover, I feel kind of tied to Flickr using that, and I’d rather work in a more “agnostic” environment. So it was cool using it to upload the pictures I had to upload, but I wasn’t really going to keep using it.

At the same time, one friend suggested using Picasa to upload some pictures, so I gave it a try. I had tried it briefly in the past, and I remember that some things were nice, but for some reason it was never my gallery manager of choice. So, trying it again, and even using the synchronisation options for the Picasa web albums, somehow I got the same feeling again: it’s nice, but there’s something undefined that makes me not use it. I have to admit that the interface is really fancy and easy to use, and it works decently well, but I don’t completely like the way the synchronisation works, not to mention that I don’t want to be stuck with only Picasa web albums. Also, I’m not happy with it being proprietary, not available in the Debian repositories, and with that special, anti-integrated interface. Some things work much better than in digiKam (I’m especially thinking fullscreen/slideshow, which sucks pretty badly in it), but I still prefer digiKam overall.

As I wasn’t too happy with the alternatives, I decided to have a look at the problem with digiKam. It turns out that digiKam just uses the so-called Kipi-plugins for picture exporting and other things, and that there was a new version of it that fixed a couple of issues… one of them being a problem with Flickr upload. The package is not available on Debian unstable because we’re currently in freeze (unfortunately, that means that Lenny will ship without a functional Flickr-uploading Kipi plugin). However, I saw that the new package was actually uploaded to experimental, so I decided to give it a try. Not only it works like a charm, but the new version 1.6 reworks the Flickr export plugin completely, and now it’s much nicer. So I’m happy now, back to digiKam with a working Flickr export \o/. To install it yourself, make sure that you have this line in your /etc/apt/sources.list:

deb http://ftp.de.debian.org/debian/ experimental main non-free contrib

Then, update your available package list and install kipi-plugins from experimental, like this:

sudo aptitude update && sudo aptitude -t experimental install kipi-plugins

That should do it.

I admit it. I’m a terrible developer. I write code, sometimes even write tests.

But. I. don’t. test. my. programs.

By hand, that is. And sometimes (usually) the coverage is not enough, and I end up making embarrassing mistakes. It usually happens outside of work, although at work I also have my share. The last one was with the Debian package dhelp, where trying to fix an issue before Lenny is released, I ended up making it even worse. The story goes like this:

There was some problem with the indexing of documents on installation/upgrade (namely, it would take ages for most people upgrading to Lenny, and they would think the upgrade process had hung). So, I go and change the indexing code so it ignores documents on installation/upgrade. Also, as suggested by someone, I created some small example utility to reindex documentation for certain packages. I test installation, upgrades, upgrade of the dhelp package itself, the utility, searching for keywords before and after all that… and everything worked.

Only that I made a typo. A typo that would make all indexing to be ignored (except for the example utility, because it was a bit lower level). And I didn’t realise, because it “only” broke some cronjob, a completely different part of the package. And it happens that the cronjob reindexed everything weekly, to make sure that you had reasonably up-to-date search indices. And it also happens that, given that the documentation reindexing was being ignored on package installation/upgrade, the weekly total reindex process was the only thing that could provide the user with indexed documentation. But I screwed up. Oh well.

Someone filed a bug yesterday, and I fixed more or less right away. But this time I spent a couple of hours thinking of test paths and ways to make it fail, and actually doing all that testing. Thanks to that, I found some potential bug in the example utility, that I fixed just in case. So hopefully everything is fine now, if I can convince the Release Masters to allow the new, less broken update to dhelp to be accepted for Lenny.

I think I need personal QA. Anyone up to the task?

Today I was playing with GnuPG, trying to add a couple of public keys to an “external” keyring (some random file, not my own keyring). Why? you ask. Well, I was preparing some Debian package containing GPG keys for APT repository signing (like debian-archive-keyring and such).

The point is, I was really confused for quite a bit because, after reading the gpg manpage, I was trying things like:

gpg --no-default-keyring --keyring keys.gpg --import ...     # Wrong!

But that wouldn’t add anything to the keys.gpg, which I swear I had in the current directory. After a lot of wondering, I realised that gpg interprets paths for keyrings as relative to… ~/.gnupg, not the current directory. I guess it’s because of security reasons, but I find it really confusing.

The lesson learned, always use --keyring ./keys.gpg or, better, never use keys.gpg as filename for external keyrings, but something more explicit and “non-standard” like my-archive-keyring.gpg or whatever.

In my recent trip to Copenhagen, I recorded a small video of the subway (it’s really cool, because it’s completely automatic, it doesn’t have drivers or anything). I wanted to edit the video to remove people that were reflected on the window, so I wondered if I could do that on Linux. I imagined it wouldn’t be trivial, but it was more frustrating than I thought. Maybe I’m too old for this.

The first thing I tried was looking in APT’s cache for “video editing”. The most promising was kino. I had tried that some time ago a couple of times, and I never made it to work, but I figured I would try again. Unfortunately, same result: I just can’t figure out how to import my videos. Maybe I’m just hitting the wrong button or whatever, but it’s really frustrating.

Second thing was having a look in the internet. I found the (dead and being rewritten?) Cinelerra, as always, and I didn’t feel like installing the old one from source, only to lose my time and not get it to work, so I just ignored it. Maybe they had it in debian-multimedia and wouldn’t have been a tough install after all. Anyway.

Next thing, I found some program called openmovieeditor. This one apparently worked, but I couldn’t figure out how to crop the image (or almost any other thing for that matter).

Next, some neat program written in Python, called pitivi. When I tried to run it though, it just said Error: Icon 'misc' not present in theme on the console and died. I later figured out that I had to install gnome-icon-theme for it to work (yeah, Debian maintainer’s fault). It’s funny, because on the webpage it says that it has some “advanced view” that you can access via the “View” menu… but I couldn’t find it. My menu only had one entry: “Fullscreen”. Great.

Oh, wait, there’s a gimp-gap. I could just import my animation in Gimp, crop the frames, and convert again to video. Easier said than done. I needed some programs that I didn’t have, and I wasn’t sure if they were so easy/quick/clean to install (sure, I could have exported to GIF animation and probably convert to video, I just didn’t want to lose so much color quality in the GIF step). Forget for now. At least I had the images, so if I could just turn them into a movie…

So, I started wondering if, given that I had decided to just crop, and especially now that I had a lot of images that were the frames, maybe I could just use some command line tool or something. So I found this tiny little program, images2mpg. Long story short, after installing some dependencies from source (that gave compilation errors, but luckily I could compile only the binaries I really needed) that program was completely retarded and didn’t even do what I wanted (it wanted at least one second between images, but I didn’t want a slideshow, just a normal movie from the frames). It looks some simple and it’s so buggy. Gah.

So I started wondering if I could just crop with mplayer... Hmmm… after a couple of problems (like documented switches that were not there and other crap), I ended up with this command line:

mencoder -vf crop=320:200:0:40 MVI_2160.AVI \
         -ovc lavc -nosound -o metro-crop.avi

That was reasonably quick and easy but it was so frustrating after all that lost time.

In any case, I ended up with the video I wanted, so I went to YouTube to upload it. When uploading, I realised that there was some option I had never seen: annotations.

YouTube annotations are really cool. They are like the notes on Flickr, but on a video :-D Actually I kind of wanted to make a note like that on this video, to show the automatic doors on the Metro station, so I was really happy to see that I could actually do it. And the interface is really easy to use and very clear. I really like it! You can see the result here:

EDIT: WTF? The annotations don’t appear on the embedded videos? You’ll have to go to the video page to see them, then…

I just read in Aaron Seigo’s blog a very nice message from a user that proves that free software is making a difference in many areas, even in some that we don’t usually think about. Some quote:

I cant tell you how much I appreciate the work you all have done. Its a work of art. If I could thank each and every one of you I would.

You have given her the world to learn and explore.

So if you get frustrated or tired in your work for Open Source/Free Software, just remember that somewhere in Missouri there is a 14 year-old girl named Hope, an A-student who runs on the track team, who is now your biggest fan and one of the newest users of Linux/Ubuntu.

Although I haven’t really participated in KDE or Ubuntu (not directly anyway), I too feel proud of what we, as a community, have created. Also, like that person, I feel very thankful for everything I have learned and got from the free software community.

Cheers guys, you all rock!

Some good news in the dhelp front: after talking to some people and a couple of messages in debian-i18n, dhelp has (hopefully) full support for UTF-8, and two more translations, the first two apart from the Spanish one: Russian and German. It’s really cool seeing some program you have written producing output in cyrillic ;-)

I haven’t uploaded yet, because I found two new strings that weren’t in dhelp.pot, but I’ll upload soon, when I receive the updates for the translation. The UTF-8 update is related to some improvements in doc-base, so things are looking good in the documentation tools side of Debian, yay! :-)

Today I have been one year working in Oslo! Yay! So far the experience has been quite good, so I’m staying here for some more time still.

I’ve also slowly becoming kind of active again in Debian (especially helping dhelp), although I admit not being very active in any other software project (Haberdasher feels kind of abandoned, because I don’t have any urge for new features). Hopefully that will change…

As I said earlier, now the fun stuff begins :-) I have been working with dhelp these days, and there are a couple of things I have changed already:

• I have dropped support for the dhelp-specific .dhelp files. Now I just use the doc-base information directly (until now, doc-base had to convert its own format to dhelp, which was a bad things for several reasons, one of them losing important information in the process).
• I have changed the indexing code so it now indexes the actual documentation content, instead of the documentation directory generated by dhelp.
• I have rewritten most of the HTML used in the searches and in the documentation directory so it’s nicer and easier to modify (e.g. no more <font> or similar obsolete tags).

While working on the indexing changes, I have been playing with swish+++, an indexing engine. Seems really useful, although some options are not that obvious, and I haven’t been able to use extract++ to extract the text according to the file format (e.g. skipping HTML tags in HTML). I’ll keep trying…

Hopefully, the package will be ready for release in a week or so…

I finally uploaded dhelp to unstable, and everything went almost surprinsingly good. The only bugs reported so far are #448211 and #447789. The first one was a silly mistake made by me, in some translation files that aren’t even being used now (that will change in the near future). The second was a bug exposed by dhelp, but actually in another package (libcommandline-ruby, which is funnily enough also maintained by me, and it’s already patched and pending upload).

So, now that the package is uploaded and we’re using a sane implementation for dhelp_parse, I can start doing fun stuff. Right now I’m mostly fixing more bugs, but I’m also implementing new features and talking to the doc-base maintainer, to improve the integration between both.

Dhelp’s new release is coming along nicely. In the last days I have fixed a couple of bugs in dhelp_parse’s rewrite, and I think it’s now ready for upload. The new package closes 28 bugs, which is more than half the current open bugs for the package.

I have warned the current maintainer and the debian-doc mailing list, so I hope to upload the new version in a couple of days…