I upgraded devel/apr1 from apr-1.5.1.1.5.3_4 to apr-1.5.1.1.5.4 and then rebuilt devel/subversion. Now, subversion always prints this: > angst(/usr/ports) # svn up > svn: E070008: Can't check path '/usr/ports': Partial results are valid but processing is incomplete Googleing, it sounds like it has to do with apr_stat or apr_file_open returning APR_INCOMPLETE, but I have no idea why. Here's a dump of what I have installed at the moment: > angst(/usr/ports) # pkg info -d subversion > subversion-1.8.10_3: > serf-1.3.7_1 > expat-2.1.0_1 > gettext-0.18.3.1_1 > apr-1.5.1.1.5.4 > sqlite3-3.8.6 > angst(/usr/ports) # pkg info -d apr > apr-1.5.1.1.5.4: > expat-2.1.0_1 > openssl-1.0.1_15 > sqlite3-3.8.6 > gdbm-1.11_2 > db5-5.3.28_2 One thing I did notice that apr1 picked up a dependency to db5; I believe it was db48 previously. This seems to be an apr1 bug with file paths, but maybe the db5 change has affected something.
Maintainers CC'd
Well, when I first found this problem, I tried to make it go away - completely removing apr1 and subversion, and doing a full, clean reinstall, which didn't help anything. When I gave up I installed the previous SVN build from the package server which got me back up and running for the meantime. In that time I updated and rebuilt the base install kernel/world, updating to `10.1-BETA3 FreeBSD 10.1-BETA3 #10 r272180`. Today I tried upgrading subversion back to the new build, and everything worked. I checked svn logs, and neither the devel/apr1 port or the devel/subversion port has had commits. Previously I was running FreeBSD 10.0-STABLE-p9 r269194. So it would seem that some combination of those versions of base, apr1, and subversion all combined to make svn break. I haven't got a clue why. I started to try to debug the apr calls in subversion but quickly got lost in trying to build LLDB, at which point I updated my src and rebuilt, getting to where I am now. Take that for what it's worth. I'm fine with closing this if we want to write it off as an odd coincidence.
I don't think the issue was related to db48-> db5. subversion uses dbX only on the server part and only if the repo was created with `svnadmin --fs-type bdb'. For the database on the client side sqlite3 is used (.svn/wc.db). At the moment I don't have an idea why svn update was failing. In case this happens again, try to run `svn cleanup' from the root checkout (/usr/ports) to cleanup possible failures, if this does not work a quick cross check can be done with svnlite (stripped down svn 1.8 in FreeBSD 10 base).
> I don't think the issue was related to db48-> db5. I agree, after thinking about it, I don't think the db5 change had anything to do with it, just coincidental I guess. > In case this happens again, try to run `svn cleanup' from the root checkout (/usr/ports) to cleanup possible failures As an FYI, I got that error no matter where I was in the file hierarchy - /, /usr/ports, /tmp, /root. I think the failure was during the process that svn does to figure out where it is and to find the closest .svn folder. svnlite is a good idea, if I get stuck there again I'll probably use that instead of svn from packages. If anybody cares to attempt to repro, I guess my only advice would be to downgrade to FreeBSD 10.0-STABLE-p9 rev r269194 and build the indicated apr1 and subversion versions. I'd close this for now; if someone else sees it again, hopefully one of us will remember or google will find this.
Seems the issue was not direct related to the apr update. Close PR as requested by submitter.
I'm having similar issue with devel/apr1 built by lang/clang35. It appears any optimization level above -O0 breaks apr_stat() in file_io/unix/filestat.c. Here's a workaround: --- apr-1.5.1/file_io/unix/filestat.c~ +++ apr-1.5.1/file_io/unix/filestat.c @@ -297,7 +297,6 @@ APR_DECLARE(apr_status_t) apr_stat(apr_f finfo->pool = pool; finfo->fname = fname; fill_out_finfo(finfo, &info, wanted); - if (wanted & APR_FINFO_LINK) wanted &= ~APR_FINFO_LINK; return (wanted & ~finfo->valid) ? APR_INCOMPLETE : APR_SUCCESS; } Will try again after 11.0-CURRENT imports clang 3.5.x if the issue persists.
(In reply to Jan Beich from comment #6) > I'm having similar issue with devel/apr1 built by lang/clang35. It appears > any optimization level above -O0 breaks apr_stat() in > file_io/unix/filestat.c. It's a bug in one of the llvm optimizers, introduced in llvm r210006. I reported this upstream, and they have reverted the change for now: http://llvm.org/viewvc/llvm-project?rev=222856&view=rev I will ensure this is fixed in the upcoming clang 3.5.0 import in base, and I hope upstream will accept it for 3.5.1 too.