Michal Čihař - Blog Archives for Debian

As I wrote before, I tried to use Ubuntu Personal Package Archive for distributing up to date Gammu, python-gammu and Wammu packages. For first time I failed because I expected it to behave more like OpenSUSE build service than like Debian archives, but I was wrong, so I have to upload different version to each Ubuntu suite.

Well that sounds like a work which should be automated. So I hacked a little shell script, which takes current version from unstable, updates changelog and injects it into my PPA. The hacky script is called deb2ppa. It requires dput to be configured for ppa same way as I have it and maybe has some other tricky dependencies which I do not realize right now.

Anyway you can now use current Wammu/Gammu versions even on older Ubuntu releases if you wish :-). (Well you have to wait till it is rebuild, but I hope it will not take much time.)

Fixing bugs in code and committing it to VCS usually also means that you need to interact somehow with BTS you use to let it know that the bug has been fixed. This is manual work which could be done by some clever commit scripts, right? All what is needed is just spend some time to set it up.

Most of my development currently goes to Gammu/Wammu which uses own Mantis bug tracker. It is already a bit prepared for integration with VCS, but I never found their documentation sufficient. Fortunately somebody wrote tutorial on integrating Mantis and Subversion, which made it quite easy to set up. All what was needed was to put little commit hook into SVN.

Now the logical step was to make it also for Debian packages. A bit of Googling revealed discussion on debian-devel. Unfortunately no example for SVN, but ripping out needed things from Manoj's script for Arch was quite easy and I made my own commit hook. While looking at this, I also found wonderful tool called debcommit, which commits changes to Debian package using changelog entries as commit message. I still wonder how many useful tools are hidden to me.

The only thing I don't know is why Google didn't show me yesterday svnlog, which seems to have support for Debian BTS out of the box. Maybe I just entered slightly different keywords than today when trying to find the mentioned thread on debian-devel.

I'm just wondering: Why do all my packages start getting RC bugs which are easy to fix right now, when ftp-master is down and uploads are not possible? It must have some coincidence...

After massive processing of new queue during weekend (check graphs to get better impression, kudos to all who managed to handle hundredth of packages during weekend), new Gammu is in unstable. It is still not in shape for migration to testing, but it is much better than the one I accidentally uploaded before. Currently there are no known open regressions, so if you see something failing what used to work before, just report it!

Well I somehow expected it will happen to me when I started to use Debian experimental distribution, but now it really happened. I noticed that last Gammu upload went to unstable instead of experimental just when today updating my other development machine and I was surprised that Gammu is going to be updated. Well the version is not that bad, but it is far from being stable.

Anyway it is good for something - unstable users will do much more testing than experimental ones ;-).

Man never realizes how much customised distribution he has until he has to reinstall it. Last week hard disk in my notebook died, so I had to reinstall system and reconfigure everything. I fortunately have backups of almost everything (at least I didn't notice that anything would be missing), but I anyway spend two evenings in installing, configuring and restoring from backups and I'm still not done with it, but the system is at least usable for normal work.

However there are also some positive things on this: I get more space and faster disk. I finally set up encrypted file system on my notebook. I dropped several old crap that lived (or better was buried) somewhere in my system and which I already forgot why it was there. And I also got rid of very bad partitioning scheme, which was there from times I used together Debian and Windows and wanted to have another partition to test SUSE installation while I worked there. Now there is only Debian to rule them all ;-).

Being far away from your home adds you need to know what time is there and whether you can safely call people not waking them up in the middle of night. So I looked for some Gnome applet that would show me time in another time zone. I expected this to be easy, but unfortunately I didn't find anything in Debian. Few minutes of Googling revealed something, but both applets I found look quite unmaintained.

After a bit of testing I decided to give World Clock Applet 0.0.0 a try. It seems to work so far and installation only needed few tweaks. As I hate to use something not in Debian packages, I packaged this beast. For now it is available only in my repository, as I'm pretty sure it would not pass any license checks :-).

It looks like everybody is talking about this, so here are my 2 cents. I remember my NM process still very well (I became DD few months ago) and I know very well how painful is to ask somebody to upload packages for you again and again.

On the other side the NM process definitely helped me to produce better packages and I learned some new things. Debian currently has pretty good quality and having such entry barrier helps to this. And I do not thing that the barrier is too high.

Maybe I was just lucky, but NM process was not that long and complicated as I heard before than I actually applied. The only thing that took incredibly long was just delay between DAM approval and actual account creation, but AFAIR it was only because responsible people were busy with release. Otherwise I'd go through NM in 3 months and I feel this is perfectly acceptable time for this and there is no need to split it up by introducing some intermediate level.

As Wammu won't have filesystem support in near future (and I'm not sure it will ever have it), I decided to package gMobileMedia for Debian. For now the package is sitting in NEW queue, but impatient can get it from my repository.

Steve, I know that caching usually helps. But from all test I've made with MediaWiki installation on phpMyAdmin wiki, I can see that enabling any caching slows things down quite a lot.

With memcached based caching, each request takes about 15 seconds, if I add XCache backend for variables, it slows down things to 10 seconds and I receive same results with file based caching. So it doesn't seem to be problem with memcached, but rather MediaWiki issue. Unfortunately it's quite a lot of PHP code to investigate and I didn't find anything obvious in low level caching interface.

So say good bye to variable caching, opcode cache is enough for now and MySQL seems to handle the load quite well.