New users trying to fetch the repository always results in an error:
$ darcs -v
2.4.4 (release)
$ darcs get --lazy http://code.haskell.org/gentoo/gentoo-haskell --no-cache
This is the gentoo-haskell darcs overlay.
**********************
darcs: bug at src/URL.hs:246 compiled May 30 2010 13:33:24                   
Another possible bug in URL.waitNextUrl:  curl_multi_perform() - no running handles
See http://wiki.darcs.net/BugTracker/Reporting for help on bug reporting.

I kill it with Ctrl+C. Sometimes you get this error after 10 pathes, sometimes after 1500. It seems random.

So, let's run 'darcs check' on the remote site to make sure the repo is intact:
$ darcs -v
2.4.4 (release)
$ darcs show repo                   
          Type: darcs
        Format: hashed
          Root: /srv/code/gentoo/gentoo-haskell
      Pristine: HashedPristine
         Cache: thisrepo:/srv/code/gentoo/gentoo-haskell, cache:/home/kolmodin/.darcs/cache
   Num Patches: 3551

$ darcs check
The repository is consistent!
Missing items in index!
[snip, long list of very changes]
Hash mismatch(es)!
[snip, long list of recent changes]
Bad index.

The patches missing in the index, and with hash mismatches are all very recent. It might be since we upgraded darcs on the remote site to 2.4.1.

So, I'd like to 'darcs repair'. I make a copy and do the changes there:

$ cd ~/public_html
$ cp -r /srv/code/gentoo/gentoo-haskell g-h
$ cd g-h/
$ darcs repair
The repository is already consistent, no changes made.                          
Missing items in index!
[snip]
Hash mismatch(es)!
[snip]
Bad index discarded.

Trying to fetch again from repaired copy:

$ darcs get --lazy http://code.haskell.org/~kolmodin/g-h --no-cache
This is the gentoo-haskell darcs overlay.
**********************
Another possible bug in URL.waitNextUrl:  curl_multi_perform() - no running handles
See http://wiki.darcs.net/BugTracker/Reporting for help on bug reporting.
Copying pristine 890 done, 147 queued. mmap-0.5.4.ebuild

And it hangs again.

So, I make a copy on the remote site using darcs itself:

$ darcs get g-h/ g-h2 --no-cache
This is the gentoo-haskell darcs overlay.
**********************
Copying patches, to get lazy repository hit ctrl-C...              
Finished getting.

That worked out well, let's check it:

$ cd g-h2
$ darcs check
The repository is consistent!

Now, again on my local machine, lets try fetching a copy from the g-h2 repo:
$ darcs get --lazy http://code.haskell.org/~kolmodin/g-h2 --no-cache
Finished getting.

Do you know what's up?
'darcs repair' didn't fix the issue, but 'darcs get' did?

Hi Lennart,

I haven't had a chance to look into this in more detail yet, but I will
say that at least part of the issue has been resolved, see issue1770 for
the curl multi_perform errors.

It's possible that you just have an incomplete repo due to the curl
problem above, in which case darcs check would reasonably fail.

I'm going to split this bug into two for our tracking purposes.  

The first issue reported here is just a duplicate of issue1770 (the curl
multi_perform_thing).  

See issue1878 for the latter issue (missing items in index).  Closing
this issue now.  Thanks for the report!

Applying this patch from issue1770

Fri Apr 16 00:47:39 CEST 2010  Dmitry Kurochkin <dmitry.kurochkin@gmail.com>
  * Fix hscurl.c when URL is downloaded during the first call to curl_multi_perform.
  Turns out that the first call to curl_multi_perform() can fetch the URL or
  result in error. I can easily reproduce this using HTTP server on localhost.
  This means that situation when running_handles is zero is valid, so remove the
  error and handle it correctly.

to darcs-2.4.4 applies nicely and solves the issue.

I've made a version bump in Gentoo, darcs-2.4.4-r1, which includes this patch.