Wed, 16 Mar 2005
Well, admittedly, I haven’t tried reading debian-devel for the past eight hours or so, but there still seems to be a bunch of confusion about the big scary plan to not support all architectures equally. Anyway some people seemed to find some of my followups useful, so continuing the “Today’s list posts”, faux-deli.cio.us-style, Clayton’s blogging I’ve been doing, here are some followups you might want to peruse.
So, this mail gives some details about what actually went on at the meeting. Not a lot, but some background’s better than none. This one is the “babies” post that might be useful to porter’s wondering how their architecture should fit into the proposed system. These two posts might be helpful to porters who want to think about how they might operate if their architecture doesn’t fit on the release track.
Here's some more links from posts after I caught up with -devel a bit more. This one has some more on how the process might work for becoming a release architecture; and this one includes some elaboration on the N+1 rule.
Mon, 26 Apr 2004
…news at 11.
Welcome to the 11 O'clock news. Our lead story tonight: Debian Release Manager doesn't know how to spell "effect".
Sat, 17 Apr 2004
Firmware, the GPL and Debian, oh my
Norbert Tretkowski’s unhappy, apparently:
Most of our users don’t care if this firmware is loaded by the Linux kernel, or by the hardware itself. They don’t care if this firmware is part of the Linux kernel, or if it’s sitting on-board on that hardware. It makes no difference, they just want to use their fucking hardware. I agree with Marco, this whole discussion is just ridiculous.
[…] I thought this issue will be fixed for a while with the next release, but looks like I was wrong…
Marco d’Itri seems to be unhappy too. I’m not really sure why; when you ask a question, you really should be prepared to accept whatever answer you get, as far as I can see. Follow that link if you don’t know what any of this is about.
In any event, it’s true that most of our users don’t care whether their firmware’s free or not; I know I certainly don’t. And it’s also true that most of our users care about having working drivers for the latest video and network cards, thanks to a recent purchase, I happen to share that concern. Unfortunately, the other thing our users care about, and that we care about ourselves, is respecting upstream author’s wishes, sometimes to a greater extent than even they care about. We’ve done this in the past by refusing to distribute KDE binaries, as the KDE license, that is, the GPL, was considered to forbid distribution of binaries that link with non-GPL-compatible libraries, which Qt was for quite some time. We’re doing the same thing with GPLed apps that want to use OpenSSL.
It’s highly unlikely that anyone’s going to sue anyone over any of these things: the free software community doesn’t care much for lawsuits in the first place, can often not afford them in the second place, and generally shares goals that are better achieved by putting up with the annoyance instead of suing.
On the other hand, that means that if we want to ensure that things like the GPL get taken seriously, we have to find some other way of making sure that happens than lawsuits and threats. Debian’s policy has long been to have a serious look for problems, and once they’ve been found, and thought about for a while, to put up with the inevitable pain that results from making a stand, and getting it solved.
Norbert suggests as a solution:
I think it’s time to activate nonfree.org to provide non-castrated kernel-images, an installer which supports the same hardware like the Linux kernel itself does, and other software which is affected.
We’ve just had a vote that says we’re going to keep distributing non-free software ourselves; and I thought I’d made it pretty clear that firmware wouldn’t need to go into non-free for sarge. That leaves only one reason to move to a non-Debian site: as an excuse to link non-free drivers into the kernel proper, rather than distributing them separately. That’s not necessary, since there’s an easy API for fixing the firmware problem; and it seems undesirable since it’s either the case that compiling in firmware is a GPL violation and no one should be doing it, or it’s not a GPL violation and there’s no reason for Debian not to be doing it. Setting up a new archive, and having users have to worry about whether they need to get the official installer or an unofficial installer for their hardware isn’t a win, and it’s not even a win compared to the effort required to either fix the problem for good, or to demonstrate that there isn’t a (legal) problem at all.
Hopefully Norbert and his supporters are as willing to spend some time doing some productive kernel and X hacking as they are to debate.
(Homework question: for those folks who think I’m, uh, verbose, consider ways of effectively dealing with issues like this that don’t involve repeated long explanations (ie, like this), that are at least equally effective, and that ideally don’t result in folks calling me arrogant the next day.)
(Oh: and if you’re Australian, sign the petition – thanks to slashdot, we’re a fifth of the way to where we’d like to be. If you’re not Australian, but you know some Aussies make them sign it, or do something similarly useful.)
Gah. Contrary to what DWN implies, nothing in the above is meant to have said that violating the GPL by including firmware in a Linux driver isn't a release critical issue for sarge. I've updated the sarge RC issues page to include a summary of the situation. Maybe it's just too nuanced. :(
Tue, 02 Dec 2003
Long, boring emails ‘r us!
Mon, 03 Nov 2003
Hrm, haven’t made a “release manager” blog post since August. Nice. Fortunately that’s not entirely representative of how slack I’ve been, but it’s not as far off as might be nice. Due to the aforementioned chaos I’ve been almost completely out of the loop for the past few weeks. On the upside, this has given Colin Walters and Steve Langasek a good chance to show off their mad skillz, which they’ve handled masterfully.
Greeting my return was also news that the glibc maintainers had finalised most of their NPTL work, so that was ready to go into unstable (they’d been developing it in experimental). It seems to have been fairly successful; the only major bug that’s shown up was expected (more or less; it’s been closed with the addition of a FAQ entry; but hopefully there’s a patch from Red Hat that’ll work around the problem automatically).
And as well, the KDE folks have decided that it’s all too much work and reorganised themselves. On the upside, KDE’s been having problems – it hasn’t been updated in testing since woody released (which is to say the updates in unstable have never been bug free enough to be put in the hands of users, although the blame for this has to be shared with the toolchain) – and getting some more effort put into it should hopefully help. On the downside, reorganisations tend to mean absolutely nothing happens for a while, and last I asked, the new KDE team seems to be in a quandry about exactly how to setup their CVS archive. And then, of course, there’s the possibility of group tensions (that are hopefully being defused a bit). Oh well. On the upside, the problems holding KDE out of testing at the moment didn’t seem very severe, so I forced it in. Future updates will be blocked pending more glibc updates, so hopefully that’s timely, and gives them some good news while they’re getting their act together.
One of the things that we really need to start doing (and have needed to do for a while now) is some aggressive removals. In aid of that, and thanks to some hax0ring of britney, Colin, Steve and Joey all have the ability to schedule removals from testing on their own. Sweet.
Thu, 21 Aug 2003
Some analysis on release delays, that’s not incredibly empirical or rigorous but seems interesting to me, at any rate.
Wed, 20 Aug 2003
A day or so in, and as well as the pre-announcement addition of LSB compliance, the sarge release criteria have had two additions: python policy (5.q) and some remarks about logrotate (5.j). I wonder how much is too much.
So, I write:
As stronger medicine, we’re going to spend the next few weeks – in particular, the period between Saturday 23rd August and Sunday 14th September – […]
On the other hand, as a maintainer, while you’re certainly encouraged to spend the next few days fixing any outstanding issues that you think might be targetted come the 23rd, […]
* August 19th (now) 0-day NMUs (as of the 23rd)
Naturally then, we have someone assuming that that policy has already started. Yet more fuel for Lessig’s fire re: regulation by laws versus regulation by code.
changes_valid = check_changes();
+
+if changes["fingerprint"] in ["D691BB89887AF7A0BAE427FD7A6AFEDA",
+ "86AADB04D2F5CC553A4D940FB1A9DD82DC814B09"]:
+ if not changes["architecture"].has_key("source") or changes["source"] not in string.split("bass bastille bow cal cheops chntpw chrootuid clips clips-doc compartment debrecipes-es dns-browse doc-es-misc dpkg-iasearch e2undel easyfw euro-support farpd firewall-easy fortunes-es gliese honeyd httpush i2e iisemulator jailer ldp-es libnasl libpam-chroot linux-tutorial-es lmbench log-analysis lskb lucas makejail manpages-es manpages-es-extra mozilla-locale-es nat nessus-core nessus-libraries nessus-plugins net-telnet-cisco psad remem roleplaying router-audit-tool sac samhain satan spacechart spellcast spellcast-doc spkproxy starplot tcltutor tiger user-es vrrpd yale"):
+ reject("NMU privileges for jfs revoked until 2003-09-15");
Meh.
Tue, 19 Aug 2003
This will suffice for blogging today.
I’m pondering trying to do more release-manager blogging, not quite sure how or if it’ll work out.