I know phpMyAdmin translators will love us for this, but I just commited translatable messages for new setup script. This leads to situation when even the best translations are at 75% (see statistics). I hope our brave translators will manage to handle these 350 new messages for upcoming 3.1 release, at least for major languages, which were always close to 100%.
PS: Looking for translator to Czech!
I just wanted to fix some RC bugs till I'll go home, so I looked at the list of open ones and randomly chosen two bugs about roxen fonts which looked like low hanging fruits. Both were in fact same issue, just copied to two packages.
I worked on the fix, creating some intermediate version and then I finally wanted to upload the package. Unfortunately in this step I somehow managed to use the intermediate version, which did not really fix the issue. As packages were already uploaded, there was not much I could do except yet another NMU, now with full set of changes.
Just as accepted emails arrived I also noticed that I messed up bug numbers in changelog - I used same bug number in both changelogs. Okay, manually closing the bug worked around this.
But now I'm afraid what else did I mess up. Probably it's time to go for a dinner and stop working on computer for now :-).
I just published new Gammu testing version. Major changes are in handling some special Nokia responses, handling of Siemens phonebook entries and introduction of automatic testing using CDash on http://cdash.cihar.com/index.php?project=Gammu. Full list of changes:
You can download from usual place: http://cihar.com/gammu/, Debian users will find packages in experimental soon.
I finally catched up with Gammu backlog from holidays and now it is time to move it a bit further.
During this week I set up CDash instance for acquiring results of
automatic nightly checks of Gammu. Each night Gammu is build on several hosts
(currently Debian x86_64, Debian x86, SUSE x86_64 and crosscompilation for
Windows on Debian) and results are posted to the dashboard. If you have
some other architecture which could participate in testing, you are welcome to
contribute! It is simple - just checkout svn, create build directory and
configure there Gammu using cmake. You can enable coverage tests
(-DCOVERAGE=ON). Then just run every night make Nightly for regular testing
or make NightlyMemoryCheck to do dynamic allocation analysis. There is more
detailed documentation in sources (INSTALL file).
Thanks to this, I can hopefully sooner spot regressions and possible problems on different architectures.
With upgrade of Mantis, new feature called roadmaps arrived. I started to use it for planning features in future Gammu releases, so you can see what bugs should be fixed in future releases in Gammu roadmap. Currently there are not much things planned, because till now I had to focus only on bug fixing, but I think with 1.21.0 we have reached much better quality than in past releases and now is time to do some important changes in the core.
As you can already see in roadmap, I plan some bigger changes to Gammu core. I currently have on Sony-Ericsson phone and I would not be able to properly test how these changes will affect Nokia drivers. So for start I will need at least Nokia Series 40 3rd edition phone. Nokia 6233 (or 6234) currently looks as a reasonable choice, but if you have any hints for cheaper one with similar features, just drop me an email.
Perfect would be if somebody would have half broken phone (I do not intend to use it for anything else than Gammu development, so broken camera, speaker, microphone or display does not really matter) and will be willing to donate it to me. If this will not work out, I'll have to buy used one and I will try to collect funds for this. If you want to contribute, check my donations page for possibilities.
I just released version 0.29 of Wammu. This release fixes various problems found by users. Full list of changes:
This release also comes with binary for Windows with embedded Gammu 1.21.0.
It looks like I again did same mistake with Gammu and python-gammu binaries - they started to crash randomly. It was again caused by fact, that they were linked to two C runtime libraries (msvcrt.dll and msvcr70.dll). I should make some automated check for this to avoid uploading so broken things, but I don't know any command line tool which can list DLLs which are required by exe and which works on Linux (Wine is okay too). Anyway the binaries has been just recompiled and uploaded, so if Gammu or python-gammu crashes for you, please download new version.
PS: Thanks to Olaf Leidinger, now I know how to check it automatically:
/usr/i586-mingw32msvc/bin/objdump -x filename.exe | grep "DLL Name"
New version of python-gammu has been just released. It fixes possible crashes and brings compatibility with Gammu 1.21.0. Full list of changes:
Download from usual place: http://cihar.com/gammu/python/
Good news everyone, after long time of inactivity and huge development over past month, new stable Gammu release is out. Since 1.20.94, there are only minor fixes in handling some corner cases in AT parser, but full list of changes since last stable 1.20.0 is quite long:
You can download from usual place: http://cihar.com/gammu/, Binary packages will be available soon.
Yesterday I faced problem with VMware server that it can not run 64-bit guest system. I'm using 64-bit SUSE and 64-bit VMware, so it should work, right? I can select 64-bit system in VMware, but the guest is simply 32-bit without any error.
In documentation, man can find only "VMware Server supports 64-bit guest operating systems only on host machines with supported processors.". How helpful! After a bit of googling, it turns out that VT needs to be enabled and usually it is not enabled in BIOS (any reason for this?).
So let's reboot, go to BIOS, enable VT and it should work. Unfortunately not, after reboot, still same problem. I was almost given up at this point, but I decided to recheck BIOS, whether I really enabled the right thing. Yes I did, but I did not notice small note, that to apply this setting, I need to power off and on the computer. That was the trick! Now it finally works. I just wonder why it has to be so complicated...
Summary: If programs would have useful man pages or error messages, man would not have to look into source code.
I just set up Debian sid chroot on my computer and have to sign something inside this chroot (dpgk-buildpackage). Okay, I want it to use gpg-agent in my host system, that should not be hard. Looking at gpg man page, GPG_AGENT_INFO variable is used to forward information about agent socket, PID and protocol version, so I set this variable according to host system, but it still does not work, giving nothing saying error that agent is not working.
So let's debug this beast - strace reveals, that communication with agent works, but it replies "113 Server Resource Problem". Hmm, still not much useful information, but let's google for this problem. Fortunately Google reveals related Seahorse code, where man can find, that not set DISPLAY variable is causing this issue. Could not the error be more friendly, so that it tells me directly what is wrong?