Sie sind hier

Sleepless in Warnemünde

Debian Etch has been released lately, as you may know, and the work on Debian Lenny is already starting. For some of the DDs the work is way much different than for the rest of the DDs: the good ol' brave porters of m68k.
Stephen Marenka asked on debian-release what is needed to get back and be able to release with Lenny?
The answers are shaking:

1. To get back to testing: Basically, the release team didn't mind the
state we had with m68k in testing recently - basically, we just ignored
it, but it was still there. The release team didn't asked for full
dropping from testing, we just didn't mind either way. We also wouldn't
mind for m68k to be back in testing - as long as we can just continue to
ignore it.

2. To get released (or a realistic chance to): Basically, make sure that
the toolchain works (see the other mails), and get really fast buildds
(otherwise, the security team would probably veto the inclusion). The
second might happen with Coldfire, but - the how is your part, not ours
(i.e. if you do it some other way, that's ok as well of course).

Having said that, I can understand if the ftp-masters don't want to have
an architecture be in testing unless there is reason to believe it is
possible to include it in the next stable release, but that's not the
domain of the release team.

ad 1)
Ah, ok... as long as we are ignored, everything is fine. But how will testing m68k get updated when the testing scripts ignore m68k? Pardon me, but isn't this a little bit strange, at least?

ad 2)
Getting really fast buildds - good joke, indeed! Or is this a Friday, 13th habit like April Fools Day?

Let's summarize: we can release with Lenny, when we get back in shape - but testing is needed for this, where we're ignored for. And without faster buildds for an arch such as m68k, there's simply no way back to make it into a release again - because of this.
Describing Coldfire as such a possibility for faster machine seems a little bit strange to me. CF is totally new, there's not progress yet on the CF front to my knowledge and a combined m68k/CF port may introduce other drawbacks, which nobody can predict for sure today. Do you really believe that ftp-masters or release team will allow such a port to get released? I don't.
Getting faster buildd in a reasonable amount of time is illusory for m68k. We can get more buildds online, but not "really fast buildds". Despite one older blog post of me, I'll receive just another '060 m68k soon (to be hosted by a fellow DD). A few days ago, two other m68k buildds were added to the m68k buildd rotation list. That will make 3 more buildds for the m68k.

Anyway, in most cases your first impression is the correct one and my first impression of the Vancouver Massacre/Proposal was: this is a plan to drop m68k!
Well, the lastest incidents confirm this impression, IMHO.
After all, I think that the m68k port would be best served by dropping Debian instead of being dropped by the project. The m68k port - de facto - has been dropped already. I'm disappointed.


Upgrading to Etch considered harmful

Na toll!
Da naht der G8-Gipfel, es ist 0:36 und die jungen Herren mit den wenigen Haaren und dem noch weniger darunter haben nichts besseres zu tun, als den ganzen Abend schon im Warnemünder Park herumzukrakeln. Aber deren Freunde in den geräumigen grün-weißen Volkswagen T3 sind auch schon da.
Viel scheint es aber wohl nicht zu bringen, da einige der geistig erdfarbennahen Bevölkerungsgruppe sich vom dortigen Kinderspielplatz an unseren Gartenzaun verlagert haben, was nicht unbedingt ein besseres Gefühl ist, um sich beruhigt ins Bett zurückbegeben zu können.


The big Debian day

Oh well... today I upgraded a server at my workplace from Sarge to Etch. This went fairly well EXCEPT that the machine was quite slow afterwards and Samba didn't work anymore. No problem, I thought, because during the upgrade the Samba was displaying a note that I'll need to change the passdb line, because it doesn't support chained backend lists anymore.
The problem was, that this didn't help. To make a long story short:
During the upgrade the file /etc/libnss-ldap.conf has been overwritten without any notification. There's even no /etc/libnss-ldap.conf.dpkg-old file.
Apparently the QA of the Etch release failed in this particular case. Am I the only one who's using LDAP?

Meebey hinted me to have a look at the config file. The problem is, that the config file has a Debconf header, which indicates that it is handled by debconf. I'm used to edit those files anyway, because usually debconf (or the package scripts) notices if the file was changed manually and gives a warning about this issue. Well, the libnss-ldap package seems to be rather dumb and doesn't recognize when something has been changed within its configuration file. So, removing the debconf header will prevent this from happening again. Thanks, Meebey!


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



Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer