darcs mirror (was: OpenBSD users here?)
kili at outback.escape.de
Sat Sep 6 13:06:21 EDT 2008
Changing the subject, to give this thread a little more positive
On Fri, Sep 05, 2008 at 12:25:04PM +0100, Simon Peyton-Jones wrote:
> Concerning the repo, as you now know something was definitely
> broken and has now been fixed. In general, if the repo server
> isn't working properly, we want to know about it. It's currently
> supported as a generous service by Galois. At some point, Haskell
> may become sufficiently successful that they can't sustain that,
> but my assumption at the moment is that problems are accidental
> rather than deliberate throttling.
Well, it partially looked like throttling, or even like tarpitting,
but I guess there are probably just some weird networking problems
going on. I looked with tcpdump on the traffic, and galois every
then and now stops talking. Sometimes there are just a few minutes
of silence, sometimes the silence lasts for hours, and then I've
just to drop the connection to continue or start over with whatever
I'm doing (get or pull). The longest hang on an established connection
was 11 hours (happend last night, and I only noticed it when I
looked at it this day).
This is the worst case when you're trying to mirror stuff with a
cronjob, because if darcs is just idling around without even running
into a timeout, such a mirror is worth nothing.
I wonder wether it's worth to play a little bit with CURLOPT_TIMEOUT
and maybe other connection options to curl, so darcs would be able
to recover/retry or at least error out when a connection hangs
badly. Would this be an option?
For my experimental mirror: please give it a try, it's at
http://darcs.volkswurst.de, and I'd like to see some people getting
and/or pulling from it (feel free to darcs get --complete, the
server should be able to handle it). But note that nofib is still
missing (because of the mentioned hanging connections).
> Concerning portability, it's not true to say that we (GHC HQ now)
> don't care about portability. We may give that impression, but
> if we do it's accidental. In general, we focus most attention
> on the things that seem to be causing our users most trouble. I
> don't think I'd absorbed that lots of people, or even you, have
> been frustrated about HC bootstrapping over an extended period.
> Perhaps you have been too polite and quiet!
My biggest mistake was to work for too long on ghc-6.8 instead of
switching to -HEAD (and just skip 6.8. for the OpenBSD ports). And
when I tried to switch to -HEAD, I ran into the networking problems.
> In any case, I'm hoping that John Dias's current work on the back
> end will mean that GHC becomes a cross-compiler, which will make
> portability a lot easier. In the short term, if you or others
> are keen on making HC bootstrapping work properly again, please
> do say so and why, so that we can factor it into our plans. (Simon
> M is away, so I don't know what he expects for GHC 6.10.)
I don't have the time now to make it happen for GHC 6.10, and IIRC
the plan was to delay the necessary changes to Cabal or cabal-bin
after the release.
Developer: Benutzer, der mit Dateien arbeitet.
-- Synergy/CM Glossar
More information about the Cvs-ghc