New version of python-gammu has been just released. It improves compatibility with Python 2.5 and brings compatibility with Gammu 1.20.0. Full list of changes:
Download from usual place: http://cihar.com/gammu/python/
New version of python-gammu has been just released. It fixes annoying problem with reporting wrong Gammu version and brings compatibility with Gammu 1.19.0. Full list of changes:
Download from usual place: http://cihar.com/gammu/python/
Continuing in Christmas release series, the next in a row is python-gammu. It only brings usual bunch of upgrades to be in sync with Gammu and improved MinGW support:
Download from usual place: http://cihar.com/gammu/python/
When Ubuntu announced public availability of Personal Package Archives, I thought it might be good to use it to provide up to date Gammu related packages. After successful registration I uploaded Gammu package and no reaction so far, so I'll wait.
However this memorised me that I wanted to use OpenSUSE Build Service for same purpose some time ago. I filled in registration and as I didn't receive any email about being accepted, I absolutely forgot about that. Now just tried to log in and it works. So you can now have access to latest Gammu, python-gammu and Wammu packages for most recent RPM distributions (Fedora 7, Fedora 8, Mandriva 2006, Mandriva 2007, openSUSE 10.2, openSUSE 10.3, openSUSE Factory, SLES 9 and SLE 10). I could not test them so any feedback is welcome :-). You can find all packages on overview page or directly in download folders.
Playing with spec files after long time was quite painful, but I got to it after I managed the hardest thing - how to make build dependencies which will work on all these distros.
I hope I will be able to announce similar service for Ubuntu users using PPA, but now I have to wait for some reaction on my source uploads.
python-gammu 0.23 has been just released. New features:
python-gammu 0.22 has been just released. New features:
python-gammu 0.21 has been just released. New features:
While working on Gammu, I still wonder why people who want to connect their phone to computer buy phones from vendors who use own proprietary protocol or do not share any documentation. Then they come to Gammu mailing list and/or bug tracker and want Gammu to support their phone. Sometimes the fix is easy, but usually it is quite lot of work to debug unknown protocol.
I know this situation quite good from past. I had Alcatel phone, which was using proprietary protocol for access to in phone contacts and events. Fortunately Alcatel released synchronisation software for these phones (it of course runs only on Windows) which had enabled debugging and it was quite easy to understand protocol thanks to logs it could produce. But as newer phones with some extensions appeared, maintaining this became harder and harder.
When I looked for new phone, I decided to buy Sony-Ericcsson K750i phone. Writing support for most of functionality (well in fact all I need) was just matter of few days. The reason why it was so fast was that this phones is using open standards (e.g. OBEX, IrMC) and vendor specific AT commands are documented in freely available documents.
It's your choice how good will your phone interoperate with computer. If you buy well documented piece of hardware, chance to have it fully supported is much higher.
python-gammu 0.20 has been just released. New features:
python-gammu now supports service numbers dialogue. How it is useful for you depends on services your network provides. For example with Vodafone in Czech republic, you can use it to configure various services:
$ ./service-numbers.py
This example shows interaction with network using service codes
Enter code (empty string to end): *111#
Talking to network...
Network reply:
Status: ActionNeeded
Vitejte v Kapesni Samoobsluze!
1 Muj ucet
2 Me sluzby
3 Nastaveni telefonu
4 Info a zabava
5 Oblibene
Enter code (empty string to end): 1
Talking to network...
Network reply:
Status: ActionNeeded
Muj ucet
1 Vyuct. a platby
2 Vydaje pod kontrolou
3 Osobni udaje
4 PIN a PUK kod
------
0 Zpet
00 Uvod
Enter code (empty string to end):
Python code which can be used for this is available as example. It will be probably one time integrated to Wammu, but it needs a bit more time than hacking this simple script :-).
Yesterday I hacked asynchronous wrapper for python-gammu. It is start of progress to make Wammu behave better while talking to phone. My plan is that all operations will go through this asynchronous wrapper and will be completely non blocking to Wammu. This means no progress bar will pop up to front, but entries will appear in window as they are being read. Progress will be of course still shown, but only in status bar.
The current code is only first step, next thing which has to be
implemented in python-gammu are virtual commands. Those will be used for
things like getting all calendar events from phone, so all you will have
to do for getting all is enqueue GetAllCalendar event and
worker will do all for you including progress reporting.
If you want to write own application using this new wrapper, you can look at example which is in sources. It shows all current possibilities, but it will be enhanced in future.
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:
The conversion is currently on the way and will probably need some time (about half of Gammu revisions have been converted so far).
Today I noticed, that documentation for python-gammu is not up to date, because I completely forgot to update it since 0.13 release.
Well anything what has to be done manually sucks, so I scripted automatic generating of this documentation, so it should always be up to date with current development snapshot.
BTW: Anybody know how to document constructor of class implemented in C using EpyDoc? I didn't manage to find way for this.
It's probably time to give up. I tried to tweak tailor to make it able to convert my repositories to Subversion for several times, but without any success. It also fails to convert it to Bazaar-NG or Git. Those are list of all VCS I consider to use in future.
I'd prefer to switch to subversion, because it is widely used and most people will be willing to use it, but I have not find any way to convert current VCS data to it. Maybe I will start with empty repository and forget the history.
python-gammu 0.19 has been just released. New features:
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.18 has been just released. New features:
After some playing with distutils to make cross compilation using them possible, I finally gave up. Maybe I did not understand some part of guide, but resulting library only crashes Python.
So I googled once more and I found another approach to cross compile Python extensions for Windows on Linux.
And it was quite simple to do it. First you need Windows installer for Python. Now you need to get dll and includes out of this. I decided to leave hard work on Wine and hoped it will work:
/usr/bin/msiexec /i /tmp/python-2.5.msi
Now you have installed Python somewhere in ~/.wine/drive_c.
All what is remaining is tuning of makefiles from original howto.
You can also look on code for python-gammu which deals this issue.
Thanks to Matthew Mueller for great howto! BTW: I tested it with Python 2.5 and MinGW 3.4.5.