Edgewall Software

Changes between Version 73 and Version 74 of TracSubversion


Ignore:
Timestamp:
Apr 18, 2010, 12:01:48 PM (12 years ago)
Author:
Remy Blank
Comment:

Small reformattting.

Legend:

Unmodified
Added
Removed
Modified
  • TracSubversion

    v73 v74  
    210210
    211211 1. Verify that you can load the bindings using the Python interactive interpreter
    212 
    213 {{{
     212 {{{
    214213$ python
    215214Python ...
    216215>>> from svn import core
    217 }}}
    218 If this succeeds, that's a good start.
    219 
    220 If it doesn't,  it usually means that your bindings are located in
    221 a place they can't be loaded from. So either move the `svn` and `libsvn`
    222 found in the /opt/subversion-xxx/lib/svn-python folder
    223 into your site-packages folder, or add the above folder to your PYTHONPATH,
    224 or create a [http://docs.python.org/lib/module-site.html svn.pth] file
    225 in your Python site-packages folder with the above folder path as its
    226 single line content (an example on a FreeBSD installation, again: /usr/local/lib/pythonN.N/site-packages/). One simple solution for rpm-based operating systems, is to install the subversion-python bindings rpm. The [http://subversion.tigris.org/project_packages.html official subversion site] points [http://summersoft.fay.ar.us/pub/subversion/latest/ here] to download those packages.
    227 '''Windows Users'''
    228 
    229 According to the README.txt file for the Subversion bindings, if you are using Python 2.5+ you need to rename all the .dll files in the libsvn folder to .pyd files. Upon further research, http://www.python.org/doc/faq/windows/#is-a-pyd-file-the-same-as-a-dll indicates you may need to have both the .pyd and .dll version of the libsvn files available. This resolved both the 'ImportError: No module named _core' error (with only the DLL) and the 'ImportError: DLL load failed' (with only the pyd) when testing from the console, and the browswer.
    230 
    231 If you get the message {{{ImportError: libsvn_swig_py-1.so.0: cannot open shared object file: No such file or directory}}} even though you can see the .so file in the correct place, then try {{{ldconfig -v}}} as root.
     216 }}}
     217 If this succeeds, that's a good start.
     218
     219 If it doesn't,  it usually means that your bindings are located in a place they can't be loaded from. So either move the `svn` and `libsvn` found in the /opt/subversion-xxx/lib/svn-python folder into your site-packages folder, or add the above folder to your PYTHONPATH, or create a [http://docs.python.org/lib/module-site.html svn.pth] file in your Python site-packages folder with the above folder path as its single line content (an example on a FreeBSD installation, again: /usr/local/lib/pythonN.N/site-packages/). One simple solution for rpm-based operating systems, is to install the subversion-python bindings rpm. The [http://subversion.tigris.org/project_packages.html official subversion site] points [http://summersoft.fay.ar.us/pub/subversion/latest/ here] to download those packages.
     220
     221 If you get the message {{{ImportError: libsvn_swig_py-1.so.0: cannot open shared object file: No such file or directory}}} even though you can see the .so file in the correct place, then try {{{ldconfig -v}}} as root.
     222
     223 '''Windows Users'''
     224
     225 According to the README.txt file for the Subversion bindings, if you are using Python 2.5+ you need to rename all the .dll files in the libsvn folder to .pyd files. Upon further research, http://www.python.org/doc/faq/windows/#is-a-pyd-file-the-same-as-a-dll indicates you may need to have both the .pyd and .dll version of the libsvn files available. This resolved both the 'ImportError: No module named _core' error (with only the DLL) and the 'ImportError: DLL load failed' (with only the pyd) when testing from the console, and the browswer.
    232226
    233227
    234228 2. Check the version
    235 {{{
     229 {{{
    236230>>> (core.SVN_VER_MAJOR, core.SVN_VER_MINOR, core.SVN_VER_MICRO, core.SVN_VER_PATCH)
    237231(1, 4, 3, 3)
    238 }}}
    239 Verify that the version given back matches your expectation.
     232 }}}
     233 Verify that the version given back matches your expectation.
    240234
    241235 3. Check that you're using the right binaries (Linux)
    242236
    243 Get the pid of the above running Python interpreter (i.e. once the
    244 binding is loaded), and get the list of the libraries used by looking at the
    245 corresponding map file.
    246 
    247 e.g.
    248 {{{
     237 Get the pid of the above running Python interpreter (i.e. once the binding is loaded), and get the list of the libraries used by looking at the corresponding map file.
     238
     239 e.g.
     240 {{{
    249241cat /proc/10213/maps | grep .so | cut -d/ -f2- | sort -u
    250 }}}
    251 
    252 In particular, pay attention to the `.../lib/svn-python/libsvn/_core.so` file
    253 and see if its location seems to be consistent with both those of the other
    254 svn libraries (`.../lib/*.so`) and the location of the Python code part of the
    255 bindings (`.../lib/svn-python/svn/core.py`).
     242 }}}
     243
     244 In particular, pay attention to the `.../lib/svn-python/libsvn/_core.so` file and see if its location seems to be consistent with both those of the other svn libraries (`.../lib/*.so`) and the location of the Python code part of the bindings (`.../lib/svn-python/svn/core.py`).
    256245
    257246 4. Have you got SVN disabled in your trac.ini file for some reason.
    258247
    259 For whatever reason, you may have trac.versioncontrol.* set to disabled in your trac.ini file. If so, set it/them to enabled (or simply delete the offending lines, since I believe they are enabled by default.)
    260 
    261 {{{
     248 For whatever reason, you may have trac.versioncontrol.* set to disabled in your trac.ini file. If so, set it/them to enabled (or simply delete the offending lines, since I believe they are enabled by default.)
     249 {{{
    262250[components]
    263251trac.versioncontrol.api.repositorymanager = enabled
     
    267255trac.versioncontrol.svn_prop.subversionmergepropertyrenderer = enabled
    268256trac.versioncontrol.svn_prop.subversionpropertyrenderer = enabled
    269 }}}
     257 }}}
    270258
    271259'''And if it doesnt....??'''
     
    275263 3. If you're using Apache / mod_python (Linux/Windows) (first tip)
    276264
    277 Get a similar list of libraries, but this time for one of your httpd process.
    278 Then compare the two, and pay attention to any difference between the `svn`
    279 libraries and the `apr` libraries. You ''have to'' have compatible APR libraries
    280 between Apache and Subversion, otherwise you risk to get a wide variety of subtle
    281 errors (e.g. #4985).
     265 Get a similar list of libraries, but this time for one of your httpd process. Then compare the two, and pay attention to any difference between the `svn` libraries and the `apr` libraries. You ''have to'' have compatible APR libraries between Apache and Subversion, otherwise you risk to get a wide variety of subtle errors (e.g. #4985).
    282266
    283267 4. If you're using Apache / mod_python (Linux) (second tip)
    284268
    285 If you have installed the Subversion .so-Files in some "remote" location, Apache may be unable to find them (and thus unable to pass them on to Python/Trac, such that Trac cannot find Subversion). To check if this is the case, do the following:
    286 
    287 {{{
     269 If you have installed the Subversion .so-Files in some "remote" location, Apache may be unable to find them (and thus unable to pass them on to Python/Trac, such that Trac cannot find Subversion). To check if this is the case, do the following:
     270
     271 {{{
    288272/etc/init.d/apache2 stop
    289273$export LD_LIBRARY_PATH=/usr/lib/python/site-packages/libsvn/:$LD_LIBRARY_PATH
    290274/etc/init.d/apache2 restart
    291 }}}
    292 
    293 If this works, you need to add the library path permanently. There are two options for this. Either add it in the Apache configuration file (http://httpd.apache.org/docs/2.2/mod/mod_env.html#setenv) or at the system level by adding the path to /etc/ld.so.conf, and then run ldconfig. More information on shared libraries can be found here: http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
    294 
    295 5. if you're getting 'undefined symbol: xmlCreatePushParserCtxt' while running make check-swig-py, it could be that your libneon is compiled against libxml2. If this is the case, try to recompile your libneon against expat instead of libxml2.
     275 }}}
     276
     277 If this works, you need to add the library path permanently. There are two options for this. Either add it in the Apache configuration file (http://httpd.apache.org/docs/2.2/mod/mod_env.html#setenv) or at the system level by adding the path to /etc/ld.so.conf, and then run ldconfig. More information on shared libraries can be found here: http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
     278
     279 5. if you're getting 'undefined symbol: xmlCreatePushParserCtxt' while running make check-swig-py, it could be that your libneon is compiled against libxml2. If this is the case, try to recompile your libneon against expat instead of libxml2.
    296280
    297281== Tip for Debian Linux ==