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

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

On Sun, Feb 15, 2004 at 10:24:09PM +0100, Goswin von Brederlow wrote:
> Wouter Verhelst <wouter@grep.be> writes:
> > Op za 14-02-2004, om 11:33 schreef Goswin von Brederlow:
> > > He is partly right complaining about failing packages that fail due to
> > > an RC bug in the toolchain (or not yet compiled packags). Its partly a
> > > problem in the buildd/wanna-build implementation and the buildd admins
> > > job to keep an eye on. In the case of build-essential packages a
> > > Dep-Wait will also not work right since sbuild does not update
> > > installed packages unless the source needs it.
> > 
> > You're completely missing the ball here. Build-depends and
> > build-conflicts have been invented exactly to fight this kind of thing.
> > If you have a problem with some part of the toolchain, adding the right
> > build-depends and/or build-conflicts is the right thing to do; when
> > sbuild (buildd's building component) sees that the build-depends and/or
> > build-conflicts are not satisfied by packages that are installed in the
> > chroot right now, it will generally do the right thing, i.e., update the
> > package in question.
> If it happens for all archs sure.

No, if it happened already it's too late. By the time Christopher
uploaded those KDE packages, he *knew* they would fail with a certain
versions of the toolchain. You know, that's what we invented
build-depends/conflicts for.

> But I would hate anyone who uploads a new mozilla or galeon because
> one unstable version of gcc on say alpha has an RC bug preventing it
> from getting build.

Yeah, me too, which is why I didn't suggest it.

> So lets clear this up so I don't do something wrong if I ever becaome
> DD and take over the buildd admin job. Last time I saw this hapening
> here I asked on #debian-devel because I wasn't sure and got told (by
> some maintainers, not buildd admins) that such arch special temporary
> problems should not be added to the Build-Depends/Conflicts. Was that
> wrong?

No, it wasn't. But you're also right that there's no reason to do a new
upload just for a single bad toolchain version that hit you.

If you know, before uploading your package, that there's a certain
compiler (or some other part of your build-dependencies) that *will*
fail to build your package correctly, then you add that to your

> Or would a patch be added to source-dependencies-unstable for
> the duration of the build for that?

No, those are add-only IIUC.

> > Again, that's superfluous. This is what "failed" and the "Should I
> > build?" mails are for. Every time I get a "Should I build?" mail, I
> > check why the package failed previously, and if the message listed in
> > wanna-build contains a bug number, I'll check whether that bug is still
> > open. Of course, that only works on machines that do have access to
> > wanna-build, which is probably why you didn't see those mails yet...
> > 
> > There's no real reason to implement your suggestion...
> The waiting for a bug would be to get packages rebuild, which is what
> was the problem in the mail. You only get the "Should I build?" mail
> on the next upload. If the bug is against another package there is no
> reason for another upload, so you won't get the mail.

Ah, that's what you mean; I thought you meant waiting on the closure of
a bug in the package being built. I'm not sure what you're suggesting is
useful then, but don't let that stop you :)

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: