Dear Open Hub Users,
We’re excited to announce that we will be moving the Open Hub Forum to
https://community.blackduck.com/s/black-duck-open-hub.
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 https://www.openhub.net/forums and users will not be able to create new discussions. If you have any questions and concerns, please email us at
[email protected]
You can see from the enlistments, that the ohloh codebase is not so up to date:
http://www.ohloh.net/projects/5745/enlistments
However, none of the stats get updated even for what data their is:
http://www.ohloh.net/projects/5745/commits
Not only the new commits aren't shown, but also the really old ones are shown as if they happened in 2007 (a lot of pages after the Levstik commits).
Also, some stats do get updated, as I can see the recent commits in that timeline graph. But since the commits don't get reckognised as shell scripts
(file -b would say ascii; they don't have the shabang), they don't amount to any statistic. There should at least be an Other/Unknown
language category for such cases and/or some good heuristic for determining if files are shell scripts and/or per-enlistment global language definition.
Hi lynxlynxlynx,
Yes, the report has not been updated in quite some time. We had problems with several repositories:
grimoire.git: not responsive after several days; download canceled.
archspecs.git: permission denied; download failed.
test.git: not responsive after several days; download canceled.
I have rescheduled the downloads, and will watch them today.
This is a big project, and I'm not familiar with it. It would be very helpful if you could give an example of a specific commit which seems wrong -- I will gladly investigate why the Ohloh report is incorrect.
Can you point me to an example of a shell script file that Ohloh does not recognize? I will investigate. A simple rule might be to say that any ascii text file with execute permissions should be considered a shell script. Am I crazy, or does that sound reasonable?
Thanks,
Robin
for Source Mage use, executable ascii files would be a very good guess for finding many bash scripts. The grimoire.git would be covered very well. Here, DETAILS is a script:
http://www.ohloh.net/projects/5745/contributors/34061/commits/11432886
However for the other significant parts of our codebase, that change wouldn't be enough. Our libraries
, sets of function declarations, are not executable. Example:
http://www.ohloh.net/projects/5745/contributors/34061/commits/11410710
We could fix that on our end by adding shabangs to all the files though, it probably has no side effects.
Wierd dates? See how Schabell's commits all got stuffed in one single point in recent time:
http://www.ohloh.net/projects/5745/contributors/38098
The first one states in the name that it should be from 2002 or atleast 2006 (when the code was bulk-imported into git without previous history). But perhaps this due to a failed update?
Thanks for the quick reply.
Do the stats update only when all the enlistments have been updated succesfully? You can see that games.git was updated nicely when you reran it, but the stats still show only things up to the end of august. That repo was last changed 5 days ago:
http://scmweb.sourcemage.org/
about the two failing enlistments. I tried to manually clone both those repos and all went fine, archspecs.git and grimoire.git downloaded nicely. The first one is very small and should complete almost instantly, while the other one is (on the contrary) quite big and takes some time (with one big pause in between). Maybe you have a too short timeout when checking if the process is alive or something similar?
Hi lynxlynxlynx,
Yes, the report will not update while there are outstanding failures.
I'll make another attempt at downloading these today.
With archspecs.git, it was a permissions problem, not a time issue.
With grimoire.git, I let the download run for 8 hours, and it did not complete. When you say takes some time
and is quite big
, exactly how long and how big do you mean? If it's going to take a couple of days, that's OK, we just need to know ahead of time which of the jobs are going to be really big.
Robin
Fresh timings:
$ time git clone http://scry.dtdm.net/codex/archspecs.git
...
real 0m4.102s
user 0m0.107s
sys 0m0.090s
$ time git clone http://scry.dtdm.net/codex/grimoire.git
...
real 15m13.092s
user 0m32.862s
sys 0m11.222s
I checked and both repos are up-to-date. I forgot to check the size, a rough estimate is 131M. Nothing that big.
try hard reseting the two enlistments, maybe something changed since they were added. As a user I can't do a complete reset.
This forum has a bad bug btw, ate my post when I was required to log in. >:(
Hmm, the grimoire.git respository is still causing us trouble, and I can't find the cause. When we attempt to clone the repository, the machine appears to hang forever.
I've tried cloning on my development box, and have had no trouble.
I'll give it another try.
hah, almost there! The reinit helped for the two previous offenders, but now games.git failed its import.
I've cleaned up the broken job and restarted the import. Could it be that after 3 weeks this job will finally finish?!?
looking good so far. :) And it's more like 4 months than 3 weeks if you consider the whole project.
Cool, that did it. :)
A simple rule might be to say that any ascii text file with execute permissions should be considered a shell script. Am I crazy, or does that sound reasonable?
<-- only this issue remains
The project was last updated on 14th of January. :/ Ok, many updates happened since, but there was always one or the other failing, so the stats are still old (currently grimoire.git is the failing one).
It would help if any update triggered a stat refresh, at least while the updater has these problems.
We have real problems with grimoire.git -- when we try to git-pull this repository, we often get stuck for several days with no forward progress, and I usually end up manually killing the git-pull process.
I'll reschedule the grimoire and we'll see what happens.
Is there anything unusual in this repository? Large binaries, or millions of objects? Are we the only people who have trouble with this?
The repository doesn't contain any big objects (the biggest is 228K), but there is plenty of small files. Including the git metadata in my clone, there's around 37000 of them, 34500 without.
I don't know of anyone with any problems here. How old is your git? Another test clone and pull went just fine here.
Something broke again and the project hasn't been updated in two weeks.
It looks like the source control server went down briefly about 3 days ago, long enough for all of our downloads to fail.
I've restarted all the jobs, and it looks like things are moving again.
The biggest repo didn't succeed though. :/
Hi lynx,
I'm not quite sure what to do about this. The grimoire repository simply refuses to pull for us -- after 24 hours, the job gets killed, with no progress.
Curiously, a clone operation goes relatively quickly, and doesn't give any hint of future trouble.
However, pulling the latest changes into an existing clone seems basically impossible for us. We see zero load on our end, so I'm assuming there's some kind of hold-up on the server end.
This is 100% consistent for us, and always has been. The only way to get an update is to throw away our repository and pull a new clone, which is very inefficient for us.
Surely we can't be the only people with this problem -- any clues?
I'm not sure if it is 100% consistent (I think it worked a few times around the end of March), but you probably have more info on that.
I and other users have no problems pulling from it. Can you tell me exactly what you're doing?
I have pulled a number of times from that repo myself in the last few days.
Still no problems with doing a git pull
now and then. I'm really curious what you're throwing at it.
Good news -- I've managed to do a pull into our repository. It was slow, but it worked.
I still don't have any answer as to why this fails for us so often. I will try to keep an eye on it.
In the meantime, we should have a new report for Source Mage sometime today.
it's been another month since the last pulls succeded. grimoire.git is still blocking everything. :/