On Sun, Aug 14, 2011 at 09:19:02PM +0200, Lucas Nussbaum wrote: > On 11/08/11 at 19:52 +0000, Philipp Kern wrote: > > On 2011-08-11, Adam Borowski <kilobyte@angband.pl> wrote: > > >> Think of both user systems and the Debian buildds which will waste more > > >> time - an especially bad problem on slower architectures. > > > The gain is especially meaningful for slower architectures, as they tend to > > > have less disk space and slower network links (arm tends to be used in > > > phones). No extra memory is needed -- decompression is not done in parallel > > > with memory-hungry stages of dpkg's work. The decompression, merely 2.5 > > > times slower than with gzip, is a tiny fraction of what dpkg takes. > > It takes a lot longer to compress on slower architectures (i.e. on the > > buildds), though. You could've built a whole package in that time. (Resorting > > to your style of argument.) > Wouldn't it be better to get more buildds for those archs, then? > That would be a totally appropriate use of Debian money... > > Of course, it might require finding more buildd maintainers. But I must > admit that I have no idea what buildd admins spend time on, and how it's > possible to help them. For example, if we tried to have more identical > buildds, instead of just one of each model, would it reduce the workload > of buildd admins significantly? Replying more generally than the problem at hand, given that you did the same. :) The problem on those arches is finding stable buildds. We want boards that support more RAM that they normally do (e.g. on MIPS) or some with SATA disks and good throughput (e.g. on ARM). So you get to use development boards, which you can only get hosted by the company doing them (e.g. for ARM), or which are not stable unless heavily patched (because they normally use a custom kernel by the vendor, e.g. for MIPS). And then there are the boards which were just buggy CPU-wise (older Loongson ones). Andi Barth bought some, but it's unhelpful if you're able to crash them as a normal user due to a pipelining bug. The situation is getting better for those machines we have. DSA would like to run Debian kernels on them, but it seems to be hard. Hence you get to run some kernels with specific patchsets to be as near to a released kernel as possible, with some extensions to let the hardware run stable (or boot at all). Yes, there is a point where you don't want to add more buildds instead of getting faster ones. There's a bunch of locking in the wanna-build database, which used to be much worse, but which is still present in some way. There's the overhead of managing the machines for DSA. But the addition of four(?) additional builders hosted at ARM, which were identical, was great. Especially if they are all set up alike, you can just put up a clusterssh session to handle them. It's just that we now lack a bit of redundancy because all of them are hosted at the same location… Kind regards Philipp Kern
Attachment:
signature.asc
Description: Digital signature