Re: Debian needs more buildds. It has offers. They aren't being accepted.
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. 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. Or because a
-dev file of another package was miscompiled and gets a recompile
binary NMU.
Adding a conflict for a version that will be gone forever in a month
and forcing the 10 other arch to rebuild for it is a lot of buildd
time wasted.
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? Or would a patch be added to source-dependencies-unstable for
the duration of the build for that?
> [...]
> > FYI:
> > There is no way to have a package Dep-Wait on a bug, which would be
> > the real solution to the problem. In most cases I think setting a
> > Dep-Wait to the next version of the faulty package is the best
> > solution, the RC bug will probably be fixed by then.
>
> 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.
> > Even more stupid is setting packages with missing Build-Depends to
> > failed instead of Dep-Wait (yes, that still happens).
>
> There are (exceptional) cases where that isn't true (although I can't
> come up with a good example right now).
The obvious example would be
Build-Depends: libc7-dev (>>1.2.3)
where of cause libc6-dev was ment. Or when a library was obsoleted and
removed/replaced. I ment of course not yet ready but existing
Build-Depends and not typos.
MfG
Goswin
Reply to: