Sie sind hier

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


Iceweasel? I want my Firefox back!

Some time ago I blogged about madwifi and my Netgear WG311T. Well, it still sucks.

I've setup a serial console to my PowerPC box now and have now some debugging output, when the madwifi driver horribly fails:

wifi0: rx FIFO overrun; resetting
wifi0: ath_reset: unable to reset hardware: 'Hardware didn't respond as expected' (HAL status 3)
wifi0: ath_chan_set: unable to reset channel 6 (2437 MHz) flags 0xc0 'Hardware didn't respond as expected' (HAL status 3)
wifi0: ath_chan_set: unable to reset channel 7 (2442 MHz) flags 0xc0 'Hardware didn't respond as expected' (HAL status 3)
wifi0: ath_chan_set: unable to reset channel 2 (2417 MHz) flags 0xc0 'Hardware didn't respond as expected' (HAL status 3)
wifi0: ath_chan_set: unable to reset channel 4 (2427 MHz) flags 0xc0 'Hardware didn't respond as expected' (HAL status 3)
wifi0: ath_chan_set: unable to reset channel 8 (2447 MHz) flags 0xc0 'Hardware didn't respond as expected' (HAL status 3)
wifi0: ath_chan_set: unable to reset channel 10 (2457 MHz) flags 0xc0 'Hardware didn't respond as expected' (HAL status 3)
wifi0: ath_chan_set: unable to reset channel 6 (2437 MHz) flags 0xc0 'Hardware didn't respond as expected' (HAL status 3)

The issue is quite easy to trigger. Just setup a wireless connection, generate some load/traffic and wait some minutes. It's really a matter of minutes and not hours. In my latest tests I just did a ping -f to another host, another ping -s 16384 to a second host, a scp -r from a thrid host and generate some disk activity by dd'ing hda to /dev/null. The machine crashed within two minutes.

Maybe it is related to some interrupt problems, but as I don't have similar problems without the Netgear WG311T, I doubt that my machine is faulty. Even worse the problem is easily reproducible on two different PowerPC machines.

So, dear lazyweb, what wifi card (PCI, a/b/g) is good and flawlessly working under PowerPC linux? Non atheros and madwifi solutions preferred (manufacturer/type/chipset).


Linux, WLAN, Netgear and Madwifi - a neverending story

Maybe some of you have already noticed, that there's a new section (flavour) on Buildd.Net called skolelinux, which maps to etch-skolelinux and has currently i386 and powerpc included.

This was just a quick addition and maybe there're are some things wrong. Please let me know about those when you find something.


Buildd.Net: etch-skolelinux added

Oh, well... in my last blog entry I stated that I'll move my drupal installation to my new server.

But I didn't know at that time that drupal has been orphaned and a grave bug has been filed to prevent it from being released with Etch. Very, very bad...

However, I've evaluated serendipity yesterday evening, but although it looks very nice and feels more speedy than drupal, it lacks some of drupals features like static pages (or I haven't found out how to do that).
And additionally, the Debian package of s9y has some issues when using a remote database. You can't start with a remote config using dbconfig -common (which is a really nice thingie on itself), but you have to abort the current debconf run, edit your config file of s9y in /etc/dbconfig-foobar/ and (really important!) fix a bug in /etc/serendipity/

Instead of $dbserver='yourserver'; it has to be $dbhost='yourserver';, because is being sourced in /usr/share/serendipity/www/ which has the following line:

$serendipity['dbHost'] = $dbhost;

So, it's really unlikely that s9y will ever know where your database server is. Alternatively you can change that line in /usr/share/serendipity/www/, of course.
Guess I'll have to file a bugreport about that.

Anyway, it would be nice if someone would adopt drupal and make it into Etch.


Blog migrating considered harmful

I'll move the drupal installation to a new host in the next days. So, it's somewhat likely that somthing will break. Sorry for that in advance... :)


Migrating to a new server

Ok, Dunc-Tanc (DT) is being discussed everywhere like here, here or here.

The reason for discussion is the amount of US-$ 6000 (or EUR 4800, as Marc Haber calculated).
For many of the readers that is really, really much money for just a month. Maybe it's even close to a yearly income in some other countries.

Many calculations and posts are dealing with living costs of Steve, costs of bureau rent, taxes, etc... but how about this calculation:

  • Many DDs are unemployed or studying.
  • An unemployed person (>1 year unemployed) gets so-called HartzIV in Germany, which is about 345.- EUR per month. Unemployed people are allowed to earn additional ca. 160.- EUR per month.
  • That will enable 30 unemployed Debian Maintainers, Developers or Users to earn some money for their living for a month. 30 people could be paid to do a BSP for a whole month.

Now, who will get more work done within a month, when you have to give away 6000 US-$? 1 person or 30 persons?
Recalculate this with your average income of your country. Maybe Joachim Breitner can tell you, how much work can be done in Ghana for 6000 US-$ and how many people can make a living out of this?

So, you might guess it: I'm not very pleased about that high amount of money that is being spent for a single person. I think the money could've spent more efficiently.



Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer