Bekijk de volledige versie : svn fucked up?
Hello!
Today i wanted to compile oscam on my router but it seems to be that subversion cannot do anything...
At first i thought the bug is from the svn repo of oscam, but also my own google project is uncheckoutable...
svn checkout http://java-registry.googlecode.com/svn/trunk/ java-registry-read-only
svn: Can't read directory 'java-registry-read-only': Operation now in progress
The .svn/entries file has always at the end:
incomplete
#some numbers here
So whats up with svn? Why is it not working anymore? Tested on an old oleg firmware and an old koppel with latest svn + dependencies!
[user@router .svn]$ svn --version
svn, version 1.6.6 (r40053)
compiled Oct 22 2009, 19:48:58
I have exactly the same problem with exactly the same version of SVN, though I'm checking another project(libxbee)
Can it be the version of SVN?
AndreyUA
16-01-2010, 18:08
I have the same problem
[admin@DIR-320 root]$ svn --version
svn, version 1.6.6 (r40053)
compiled Oct 22 2009, 19:48:58
Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).
The following repository access (RA) modules are available:
* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
- handles 'http' scheme
- handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
So who is responsible for the ipkg repo?
Is it oleg or is it another developer! I need svn on the router, because i want to compile native on the router (just little projects).
Now i can checkout with a different computer, zip it and load it up via ftp! That sucks...
actually it is in such state over last couple of years. svnserve is working ok, but svn client not.
As to optware guys --- there was a guy from our forum (oleo), but he doesn't appear here for a long time. So I think the best way to contact them is #nslu2-linux IRC freenode.net (ask rwhitby or bzhou)
Another possibility is to create a ticket in their site http://trac.nslu2-linux.org/optware
I know that svn worked!
And not years ago...
I compiled the svn 1.6.6 version, but i got same error!
Now i try 1.6.0 and if this isnt working i will try some 1.5.X versions...
I will upload the ipkg when it works! ;)
Update: Ok, svn 1.6.0 also not working!
I compile it with the apr, apr-util and neon included into the directory (you can download the deps from the subversion page).
Currently i am compiling 1.5.0...
Maybe the bug is in apr, apr-util or neon and not in svn...
it seems that openwrt also has similar problem. KGy moved forward in understanding of it, but probably not to the end:
http://svn.haxx.se/users/archive-2009-03/0641.shtml
Ok, also svn 1.5.0 didnt work!
The problem is the apr package. There is a return, which svn doesnt like and so the operation in progress msg appears.
And the bug is also on some wrt images..
Great the ipkg repo ppl, released the newest version, but this is also not working...
Is noone testing the apps, before the will be released?
Is noone testing the apps, before the will be released?
that's what I've been wondering as well...
And I think just a few apps are tested by the looks of it.
because why bother uploading when it doesn't work?:p
Did somebody on this thread made the move about svn client fault ?
Either
#nslu2-linux IRC freenode.net (ask rwhitby or bzhou)
or ticket in http://trac.nslu2-linux.org/optware
:cool:
By the way, i would appreciate a moderator to put a sticky about the impossibility to use svn, and subsquently native compilation procedure.
I created a thread http://wl500g.info/showthread.php?t=24487 with the same svn client error, in wl500g HW related folder.
It will maybe useful to create a Folder, under AsusForum.NET -- WL500g, that is about Packages, Q&A, compilation common to all Oleg FW.
Because of this lack, today, people are posting these articles in the specific language folders, or HW related, without dependency on HW or language.
This nasty problem is related to apr_read_dir() which assumes that the return value is set upon reaching end of directory stream. apr itself contains a hack for glibc but this workaround fails for uclibc.
There is an easy fix for this. I applied this patch (http://bugs.gentoo.org/attachment.cgi?id=149790&action=view) to readdir_r.c and readdir64_r.c from uclibc, cross-compiled the modified uclibc-opt-0.9.28-13 and SVN is working like it used to.
Thanks a lot, it works, take care if you cross-compile to copy all related libs,
ld-uClibc-0.9.28.so
libc.a
libuClibc-0.9.28.so
or you might get strange side effects
Well could someone of you 2 upload the patched .so file?