Gramps – Python 3 encoding bug and 2 parallel release freezes

Gramps project

The Gramps project had recently received a lot of reports from users of the new Python 3 version of Gramps (4.1.1) that after they upgraded, Gramps did not function and there were lots of error messages. This was serious if they had not taken a backup before the upgrade, because the new database was not backwards compatible. This turned out to be because in the switch to Python 3, as part of the database upgrade some strings were being encoded in ASCII instead of Unicode. This was a problem for those non-English languages with special characters.

Nick produced a fix for this, and then Tim added a function that fixed the problem also for people that had already converted to 4.1.1 of Gramps. But this still left the problem that Debian and Ubuntu users were going very soon upgrade to 4.1.1 without the fix, and both Debian and Ubuntu are in freeze mode before they issue their next release.

With the help of Tim & Paul from the Gramps project, I was able to patch the version of Gramps (4.1.1) in Debian, and convince the Release Team to unblock the Debian freeze for this fix so that it would be part of the soon to be released Jessie. Then I also submitted a bug, and got this version of Gramps synced to Ubuntu Vivid (15.04).

So hopefully, things will go much smoother for Gramps users upgrading to the new Debian and Ubuntu in the next few months.

Abcmidi and the Mayhem Bugs

When I managed to adopt the abcmidi package in Debian a while back, I had contacted Seymour Shlien (the upstream maintainer) about the four Mayhem bugs (here’s an example of one of them). Unfortunately, neither Seymour or I at the time could work out what was going on.

Although the Mayhem Team had provided a script that always confirmed the crash when a certain invalid command option was passed to the abcmidi commands, the core dump provided was from an i386 (32 bit) processor, and I am running an AMD 64 bit processor. This meant that gdb did not give a traceback at all, even when I went to the effort of downloading the source code and building the package again without stripping the debugging symbols.

Recently, I noticed that Seymour had released a new version of abcmidi, and I decided to tackle the problems again whilst packaging this new version. To make things easier for me, I added a -dbg package to abcmidi so that the debugging symbols would be available for gdb to provide a useful backtrace.

But even with this, I found that gdb was not dumping the core when the script was run to produce the crash. So I learnt a little bit more about debugging. Why was there no dump of the core? Running $ ulimit -c gave the output “0”, which meant – no core-dump! Following the advice on this very useful website (linux core dumps), I set things up so that the above command gave the output “unlimited”. Normally it is advisable that you put a limit on the core dumps to avoid your machine’s hard disk filling up, but I was doing this on an expendable Virtual Machine.

This time when I ran the script, the core was dumped! So when I loaded the core-dump into gdb with $ gdb usr/bin/abcmatch core, I was able to: > set logging on, then type > bt full, and > quit, and found a text file with the full backtrace that I emailed to Seymour for each binary command that had the bug.

Very quickly, Seymour fixed the bugs and released a new version. I packaged it straight away and Tobias Frost sponsored it. The package is still waiting in the NEW queue because of the new -dbg package, but hopefully it will be released into experimental soon and the bugs will be automatically closed.