Michal Čihař - Blog Archives for Gammu

I bear in my mind idea for automatically configuring Gammu for some time. It should not be that hard using udev, Bluez and other tools which we already have available on average Linux system.

Today afternoon I've finally found some time to play with that and it's almost done. Well it's not fully automatic right now, it will just generate configuration file with possible choices, but at least some help. For now only udev and Bluez is supported, but I will add support for libusb soon as well.

The new tool is called gammu-detect and looks at devices available in the system and outputs something, what can be used as configuration file (you can find example in the documentation).

Once it will make reasonable guesses what user actually wants, it might get integrated into libGammu so that other applications like Wammu can benefit from it as well.

For some time, I observed that Gammu test dashboard does not get updates from my Debian box. Looking the CTest logs, the problem was in using IPv6 even when the box does not have it enabled:

Failed to connect to 2001:1528:136:dead:beef::1003: Network is unreachable

Due to lack of time I ignored it, but it looks all what was needed is to update curl. The bug was caused by using c-ares resolver, which for some reason favors AAAA records even when the system has no IPv6.

I've just released new version of Gammu, which comes with some things, which are worth mentioning.

First thing is m-obex support (which I've already announced). Since last announcement, there were some improvements, but I'm affraid it still does not work, because it was not completely tested. So the very same request applies - testers welcome and we need feedback.

The second big change is universal SQL backend for Gammu SMSD, which consolidates code of former MySQL, PostgreSQL and DBI backends. It also adds option to configure SQL queries it will use. This was tested using usual testsuite, so it is working, but there still might be some glitches, which will need polishing before we can declare it stable.

During the weekend, I've found some time to improve documentation for Gammu. One of user accessible things which did lack documentation are native file formats used by Gammu.

There is not that much of them as Gammu supports standard formats for most data (like vCard, vCalendar, iCalendar), but there are things where standard simply does not exists and we need to store that data as well. This is the case for backups (both data and SMS), where SMS backup format is used as well for files backend in Gammu SMSD.

So I went through the SMS backup internals and wrote the documentation. While reading the code I of course discovered quite obvious bug, which was for some reason undiscovered for very long time.

I've found some time to implement m-obex protocol based on documentation provided by samsyncro project. However I don't have any phone to test it, so any testers are welcome :-).

The testing should be quite easy - just get current Git version of Gammu (either using git or use snapshots) and try to use commands which manipulate with contacts and calendar:

gammu getallmemory ME
gammu getallcalendar
gammu getmemory ME 1
gammu getcalendar 1
gammu addnew test.vcf
gammu addnew test.vcs

In case you have not yet used Gammu with your phone, the configuration for USB cable should look like:

[gammu]
device = /dev/ttyACM0
connection = at

And for Bluetooth:

[gammu]
device = address of the phone
connection = blueobex
model = mobex

Of course there is no guarantee that any of the commands will work, because all I could verify is that code compiles and looks correct. It might as well do something bad to your phone, so backup is recommended.

I've just finished another step for new Gammu manual - it includes also documentation for gammu utility. It includes all content from the man page, reformatted and improved in some sections. So now the documentation does cover all important parts and can contain correct cross references.

The only problematic thing was to handle non dash starting commands in Sphinx. Unfortunately it does not seem to like this idea, so I had to invent some ugly hacks, which workaround that (just changing the regexps which sphinx.domains.std uses).

The man page will be from now on generated from this source as well.

I had this topic in mind for quite a long time, but it got more recently more attention because of discussions on gammu-users mailing list. Gammu should use some library for do basic stuff like strings or date manipulations, logging and so on.

The reason is that having own implementation of all that is not really useful and just source of another amount of bugs. Currently mi intention is to use GLib, simply because I don't know any C alternative (though there are probably lot of C++ cross platform libraries).

Of course the biggest question is how to make the change, because it will be obviously intrusive and making such big changes will probably lead to several months of work without really making another release. Even if it will be done on separate branch (what would be most likely the case), developers will spend most of time on this issue and not much time will be spent on bug fixes (and backporting them).

Some weeks ago, I've started to change documentation structure of Gammu to move from separate documents here and there into one comprehensive documentation which would cover it all. As a tool to do this I've chosen Sphinx, simply because I felt most convenient with the format and outputs it provides.

So far the SMSD documentation has been converted from various places and formats, but it also opened up a question - how to deal with translations? So far we used po4a to translate man pages, however using it for generated man pages is slightly complicated (there are some macros which po4a does not understand and it seems to break encoding on the way).

Translating whole new documentation is something what is unlikely to be finished, especially considering fact, that the only real existing translation so far is Czech which was done by me.

For now I decided to keep old translated man pages and postpone the decision, but considering current situation, I will most likely just drop the translations for man pages unless I find some good solution how to translate Sphinx documents (po4a should be able to do that, but it will probably need some tuning).

While working on new Gammu documentation I came to need to include some graphs showing some workflows. Looking into Sphinx documentation (which is used for the documentation for Gammu), I've discovered nice integration with graphviz.

Fortunately it was pretty easy to learn the basics, though I've never used it before and here it comes - message processing workflows for SMSD.

During last weeks I finally got upset with state of developer documentation for Gammu and python-gammu. Not that it would be non existing, but it was spread over various places in various formats and partially outdated.

I decided to write all documentation in Shpinx as I know this tool and it seems to fit quite well in mixed C/Python environment.

The first step was to migrate existing docs into same format (reStructuredText) and create documentation structure. I believe this is now completed and you can check results here.

Yes there are still lot of rough edges and lot of work to do, but I anyway think that current state is better then mess we used to have before.