On Thu, Feb 19, 2004 at 01:12:41AM +0100, Ingo Juergensmann wrote: > On Wed, Feb 18, 2004 at 05:54:30PM -0500, Nathanael Nerode wrote: > > > In re buildds, and in declining order of importance: > > * I'd like a quick, public reply to questions sent to the port mailing lists > > like "Why hasn't qt-x11-free built on mipsel despite being first in the queue > > for weeks?" > > Obviously it was in weak-no-auto-build. That's fairly ok when there is no > huge backlog. There is something to be said about it being in weak-no-auto even when there is a huge backlog. qt-x11-free takes a considerable amount of time to be built; I can imagine that Ryan wanted to give priority to building a high quantity of packages being built instead of "just" the big ones. (Of course that doesn't mean there's no problem, only that the motives for not building qt-x11-free are not that hostile or strange) [...] > Of course, when James would accept communication with me directly I could > have told him that very soon, but instead I'm forced to use intermediators > such as Wouter and Adam to communicate anything to James. That's simply not true. [...] > But maybe you meant spice instead of tanda. Indeed, spice was waiting a > whole week for access, which it has now. Although there's is quite some > confusion about the way how to access incoming at all (security reasons). > Funny enough James seems to favour now a method I already offered him last > year in late summer/early autumn because I was concerned about a certain > security issue. He put my concerns down as being not that important to force > me changing the routing via a static (metered) IP. Actually, this is quite > that thing that is now the wanted behaviour, at least for ssh connections, > not for http traffic. There's nothing funny about that. Before the compromise -when ftp-master.d.o was still not restricted- there was no point in trying to close down SSH access, as there were a thousand developers that had shell access to that machine. Closing down a simple one-command SSH access, and/or HTTP access, from buildd machines in such a situation is pointless; it's far easier for an attacker to compromise a Debian Developer's machine than to try to break into an autobuilder machine, which is generally watched upon much closer than a random developer's machine. In the mean time, however, that situation has changed. It is now no longer the case that an attacker has the personal machines of over a thousand developers to choose from; if someone wants to break into ftp-master.d.o, he either has to break into the personal machines of a handful developers (ftp-masters, release managers, and debian-admin folks), or into one of the buildd machines. Since most of those buildd machines are generally known and advertised (through <http://db.debian.org/> if nothing else, but also through your <http://www.buildd.net/>), it is now a lot more sensible and important to implement access restrictions to ftp-master.d.o as much as is reasonably possible. Which is what James is trying to do. Personally, I can only support him in that. [...] > > * I'd like to see 'building' packages which failed to build > > requeued/dep-waited/failed every two weeks (or more often, of course) > > Uh? You mean a list of now-building packages that were broken two weeks ago? > Something like a diff for failed/dep-wait list with building/needs-build? Doesn't matter. Nathanael, the buildd system is thought out a lot better than you seem to assume. Any state change from "building" to some other state *always* involves a human decision (the others can be automated). See http://people.debian.org/~wouter/wanna-build-states for the full story, or http://people.d.o/~wouter/wanna-build.png for a flowchart of the possible states. The point of the "failed" state is to mark packages that are /buggy/, and of which a rebuild is /pointless/ until "something" (the package itself, usually) is fixed. The point of the "dep-wait" state is exactly to mark a package that cannot be built until some build-dependency is available, as waiting on that build-dependency. While we can build such packages after a given, fixed, period of time, there's no point in trying that until the build-dependency is available, is there? [...] -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org "Stop breathing down my neck." "My breathing is merely a simulation." "So is my neck, stop it anyway!" -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.
Attachment:
signature.asc
Description: Digital signature