Sie sind hier

Serendipity and shared installations on Debian

Today - as many of you have already noticed - is/was a big day for Debian:

  • Sam Hocevar won the DPL election
  • Debian (old)stable 3.1 released a new version
  • Debian Etch 4.0 was released

Well, I could add another topic:

  • Debian is no longer Debian for me because not all of my archs are supported anymore

In a more detailed view:
Sam Hocevar won the DPL election
Congrats to Sam! I can agree with most of the points he made in his DPL platform, e.g. a sexier website, sexier distribution, remaing the universal OS, etc.
sexier website: Really, the current design of Debians website is awful. It's really something back from the 90s. Bad look, bad design and stuff you're looking for is difficult to find, because it's badly structured and stuff is spread all over the place. I think, it would be good to have some decent CMS and some good designers/graphic artists - a good package maintainier doesn't make a good webdesigner.
sexier distribution: Many people are using Ubuntu because they're desktop users. The current release cycles are way too long and drive people away from Debian. It's a different matter, of course, for servers or managed systems like Terminal Servers or such. Those are fine with longer release cycles. Splitting up the release in some core and sub releases is a quite common proposal. Yes, this split is difficult, but I think it's the way to go.
remaing the universal OS: As of the release of Etch, Debian became the no-more-universal OS - just because m68k wasn't released for obscure reasons. I'm a great m68k user and now I'm left behind by Debian with the problem that my pet arch is not supported anymore. Running testing/unstable is not an option for m68k IMHO. Because the m68k porters didn't come up with an alternative release plan so far, I think it's the best to shutdown my 3 m68k machines - all of them are m68k buildds - within the next weeks or months. They're producing (well, some little) heat, some disturbing noise and consume a lot of power of course. Currently I accept those drawbacks in order to help the m68k port by donating CPU power running some buildds for about 7 years now. I've spent much more money on this purpose - not only for paying the electricity bills - for phone calls to get crashed remote machines rebooted, sending replacement parts for other buildds or even driving by car to bring machines or other parts to other persons (like to Michael Schmitz or accel boards to the Netherlands for porting stuff. Anyway, I will happily reactivate the machines when it's up to make a new release for the m68k architecture again! :)

Some other point Sam mentioned in his platform is this:

There are very useful services around, such as, or I cannot understand why they are not Debian services.

I already had a conversation with Sam about this in which I expressed my general intention to develop at least Buildd.Net beyond its current state - it's quite frustrating for me to see Buildd.Net being stuck in development just because I've no more time and skill to develop Buildd.Net further. Sadly, my call for help wasn't as successful as I wanted. Only two persons wanted to help: faw and joey - and both are quite busy with other stuff.
Apparently, Buildd.Net will most likely suffer from shutting down my m68ks due to the missing m68k Etch release as well, because it was always a frontend to my m68k buildds in my eyes. All other stuff on Buildd.Net is just a nice addition to that. And when I don't operate m68k buildds on a daily basis, it's obvious that I won't invest much more time into the development of Buildd.Net. This is already true for the past year where I haven't found the time to fix some serious problems in the backend scripts and database of Buildd.Net, which basically breaks (source and therefor ptracker.cgi(example) as well. I even haven't found the time to setup trac and svn again after the move to the new server during last autumn.
Erm, anyway.. back to the topic: I wish Sam the best for his period - but I don't think that he can make a big change. I doubt in general that any DPL is able to push big changes in Debian. One reason for this is the short period of just one year. Another reason is that many DDs won't let big changes to be made.


Was hat ein Hubsteiger mit dem G8-Gipfel zu tun?

Hmmm... maybe I'm doing something wrong, but somehow I can't get s9y to use a multi-site config as described on this page (by Garvin Hicking).

Of course, symlinking and such went fine and I get the config screen (serendipity_admin.php), but I miss the place where to change the database setup, which is done in the Debian package via db-config and lies in /etc/serendpity/

This is my multisite setup so far (a mixed setup with copied/symlinked files):

lrwxrwxrwx archives -> /usr/share/serendipity/www/archives
lrwxrwxrwx bundled-libs -> /usr/share/serendipity/www/bundled-libs
lrwxrwxrwx comment.php -> /usr/share/serendipity/www/comment.php
lrwxrwxrwx exit.php -> /usr/share/serendipity/www/exit.php
drwxrwxr-x htdocs
lrwxrwxrwx include -> /usr/share/serendipity/www/include
lrwxrwxrwx index.php -> /usr/share/serendipity/www/index.php
lrwxrwxrwx lang -> /usr/share/serendipity/www/lang
drwxr-xr-x pics
lrwxrwxrwx plugins -> /usr/share/serendipity/www/plugins
lrwxrwxrwx rss.php -> /usr/share/serendipity/www/rss.php
-rw-r--r-- 1 serendipity_admin_image_selector.php
-rw-r--r-- 1 serendipity_admin.php
-rw-r--r-- 1
-rw-r--r-- 1
-rw-r--r-- 1 serendipity.css.php
drwxrwxrwx templates
drwxrwxr-x templates_c
drwxrwxr-x uploads
lrwxrwxrwx wfwcomment.php -> /usr/share/serendipity/www/wfwcomment.php

Granted, during the last days I haven't found that much time (Easter holidays) yet to have a deeper look into the topic, but I got the impression that it's not that easy to use s9y on Debian with a shared installation setup as described on Garvins page. A sql scheme for the psql database is also missing in /usr/share/doc/serendipity.

Maybe you, dear lazyweb, have already a nice setup script for this purpose for Debian? Would be nice... :-)


Heiligendamm und der Gipfel der Frechheiten

Ein einfaches Problem:
Die Firma, in der ich arbeite, möchte gerne einen Hubsteiger für ein paar Tests mieten. Leider ist der gewünschte Hubsteiger diese Woche ausgebucht: der ist nämlich unterwegs zum Aufhängen von (Überwachungs-)Kameras für den G8-Gipfel.

Ein Schelm, wer daran glaubt, daß die Kameras nach dem Gipfel wieder abmontiert werden...



Naja, wie vielleicht mancher schon weiß, findet demnächst in Heiligendamm der tolle G8 Gipfel statt. Das hat zum einen schöne Nebenwirkungen (in Warnemünde werden z.B. einige kaputte Straßen neu asphaltiert), zum anderen aber auch sehr negative Auswirkungen. Die Wiedererrichtung der Mauer (wenn auch im kleinen Maßstab) ist nur eine davon.
Heute bin ich über eine recht interessante Seite bzgl. des Heiligendamm-Problems gestolpert:
Pro Heiligendamm
Wie vielleicht mancher auch weiß, gehört die weiße Stadt am Meer einer Investorengruppe. Inwieweit da nun auch das Kempinski Grand-Hotel dazugehört, entzieht sich meiner Kenntnis, aber ich glaube kaum, daß Kempinski lediglich Mieter ist.
Jedenfalls haben wir es dem G8-Gipfel zu verdanken, daß denkmalgeschützte Häuser einfach mir nichts, dir nichts abgerissen werden, um einer Presse-Tribüne Platz zu machen. Auch ein riesiger Findling und Gedenkstein wird umgesetzt. Ist ja auch doof, wenn die Pressefutzies dann nicht dem tollen Herrn Bush beim Posieren zuschauen können, weil so ein doofes Ding von Stein die Sicht versperrt.


Buildd.Net: version 0.96 of released

I've been using Debian for about 10 years now. Debian was my first Linux distribution. For about 7 years I've been running a Debian m68k buildd now. For some time now I've been worrying about Debian and its future.
IMHO, there are several reasons to worry about its future.
a) Release cycles.
Funny enough Martin Michlmayr wrote today about Gnome release cycles. Apparently Gnome suffered from similar problems in Gnome 1.x times as Debian still does today. The big difference between Gnome and Debian is: Gnome has actually learned from its mistakes and changed its release model to something better. Really. I don't use "better" very often in conjunction with "Gnome", but in this regard, the Gnome project did really something good.
Debian, on the other hand, suffers more and more from its "release everything for all when it's ready" syndrome. Releases are always delayed, it's a big chunk of work for everyone involved, Debian is losing users because of the delays and so on...
b) Debian as a base for other distributions.
Lately, several distributions announced, that they will use Ubuntu as a base for their own distribution and not Debian any longer.
c) Internal problems.
Debian has many internal problems. Many of them have to do with communication problems. Others with "you can't force anyone to do anything in Debian" ideology. Some with unresponsive persons in key positions. Some problems are a mixture of all the above. Altogether, these problems are causing that many developers are losing their fun in the long run.
d) Flame wars.
Well, actually this could be listed in b) Internel problems as well, but it's a massive problem of itself, so I think it deserves its own section. Flame wars are really time consuming and destructive. I know what I say. Been there, done that.
e) Getting new people in.
It is often said, that there are >1000 Debian Developers. The truth is that many of them are inactive or MIA. There was a proposal lately to find those inactive DDs and handle them accordingly. Given this fact of many, many inactive DDs means, that there is more work for those left. To solve this problem of overworked DDs (it's another truth, that some DDs are very active and have far too many jobs within Debian), Debian needs to attract more people and encourage people to contribute. Currently, it's not that easy for people to contribute, because of bureaucratic formalisms like sponsored uploads and such. Additionally, not everyone willing to help wants to do packaging or other tasks. There is a lot of other work to do like making graphics, organizing booths or other events, etc. Currently those tasks are mostly done by DDs that could better spent their time on developing Debian itself (packaging, porting, ...).

Ok, enough for now. But how can those problems be solved?
ad a)
Martin mentioned in his post about the Gnome Release management, that they changed from "release when it's ready" to time based releases and gained credibility because of this.
I think, Debian would benefit as well from this type of release management. Additionally, every Developer can react to this new method and make his packages fit for the release because he knows "Hey! Just 4 weeks until the release! Let's get my packages ready for it!"
Another problem, IMHO, is the "release all packages for all archs at one time" problem. This lead to the drop of m68k for etch (via some obscure circumstances like a very broken gcc 4.0 version and some strange release criteria, sometimes referenced as Vancouver Massacre).
Someone of the contestants for the new DPL job mentioned in his world domination plan to have a stable release of some basic components every year and having sub-releases for desktop environments (KDE, Gnome, XFCE...) every 6 months. Basically I believe that this is the way to go. You can discuss the time frames, of course. Release a stable base every year or every 2 years? But really, I think this would be the best way to deal with many problems Debian has.
If every 1-2 years a new stable base would be released, everyone could be happy: the admins with long release cycles for their servers, the users with faster releases for their desktops and (maybe) the porters who can (maybe) omit a subrelease of the desktop apps and concentrate on porting the base system if needed. Really. 15000 packages for (let's say) 15 archs is way too much work for everyone.

ad b)
With the above mentioned changes, Debian could re-gain some more market share and users from other distributions like Ubuntu - and be a base for distributions again. The reputation of Debian would rise again, because the releases wouldn't be delayed again.
I think it would be ok for smaller ports (like m68k) to release differently than the main archs (i386, amd64, ppc, arm): if every year a new stable base release would be done, it could be ok for them to skip a release, if necessary. Of course, details must be elaborated more in detail.

ad c)
There are many internal problems. The most urgent one is "bad communication". Needless to say that it's very important to communicate with your work mates to get your work done. If someone fails basic communication skills (answering questions about the stuff s/he is responsible for) in a reasonable time frame, s/he's simply the wrong person in that position and should be replaced. Of course this interfere with the current understanding of "not being able to be forced to do things" in Debian. People should change their mind about that.
Basically, it's similar to NMUs: if a package maintainer fails to fulfill his responsibilities (fixing bugs), he can either be enforced to fix the problem in that package by a bugreport or he can somewhat be replaced by doing a NMU when he's not fulfilling his duties. If he fails often to get his package into a good shape, he can be replaced permanently by hijacking the package.
Or to give a real world example: If you are holding a honorary post, let's say, you're doing the financial paper work for your soccer club, you can't say "Oh no... I don't have the time to do the tax declaration now or the next month...". That just doesn't work. Either you do your duties on time or you need to step down from that post. Otherwise you would do damage to your club. This is valid for other volunteer organisations as well, like Debian. Do your duties on time or step down from your post.

ad d)
Well, I'm not innocent when speaking about flame wars. Anyway, people can learn and change their mind. Flame wars are really bad in Debian, but it seems to be something like a sport to me sometimes. And usually it needs two parties for a flame war. That's the reason why I believe that expelling a fellow DD because they were involved in some major flame wars in the past is simply wrong. Either expel all parties or none.
A party is not only involved when answering to mails on mailing lists, but also when doing stuff that forces the other party to react - for example by starting a flame war on a mailing list. There's always action and always reaction. Therefore you can't disjoin both and just judge upon one party.
When a mediation is tempted, both parties are required to obey the mediators decision. Of course there should be a fair decision that honors both sides. Both sides have to give in for a successful mediation attempt. If that's not the case, the mediator failed. Not obeying to the mediators decision, because "no-one can be forced to do anything in Debian" (see above), is plainly wrong.
Anyway, most people should know of what I'm speaking here. I think it's plainly wrong to expel developers that have done really great work in the past due to some flame wars. Debian as a community has failed when it chooses this ultima ratio. Debian just proves that it is unable to establish a community where people can work together, when developers are going to get expelled because they thing that a mischief was done to him.
How would you feel and react when someone would play bad games on you? Wouldn't you yell loudly as well?
So, how can something like this be avoided? Maybe a Code of Conduct could help, maybe that CoC wouldn't be necessary when everyone would be nice to anyone and remember that there's a human being each mail with feelings and emotions?
Anyway, Debian needs to abandon flame wars in general.

ad e)
Well, I've already written a little bit about this problem above. There are many tasks in Debian that doesn't need technical excellence of packaging details - instead it needs excellence in social skills. Something that many technically focussed people are missing. Debian needs to become more attractive to those kind of people that are good at this non-technical issues and encourage them to join the project - and not to frighten them away by a very technical and bureaucratic procedure like the current NM process. Those kind of people won't wait some years to be actually being able to do work. They will just go on and find a place where their skills are better welcomed.

Ok, that's for now, I think... it's been a long post and therefore I've used folding for it.

Well, not a nice one. Debian needs big changes in its structure and the candidates for the upcoming DPL elections identified some of them and put them on their agenda for their DPL period (if they win, of course). But the history showed that none of the past DPLs had really the power or the will to push big changes and made hard decisions. So, after all everything will stay as it is now. Nothing will change for the better, I fear. Users will leave Debian because of its stale release cycles, more and more Debian-based distributions will change their base to Ubuntu and Debian will become more and more irrelevant over time instead of being a strong participant in the free software world.


Eisregen in Rostock

Although the changes have been done in September, I finally uploaded the new version today.

# - fixed a bug in recognition of running buildd processes
# - fixed a bug in N-D-P detection

You can find the updated version at

Wireless Bridge Linksys WET54G

Heute morgen gab es Eisregen in Rostock. Auto freikratzen war nicht möglich, da die Eisschicht einfach zu dick war. Also was bleibt einem anderes übrig, als das zu tun, was man eigentlich nicht tun sollte: Motor laufen lassen und abwarten. Nach 10 Minuten war der Wagen dann ausreichend warm, daß man mit dem Eiskratzer nachhelfen konnte.

Auch die Fahrt zur Arbeit (das nächste Mal, wenn der 23.02. auf einen Wochentag fällt, nehme ich mir jedenfalls einen Tag Urlaub) war dann etwas geruhsamer als an anderen Tagen: statt mit 80 über die Stadtautobahn zu fahren, waren eher so 60-70 drin. Das eigentliche Problem waren aber die Nebenstraßen in der Stadt.

Da sind mir zugeschneite Straßen ehrlich gesagt viel lieber... :-)


Blog migration finished

Ok, for some time now, I've been using my old Samsung Vm8100KXDT Laptop to connect my wired network to my Linksys WRT54GS router, which resides on another floor.

Well, if you read my old Drupal blog, you may have noticed, that I complained several times about my Netgear WG311T PCI card, being not able to be run in my PowerPCs. That's the reason why my Laptop was acting as a wired/wireless bridge (or more exactly a router between both worlds).

Today I bought a Linksys WET54G wireless bridge to replace my Laptop for that purpose. My Laptop was just too noisy and too power consuming and - even worse - the harddisk began to die. It was giving loud *klackklack* noises from time to time, resulting in a loss of DMA and therefore needed a power cycle afterwards.

Anyway, the WET54G is a nice small box with one antenna and one ethernet port. It is advertised as being a operating system independent device - which is clearly not true. You'll need a Windows PC to configure the device and it's quite awful to configure.

Instead of accessing the WET54G bei http, the CD-Rom contains a small program that scans the ethernet for that device. Next problem will arise when you want to configure your WLAN/WiFi settings. It is pre-configured to use channel 6 and infrastructure mode. Unfortunately, you'll need to first configure infrastructure or ad-hoc mode before you proceed to configure your ESSID, channel and b/g/mixed mode settings. Even worse because you can't change the channel or the mode when you have chosen infrastructure mode.

So in order to change your channel, you'll need to configure it in ad-hoc mode first, then change your channel and mode first, safe your settings, let the device reboot and continue with configuring infrastructure mode again.
Really badly tested piece of software, Linksys!

But beside of this huge annoyance the WET54G works quite nice once setup properly. Alas, I can't recommend it to buy for the above reasons.

After configuring it the first time, there actually is a webinterface, where you can configure the device with your favorite free OS. However, it was not accessible the first time to me, although I configured a Laptop to use the described default network in the manual. The above mentioned problems of not being able to configure the channel in infrastructure mode still exists in the webinterface.


Buildd.Net: new arm subarch added - armel

On this weekend, I finalized my blog migration from Drupal to Serendipity.

I was somewhat surprised that my latest blog entry in Drupal gathered that much attention. It was the most read article on my (old) blog, mainly because it was featured by someone on the Drupal talk site.

Anyway, my old blog is now available at whereas the new blog is at Thanks to Alexander Wirt for updating my links on planet.d.o!


First new entry

Aurelien Jarno asked me to add another arm port to Buildd.Net, namely armel - a new ABI version for newer little endian based arm boxes. Read more about that new arch in the Debian Wiki.

Anyway, here it is: armel page on Buildd.Net - have fun!



Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer