browser requests fail with an exception related to svn

[chad.campbell@…]

Did a build on Solaris 9, with Python 2.4.2, Subversion 1.3.0, SQLite 3.2.8, Clearsilver 0.10.2, SWIG 1.3.27, Trac 0.9.2, PYSQLite 2.0.5, based on the instructions found at http://systemsadmin.info/solaris/articles/building-trac-on-solaris and the TracInstall doc.

crle output:

Configuration file [version 4]: /var/ld/ld.config
  Default Library Path (ELF):   /usr/lib:/opt/sqlite-3.2.8/lib/:/opt/subversion-1.3.0/lib/:/opt/subversion-1.3.0/lib/svn-python/libsvn/:/opt/clearsilver-0.10.2/lib/

environment variables:
LD_LIBRARY_PATH=/opt/csw/lib:/opt/csw/bdb43/lib
PYTHONPATH=/opt/subversion-1.3.0/lib/svn-python:/opt/sqlite-3.2.8/lib:/opt/subversion-1.3.0/lib:/opt/clearsilver-0.10.2/lib
PATH=/opt/python-2.4.2/bin:/usr/xpg4/bin:/opt/csw/gcc3/bin:/opt/csw/bin:/usr/sfw/bin:/usr/ccs/bin:/usr/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin

svnadmin was successful creating a repository at /opt/Subversion
trac-admin was successful creating it's environment at /opt/Trac with /opt/Subversion as the repository
tracd --port 8000 /opt/Trac starts up and can be accessed via Firefox

When I try to access the source browser, I get /opt/Subversion does not appear to be a Subversion repository.

Also, tracd throws this exception:

Exception exceptions.AttributeError: "'SubversionRepository' object has no attribute 'log'" in <bound method SubversionRepository.__del__ of <trac.versioncontrol.svn_fs.SubversionRepository object at 0x3c44b0>> ignored

---

Problem identified: This problem is platform-specific and due to the use of GNU libiconv by apr-util, which doesn't know about the default locale used ("646").

comment:19 describes the problem and comment:20 + comment:32 describe a workaround. The other alternative would be to not use GNU libiconv but the native Solaris iconv library.

[Wally.Hartshorn@…]

I'm encountering the same error, running Solaris 7, Python 2.3.5, Subversion 1.2.3, SQLite 3.2.8, ClearSilver 0.9.14, SWIG 1.3.27, Trac 0.9.3, and PySQLite 2.0.5. The specific error message I get is:

Exception exceptions.AttributeError: "'SubversionRepository'
object has no attribute 'log'" in <bound method 
SubversionRepository.__del__ of 
<trac.versioncontrol.svn_fs.SubversionRepository
object at 0x3fd790>> ignored

[athomas]

Code blocked exceptions.

[craig.steinberger@…]

Same issue: Solaris 10, Trac 0.9.3, Subversion 1.2.3, Clearsilver 0.10.2, SWIG 1.3.21, Python 2.3.5, SQLite 2.8.16, Pysqlite 1.0

Exception exceptions.AttributeError??: "'SubversionRepository' object has no attribute 'log'" in <bound method SubversionRepository.del of <trac.versioncontrol.svn_fs.SubversionRepository object at 0x4eefb0>> ignored

[cboos]

The problem with .log is a very minor one, merely a symptom that something went wrong in the SubversionRepository constructor, most probably during the call to svn_repos_open.

I'll try to reproduce this myself, but in the meantime, it would help if one of you could reproduce the error using this small script: attachment:ticket:2620:check_svn_repos.py

python check_svn_repos.py /opt/Subversion 0

[schuetze@…]

Hi,

I have the same problem on Windows after I've upgraded my SVN-repositories from SVN-1.1.4/TRAC-0.8.3 to SVN-1.3.0/TRAC-0.9.3. I used the upgrade hint from DB-Upgrade and TracUpgrade.

The test-script "check_svn_repos.py" produces the following output:

T:\>c:\Programme\Python\python.exe T:\check_svn_repos.py d:\svn\test 5
Traceback (most recent call last):
  File "T:\check_svn_repos.py", line 34, in ?
    ChangeCollectorChecker(path).check(int(rev))
  File "T:\check_svn_repos.py", line 19, in __init__
    self.repos = repos.svn_repos_open(self.path, self.pool())
SystemError: null argument to internal routine
Usage: python check_repos.py <repository_path> <revision>

A fast solution of this problem would be fine - the users of my tool (that is supported with TRAC) can't continue their work ...

[cboos]

to schuetze@...:

There's something which I find strange: the SystemError: null arg... sounds like a generic SVN 1.1.x error to me. In 1.3.0, it's usually SubversionException: .... Anyway, the stack trace would look different if that was really 1.3.0. You can check this by adding:

from svn import core
print core.SVN_VER_MAJOR, core.SVN_VER_MINOR

in the script.

I think you're still using the 1.1.4 bindings and you try to open a 1.3.0 repository with them.

[craig.steinberger@…]

OK, I ran the script:

$ /opt/csw/bin/python /export/home/cjs/check_repos.py /export/home/polarissvn/blastware 50
Checked revision 50 (0 objects unreachable)

seems to work just fine.

Startup Trac and access the source browser:

$

 bin/tracd --port 8000 polaris
...
Exception exceptions.AttributeError: "'SubversionRepository' object has no attribute 'log'" in <bound method SubversionRepository.__del__ of <trac.versioncontrol.svn_fs.SubversionRepository object at 0x4eedf0>> ignored

From the log:

21:36:53 Trac[main] ERROR: /export/home/polarissvn/blastware does not appear to be a Subversion repository.
Traceback (most recent call last):
  File "/export/home/trac/lib/python2.3/site-packages/trac/web/standalone.py", line 303, in _do_trac_req
    dispatch_request(path_info, req, env)
  File "/export/home/trac/lib/python2.3/site-packages/trac/web/main.py", line 139, in dispatch_request
    dispatcher.dispatch(req)
  File "/export/home/trac/lib/python2.3/site-packages/trac/web/main.py", line 107, in dispatch
    resp = chosen_handler.process_request(req)
  File "/export/home/trac/lib/python2.3/site-packages/trac/versioncontrol/web_ui/browser.py", line 92, in process_request
    repos = self.env.get_repository(req.authname)
  File "/export/home/trac/lib/python2.3/site-packages/trac/env.py", line 162, in get_repository
    repos = SubversionRepository(repos_dir, authz, self.log)
  File "/export/home/trac/lib/python2.3/site-packages/trac/versioncontrol/svn_fs.py", line 189, in __init__
    raise TracError, \
TracError: /export/home/polarissvn/blastware does not appear to be a Subversion repository.

It doesn't work.

[craig.steinberger@…]

Trac is working fine on my site when I configure mod_python. In my httpd.conf file I set:

PythonPath "sys.path + ['/export/home/trac/lib/python2.3/site-packages']"

However, when running standalone, I get the exception. In that case, I execute from the shell:

PYTHONPATH=$PYTHONPATH:/export/home/trac/lib/python2.3/site-packages
export PYTHONPATH

then run tracd.

It might be a path issue:

>>> import sys
>>> print sys.path
['', '/export/home/trac', '/export/home/trac/lib/python2.3/site-packages', '/opt/csw/lib/python23.zip', '/opt/csw/lib/python2.3', '/opt/csw/lib/python2.3/plat-sunos5', '/opt/csw/lib/python2.3/lib-tk', '/opt/csw/lib/python2.3/lib-dynload', '/opt/csw/lib/python2.3/site-packages', '/opt/csw/lib/python2.3/site-packages/setuptools-0.6a9-py2.3.egg']

/opt/csw/lib/python2.3/svn is not directly in the path, so add it (sorry if this is obvious, I'm a python newbie).

Still get the exception when running tracd. mod_python is still working, which is odd.

[anonymous]

Hi cboos,

you are right - I had the old SVN bindings running. I have now updated to 1.3, but the problem still exists:

T:\>c:\Programme\Python\python.exe T:\check_svn_repos.py d:/svn/test 5
Checked revision 5 (0 objects unreachable)
Exception exceptions.AssertionError: 
<exceptions.AssertionError instance at 0x009F74B8> in 
<bound method Pool.__del__ of <trac.versioncontrol.svn_fs.Pool object
at 0x00ADDA90>> ignored

I will try it with mod_python now, too ...

[cboos]

to schuetze:

The check program succeeds, even if there's a problem with the Pools, which can be ignored. This means Trac should now be able to open the repository, provided it runs in the same environment (i.e. be careful to use the 1.3 bindings).

to craig:

You have certainly a similar problem than schuetze has: you're trying to open a 1.3 repository using older bindings. That's probably why it works when you're running Trac with mod_python (for some reason, it picks the correct bindings) and it doesn't work when running with tracd.

Check this by enabling debug logging and add the following lines:

trac/versioncontrol/svn_fs.py

@@ -175 +175 @@
     """
 
     def __init__(self, path, authz, log):
+        log.debug('Using Subversion bindings %d.%d.%d' % \
+                  (core.SVN_VER_MAJOR, core.SVN_VER_MINOR, core.SVN_VER_MICRO))
         if core.SVN_VER_MAJOR < 1:
             raise TracError, \
                   "Subversion >= 1.0 required: Found %d.%d.%d" % \

[craig.steinberger@…]

When I patch the svn_fs.py file as specified everything works in standalone. When I move the original file back, the standalone fails again. I removed the .pyc files before each run. This doesn't make much sense to me.

From the log (from a successful run):

22:44:59 Trac[svn_fs] DEBUG: Using Subversion bindings 1.2.3
22:44:59 Trac[svn_fs] DEBUG: Opening subversion file-system at /export/home/polarissvn/blastware with scope /polaris/
22:44:59 Trac[cache] DEBUG: Checking whether sync with repository is needed
22:44:59 Trac[svn_fs] DEBUG: Closing subversion file-system at /export/home/polarissvn/blastware

I'm running SVN 1.2.3

[schuetze@…]

Everything works fine for me now. The problem was the wrong SVN bindings ... The mod_python is running also.

Probably it would be helpful to make an automatic check by TRAC if the used SVN bindings have the right version corresponding to the used SVN version.

[lzap]

This problem can occur if you have the SVN repository under different user than trac runs under. E.g. this can happen if you run Trac under FCGI as lighttpd or apache and you have /var/svn as nobody.

[anonymous]

Adding some debugging to trac/versioncontrol/svn_fs.py, it seems that in SubversionRepository.init():

  path = os.path.normpath(path).replace('\\', '/')

returns the path of the SVN repo.

However:

  self.path = repos.svn_repos_find_root_path(path, self.pool())

returns NULL

Any idea why?

[cboos]

On Windows? What's the value of path?

[anonymous]

With the above, in mind, I did the following:

$ python
Python 2.4.2 (#1, Jan 11 2006, 01:58:37) 
[GCC 3.4.3 (TWW)] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> from svn import repos
>>> from trac.versioncontrol.svn_fs import Pool
>>> path='/var/svn/test'
>>> pool = Pool()
>>> repos.svn_repos_find_root_path(path,pool())
'/var/svn/test'

Odd that this works given the results in the above comment. I modified svn_fs.py:

path = os.path.normpath(path).replace('\\', '/')
self.path = repos.svn_repos_find_root_path(path, self.pool())
self.path = path

I then received the subversion error:

("Can't create a character converter from 'UTF-8' to native encoding", 2)

[bugs-trac@…]

Sorry, the value of path is '/var/svn/test' and this is on Solaris 8 with Trac 0.9.4, clearsilver 0.10.3, subversion 1.2.3, and Python 2.4.2. The problem is that repos.svn_repos_find_root_path() is return None.

[bugs-trac@…]

This isn't a problem with Trac. A description of the problem:

http://marc.theaimsgroup.com/?l=apr-dev&m=114954995213823&w=2

If GNU libiconv knew about "646" as an alias for "ASCII", then things should work.

[bugs-trac@…]

I fixed this problem by applying the following patch to GNU libiconv 1.9.2, regenerating lib/aliases.gperf and lib/aliases.h using Makefile.devel, and rebuilt it.

Index: lib/encodings.def
===================================================================
--- lib/encodings.def.orig	2006-06-09 11:28:55.861092000 -0500
+++ lib/encodings.def	2006-06-09 12:19:58.081380000 -0500
@@ -38,6 +38,7 @@
 
 DEFENCODING(( "US-ASCII",               /* IANA */
               "ASCII",                  /* IANA, JDK 1.1 */
+              "646",                    /* Solaris */
               "ISO646-US",              /* IANA */
               "ISO_646.IRV:1991",       /* IANA */
               "ISO-IR-6",               /* IANA */

[cboos]

One thing I did not understand yet in the above is the difference between the command line which worked and from within Trac which failed... Did the environment change in between?

[bugs-trac@…]

Yeah, I don't know either. I'd just close the bug and tell people to patch their libiconv. If apr-util was built with the Solaris iconv, then there shouldn't be a problem.

[cboos]

Ah, then it might be because of the setlocale call we do, in the web front-end. That's the value of the TracLocale option in case of mod_python.

I'm not sure the original poster and craig had the same issue, but if that was not the case, the bug can be reopened.

[lim.yee.szu@…]

Hi all,

I am newbie to solaris and subversion, who has just started 2 months ago. I have encountered the same error as I did a build the Subversion 1.3.1 and Trac 0.9.5 on Solaris 10, based on the instructions found at http://systemsadmin.info/solaris/articles/building-trac-on-solaris and the TracInstall doc. Below is details of my environment variable setting and the steps I have done.

I have installed Subversion-1.3.1, Trac-0.9.5, Swig-1.3.29,Clearsilver-0.10.2, Pysqlite-2.2.2, Sqlite-3.3.5, Apache-2.0.55. Environment Variables: PATH= /usr/sbin:/usr/bin:/usr/local/bin/:/usr/ccs/bin/ LD_LIBRARY_PATH=/usr/local/lib://usr/lib:/lib PYTHONPATH=/usr/local/lib/svn-python

Subversion repository at /svn_test was successfully created. Trac environment at /trac_test with /svn_test as repository was successfully created.

I have not do any configuration after succesfully installed Trac and start Trac up by run the following command: tracd –port 8000 /trac_test

When I try to access the source browser, I get "/svn_test does not appear to be a Subversion repository." And tracd throws this exception:

Exception exceptions.AttributeError?: "'SubversionRepository' object has no attribute 'log'" in <bound method SubversionRepository.del of <trac.versioncontrol.svn_fs.SubversionRepository object at 0x4eb7f0>> ignored

I get the error is it because I have miss out some step(s)? Or do I need to configure my apache or something else? Can anyone please advice me to get my “Browser Source”. You help is appreciate.

Fyi, I have successfully running configure my apache to access /svn_test repos via WebSvn?. So I assume my subversion and apache is configure correctly.

[cboos]

Please, (re-)read the comments 19, 20, 22 and 23. Try to figure out if this is a problem with the way apr-util has been built, w.r.t. iconv (GNU or not?). If GNU, follow the advice given in comment:20. Also, try changing the TracLocale parameter to something known.

[lys]

Sorry cboos.. Please allow me to ask stupid(newbie) questions..

1) I'm using the precompiled binaries GNU libiconv which get from www.sunfreeware.com. (comment #19)How do i check if GNU libiconv know about "ASCII"? 2) (comment #20) Where can i get the patch? Can you please guide me how to apply the patch step by step? 3) My python also using precompiled binaries (from www.sunfreeware.com). I have searched through my solaris system, but i still can't find mod_python. Can you please tell me where the TracLocale parameter is? How and where can i get mod_python?

All the libraries and software that i have installed is using pre-compiled binaries from www.sunfreeware.com except apache-2.0.55, subversion-1.3.1, openssl-0.9.8a, trac-0.9.5, clearsilver-0.10.2, pysqlite-2.2.2 & sqlite-3.3.5, which is installed from the source.

[cboos]

Can you simply try the following:

$ export LC_CTYPE=US_en.ASCII
$ tracd –port 8000 /trac_test

Maybe that could be enough...

[lys]

Cboos.. i have tried the command you mention above.. but i still get the same exception as the output.

172.16.2.178 - - [30/Jun/2006 09:14:41] "GET /trac_test/browser HTTP/1.1" 500 - Exception exceptions.AttributeError?: "'SubversionRepository' object has no attribute 'log'" in <bound method SubversionRepository.del of <trac.versioncontrol.svn_fs.SubversionRepository object at 0x4eb090>> ignored

Do i need to configure something like apache2 before starting Trac standalone server? I run Trac standalone server straight away after created the Trac environment.

[cboos]

I was somehow hoping that the export... above would prevent you from going through the more complex steps of comment:20. Maybe your best chance is to ask for help on some Solaris help forum, or directly at www.sunfreeware.com.

[lys]

cboos, thanks for all the help.. i will re-try everything again..

[katanafx@…]

comment 20 said something about patching libiconv with Makefile.devel, anyone can tell how this is done?

[cboos]

Assuming you've created a file named 646.patch containing the patch present in comment:20, try:

$ cd libiconv-1.9.2
$ patch -p0 < 646.patch
$ make -f Makefile.devel lib/aliases.h
$ make # using the "user" Makefile

But that patch was against libiconv-1.9.2, I don't know if it applies (or even if it is needed) for more recent versions of GNU iconv.

By the way, I'm closing this ticket now, as the problem is clearly identified and a workaround is documented...

(the me in the worksforme being here bugs-trac@…)

[anonymous]

Setting LC_CTYPE worked for me - with no need to patch libiconv. If you're on Solaris check /etc/TIMEZONE for a suitable setting.

[marc@…]

Indeed setting LC_CTYPE worked for me on solaris:

export LC_CTYPE=en_US.UTF-8

no patching needed