Michal Čihař - Blog Archives for Debian

RC bugs

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

New Gammu is in Debian

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!

I should review better what I upload

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

Reinstalling notebook

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

World clock applet

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

Debian Maintainers

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.

MediaWiki caching

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.

XCache in Debian is up to date

Same time I complained about not up to date xcache package, I wrote to current maintainer whether I can adopt it. As he promptly agreed to this, we now have up to date package in Debian archives.

The only thing I messed down is that I did upload in hurry and didn't check which all bugs I can close by it. Today it turned out that all opened bugs could be closed, so I made another upload just to close those bugs ;-).

Xcache opcode cacher

As I wrote in previous post, memcached didn't help as expected with wiki performace, so it was time to look for something else.

Since I'm using lighttpd, I still considered using of XCache, but the Debian package is not really up to date (now it even does not install with current php), so it was too much effort.

But today I decided it's time to try it. I built package from current version (you can get it on debian.cihar.com), installed and it seems to increase performance a lot. Most visible it is on wiki pages, which now take about quarter of time to process. I only hope it won't have any stability impacts, but it survived fine stress tests I did so far.