Hmmm, I'm not really familiar with newlib and how they are using cvs, but it seems that the newlib cvs module is just an alias for stuff really located elsewhere in the repo. I changed the ... [More] enlistments to point at the two major components (src/newlib and src/libgloss) instead. However, I'll share the following observation. If I run this command, it fails: cvs -z 9 -d :pserver:anoncvs:[email protected]:/cvs/src co -D'1999/05/03 07:29:06Z' -A -d'476' newlib But it I add -N in there, it succeeds: cvs -z 9 -d :pserver:anoncvs:[email protected]:/cvs/src co -D'1999/05/03 07:29:06Z' -AN -d'476' newlib Maybe that's the problem you are hitting as well? Cheers, Peter [Less]

Hmm, on second though, if it is unrecognized source that's the cause of this, it looks like a ohloh problem. I had a second look and the files are shell scripts. They start like this: # This shell ... [More] script emits a C file. -- C -- # It does some substitutions. http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/emultempl/pe.em?rev=1.151&content-type=text/x-cvsweb-markup&cvsroot=src So they are regular sh script, but they are a bit special in that the bulk of them looks a lot like C, maybe that's the problem. Perhaps further problems are caused by the fact that all the C function names have sh variable substitution in them, e.g. static void gld${EMULATIONNAME}beforeparse (void) { ... } So, my main point is that the files are regular shell scripts, and not in some exotic language for some ad hoc preprocessor. [Less]

Hi Robin, Thanks for excellent support! Cheers, Peter

Oh, sorry for not adding a note here as well, but it's the same story as in https://www.ohloh.net/forums/10/topics/3872 Sorry about that and thanks for adding the ticket! Cheers, Peter

It turned out that the person who originally added the ggivnc enlistment added the complete svn repo, and not just the trunk. I have since switch to git, so I changed the enlistment accordingly. Sorry for the noise... Cheers, Peter