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

Re: The archive now supports xz compression

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

Reply to: