Re: Debian needs more buildds. It has offers. They aren't beingaccepted.
Wouter Verhelst <wouter@grep.be> writes:
> 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.
Only a few hours and less than the various mozilla packages not
excluded. The list was to random to show some deeper thought like
prefering the small packages.
> (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)
The only thing hostile is not answering to the question why it wasn't build.
> [...]
> > 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.
That he could have told him or that he has to use intermediators?
> [...]
> > 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.
Why not move wanna-build off ftp-master then? All it needs is the
quinn-diff output for accepted/autobuild and the main archive and
thats easily transfered through a strictly controled ssh connect, by
mail, via http or any number of other ways.
> [...]
> > > * 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?
He just ment that the human decision to change state should be made in
that time. Its unnaceptable to let packages hang as "building" for
weeks when the build log clearly indicates a trivial Dep-Wait.
If there is a bigger reason for it that should be indicated somewhere
so people don't start to wonder. A red light on www.buildd.net with a
"hardware breakdown" comment would prevent any informed person from
screaming about his package not getting build.
> [...]
MfG
Goswin
Reply to: