Michal Čihař - Blog Archives for Debian

Jak na debianí balíčky?

Tak jsem se nechal přemluvit k napsaní seriálu o tvorbě balíčků pro Debian. Protože je přeci jen dělám už nějaký ten pátek, tak už jsem asi zapomněl na některé věci, na které jsem v začátcích narazil. A proto jsem se rozhodl napsat tento zápisek :-). Pokud jste měli (nebo máte) s něčím problémy při vytváření balíčku pro Debian, napište to do diskuze, za odměnu se vám pokusím nabídnout co nejlepší odpověď ve vznikajícím seriálu.

PS: Když mi Robert poprvé napsal, tak jsem moc netušil co psát. Teď už se blížím třinácti dílům, takže si myslím, že se máte na co těšit :-).

Toshiba ACPI keys, HAL and friends

Long time ago I used FnFX to handle events from ACPI keys on my Toshiba notebook. However when reinstalling notebook because of disk crash, I thought there must be a cleaner way to handle these and I found patch for acpid which added handling of these special events.

However I really didn't like patching acpid on every update and there didn't seem to be chance to merge it upstream, so I started to look for better solution. After another amount of googling, I found that HAL already has some support for Toshiba hotkeys. Unfortunately it is now disabled in Debian because most key did not emit anything using HAL.

Okay, let's fix the HAL, maybe it will get later enabled. Converting FnFX keymap to C code was quite easy and I made a patch for HAL to add support for all keys. Hopefully it get merged soon and I can then file bug on Debian package to reenable Toshiba support in HAL.

Meanwhile I'd like to find some generic way of configuring what happens on these events. For now I hacked simple Python script which listens to DBUS events and invokes appropriate commands for keys, but I hope that some such tool already exists and I just missed it. If you know something, please let me know at michal@cihar.com.

České man stránky pro Debian

Dnes jsem se konečně zase do delší době dostal k údržbě mých balíčků v Debianu a kromě drobných oprav (například Enca už bohužel není udržovaná a její stránky pohltili spammeři) jsem si rozhodl přidělat práci a připravil jsem balíček s českými man stránkami . Teď už jenom zbývá počkat, než projde přes frontu nových balíčků . Nedočkavci balíček mezitím najdou v mém repository .

My key is finally in keyring

I somehow expected that this will never happen, but todays update contained debian-keyring version 2007.12.04, which includes changes from last two years or so. So finally who-uploads and other tools work reasonably good for mine stuff.

Anyway I think with more than 6000 lines in last changelog entry, it is good candidate to be the longest changelog entry ever been in Debian :-).

Too lazy to manually upload to PPA

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

Lets automate the work

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.

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