Sie sind hier

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!


Kernel Oopses with LVM and XEN

Ok, Etch was scheduled for release in December. We have now mid of January and Etch is still not released, but just frozen.

In October there was a large thread about m68k not a release arch for etch; status in testing, futureplans? (both on debian-68k as well as on debian-project).
M68k is performing quite well after the gcc issues were finally solved (thanks to Roman Zippel for his great work!) and I'm wondering, if m68k could be a release arch *now*?
M68k is >98%, whereas there are problems with the alpha arch apparently, which drops below 97%. And arm had some problems as well...


Debian, the release and m68k

There aresomeposts on planet about IRCing with Irssi.

IMHO, one of the greatest thing in irssi is the proxy module. It's great to be able to use any IRC client you like plus having the benefit of being able to use the running irssi instance in the screen on your server. For example, when my DSL get's disconnected for some odd reason while I'm at work, I can happily use the irssi (with running proxy) in a screen session without any problems. Irssis proxy module is really worth a try! :-)


IRCing with Irssi

In one of my last blog entries I complained that Firefox/Iceweasel doesn't work anymore on my PPC box. It seems as if the reason is a small entry in the prefs.js file:
user_pref("layout.css.dpi", 1);

A DPI of 1 is (of course) nonsense. When setting this value back to a senseable value (75 or 100) everything works again, which is nice. :)

Another problem I discovered during this topic was, that my browser still uses ~/.firefox instead of ~/.mozilla/firefox. So I have to migrate my settings in the next days to be uptodate config-wise, too... ;)


Firefox/Iceweasel works again!

Aurelien Jarno wrote in his blog about new arm buildds he set up to work around the non-responsive arm buildd admin.
The topic has been carried to the debian-project ML under 2 threads:

There are some interesting bits in these threads:

  1. Aurelien wrote:

    It is known among debian developers that the Debian System
    Administration Team (aka DSA or is not
    really responsive.

    Very true, but some may object that wanna-build admins (which do manage the buildd permissions) are in charge of this problem and not DSA. IMHO it doesn't matter who is to blame (w-b admins or DSA), because in both cases the persons behind these teams are the same.
    Another point Aurelien mentions are the still locked down machines like escher. Here, DSA is really to blame, IMHO.
  2. Next, Anthony Towns replies:
    So apparently this complaint was immediately followed up by setting up an emulated autobuilder not synced in with the regular stuff [0]. This resulted in James and Ryan adding a quick hack to disable arm uploads, which have remained disabled over the past few days, apparently with some of the deferred uploads from the official autobuilder getting overwritten by later uploads by Aurelian's autobuilder.
    Funny, eh? Instead of responding to Aureliens critics, the DPL has chosen to accuse him of being aggresive by setting up some machines to deal with the problem. Even more fun: the w-b admins seem to have enough time to work around Aureliens work-around - instead of fixing the cause to Aureliens initial posting. So, why do they invest so much time in excluding/rejecting Aureliens packages instead of using that time to fix the arm buildds?
    This funny behaviour (of not answering the questions) was noted others as well hereand here and here
  3. Bill Allombert proposed to add some communication delegate to "fix" the communication problem between DDs and DSA. Nice thought, but I guess the communication delegate would suffer from the very same problem, trying to communicate with a black hole because s/he's not accepted by DSA. The followups to this post are worth to read, too.
  4. Wouter writes in his followup:
    There's not much to work out, really. The "procedure" is "set the host
    up, send mail with SSH key, IP address, and similar information to the
    right person, cross fingers, and hopefully it'll be accepted sometime,
    otherwise don't expect a reply". While this works, I cannot say that
    it's never been frustrating to me either, and at times I myself have
    also been _very_ tempted to just bypass the official "procedure" and
    install some hack so that the box would at least build packages.
    Especially at times when we're backlogged---and, surprise, I don't often set up a box when we're _not_ backlogged. Occasionally, this type of frustration was also at the root of Ingo's "Serious problems with mr Troup" mail.

    Wouter really made some points here: First, allowing a new buildd is really not as much work as some might think. It's not like that the w-b admins need to setup the new buildd theirselves, but only editing some scripts and ACLs. Let's say it lasts 10-15 minutes at most. We (m68k porters) still wait to see Akire being added back to the ACLs as well, after it suffered from a dead disk and thus having a new SSH host key. For over a year now, IIRC. It would be easy for us to bypass the problem and connect to w-b via another buildd, but James is somewhat peculiar with such solutions... ;-)
    And after all, the whole problem is really not new and for me it's funny to see this topic coming up again and again and again and seeing no improvement after all these years...
  5. In a different thread Steve Langasek writes:
    Now, many people will probably object, pointing out that
    $ is widely regarded as a blackhole.

    That email alias was introduced back then primarily in order to have one single contact address to get in touch with buildd admins, because people often enough didn't know how to reach buildd admins before that. M68k porters for example were using a different mailing list and not debian-$port@l.d.o and other buildd admins didn't seem to read the port MLs as well. So, when the buildd admins can't be reached via $port@b.d.o, does it make sense to have that address at all? I doubt so. It doesn't make a different under which email address the black hole is hidden. The black hole itself is the problem, which needs to get solved, and not the email alias for it.
    Indeed, in the case of Aurelien's
    buildds, we have the additional variable of using emulated arm systems -- I don't know what ARM instruction set qemu emulates, and I don't know who else among the ARM porters knows, maybe it's been discussed and maybe it hasn't, but it's definitely another variable that contributes to these buildds being a poor predictor for the official autobuilders.
    (Thankfully, he doesn't mention any use of distcc+cross-compiling here -- having a cross-compiler that does fp math differently than a native compiler does because of arm's fp pecularities would be yet another twist we don't need...)

    M68k is experimenting with emulated buildds and distcc/crosscc setups and Bill Allombert is doing a great job with this stuff. But m68k has used those for some heavy weighted builds and other stuff, not as a regular service so far.
    You can't setup strict rules in such strange way as the Vancouver proposal and then disregard any tries to comply with them.
  6. Sven Luther writes:
    Don't you find it a bit hypocrit to have x86 uploads go directly to the archive, and not allowing even a single day delay which would allow to stop unclean DD-build-boxes breakage and a clean state, and on the other day let the other arches depend on the good will of the buildd maintainer, who is usually a single person, who doesn't communicate much, and who sometimes is not able to sign and thus upload the packages for a couple of days (sometimes more even, but i guess this is the exception).
    This is the single-point-of-failure all over again, and we should really move away from such setups and into a more transparent team-based with inter-team communication and multiple backups setup.

    Yes, true... while Vancouver dealt with buildd machine redundancy, it missed buildd admin redundancy, which was mentioned several times during the huge Vancouver Proposal discussion on debian-devel back then. And it's obvious that this problem is still not solved and the single buildd admins of some archs have been the SPOF many, many times since then.

It's obvious for many people where big problems within Debian reside, but so far every DPL has failed in fixing these problems and I doubt that this will ever change. :-(


Aurelien and the Arm port

Or: Everything was better in the past!

I don't know whether the change from Firefox to Iceweasel or the upgrade to v2.x caused this, but Firefox/Iceweasel doesn't run anymore on my PowerPC:

[ij@muaddib:]~$ firefox

The application 'Gecko' lost its connection to the display :0.0;

most likely the X server was shut down or you killed/destroyed

the application.

You can have a more detailed bugreport in the BTS.

Anyway, somehow I feel bad with this bugreport, not because of the bugreport, but because of the non-reaction so far. True, we have christmas vacation all around the world and maybe the maintainer is absent because of this, but I think Firefox/Iceweasel is a rather important and often used package which should deserve a team maintainership. 'nuff said...



Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer