[Buildd-tools-devel] sbuild --auto-give-back / sbuild<>wanna-build interaction

Florian Lohoff flo at rfc822.org
Tue Jan 8 17:28:01 UTC 2008


On Tue, Jan 08, 2008 at 12:24:30PM +0100, Michael Banck wrote:
> On Tue, Jan 08, 2008 at 11:38:44AM +0100, Florian Lohoff wrote:
> > is there a reason why sbuild has a "wanna-build" dependency? As i
> > understand sbuild in case its been run from buildd gives back packages 
> > when they fail building due to problems of the build environment.
> 
> That is usually when sbuild doesn't even get to installing the
> build-depends, or unpacking the source package fails, IME.
>

I was just asking what the point is to split the error handling between 
sbuild and buildd. On one end buildd takes a package from wanna-build
and sbuild hands them back if something goes wrong. Coming from the KISS
end of life i'd rather make it simple by letting sbuild just deal with
building and instead of trying error handling in wanna-build return
sensible error codes that buildd knows enough to give back the package. 
This would fail in case sbuild gets handed more than one package 
as then the error code would be useless. This is why i ask on the
purpose of the package batching to sbuild.

> > I find this overly complicated to rebuild wanna-build invocations from
> > multiple pieces of software etc. I found multiple problems with local
> > wanna-builds in sbuild and buildd and fixed at least the buildd part.
> > 
> > My guess would be that a return code from sbuild wouldn't work because
> > buildd hands out multiple packages at once to sbuild? Is this a real
> > performance win on any platform? Compared to build time this shouldnt
> > matter should it?
> 
> At least in the distant past, all buildds hammering buildd.debian.org
> via SSH was a serious performance issue, so taking the packages to build
> by batch was sensible.  These days, the buildds re-use a SSH connection
> so this might not be an issue anymore.

I rather meant the buildd -> sbuild package batching not the one buildd
<-> wanna-build. This can be limited by max_build in the config file
but is the sbuild overhead really that huge that it makes sense?

> Not sure whether there is any other rationale for that.

Not hammering at wanna-build makes sense. I was too wondering
why listing a wanna-build database with 3 packages takes ages
on an R4k 250Mhz I2. 

> BTW, this list is very probably not read by the wanna-build/buildd
> author, it's for the end-user version of sbuild in unstable (though
> there is some effort underway to provide wanna-build/buildd as well)

I was sending simple patches to Roger lately for various aspects of
wanna-build/buildd/sbuild and he told me to subscribe here.

Making the whole autobuilding infrastructure usable for everyone
with little effort would be a huge win. I started building
the trunk and sid kernels in a loop on mips for example.
I have more machines of different architectures i could simple
let heat air or do something more sensible.

Flo
-- 
Florian Lohoff                  flo at rfc822.org             +49-171-2280134
	Those who would give up a little freedom to get a little 
          security shall soon have neither - Benjamin Franklin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20080108/cc0c6e89/attachment.pgp 


More information about the Buildd-tools-devel mailing list