Forums : Technical Issue Help

Dear Open Hub Users,

We’re excited to announce that we will be moving the Open Hub Forum to Beginning immediately, users can head over, register, get technical help and discuss issue pertinent to the Open Hub. Registered users can also subscribe to Open Hub announcements here.

On May 1, 2020, we will be freezing and users will not be able to create new discussions. If you have any questions and concerns, please email us at

Projects not updating

The following project downloads have failed or partially failed 2 months ago and have not been updated since: abuse, libcaca, libpipi, monsterz, neercs, toilet.

Sam Hocevar almost 13 years ago

Please add project equalizer to this list.

Stefan Eilemann almost 13 years ago

Why is it that some of my projects
have been marked as failing for 3
months and not retried (mirbsd, for
example)? Also, in mksh, some of the
enlistments are marked as broken too
even though, for the gentoo one, I
know it worked two weeks ago. (The
ones on ds9.midnightbsd have been
fixed ~2-3 days ago only, though.)

The retry algorithms seem to be un-
reliable. There should be a button
“retry this enlistment” somewhere.
Maybe for project managers only.

mirabilos almost 13 years ago

It depends on the errors encountered usually; only known errors will be retried at all, and even then it'll wait longer and longer between retries, eventually giving up after a week or so I think.

James Ross almost 13 years ago


These projects all failed because the Subversion server at had become unresponsive. Calls to svn info would time out after several hours.

Worse, and somewhat unluckily, when we did get responses, it appears that a couple of the Subversion URLs had been deleted, so it appeared that the entire server may have been removed. These URLs no longer exist:


I removed both of these URLs from the abuse project.

We are now running updates for the other projects, and some of them have already completed. I'll keep an eye on them today.


Robin Luckey almost 13 years ago


Project equalizer failed to update because someone checked a .svn directory into the source control system at revision 4139, which makes it impossible for us now to check out revision 4139.

As a workaround, we have an alternate Subversion downloader we can use that does not require checkout. I have started a new, clean download of the Subversion history using this alternate downloader. If this succeeds, great. If not, then we will probably be unable to process this repository unless the errant .svn directory is cleaned up from the repository history.


Robin Luckey almost 13 years ago


James is correct. Ohloh only retries in the cases where the error messages are known to be OK for retry. This is a decision motivated by safety. Ohloh operations can be very long and very resource-intensive, both on our end and for the source control server. We try very hard to be "good citizens" and to not heap abuse on servers.

None of the errors reported in this thread could have been corrected through simple retries. In one case, repositories had been deleted; in another, a repository had corrupt data.

In the MirOS case, our servers did indeed retry 4 times over a period of about 2 weeks before giving up. The MirOS project is very large, the CVS servers are very slow, and CVS is not a good match for the kind of operations Ohloh is attempting. We very often time out or are disconnected from the CVS servers. There are only so many hours of server time we can dedicate to any particular project. I've reset the retry counters and rescheduled the MirOS updates, but I am not confident they will finish in a timely manner.

Robin Luckey almost 13 years ago

Hi Robin,

You are right, we've had an issue with an accidently-checked in .svn. This has been removed from the repository, but I could not figure out how to purge it from the history.

Is there a way to skip revisions which fail to check out?

Stefan Eilemann almost 13 years ago

Hi Stefan,

No, Ohloh does not have the ability to skip revisions. However, it does appear that the new download worked, and the updated report is ready. We shouldn't have any more trouble.


Robin Luckey almost 13 years ago

Hi Robin,

thanks. Indeed, they are huge, and the way
you use CVS is slow. Maybe I’ll split the
huge part of them down, like NetBSD did.

Anyway, the p/mirbsd seems to be working
now (the huge ones), please re-run these
for p/mksh as well (both Gentoo and Mid-
nightBSD repos work for me). There are
others failing for quite some time, but
you probably have scripts to track them

mirabilos almost 13 years ago

Uhm, right now it’s trying to sync
the two fattest repos I have…

… you might want to do the follo-
wing things:

• set it so that managers can say
“this enlistment is historic,
there will be no more commits in
it, so don’t try to upgrade it”
(maybe with an override “upgrade
it now” in case something changed,
like I suggested for retrying the
failed ones)

• set (probably as site admin, and
manually) limits for concurrent
repo connections (appears to be
2 though, which sounds about ok)

mirabilos almost 13 years ago

Hi Thorsten,

I've rescheduled the /p/mksh jobs and a couple of other jobs that failed trying to reach the server.

The particular error that caused us to stop retrying these jobs has been added to our error white list, so these failures shouldn't be permanent in the future.

I agree with your recommendations -- we've actually wanted to implement features like these for a while now. I can't promise when we'll get the features implemented, but we are on the same page there.


Robin Luckey almost 13 years ago

Thanks for the reply, appreciated,
and I fully understand not being
able to gain features in some time…
I have the same problems ;-)

mirabilos almost 13 years ago