Re: unexpected NMUs || buildd queue
Wouter Verhelst <wouter@grep.be> writes:
> On Sun, Jul 18, 2004 at 09:32:39AM +0200, Goswin von Brederlow wrote:
>> Wouter Verhelst <wouter@grep.be> writes:
>> Avoiding a build for gnome or kde packages or building them in the
>> right order with proper delays for dinstall runs inbetween will save
>> hours of wasted build time for m68k (less for others), save a huge
>> delay till the admin comes around and saves the admins time. For
>> several archs the admin time seems to be the limiting factor (not for
>> m68k, true).
>
> That's their own fault. Look up "AddPkg" in the buildd source some day;
> it creates a packages repository in ~buildd which allows freshly built
> packages to be installed if they're needed for future builds, even
> before they've gone through dinstall. On m68k we don't use that anymore
> because it's a waste of disk space for little gain, but on an
> architecture with one or only a few buildd machines...
Is that the only reason? I thought there were others, like avoiding to
build against packages that are broken and will be failed by the admin.
>> >> Even creating the chroot from scratch with cdebootstrap is a matter of
>> >> one to a few minutes nowadays.
>> >
>> > Not bothering to clean the chroot takes no time at all; and experience
>> > tells me that buildd is fairly capable at maintaining a chroot which,
>> > although not perfectly clean and up-to-date, can still be used to build
>> > packages in.
In the short time I had it running I had a few cases of it
breaking. The 'you need to run apt-get -f install' message when it
removed X wile Y Depends X and removing Y then failed (or something to
that effect).
>> > In fact, in the three years that I've been a buildd maintainer now, I
>> > can remember only a handful of occasions where the buildd chroot had
>> > become so badly broken that I had to intervene before buildd would start
>> > to build again, and where the cause was *not* a power or hardware
>> > failure.
>>
>> But what about power failure? Its pretty hard to recover from
>> that. You can't be sure the chroot is in good health and even apt/dpkg
>> can't be truest to tell you,
>
> Actually, that isn't true. The build-essential packages usually remain
> on the system, so you can be quite sure that they'll still be intact.
> If the system was installing or removing packages at the time of the
> power failure, you just need to check up on any packages not
> build-essential.
Fair enough.
> In that case, it'd be nice if you could create a wanna-build compatible
> interface, so that people prefering to keep using buildd (because they
> know it better, if nothing else) can do so.
>
> That doesn't even have to be through ssh; you could create a wrapper
> which is installed on the buildd host and leave $ssh_cmd empty in the
> buildd configuration.
>
> It might even be nice to allow people to run the multibuild client with
> wanna-build, I'd say...
Yes. Definetly something to do. Mapping the states itself is easy
(multibuild has a few more states but they can be mapped) and both
allow for an external interface.
Have you checked the man page url posted here some days ago? Can you
tell me if the manpage documents all the wanna-build command features?
Would be easier than going through the source I think.
MfG
Goswin
Reply to: