moving trac/svn to new server

[Mr Papa]

we've been running our svn 1.5.5 and trac 0.11-stable on our server
(updating along the way of course) for a couple years now. this past
weekend, we moved to a new server and we just cant seem to get things
working once again.

We can't even get Trac to show up on the web, but we can access is via
the server command line.

Trying to do a resync yields the following error:

Resyncing repository history...
Command failed: Couldn't open Subversion repository /svn:
SubversionException: ("Expected FS format '2'; found format '3'",
160043)

We moved our trac (and svn) repos/dirs over as they were on the
previous server, so I am guessing its somewhere in the installation,
but am unable to find it.

There is one issue with svn still to resolve (commits fail) but its
visible on the web and one can checkout stuff... working that
separately but thought it worth mentioning...

Any ideas?

[Ariel Balter]

Here are some things to consider:
1) the file permissions on the new server
Is trac in a web readable directory? Does the necessary user have write
permissions on the necessary files? (try TracInstall for details)
2) directives in the apache2.conf file. .htpasswd file?
You copied the trac directories, but the global apache configuration
file might have important things such as aliases to the trac directory
that you are used to using, and will also be important for trac to find
stuff.
3) name of user, and name of server (i.e. hostname)
Password and authentication information in .htaccess files is by user.
The hostname is part of important paths that are in trac.ini etc.

--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

Ariel I Balter, Ph.D.
Postdoc
Biological Monitoring/Modeling
Fundamental and Computational Sciences Directorate

Pacific Northwest National Laboratory
Mail:
PO Box 999, MS P7-58,Richland, WA 99352
Shipping:
790 6th Street, MS P7-58, Richland, WA 99354

Tel: 509-376-7605
Cell: 509-713-0087
ariel....@pnl.gov
www.arielbalter.com
www.pnl.gov

[Emmanuel Blot]

> Resyncing repository history...
> Command failed: Couldn't open Subversion repository /svn:
> SubversionException: ("Expected FS format '2'; found format '3'",
> 160043)

It looks like you are using a wrong version of Subversion on the
server, a version that does not match the version that has been used
to create and manage the repository.

Did you move your SVN repository using a "raw" method (save/restore
SVN directories), or did you use the "proper" method (svnadmin dump &
svnadmin load) ?

I don't remember which SVN FS version numbering scheme, but it's something like:
FS v2: SVN 1.4
FS v3: SVN 1.5 (+upgrade)
FS v4: SVN 1.6 (+upgrade)

Cross check that the Subversion Python binding you use do match the
SVN repository FS format.

HTH
Manu

[Mr Papa]

both svn versions were 1.5.5 built from source code...

the svn repo was moved with the raw method (has worked before). I
want to go try the dump/load method, but host failed to heed my
request to leave the older server active for a bit - so trying to see
if it can be turned back on... For grins, I did do a dump/load from
the svn on the new server to a new repo to see what happens since svn
is working on the new server (except for commits)... got the same
result (not really surprising)

the format file in svn has a 5 in it...

sorry, subversion python binding? mod_python?

Thanks!

[Mr Papa]

ah, okay, found some stuff on the bindings... svn was just built
using the standard process .configure, make, make install...

will try some of the stuff listed on the trac subversion page...

[Mr Papa]

hmmm... its using swig v 1.3.29... which the trac page says dont use
despite it being delivered with svn... now to find an older
verison... swig's older version page just errors out...

[Mr Papa]

well, using swig 1.3.25 as suggested in the trac help didnt make any
difference... argh...

[Jason Botwick]

What versions of trac and svn are on the new server? Sounds like your new server's svn version might be 1.4.x . . .

[Mr Papa]

svn reports 1.5.5.. and it was built from source... is there another
way besides the output on the html browser page and svnadmin to check
the version?

[Emmanuel Blot]

> ah, okay, found some stuff on the bindings...  svn was just built
> using the standard process .configure, make, make install...

These commands do not built the Python bindings, see:
make swig-py
make swig-py-install

[Mr Papa]

yes, I have already rebuilt the swig bindings... svn shipped with and
built v1.3.29... a trac/svn page said this was a bad version, so I had
manually rebuilt them at v1.3.25, the trac recommended version, but
still have he same issue...

Steve

[Emmanuel Blot]

> yes, I have already rebuilt the swig bindings...  svn shipped with and
> built v1.3.29... a trac/svn page said this was a bad version, so I had
> manually rebuilt them at v1.3.25, the trac recommended version, but
> still have he same issue...

Are you sure your system does not have an older version of the Python
bindings that could be loaded and used instead of the one you built?

Try loading SVN bindings from Python interactive command prompt and
get the actual SVN library revision

python
import svn.core
print "%d.%d.%d" % (svn.core.SVN_VER_MAJOR, svn.core.SVN_VER_MINOR,
svn.core.SVN_VER_MICRO)

be sure to run "python" with the same uid as the web server.

[Mr Papa]

Okay, now you are just making things confusing! ;)

Doing so yields the following result:

1.4.2

which I am struggling to understand... since subversion outputs
v1.5.5 when you browse the repo... and was clearly built from 1.5.5
source... however, to add more to the mix, if I do "yum list
subversion" it also reports 1.4.2???

could there be multiple subversions installed on the server in
different locations (I know this is the trac user group...) and
different things are pulling from different installations??

Thanks...

[Emmanuel Blot]

> Okay, now you are just making things confusing!  ;)

You meant: it starts to make sense with the error you got ;-)

> Doing so yields the following result:
> 1.4.2

This means that the SVN bindings you use come from SVN 1.4.2, which
may not use a SVN FSFS repository created/upgraded with SVN 1.5.x

> if I do "yum list subversion" it also reports 1.4.2???

No idea, I don't use this package manager.

> could there be multiple subversions installed on the server in
> different locations (I know this is the trac user group...) and
> different things are pulling from different installations??

Yes.
You may have Subversion command tools for 1.5, and Subversion python
bindings for 1.4 on the same machine.
The first ones are located by the system using the PATH environment
variable, while the second ones are located using the PYTHONPATH
environment variable.

Time to search for "libsvn" directory using the 'find' tool...

Cheers,
Manu

[Mr Papa]

okay, sorry, having some trouble following you know...

PATH includes the /usr/local/bin directory on it where svn and swig
are located...

PYTHONPATH includes (I believe via PythonPath "sys.path + ['/usr/
local/lib/svn-python'] in httpd.conf) /usr/local/lib/svn-python
directory... there are subdirs libsvn and svn under there...

there are also a bunch of libsvn_xxx.so (and other extensions) located
one directory up at /usr/local/lib

??

Thanks...

Steve

[Emmanuel Blot]

> PYTHONPATH includes (I believe via  PythonPath "sys.path + ['/usr/
> local/lib/svn-python'] in httpd.conf) /usr/local/lib/svn-python
> directory...  there are subdirs libsvn and svn under there...

If sys.path points to one the previously installed SVN python
bindings, then your own built bindings will never be loaded.

Cheers,
Manu

[Mr Papa]

just to clarify, when you say python bindings, are you referring to
swig? there is a swig executable in /usr/local/bin (same place as svn
executables) that returns version 1.3.25 which is what I built... or
are there shard object libraries in use for the bindings?

I have also tried removing that PYTHONPATH statement from the
trac.conf file and end up with the same result...

is that svn-python directory the correct place to have python looking
for the bindings? or should it possibly be up one directory to where
all the libsvn_xxx.so files are? or perhaps down one directory to
where the libsvn or svn directories are?

appreciate all your help... first time an issue has come up with trac/
svn installs and first time dealing with bindings? ;)

Steve

[Mr Papa]

From http://trac.edgewall.org/wiki/TracSubversion

# Read ./subversion/bindings/swig/INSTALL in order to build the
bindings. In particular, pay attention to the version of SWIG which
can be required (1.3.0 comes with pre-generated wrappers, though). Do
not install swig 1.3.28 or 1.3.29. Version 1.3.27 seems to works fine
(Although not in all cases. The subversion users mailing lists suggest
going back to 1.3.25, which may be necessary).
# In your subversion source root, do make swig-py; make install-swig-
py (NOTE: there is a dash between 'install' and 'swig'!)
# Adapt your PYTHONPATH so that it contains the svn-python folder (the
one containing the svn and libsvn packages).

wondering if I followed those steps properly... if I do the make
swig-py and make isntall-swig-py on the bindings that come with
subversion, it installs swig v1.3.29 which it explicitly says do not
use... so I went and grabbed a new copy of swig (v 1.3.25) and
installed it... however, it was not part of the svn build/install
process and had a diff file structure than what was contained under
the svn source... is there a special svn compatible version of swig
that has to be gotten? does it have to be located under the
subversion code and built the way its says above? or maybe stated
differently, does it have to be built as part of the subversion build?

[Emmanuel Blot]

> just to clarify, when you say python bindings, are you referring to
> swig?

Not really: SWIG is a *generator*: it helps building the wrapper code
that stands between the Python interpreter (SWIG may generate wrapper
for many other language) and the underlying C native library (.so).
Python bindings are made of Python (.py) code and C wrappers (c file
compiled into a .so lib), which are both generated with the SWIG tool.

>  there is a swig executable in /usr/local/bin (same place as svn
> executables) that returns version 1.3.25 which is what I built...  or
> are there shard object libraries in use for the bindings?

SWIG is only required to *build* the bindings, not to run them.
The SWIG version only matters when you build the bindings.

> I have also tried removing that PYTHONPATH statement from the
> trac.conf file and end up with the same result...

You could try to add the path to your bindings before sys.path, not after

> is that svn-python directory the correct place to have python looking
> for the bindings?

I guess that LD_LIBRARY_PATH also matters to locate the .so part of
the bindings.

> appreciate all your help...  first time an issue has come up with trac/
> svn installs and first time dealing with bindings?  ;)

Do you really need to rebuild SVN? Is there no way to add the packages
with your favorite package manager?

Cheers,
Manu

[Christian Boos]

Emmanuel Blot wrote:
>> just to clarify, when you say python bindings, are you referring to
>> swig?
>>
> Not really: SWIG is a *generator*: it helps building the wrapper code
> that stands between the Python interpreter (SWIG may generate wrapper
> for many other language) and the underlying C native library (.so).
> Python bindings are made of Python (.py) code and C wrappers (c file
> compiled into a .so lib), which are both generated with the SWIG tool.
>
>
>> there is a swig executable in /usr/local/bin (same place as svn
>> executables) that returns version 1.3.25 which is what I built... or
>> are there shard object libraries in use for the bindings?
>>
> SWIG is only required to *build* the bindings, not to run them.
> The SWIG version only matters when you build the bindings.
>

Not even, as the generated bindings are shipped in the Subversion source
tarball.
You only need SWIG when building Subversion from a source checkout, or
when you want to modify the .i files.
So most of the time (including in this situation) SWIG doesn't even come
into the picture.
IIRC, the advice from the TracSubversion page comes from a time when the
generated bindings /weren't/ shipped (the 1.2.x / 1.3.x period, again IIRC).

I'd suggest to the original poster to follow the steps in
http://trac.edgewall.org/wiki/TracSubversion#Checklist in particular step 3.

-- Christian

[Mr Papa]

appreciate all the help guys...

making some great progress... managed to get pythong using the right
bindings and get it talking to svn... i can even resync trac with
svn... woot...

I havent tried checklist step 3 because, well, um, not sure how to get
the python pid... using ps or pstree, I dont really see a python
process...

so anyways, trac "seems" to be working, except I cant access it from
the web where it should be... I just get a 404 page... must be
something in my .conf files but they are copies of the old server
where the web access was working... permissions? apache owns
everything... will compare settings again with old server (finally
got them to reactivate it)...

other ideas?

> I'd suggest to the original poster to follow the steps inhttp://trac.edgewall.org/wiki/TracSubversion#Checklistin particular step 3.
>
> -- Christian

[Mr Papa]

the apache server error log seems to filled with trac/python
errors... very odd looking stuff..

one of the predominant, repeating ones is about not being able to
extract files to the egg cache... whats strange is where it says the
egg cache is pointing to is not where the egg cache is set to with
python env var in trac.conf at apache start time... I know the
trac.conf is getting parsed at startup because if I insert an error,
apache chokes... thats where the location is specified to for the web
trac so its almost as if that file is getting parsed but not actually
updating anything or being used...

[Mr Papa]

here is the error message seen after restarting apache:

[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] ServerName:
'simplepressforum.com'
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248]
DocumentRoot: '/home/xxxxx/public_html'
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] URI: '/
trac/'
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] Location: '/
trac'
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] Directory:
None
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] Filename: '/
trac/htdocs/'
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] PathInfo:
''
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] Traceback
(most recent call last):
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] File "/
usr/lib/python2.4/site-packages/mod_python/importer.py", line 1537, in
HandlerDispatch\n default=default_handler, arg=req,
silent=hlist.silent)
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] File "/
usr/lib/python2.4/site-packages/mod_python/importer.py", line 1229, in
_process_target\n result = _execute_target(config, req, object,
arg)
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] File "/
usr/lib/python2.4/site-packages/mod_python/importer.py", line 1128, in
_execute_target\n result = object(arg)
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] File "/
usr/lib/python2.4/site-packages/Trac-0.11.5stable_r8186-py2.4.egg/trac/
web/modpython_frontend.py", line 143, in handler\n reload
(sys.modules['trac.web'])
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] File "/
usr/lib/python2.4/site-packages/Trac-0.11.5stable_r8186-py2.4.egg/trac/
web/__init__.py", line 10, in ?\n from trac.web.api import *
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] File "/
usr/lib/python2.4/site-packages/Trac-0.11.5stable_r8186-py2.4.egg/trac/
web/api.py", line 29, in ?\n from trac.util import
get_last_traceback, md5, unquote
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] File "/
usr/lib/python2.4/site-packages/Trac-0.11.5stable_r8186-py2.4.egg/trac/
util/__init__.py", line 33, in ?\n from trac.util.html import
escape, unescape, Markup, Deuglifier
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] File "/
usr/lib/python2.4/site-packages/Trac-0.11.5stable_r8186-py2.4.egg/trac/
util/html.py", line 16, in ?\n from genshi import Markup, escape,
unescape
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] File "/
usr/lib/python2.4/site-packages/Genshi-0.5.1-py2.4-linux-i686.egg/
genshi/__init__.py", line 32, in ?
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] File "/
usr/lib/python2.4/site-packages/Genshi-0.5.1-py2.4-linux-i686.egg/
genshi/core.py", line 544, in ?
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] File "/
usr/lib/python2.4/site-packages/Genshi-0.5.1-py2.4-linux-i686.egg/
genshi/_speedups.py", line 7, in ?
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] File "/
usr/lib/python2.4/site-packages/Genshi-0.5.1-py2.4-linux-i686.egg/
genshi/_speedups.py", line 4, in __bootstrap__
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] File "/
usr/lib/python2.4/site-packages/setuptools-0.6c9-py2.4.egg/
pkg_resources.py", line 840, in resource_filename\n return
get_provider(package_or_requirement).get_resource_filename(
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] File "/
usr/lib/python2.4/site-packages/setuptools-0.6c9-py2.4.egg/
pkg_resources.py", line 1310, in get_resource_filename\n
self._extract_resource(manager, self._eager_to_zip(name))
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] File "/
usr/lib/python2.4/site-packages/setuptools-0.6c9-py2.4.egg/
pkg_resources.py", line 1331, in _extract_resource\n real_path =
manager.get_cache_path(
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] File "/
usr/lib/python2.4/site-packages/setuptools-0.6c9-py2.4.egg/
pkg_resources.py", line 921, in get_cache_path\n
self.extraction_error()
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248] File "/
usr/lib/python2.4/site-packages/setuptools-0.6c9-py2.4.egg/
pkg_resources.py", line 887, in extraction_error\n raise err
[Sun May 10 14:00:42 2009] [error] [client 174.18.101.248]
ExtractionError: Can't extract file(s) to egg cache\n\nThe following
error occurred while trying to extract file(s) to the Python egg
\ncache:\n\n [Errno 13] Permission denied: '/trac/.egg-cache/
Genshi-0.5.1-py2.4-linux-i686.egg-tmp'\n\nThe Python egg cache
directory is currently set to:\n\n /trac/.egg-cache\n\nPerhaps your
account does not have write access to this directory? You can\nchange
the cache directory by setting the PYTHON_EGG_CACHE environment
\nvariable to point to an accessible directory.\n

And also my current trac.conf file:

alias /trac /trac/htdocs

### Trac need to know where the database is located
<Location /trac>
SetHandler mod_python
PythonHandler trac.web.modpython_frontend
PythonOption TracEnv /trac
PythonOption TracUriRoot /trac
SetEnv PYTHON_EGG_CACHE /trac/eggs
PythonInterpreter trac
</Location>

### You need this to allow users to authenticate
<Location /trac/login>
AuthType Basic
AuthName "trac"
# AuthUserFile /trac/passwds
AuthUserFile /svn/users/passwords
Require valid-user
</Location>

I have tried many different combinations of stuff in trac.conf,
including the format (ie main_interpreter) on tracmodpython... none
have made any difference and this exact trac.conf was working on the
old server...

seems odd that the error message about the egg cache doesnt even refer
to the location specified in the conf file where the egg cache is
set. also odd that visiting the http://simplepressforum.com/trac page
doesnt find anything... this all worked like this before, so I must
still have something configured wrong - just cant figure out what...

another strange thing is that over time (maybe continuously?), the
apache error log continues to grow in size and the number of those
error messages. Its as if its cycling through every "page" in trac
and generating an error per page... its currently updating the error
logs for all files uploaded in svn as if the trac browser were viewing
each and every file...

any ideas?

Thanks...

Steve

I have found many, many sites with this error googling, but none of
them have helped...