[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian needs more buildds. It has offers. They aren't beingaccepted.

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

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

Reply to: