sorted by: recent | see : popular

Content Tagged with wammu + python-gammu

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.

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.

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.

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.

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.

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).

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).

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.

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.

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.

If you will be first weekend in November near Brno, you might be interested in LinuxAlt, where I will have a talk about Gammu and generally mobile phones under Linux.

The talk will be in Czech language as most of audience is expected to be Czech speaking.

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.

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.

If you are only interested in information about new releases, you can use new RSS feeds/categories I just created - python-gammu releases and Wammu releases. Those will be really low trafic feeds containing only information about new releases and no ideas or development progress as in regullar python-gammu or Wammu feeds/categories.