Michal Čihař - Archive for Jan. 1, 2012

First phpMyAdmin's alpha release for 3.5 is out for some time and it's best time to start translating if you want to be on time for final release.

For information about translating, check our website, in short you can translate either offline (get file from Git, translate and post it to translations tracker) or use online translation system available here:

https://l10n.cihar.com/projects/phpmyadmin/

As you can see in the summary, there is lot of new or changed strings, many of the new ones coming from advisor. I suggest you to keep these as last to translate as there is quite lot of them and it is more important to have translated rest of application. The advisor messages are placed at the end of po file.

I believe we can reach good amount of complete translations by final release with your contributions!

PS: You can expect me again to publish translations stats on this blog as we're heading to release.

I have a laptop used for playing music (and occasionally also videos) which is currently running Windows XP with XBMC. Reinstalling this beast to Linux is on my todo list for ages and now I've finally found time to try that.

Starting Debian installer worked like charm and in few minutes I got Debian system running. I've chosen to run sid, well for reason I run it usually on place where I want latest software. Installing XBMC from Debian multimedia worked also fine and you can easily find some howtos for directly starting XBMC.

And that's where I ran into trouble - XBMC is damn slow. Notebook has oldish nVidia GeForce FX Go5200 card, which seems to be poorly supported by nouveau (and "Do not file bug reports about this driver." suggest that this is what authors do expect). Okay, I can survive having some binary crap so let's try nVidia proprietary drivers. I've quickly realized that the legacy drivers won't work with recent xserver and probably also not with the kernel.

Maybe I should try installing something older, what would run binary drivers, but for now I gave up and system is back on Windows (with all problems I have there...).

From what I can see on both my personal Flattr account (where was never really much going on) and on (more attractive) phpMyAdmin's profile, the amount of people using Flattr there goes down there every month. There was definitely big momentum when it has been introduced, many geeks saw it as great opportunity for making micro payments work. Maybe people who started to use it at beginning are slowly abandoning it (what is true for me as well) and new ones simply don't come that much or whatever else. Anyway I definitely don't have the big picture to see whether is global trend or just my project is more unlucky...

One of Django applications I maintain is our internal tool used at SUSE used for managing incoming L3 requests. Recently request to add some API arose (read only for now). Looking at available solutions, I came to conclusion that django-piston should be the best choice for me.

Adding simple model based API with it is indeed quite simple, all basic information you need is written in getting started part of their documentation.

On the other side, things can never go without problems, so I was hit by well known bug. Fortunately fix exists, though it is not yet merged upstream. While digging so deep into problem anyway, I've submitted a request to include this patch in devel:languages:python OBS repo.

It took me much more uploads than I expected, but ColorHug client is finally in unstable. I was fighting with various bugs, which I could not reproduce locally and of course with my own stupidity in configuring pbuilder.

Anyway the buildds overview now shows mostly green, so this is good. The remaining ones mostly wait for libgusb, which needs build on armhf and needs to be ported to non Linux (or rather libusb needs to exist there).

One of things I've learned on the way is that docbook-utils is not enough to convert docbook to man pages, you need docbook package as well. Still I don't understand why this did locally work for me...

The one outstanding issue is that client code assumes it runs on little endian host (or rather same endianity as the ColorHug device) and thus will break on PPC and other big endian machines. The upstream is aware of that an I even managed to produce patch which should fix it, though I have no means to test it (lack of big endian hardware and lack of the ColorHug device itself).

This is mostly note to myself, when I will set this up for next time.

Every time I set up test environment for Gammu SMSD, I'm lost in PostgreSQL configuration. Simple reason is that I do not use it at all for any other reason.

Adding user and creating a database:

# su - postgres
postgres@rincewind:~> psql template1
psql (9.1.1)
Type "help" for help.

template1=# CREATE USER smsd WITH PASSWORD 'smsd';
CREATE ROLE
template1=# CREATE DATABASE smsd OWNER = smsd;
CREATE DATABASE
template1=# GRANT ALL PRIVILEGES ON DATABASE smsd TO smsd;
GRANT
template1=# \q

Next stem is to allow anybody to connect as smsd user. There might be better ways to do that, however I've chosen the simplest one - to trust any local connection - as testing of Gammu SMSD is anyway the only thing this database server does. Edit /var/lib/pgsql/data/pg_hba.conf:

# "local" is for Unix domain socket connections only
local   all             all                                     trust
# IPv4 local connections:
host    all             all             127.0.0.1/32            trust
# IPv6 local connections:
host    all             all             ::1/128                 trust

uTidyLib is definitely something you would call a dead project - no new release for seven years, dozens of open bugs and submitted patches and no active development. On the other side it is still used by several packages in Debian, thus worth maintaining. This is also reason, why there are few crucial patches in Debian repository to make it work (for example on 64-bit architectures).

While googling whether there is something new going on with uTidyLib, I've noticed two efforts. One is PyTidyLib, a complete reimplementation, which provides different API and thus does not seem to be used anywhere yet.

Another (well almost two years old, but I did not look earlier) effort is to fork in on Github and make it work with MacOS X. Okay, when somebody took the "effort", lets try to merge Debian patches there, hopefully there will be a release sometimes. So here is the pull request.

Update: I've just learned, there is another fork going on - https://github.com/lachlan-00/utidylib2

Today, I've spent some time on ColorHug software (which I've preordered some time ago).

The first missing bit there were Debian packages. There are already some packages available for Ubuntu, but I've chosen clean start and did all the packaging on my own. The packages are now waiting in NEW queue (which is amazingly empty in last months) and will hopefully get accepted soon. In case you are too impatient, you can look to git repository on Alioth (you will need libgusb as well). Packaging effort lead to writing (quite minimalistic) man page for colorhug-ccmx, which I've also sent upstream.

The other thing, where I can help right now (not owning the device itself) is translation. As you can see on Transifex, my task is done here and Czech translation is complete :-).