Re: Debian needs more buildds. It has offers. They aren't being accepted.
Wouter Verhelst <wouter@grep.be> writes:
> 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.
He is to blame then, agreed. If one is aware of it before an upload it
should allways be added. But lets consider the case of the buildd
admin finding a "failed" mail and sees its another packages bug.
> > 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
> build-conflicts.
So what, from the buildd admins side, should be done in the case of
one bug in FOO failing BLA for just one arch?
1. Report a bug and force the maintainer to upload a fixed version
(causing all archs to rebuild?
2. Dep-Wait BLA on the next version of FOO in the hope it gets fixed?
3. Fail the package and keep track of it and schedule a rebuild when
the problem is solved?
4. Fail the package and let the maintainer decide if he wants to
upload a new source or bother the buildd admin for a rebuild later?
> > Or would a patch be added to source-dependencies-unstable for
> > the duration of the build for that?
>
> No, those are add-only IIUC.
They are never cleaned up when stuff gets obsolete?
-rw-rw-r-- 1 buildd buildd 278K Jan 26 23:58 /etc/source-dependencies-unstable
No wonder its so big. Looking through it I see:
*XFREE-LIBC5-PATCH:
patchcond {
[ "$(dpkg --print-architecture)" = "m68k" ]
}
patch {
--- xfree86-1-3.3.6/debian/control.orig Sun Jul 9 19:09:20 2000
+++ xfree86-1-3.3.6/debian/control Sun Jul 9 19:16:55 2000
Do we realy need that anymore? :)
> [...]
> > > 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 :)
Its adding to much cross services information and depends as discussed
on irc a while back, and nobody offers a patch for it. If such a
feature were to be added it would need several month testing first and
hopefully not on m68k where we don't have build time surpluses for
experiments.
MfG
Goswin
Reply to: