You are here

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.


Dunc-Tanc and what can be done with 6000 US-$...

Thomas Pöhnitzsch wrote in a comment to my previous blog entry about replication with PostgreSQL:

we had just finished a big project (based on sarge) which, among other features, required almost the same setup. I have pgcluster-debs for postgresql versions 7.4.7 (the orignal sarge one), 7.4.13 and 8.1.4 available. You can get my patches and I could point you to all the pitfalls we encountered. If however you think your project will be finished here, I have to disappoint you. Pgcluster is still a bit buggy at some ends and may need some debugging and patching until you can ship it. So expect it to become a tough ride at worst. But as I really would like to see pgcluster becomming an official debian project I really would like to assist you as much as I can.

It would be really nice to have pgcluster debs available, but sadly I couldn't reach Thomas by mail. Maybe I just found an outdated email address by search for his name on Google?

Anyway, it would be nice to get in contact with you, Thomas. You could use my Feedback Page to get in contact with me. Other interested people can use that of course as well... ;)


PGCluster debs

Dear Lazyweb...

For a project I need to setup two freeradius server with a PostgreSQL database backend. It's intended that the freeradius server are accessing their database backends locally, i.e. on the same machine. Of course, the two database needs to be in sync.

And now there's a problem: each radius server needs to write to its database, of course, which makes such solutions as slony-1 impossible to use. Otherwise slony-1 works nicely for replication.

Next option is pgcluster which ought to be a master-master replication. Sadly, it seems that there's no Debian package. Don Armstrong tried to make one some time ago, as he told me on IRC, but due to the bad debugging options pgcluster gives, he got stuck somewhere.

So, I ask you, dear Lazyweb, if there are other options left? It's no necessary to have a full master-master replication, but in a master-slave replication writes to the DB should automatically and transparently get redirected and spooled (in case the master is unreachable). (Although is is near master-master replication ;).
Or had anyone else more luck with making PGCluster Debs? Or would like to join forces with Don Armstrong and me to make some?


PostgreSQL and Replication

Or: The Consequences of that awful Vancouver Proposal...

It's no news that I'm no big fan of the Vancouver Proposal. It's aiming into the wrong direction, IMHO, and is not very well thought through. It's basically a master plan of dropping archs.

Anyway, the more m68k is diverting from the other archs after exclusion of testing migration, the more it becomes clear what consequences this has for an arch that is going to be dropped from Debian.

Roman Zippel (a m68k hacker) summarizes some consequences quite nicely in his post to debian-68k and debian-release.

As someone who has recently looked at and fixed many problems, I must say
the release team has done m68k no service by doing this and actually
sabotaged m68k in its ability to catch up again. ...

Roman did really amazing work in tracking down and fixing the toolchain problems m68k had. Many kudos for that!
And it was some kind of obvious that the testing migration exclusion will hurt m68k more than it would help. And it will get worse and worse over time. And still the Vancouver proposal has no plan how to proceed in such a situation.

So the situation is now that m68k gets kicked out without no alternative
in place? Once the current building frenzy calms down, the situation
shouldn't look too bad and if bugs for which fixes exists in the BTS where
actually fixed, m68k could be released with just a few packages less.

True. Instead of dropping a complete arch, it would've been better to just drop some package from that arch from the release. There's a thread on -devel about this about that.

Not releasing m68k could have far worse consequences and should be
absolutely the last resort, e.g. it makes it difficult to upgrade between
stable releases, which might become a real issue, as m68k is likely to
need an ABI change for TLS support.

I doubt that anyone proposing the Vancouver plan was thinking about those kind of problems. Great job. Thank you!

As Wookey stated in the above mentioned thread on debian-devel, m68k just was the first arch and arm will follow most likely.
So, I propose to change Debians website from ''Debian is a free operating system (OS) for your computer.'' to the more appropriate ''Debian is a free operating system (OS) for your i386/amd64 computers.''



Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer