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

Re: Timeouts


Am Montag, den 08.03.2010, 22:56 +0100 schrieb Marc 'HE' Brockschmidt:
> Joachim Breitner <nomeata@debian.org> writes:
> > Am Montag, den 08.03.2010, 22:30 +0100 schrieb Marc 'HE' Brockschmidt:
> >> This might be a solution, yes, though I would prefer not to do
> >> this. You've managed to get highlighting-kate's build times down, making
> >> it build everywhere but on armel (where it got tried on a sloooow
> >> buildd, let's see if this gets better on one of the faster boxes). We
> >> have similar problem with agda, could you have a look at that?
> > We also have the problem with haskell-src-exts (a build dependency of
> > hlint), where no such easy solution is available. This might not affect
> > the transition, as it is “only” a build dependency and haskell-src-exts
> > is not in testing.
> Hum, well, it would be helpful if we could rebuild what is in testing
> with packages from testing. We shouldn't abuse britney's bugs too
> much.

I agree. In principle, I’m all for enforcing build-dependencies at
upgrade time... but in practice, sometimes, it helps :-)

> Is there an option to get ghc6 to leave out optimizations that eat
> up a lot of memory? It just feels wrong to see something not build on
> s390 because of missing resources :-)

I find an architecture that only allows 2GB of virtual memory for one
process (including mmap’ed files and what not) not the ideal of a strong
architecture... but of course it is in comparison to armel etc.

In the case of agda, I don’t think there is a lot we can do without
reimplementing part of the build system. I asked upstream about ghc’s
memory consumption, and there are no easy fixes. See thread
http://lists.debian.org/debian-haskell/2010/03/msg00055.html for more

Note that leaving out optimizations could make the resulting binary
close to unusable (in the worst case), so I’m not sure if we make our
users a service by providing lower qualities packages just to look good
on the arch coverage graph. Before we do that, I’d be in favor for
dropping the support for these arches.

> > There is the unreproducible bug
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554174 which needs to
> > be closed or tagged squeeze-ignore (which you can probably do). Other
> > than that, it looks good!
> I've downgraded it to important. The semantics of *-ignore is a bit
> different, indicating that the bug fix is needed, but can be done at a
> later point. That's not the issue here, where we don't even know if
> there's an actual bug in the package.

good, thanks for the clarification.

BTW, on the page
haskell-mtl is listed, although it has built on all arches. Is it just
that testing.pl does not handle synchronous transitions very well or
what needs to be done to reduce the list on that page?


Joachim "nomeata" Breitner
Debian Developer
  nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: