sorted by: recent | see : popular

Content Tagged with gammu + coding

I handle bug reports and email communication as soon as possible, but it does not mean that it may take month or even more to get reply. I'm not working full time on my free software projects, I do it only in my free time. Besides this I have regular job and I also have a real life with another hobbies.

So if you wrote me something, just try to be patient, sending another emails to urge your issue won't help anybody. I will just have more unread mail to process until I get to real work.

As I wrote before, I tried to use Ubuntu Personal Package Archive for distributing up to date Gammu, python-gammu and Wammu packages. For first time I failed because I expected it to behave more like OpenSUSE build service than like Debian archives, but I was wrong, so I have to upload different version to each Ubuntu suite.

Well that sounds like a work which should be automated. So I hacked a little shell script, which takes current version from unstable, updates changelog and injects it into my PPA. The hacky script is called deb2ppa. It requires dput to be configured for ppa same way as I have it and maybe has some other tricky dependencies which I do not realize right now.

Anyway you can now use current Wammu/Gammu versions even on older Ubuntu releases if you wish :-). (Well you have to wait till it is rebuild, but I hope it will not take much time.)

Fixing bugs in code and committing it to VCS usually also means that you need to interact somehow with BTS you use to let it know that the bug has been fixed. This is manual work which could be done by some clever commit scripts, right? All what is needed is just spend some time to set it up.

Most of my development currently goes to Gammu/Wammu which uses own Mantis bug tracker. It is already a bit prepared for integration with VCS, but I never found their documentation sufficient. Fortunately somebody wrote tutorial on integrating Mantis and Subversion, which made it quite easy to set up. All what was needed was to put little commit hook into SVN.

Now the logical step was to make it also for Debian packages. A bit of Googling revealed discussion on debian-devel. Unfortunately no example for SVN, but ripping out needed things from Manoj's script for Arch was quite easy and I made my own commit hook. While looking at this, I also found wonderful tool called debcommit, which commits changes to Debian package using changelog entries as commit message. I still wonder how many useful tools are hidden to me.

The only thing I don't know is why Google didn't show me yesterday svnlog, which seems to have support for Debian BTS out of the box. Maybe I just entered slightly different keywords than today when trying to find the mentioned thread on debian-devel.

Today, when walking through some Wammu/Gammu bugs, I came to conclusion that the spam changed some people to behave insane. The email field in bug tracker is there to allow developer to contact you, for example when he makes a fix for issue you reported and wants you to test it. Entering addresses as ones at TrashMail which will vanish soon (the bug I'm talking about is two days old, what I feel is good enough reaction time from my side), will not help anybody.

Thank you firebird76 (whatever your real name is) for realizing how people are stupid.

PS: I use Mantis bug tracker, which I believe does not expose email addresses to anyone besides privileged users.

If you want to follow SVN commits on some of my SVN repositories, you can subscribe to appropriate maling list, which gets notification on each SVN commit. I hope I set up mailman correctly and everything will work as I expect :-).

This list is also automatically forwared to packages.qa.debian.org, so you can also subscribe there for Debian package changes.

If you want to follow SVN commits on some of my SVN repositories, you can subscribe to appropriate maling list, which gets notification on each SVN commit. I hope I set up mailman correctly and everything will work as I expect :-).

This list is also automatically forwared to packages.qa.debian.org, so you can also subscribe there for Debian package changes.

Current Gammu versioning scheme confuses people a lot. For some time 1.x.0 versions are stable and 1.x.y are testing. However when somebody sees 1.10.5, he things this is updated version of Gammu 1.10.0. So it's probably time to move to something more obvious starting from next development cycle.

To stay as much compatible as possible with current scheme, I thing about minor change - so start testing releases on something like 1.11.90. I thing this is also quite often used (I've seen such versions in PyGTK in past) and nobody will confuse it with patch releases. Or should I switch to something completely different? I currently do not consider 1.11.0-rc1 as I'd like to keep version only numeric.

Today last batch of Wammu and python-gammu has been converted to Subversion. It was almost painless, it only required lot of CPU time. All project pages should now link to Subversion repositories and snapshots. Also all projects now have publicly available statistics on http://www.ohloh.net and http://cia.vc.

Unfortunately for python-gammu and Wammu are statistics a bit messed up - for Wammu ohloh didn't find license header, which is in almost every file, in python-gammu, doc string comments are not counted as being comments, so without it project has obviously to low comments ratio.

Anyway I was quite impressed by code grow of Wammu in last half year, because I still thing I don't have enough time for Wammu. However if their stats are true, the code amount grows quite fast in last months.

Today last batch of Wammu and python-gammu has been converted to Subversion. It was almost painless, it only required lot of CPU time. All project pages should now link to Subversion repositories and snapshots. Also all projects now have publicly available statistics on http://www.ohloh.net and http://cia.vc.

Unfortunately for python-gammu and Wammu are statistics a bit messed up - for Wammu ohloh didn't find license header, which is in almost every file, in python-gammu, doc string comments are not counted as being comments, so without it project has obviously to low comments ratio.

Anyway I was quite impressed by code grow of Wammu in last half year, because I still thing I don't have enough time for Wammu. However if their stats are true, the code amount grows quite fast in last months.

Today last batch of Wammu and python-gammu has been converted to Subversion. It was almost painless, it only required lot of CPU time. All project pages should now link to Subversion repositories and snapshots. Also all projects now have publicly available statistics on http://www.ohloh.net and http://cia.vc.

Unfortunately for python-gammu and Wammu are statistics a bit messed up - for Wammu ohloh didn't find license header, which is in almost every file, in python-gammu, doc string comments are not counted as being comments, so without it project has obviously to low comments ratio.

Anyway I was quite impressed by code grow of Wammu in last half year, because I still thing I don't have enough time for Wammu. However if their stats are true, the code amount grows quite fast in last months.

After more playing with Tailor, I managed to hack it enough to convert my Arch repositories to Subversion. Move from distributed to non distributed VCS migth look as step backwards, but I have pretty good reasons for this:

• Subversion is widely used and there is big chance that potential contributor will know how to use it. This lowers barrier for contributing (especially when compared to current Arch/Bazaar).
• Subversion sucks much less than CVS which is other well known VCS.
• If I want to work distributed I can still use Bazaar-NG with foreign branch features.

The conversion is currently on the way and will probably need some time (about half of Gammu revisions have been converted so far).

After more playing with Tailor, I managed to hack it enough to convert my Arch repositories to Subversion. Move from distributed to non distributed VCS migth look as step backwards, but I have pretty good reasons for this:

• Subversion is widely used and there is big chance that potential contributor will know how to use it. This lowers barrier for contributing (especially when compared to current Arch/Bazaar).
• Subversion sucks much less than CVS which is other well known VCS.
• If I want to work distributed I can still use Bazaar-NG with foreign branch features.

The conversion is currently on the way and will probably need some time (about half of Gammu revisions have been converted so far).

I still more and more think, that I should move out of Bazaar to some more maintained piece of software for version control. The biggest problem I currently see, that I was not able to convert by Bazaar repositories to some other format. I tried to convert to Bazaar-NG by booth BzrTools and Tailor, but none of them succeeded, then I tried conversion to Git, but Tailor failed also on this task.

Maybe I will try Subversion, which is now very widely used software, although it has some annoyances. I originally wanted distributed VCS, because I was often offline at home, but this is not the case anymore, so using centralised VCS on my own server should not be a big problem.

python-gammu 0.17 has been just released. New features:

• Support for python 2.5.
• Initial support for WAP bookmarks.
• Initial support for MMS indicators.

I already announced that Gammu translations were converted to gettext. Reasons for conversion were written already some time ago. Now I'd like to write about some technical details on conversion.

First I thought the conversion will be simple. Just convert one text file format to other. Unfortunately there were lots of typos in old translations, which I had to fix, because gettext is much stricter about syntax. This itself would be also good reason to switch - old localisations had several types of errors, most frequently bad escaped quotes or messed format strings. This sometimes lead to Gammu crash, because it confuses printf like functions.

Another thing which was broken in old translation were duplicates of some strings. There were about 20 duplicate messages, which only added work to translators and were never used, because Gammu used first string which matched.

After I spot common mistakes, it was quite easy to write conversion script which would handle them. It is written in Python and uses its ConfigParser module to read old localisations. Using already done modules makes thinks a lot easier :-). After reading them, they are fixed to avoid syntax errors in gettext and written in gettext format to new file. All this in 123 lines of code (well, many of this are comments and string constants).

PS: You can download conversion script here, maybe it will be usable also for some other project.

I played a bit with Gammu and my phone (Sony-Ericsson K750i) yesterday, and I found yet another firmware bug. Enabling call line identification over cable (or any connection) makes phone hang when you receive call. Don't know why it is not able to look up number, when it already shows it on the display…

I still more and more think, that I should move out of Bazaar to some more maintained piece of software for version control. The biggest problem I currently see, that I was not able to convert by Bazaar repositories to some other format. I tried to convert to Bazaar-NG by booth BzrTools and Tailor, but none of them succeeded, then I tried conversion to Git, but Tailor failed also on this task.

Maybe I will try Subversion, which is now very widely used software, although it has some annoyances. I originally wanted distributed VCS, because I was often offline at home, but this is not the case anymore, so using centralised VCS on my own server should not be a big problem.

Maybe I'm a bit late, but happy new year! I was quite silent in last days as I was having rest from computer and enjoyed real life.

What will this year bring? I will hopefully become Debian Developer, as only required step right now is account creation. This is good news for Gammu users who run Debian, as I would like to upload testing versions to experimental (as well as appropriate python-gammu builds).

What else? Some new releases of my projects :-). I'm still working on Wammu and configuration wizard. There is a bit more work than I expected, but it should be ready during January. I don't expect much new features in python-gammu, it will be just kept in sync with gammu.

The only remaining project is Ukolovnik, which is in perfect state for me, however other users request more features and I should sometimes get at least to patch merging :-).