[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: problem with svnshell

From: Michael S <mike_ml_at_suessnetz.de>
Date: 2003-05-13 20:01:01 CEST

Am Die, 2003-05-13 um 19.24 schrieb Faheem Mitha:
> On Mon, 12 May 2003 17:22:31 -0700, Greg Stein <gstein@lyra.org> wrote:
> > On Tue, May 13, 2003 at 12:14:52AM +0100, Colin Watson wrote:
> >> On Mon, May 12, 2003 at 07:35:06PM +0000, Faheem Mitha wrote:
> >> > I'm running subversion 0.21 backported to Debian Woody (by Colin
> >> > Watson).
> >> >
> >> > I get the following error message when trying to run svnshell. I just
> >> > want to check whether this is a real problem or I am doing something
> >> > wrong.
> >>
> >> Weird; I can't reproduce it on either the official 0.21 packages from
> >> unstable or on my build (admittedly on the machine that built it).
> >>
> >> I also can't find PyType_IsSubtype anywhere in the built source tree.
> >
> > I think that I've seen this before. If I recall correctly, it is due to a
> > mismatch between the SWIG runtime library and the version of Python that is
> > being used. For example, the runtime might have been built for Python 1.5,
> > but you've built the wrapper module for Python 2.x and are running the whole
> > mess under a 2.x interpreter.
> >
> > The answer is to check your SWIG configuration to ensure that the runtime
> > library is built for the same version of Python that you intend to use with
> > the wrapper extension modules.
> >
> >>...
> >> > Versions of packages subversion depends on:
> >> > ii db4.1-util 4.1.25-4 Berkeley v4.1 Database Utilities
> >> > ii libapr0 2.0.45-2.woody.2 The Apache Portable Runtime
> >> > ii libc6 2.3.1-16 GNU C Library: Shared libraries an
> >>
> >> That's testing or unstable, not woody. I've never tried my package
> >> builds there ... perhaps Python has changed?
> >
> > Check the swig packages, too. Debian might have to add dependencies between
> > the SWIG package and specific versions of Python. Possibly different SWIG
> > runtimes based on which Python needs to use it.
> >
> > Of course, I could be misremembering the PyType_IsSubType problem. But take
> > a look and see what you find...
>
> I tried downgrading to the version of libswig1.3 in Debian
> Stable. This is 1.3.11-1, and from the changelogs, is against Python
> 2.1. The version I previously had installed was 1.3.17-0.woody.1. I'm
> not sure what Python version this was against but presumably nothing
> earlier than 2.1. However, I now get a different error.
>
> Traceback (most recent call last):
> File "/usr/bin/svnshell", line 347, in ?
> main()
> File "/usr/bin/svnshell", line 344, in main
> util.run_app(SVNShell, sys.argv[1])
> File
> "/home/cjwatson/src/apt-src/subversion-0.21.0/debian
> /tmp/usr/lib/python2.1/site-packages/svn/util.py",
> line 40, in
> run_app
> TypeError: Type error. Expected _p_apr_pool_t
>
> I'm not sure what conclusion to draw from any of this. Any opinion if
> any of this should be reported as a bug or not, and if so to who? It
> does seem that the Debian dependencies on swig should be tightened if
> it depends so crucially on the particular version of a program.
>
> Faheem.

I got bitten by the same error just yesterday, after I upgraded to the
package provided by cjwatson it worked
(libswig1.3_1.3.17-0.woody.1_i386.deb that is) for me. However, thats
what you had installed in the first place, isn't it? And you were using
the corresponding python2.1-subversion_0.21.0-0.woody.1_i386.deb and
swig1.3_1.3.17-0.woody.1_i386.deb from his site as well (sorry, did not
read all of your original mail)?

Michael

-- 
"What we do in life, echos in eternity..."
Michael S 
GPG-Key: http://www.suessnetz.de/michael/michaelsuess.gpg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 13 20:00:16 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.