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

Re: vtk / m68k



Ingo Jürgensmann dixit:

> On 2013-12-06 10:59, Christian T. Steigies wrote:
>>> We should increase the timeout on all buildds, I think...

Not that vtk failed due to the timeout, but a segfault.

>> kullervo just failed to build kate... while creating the kate-dbg package.
>> All the other debs have already been created. Three days wasted, or should I
>> upload the debs without the dbg package?

Hm, not really.

Anyway, I increased my timeout from 600 to 1800, too.
The slower ones should maybe use even more.

> *.deb. Funny enough I think all those failed at the *-dbg.deb as well. Can this
> be caused by xz as compression tool?

xz needs just under 186 MiB of RAM for compressing at the default level
but quite some CPU of course. That’s not an indication it’s bad, I think
even m68k can work with xz.

>> Can somebody remind me how to increase the timeout on a per package base?

Meh, just crank it globally.

>> Or how to tell the build which packages I do not want him to build?
>
> Back then we used a unified list that were downloaded from Stephens webspace
> and used by some @includes in the config. I don't know whether this @include
> still works, but when it does we should use that approach again instead of
> maintaining on each buildd such a list.

That would certainly be welcome. I’m putting packages into Not-For-Us
but then _no_ buildd will pick them up; we have cases where packages
can only reasonably be built on ARAnyM (huge, etc.) or cannot be built
on ARAnyM at all (that thing with L2 caches recently), so we can still
use per-buildd overrides then.

bye,
//mirabilos
-- 
„Also irgendwie hast du IMMER recht. Hier zuckelte gerade ein Triebwagen mit
der Aufschrift "Ostdeutsche Eisenbahn" durch Wuppertal. Ich glaubs machmal
nicht…“						-- Natureshadow, per SMS
„Hilf mir mal grad beim Denken“			-- Natureshadow, IRL, 2x


Reply to: