Planet Open Ghana

July 17, 2010

Joachim Breitner

How forky may one maintain a Debian package?

I maintain most of my Debian packages because I use them myself. Sometimes, I have some needs that go slightly beyond what is currently offered by the software. This is not a problem: Debian ships Free Software and I can program, therefore I can patch the software to also do what I want it to do. Trying to be a good member of the Free Software community, I then submit the patch to the upstream author. If he accepts the patch (which is usually the case), everything is fine. But what if he does not reply to the report or rejects it because he does not want this feature (although the patch is technically fine)? I see two options:

  1. I could continue to use a privately patched and built version of the package, while separately building packages for Debian. This way, Debian ships the software as intended by the upstream maintainer while I can use the features I need. On the other hand, I would not be using the version that I upload to Debian, which is not good, and it causes double work when a a new version is released.
  2. I could upload a package to Debian that contains my patch. The technical infrastructure to add patch in Debian packages has always been there... I would actually use the package as it is in Debian and only manage one line of versions. But would I be abusing my powers as a Debian maintainer? If I were not the maintainer, I could not make this decision by myself (this happend with my patch to nagstamon). Plus it could have a negative effect on the Debian-upstream relationship.

How do other Debian Developers handle such issues? The actual case I’m considering is a feature enhancement for link-monitor-applet (but I only just wrote the patch, so it does not yet fall in the category “upstream does not reply”).

by mail@joachim-breitner.de (nomeata) at July 17, 2010 07:59 PM

July 03, 2010

Joachim Breitner

Free Groups Formalized

Since a few months, I have been playing around with Isabelle, a theorem prover system. I find it very intriguing to have proofs of mathematical statements checked by something as pendantic and comprehensive as a machine. Mathematicians always claim that their statements are true in all eternity, but the proofs are just checked by error-prone human beings. Especially with complex, large proofs that are only read by a handful of people, I doubt that these are always fully correct. Note that this does not imply that I doubt that the results are correct. They probably are. But a bit of doubt remains. A computer-checked proof, in contrast, can not accidentially omit corner cases, leave out seemingly “trivial” assumtions of used theorems or be misled by slightly differing definition from different sources.

I was hoping to check at least parts of my diploma thesis using Isabelle, but it turns out that the standard algebra library shipped with Isabelle is not complete enough. Even free groups were missing. This was motivation enough to try to formalize them and prove the universal property and some isomorphisms (The free group over the empty set is the unit group, the free group over one generator is the additive group of integers and free groups over sets of same cardinality are isomophic). I submitted the resulting theory to the Archive of Formal Proofs and it was accepted. You can view the complete document or the document without proofs.

I did not formalize the fact that isomorphic free groups have bases of same cardinality. As far as I know there is no simple argument that works directly with free groups. The proofs I have seen pass to the abelianization of the free group, i.e. the free module over ℤ and apply the well known proof from the analogous statement about vector spaces. But if someone knows an elementary proof of this fact, I’d like to hear about it.

by mail@joachim-breitner.de (nomeata) at July 03, 2010 10:44 AM

June 29, 2010

Kofi Boakye

I love my country

It had to take the on going world cup to really bring the fact home to me …but i really love my country, mother land and land of my birth , the black star of Africa…GHANA…GHANA (GH) totally rocks…Go Black Stars and make the whole Africa proud


by kdex at June 29, 2010 02:21 PM

June 24, 2010

Joachim Breitner

nagstamon forklet necessary

A while ago, I discovered nagstamon, a very useful piece of software by Henri Wahl. This program sits in the notification area of your desktop and alerts you when your nagios-monitored services have problems. Using nagstamon allows me to keep my servers under close surveillance, and it also adds another channel besides e-mail alerts, which will be helpful in case my mail server has problems.

The wish

I am not a full time sysadmin, I only monitor very few hosts and the services rarely have problems. Therefore, I do not want nagstamon to constantly sit in the notification area but only use it when there is something, well, to notify me about. It turned out that nagstamon did not support this mode of operation, so I created a ticket and asked whether this feature could be added. The author raised two points, one being that then the user would not know when nagios crashed and the other being that you would not be able to configure nagstamon because you do not see it. He also indicated that he does not have the resources to work on it and asked if I could find the time.

The patch

Since I really liked nagstamon, but really want to keep my panel uncluttered, I found the time: I created a series of self-containing patches, adding an option for the feature, adding code to prevent more than one instance of nagstamon running in parallel and adding a "nagstamon --settings" flag that would signal the running instance to show the settings – similar to how mail-notification is been behaving. The author then raised the valid point that some people run more than one instances in parallel, with different configuration options. I then extended the patch to cater for that.

The rebuff

The author remained reserved, did not answer my last commend on the ticket and then, six weeks later, closed the bug without explanation and turned off the possibility to add comments. I can understand when people are reluctant to add contributed features to their code, I often feel the same way. But completely blocking more comments is not a nice way of communicating with possible contributors.

The fork(let)

So I’m left with no option but patching each released version with my changes and building my own package. As I have to do this work anyways, I’d like to share it. You can find my branch in my git repository. If you happen to want this feature as well and are using a Debian-based distribution, please let me know: I am building modified Debian packages anyways and can publish them as well. As I don’t want to maintain this fork of nagstamon I don’t plan to diverge any more from Henri’s code, so if you have other feature requests, please talk to him first.

by mail@joachim-breitner.de (nomeata) at June 24, 2010 05:46 PM