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...
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! :-)
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... ;)
It is known among debian developers that the Debian System
Administration Team (aka DSA or email@example.com) is not
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.
Next, Anthony Towns replies: So apparently this complaint was immediately followed up by setting up an emulated autobuilder not synced in with the regular buildd.debian.org stuff . 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
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.
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...
In a different thread Steve Langasek writes: Now, many people will probably object, pointing out that
$firstname.lastname@example.org 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 email@example.com and other buildd admins didn't seem to read the port MLs as well. So, when the buildd admins can't be reached via $firstname.lastname@example.org, 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.
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. :-(