trac svn-python mismatch with apache 2.2 under windows

[jschmidt@…]

If you use xampp apache 2.2 and trac 11b1, you have to use the svn-python binding from this page (binding for apache 2.0)  http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91&expandFolder=91&folderID=74 Subversion recommended this binding  http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=8100&expandFolder=8100&folderID=8100 But in this case I have an unsynchronized repository. error-stack:

2008-01-30 12:21:21,890 Trac[svn_fs] INFO: Failed to load Subversion bindings
Traceback (most recent call last):
  File "C:\Python25\Lib\site-packages\trac\versioncontrol\svn_fs.py", line 251, in __init__
    _import_svn()
  File "C:\Python25\Lib\site-packages\trac\versioncontrol\svn_fs.py", line 69, in _import_svn
    from svn import fs, repos, core, delta
  File "C:\Python25\Lib\site-packages\svn\fs.py", line 19, in <module>
    from libsvn.fs import *
  File "C:\Python25\Lib\site-packages\libsvn\fs.py", line 29, in <module>
    import core
  File "C:\Python25\Lib\site-packages\libsvn\core.py", line 5, in <module>
    import _core
ImportError: DLL load failed: Die angegebene Prozedur wurde nicht gefunden.

So I go back to use the binding for apache 2.0. If you follow the install-guide from Trac, you won't realize this mistake, because the link brings you to subversion/apache 2.0. Please resolve this mismatch!

[anonymous]

<<If you follow the install-guide from guide>> has to be 'from trac' 8)

[cboos]

Which part of the install guide?

At least, the TracOnWindows#using-installers part seems clear enough about this.

OTOH, the next section (manual install) still needs much cleanup/removal.

[jschmidt@…]

In this part of the guide TracOnWindows#using-installers the link of the subversion-python 2.5 binding points on a apache 2.0 version. I installed Apache 2.2 and downloaded the corresponding version directly from tigris.

[cboos]

Ok, so you haven't read the associated notes ;-)

[anonymousjschmidt@…]

I think the problem is, that tigris offer the svn-binding as a working exe, which is not. so let's close the ticket and I will send this ticket to the subversion developers, because they have to recover their bindings and not the trac-ians, isn't it?

[cboos]

Ok, sorry, I didn't get it at first.

So you're basically saying that the  Subversion 1.4.6 bindings for Apache 2.2 are actually not compatible with Apache 2.2, but that the  Subversion 1.4.6 bindings for Apache 2.0 are?

That's weird. Though I haven't tried myself, I doubt this. From the Apache 2.2 page:

Windows binaries built against Apache 2.2.x -- note that Apache 2.2.4 or higher is required.

Have you checked whether the xampp Apache 2.2 satisfies this requirement?

[jschmidt@…]

Yes, I checked: I'm using the newest release xampp 1.6.5 with Apache 2.2.6

[Laurens Blanckenborg <laurens@…>]

My experiences in this matter are even wierder.

I encountered the same error as mentioned above. I tried to get Trac working under Apache 2.2.8 with mod_python. I have installed (binary releases) Apache 2.2.8 from ApacheLounge? (compiled with VC2008), ActivePython 2.5.2.2, mod_python 3.3.1 from apache.org and the svn-bindings from subversion.tigris.org (the ones compiled against 2.2).

Though everything installed without a problem, the mod_python testhandler showed that mod_python was functioning OK and both my existing trac-envs as well as the newly created test-environment ran fine under the standalone tracd, I was not able to browse the repo when accessing the envs via mod_python. The traclog returned the same error as stated above.

I read the remarks in the help/guide about adding the bindings (./svn and ./libsvn) to the pythonpath, but that didn't help. When testing if using Apache 2.0 would solve the problem (with the appropriate 2.0-mod_python and 2.0-bindings) I accidentally got it working under 2.2.

The following weird mixing did the trick: ActivePython 2.5.2.2 (not changed when going back to 2.0); uninstalled svn-python and mod_python for 2.2; installed svn-python for Apache 2.0; installed mod-python for Apache 2.0 * BUT * loaded the Apache-modulefile (mod_python.so) from the 2.2-package. Now I can browse the repo via mod_python under Apache 2.2.8.

Using the 2.0-mod_python.so under Apache 2.2.8 causes it to fail starting the service, using the whole mod_python2.2-package together with the bindings for 2.0 (as mentioned above) causes Trac in import the bindings, but Trac then stops after importing the bindings (giving a blank page and leaving "[...] Trac[svn_fs] DEBUG: Subversion bindings imported" as the last line in the log).

I really don't know a possible cause of this wierd behavior, but I hope some other people could benefit from my experience as it took me several days searching the internet to get it all working.

Remark: I'm using Windows Server 2003 x64 SP2, but all software (Python, Apache, SVN) is 32bit. I don't think this error to have anything to do with x64.

[cboos]

Thanks a lot for your detailed explanation, I'll add a link to it at the relevant places.

I think this whole story can be explained by mismatched MSVCRTs. You could have a look at the various .exe, .so and .pyd files involved here using the dependency walker (depends.exe) and see to which MSVC runtime each is linked to.

Off-topic note to self: [...] should not be recognized as a relative wiki link...

[ebekker4csc@…]

More info on this issue. We experienced the exact same problem, here is our setup: VisualSVN Server (Apache 2.2.9), with the latest bins for Python 2.5, SVN 1.5, SVN-Python (SVN1.5-Py2.5-Apache2.2), mod_python-3.3.1 (Apache 2.2), Trac 0.11.

Just as in your case, we could run tracd with no problems, but when running through Apache (VisualSVN Server) we got the same error trace failing to load _core. We solved it by replacing the libapr-1.dll in the Apache bin with the version that's in Python's libsvn, just substituting seems to have fixed it.

Using the "depends" utility we see that one specific routines symbol name has changed, specifically "_apr_time_ansi_put@12" became "_apr_time_ansi_put@8" and libsvn has a dependency on the latter. Looks like this is an issue for the SVN guys to fix, but I'm curious how the signature for this routine changed between the builds?

[sakesun]

We experienced the exact same problem as ebekker4csc

and the solution mentioned solve the problem.

We solved it by replacing the libapr-1.dll in the Apache bin with the version that's in Python's libsvn, just substituting seems to have fixed it.

Thanks

[wtigotw]

Same setup, same problem, same solution as the other two

Replying to sakesun:

We experienced the exact same problem as ebekker4csc

and the solution mentioned solve the problem.

We solved it by replacing the libapr-1.dll in the Apache bin with the version that's in Python's libsvn, just substituting seems to have fixed it.

Thanks

[anonymous]

VisualSvn? 1.7.2 Python 2.5.4 setuptools-0.6c9.win32-py2.5 genshi-0.5.1.win32-py2.5 Trac0.11.4.win32 svn-python-1.6.2-win32-py2.5 mod_python_3.3.1-win32-py2.5-Apache2.2

Same Problem, same fix. Thanks a bunch.

[anonymous]

Replying to sakesun:

We solved it by replacing the libapr-1.dll in the Apache bin with the version that's in Python's libsvn, just substituting seems to have fixed it.

Same problem and fix here:

Windows 2000 SVN 1.6.5 Python 2.5.4 Trac 0.11.5 svn-python-1.6.5-win32-py2.5 mod_python_3.3.1-win32-py2.5-Apache2.2

[bxdtech]

FIXED!!!

My upgrade of Apache, SVN and Trac was going fine; I had all the programs running great on their own, but there was one very crucial problem left to overcome: Trac could see the SVN repos while running on tracd, but Trac couldn't see the repos while running on Apache. I tried everything, had literally been so frustrated that I was going to switch to Bugzilla...I've literally days spent trying to get Trac to talk to SVN...uninstalling, reinstalling, moving files, adding little bits and pieces of Python code here and there, swapping versions of bindings, swapping module versions, reconfiguring Apache from mod_python to fcgi and back again, pouring over forums, tickets, email groups, installation instructions, etc...-you know, all that troubleshooting stuff we all know and love so well...and now, it's all fixed.

Apache/2.2.14 (Win32) DAV/2 SVN/1.6.6 mod_python/3.3.1 Python/2.5.4

I just stopped Apache, copied ALL the .dll files from /libsvn to my Apache /bin dir and restarted Apache. Everything now works perfectly. w00t!

-I have to say that this was undoubtedly the absolute worst upgrade procedure I've ever experienced. I understand that integrating these programs is a huge development task, and as a developer and sysadmin I appreciate all the work that goes into building all the associated parts and APIs, but there MUST be an easier upgrade path...from an engineering prospective the work done to improve Trac is fantastic, but from an end-user perspective, specifically the installation and configuration of it, Trac is a disjointed hodge-podge of instructions that usually carry the caveat of "your mileage may vary". Someone needs to focus on keeping the installation instructions clear and concise, or perhaps build and maintain an installer system that actually works....or both. -JMHO

[anonymous]

I have to agree with what was said before... There MUST be an easier way to make Trac + SVN work together. I am trying to make SVN 1.6.9, Trac 0.11.7, and ActivePython 2.6.15 work together on Windows 7. All installed, and very nicely, but Trac refuses to see my repository. It's the famous Failed to load Subversion bindings problem.

IMO, Trac and Subversion need to become one single product. A given Trac version already requires specific bindings from a particular build of Subversion. The installer should include Trac, Subversion, Genshi, Python from python.org,^* easy-install, Apache, and whatever else might be needed for a complete standalone system, with each piece optionally installable at user discretion.

The other option is to cut the umbilical cord between Subversion and Trac, so that users don't have to hunt down this and that from all over the web.

Granted, Trac and Subversion are completely separate projects, each with their respective development teams. And yes, I know volunteering time and effort on open source projects is very often a thankless job. But folks, it is utterly ridiculous to expect the user to dig through a dozen wiki pages, and twice as many search engine query results, and days later have little more than fading hope that Trac and Subversion will ever work together on their machine.

I do so want to see this great duo working in concert, and I'll gladly contribute something to the projects when they do.^* But my confidence level in the software is nearing bottom of the tank.

Thank you.

_{* ActiveState only has the current plus previous version of ActivePython available for download, and their standard license prohibits distribution.}

_{Much like the BitNami stack. only the SVN/Trac versions they use are showing their age, and I could not get their combo to work with TortoiseSVN nor AnkhSVN.}

_{* An obvious first contribution would be my install instructions.}