Diary of a CrazyFrench

gtkam 0.13.1 "It is still ex-Mas" has been released today.

Gtkam is a GTK frontend for libgphoto2.

This release brings various bug fixes. I really hope somebody would give this program more love.

We have had users complain that they couldn't use their "USB Mass Storage" camera using a libgphoto2 client, and we finally implemented support of these using the disk: driver. Philip Langdale have been having the opposite use case: using a non Mass Storage camera using a file manager.

This is how gphotofs is born. gphotofs is a FUSE file system, ie a user space filesystem using libgphoto2. The code has reached gphoto CVS.

More about this later.

libgphoto2 2.1.99 has been release today on Boxing Day. It is the first pre-release of the upcoming 2.2.

This release is for testing purpose.

Beside the numerous bug fixes and new camera support, the major feature is the support of cameras mounted as filesystems (works better if you have libhal) that I have already described, as well as better handling of the in memory caching (by Marcus).

The tarballs are available on Sourceforge as usual.

My Thinkpad Z60t has arrived. I open the sealed box, I broke the seal that say I have to agree to a license I can't read, I plugged in the AC adapter (damn, they have a new AC model, different from the previous I have used...) powered it on and inserted the Ubuntu Dapper Flight 2 CD (it is a pre-release of the upcoming Ubuntu Dapper Drake 6.04).

The install went smoothly but for an ata2 error clogging the screen (known bug in kernel fixed in a more recent image/package). I login into X, but with some glitches. Default resolution of 1024x768, a bit stretched, but 915resolution fixes it (see bug 6089 for details about the problem with the current package), and after an X11 reconfiguration, 1280x800. Thanks to mjg59 for the hints.

I'll post a more detailled installation procedure.

My new laptop is here... I still haven't opened the box.

Merry ex-Mas everybody!

Something I forgot to talk about are the encoding for these iCalendar and vCard data. Why? Just because it is not clearly specified, or not in a way adapted to that use. I don't know what where the reason behind that, but something I'm sure is that it is a little bit shortsighted, as the RFC only address the use of that format as MIME content not providing any provision for a more versatile usage.

vCard: RFC 2426, section 5 state the difference between the vCard 2.1 format and the version 3.0 that the RFC specifies. It is written:

. The VCARD CHARSET type parameter has been eliminated. Character set can only be specified on the CHARSET parameter on the Content-Type MIME header field.

Previously we could specify CHARSET parameter for each field; now it is no longer allowed and requires that the outer MIME header specifies the encoding. This is quite restricting as we not necessarily have this in a MIME enveloppe. This leads to some weird behaviour with other software. For example, MacOS X Address Book application allows exporting addresses to vCard. If everything is in ASCII, then the vCard .vcf file is stored as an ASCII file. If it contains non ASCII data, like accents in French, the file is written in 16-bits Unicode, with a leading bom marker which is not without confusing other reader.

iCalendar: Section 4.1.4 for RFC 2445 state about encoding:

There is not a property parameter to declare the character set used in a property value. The default character set for an iCalendar object is UTF-8 as defined in RFC 2279.

Again, same as vCard, the charset specification is to be set by the MIME container. But this time, a default is specified: UTF-8. This is one point where vCard and iCalendar differ and where at least iCalendar has a sane default.

Now when the data comes from the device, sometime the developer has to figure out what charset it is. Even worse. Sometime it completely depend on the language the device is set in, and there might not be any way to know that, and assume that the user have the same language settings on both side. It is a problem as these encoding problem cause data loss of a various kind. Sometime it is just not the right char (but in that case that only cause differences), sometime it cause the string to be truncated because of a charset conversion failure.

This is something to be considered, and for the sync engine, I'd myself just go by using UTF-8 all the way.

I desperatly need a new laptop.

My old PowerBook G3/400 (runing Ubuntu Linux) is dying slowly and slowly after over 5 years of good service (compiling AbiWord at 300 km/h, daily). The AC adapter connection on the motherboard is flacky and does not work well. So it is getting more and more inconvenient. I have been looking at a the available choice. My criteras are:

• I don't want a piece-of-crap. I have my PowerBook for over 5 years, so you get what I expect to have in term of lifetime
• I don't want a luggage. No huge screen or heavy duty. 3kg maximum. Ideally 2kg.
• I want battery life and decent CPU power. Looks like these days, Pentium M is the way to go.
• I want it fully supported by Linux. I don't mind hacking a bit at first for the installation, just so that it works great after. That means wifi should work with free driver (no Atheros, no Broadcom), video adapter should'nt require a proprietary driver, and suspend MUST work. That means no fancy video card.

After analyzing what was available on the market, I ended up focusing on IBM/Lenovo thinkpad laptop. Just because they have their reputation, I have been satisfied with the Thinkpad 600E that I had at a previous job and that lot of Linux hackers seems to have one too. It also appears that most if not all the recent models works great with Linux. Given the price of a small X40, I'll just pick a Z60t from the new Z Series (link remove due to retarded website). Marginally heavier (2.0 to 2.2kg), larger screen, it looks all good, and CAD$600 less than a X40.

The only thing that bothers me is that I can not buy it bare, without the Microsoft bundle. I'll have to deal with that afterwards. Some links for reference:

• Getting a Windows Refun in California Small Claims Court where the author explain how to get a refund. Informative on how to proceed. However the law will probably differ.
• The Toshiba Standoff gives other bits of information on how to negotiate.
• The AFUL (Association Francaise des Utilisateur du Libre) has a complete file on the situation in France. It appears that the DGCCRF, the authority in charge of competition regulation in France is aware and acknowledge that this is illegal bundle sale. What to do to get a refund.

In Canada, the competition bureau, and the associated regulation have something about bundling. Last time I contacted them about a prioprietary photo editing software bundled, they didn't want to do anything unless I could prove that it actually did increase the price of the hardware or that it was preventing sales of competing products. This is not a case won.

You may want to read part 1 if you haven't already. I have explained why we might want to have synchronisation. Now I'll explain how we would do that.

First we need to understand how PIM data are or can be formatted. Actually there are various formats, more or less proprietary. And there are a couple of IETF format, vCard, vCalendar and iCalendar. iCalendar is the version 2.0 of vCalendar, and has been ratified as RFC 2445 by the IETF. It is the standard for storing calendaring information. vCard has been ratified as RFC 2426 and specifies a way to store and transmit contact information.

Both iCalendar and vCard have a common organisation, that is logical given the nature of the data. We have records that contain fields, with attributes. For example, a contact would be as follow:

BEGIN:vCard
VERSION:3.0
FN:Homer Simpson
ORG:Springfield Nuclear Plant
ADR;TYPE=HOME:;;742 Evergreen Terrace
 ;Springfield;IL;;U.S.A.
TEL;TYPE=VOICE,MSG,WORK:+1-555-555-1234
EMAIL;TYPE=INTERNET:chunkylover53@aol.com
URL:http://members.aol.com/~chunkylover53/
END:vCard

The vCard is a record, and each field is one of this lines that starts with a keyword followed by a ":", at least when it comes to the vCard format. iCalendar is quite similar, but allow embedding another record. No big deal. This is the logical organisation, and if you look closer, you'll realize that this is the design choice made for the Palm .pdb format where the data is just a bunch of records.

To be continued...

I was having issues not being able to connect to the Netatalk server. It insisted on using plain text and refusing passwords of more than 8 characters. According to the UAM documentation, the plain text UAM is limited to 8 characters passwords and the only other UAM that supports using the standard UNIX password is dhx. Reading the README.Debian from the package, it tells that this UAM module is not compiled because it require OpenSSL, and OpenSSL license is not compatible with the GPL that Netatalk is licensed under. WTF?!

$ apt-get source netatalk
$ sudo apt-get build-dep netatalk
$ cd netatalk-2.0.3
$ DEB_BUILD_OPTIONS=ssl debuild
$ sudo debi

And voila I have an up to date packages with SSL support opted in for the dhx UAM. Make sure you install libcrack-dev and libssl-dev prior doing that.