On Tue, Mar 22, 2022 at 12:38 AM Nathan Hartman
<hartman.nat...@gmail.com> wrote:
>
> On Mon, Mar 21, 2022 at 9:18 PM Jun Omae <jun6...@gmail.com> wrote:
> >
> > On Tue, Mar 22, 2022 at 9:10 AM Mark Phippard <markp...@gmail.com> wrote:
> > >
> > > This seems to be the main thing I am stuck on. I used Debian Buster so
> > > that it would just be Python 2.7. It also occurred to me I was seeing
> > > this using the release tarball so SWIG would not even be involved any
> > > more .. right? The bindings were generated when the last RM generated
> > > the tarball.
> > >
> > > Does this ring any bells to anyone about why this is invalid?
> > >
> > >   File 
> > > "/home/svnrm/subversion-1.14.2/subversion/bindings/swig/python/libsvn/core.py",
> > > line 144
> > >     def apr_initialize() -> "apr_status_t":
> > >                                   ^
> > > SyntaxError: invalid syntax
> > >
> > > I have tried searching for "->" but not coming up with anything. It
> > > does seem vaguely familiar but I think I am remembering the similar
> > > Ruby operator that was deprecated. It seems like we are missing
> > > something obvious else this would have shown up when people signed the
> > > last release.
> > >
> > > Mark
> >
> > The swig-py for Python 2 depends "swig -python -classic". However,
> > -classic option is no longer supported since SWIG 4. SWIG 3 should be
> > used for 1.14.x releases to support Python 2.7 (swig3.0 package is
> > able to use in Debian Buster).
>
> I went looking for this information in
> subversion/bindings/swig/INSTALL and didn't see it the first time
> around, but it turns out it was there. Hopefully r1899118 and r1899120
> make things a bit more clear...

Honestly ... there are not. Mainly because there is just still way too
much information covering too many scenarios. I would prefer to see
the Release section of HACKING updated to describe how to build the
release tarball. We know roughly speaking the environment we are in,
or recommending so we ought to be able to be more specific.

As I understand things ... the release.py creates tarballs designed
for Python 3. That is fine, however we are rolling the release on a
system with Python 2 (which will also help for when we are rolling SVN
1.10.x releases which do not support Python 3). So now, I am expected
to test the release tarball so I need to extract and build it.

This all mostly works. Exception is Python. It sounds like I need to
take steps to regenerate the Python bindings for Python 2. The
question is how. So far I have been told I need to re-run autogen.sh.
I did so. I then ran ./configure --with-swig=/home/svnrm/prefix so
that it picks up the Swig 3.0.12 from the clean room. This all seems
to work. Maybe there is some other step I do not know to make Swig
actually regen the bindings?

Anyway, when I build and test the Python bindings I get a new error:

$ make check-swig-py

if [ "LD_LIBRARY_PATH" = "DYLD_LIBRARY_PATH" ]; then for d in
/home/svnrm/subversion-1.14.2/subversion/bindings/swig/python/libsvn_swig_py
/home/svnrm/subversion-1.14.2/subversion/bindings/swig/python/../../../libsvn_*;
do if [ -n "$DYLD_LIBRARY_PATH" ]; then
LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$d/.libs"; else
LD_LIBRARY_PATH="$d/.libs"; fi; done; export LD_LIBRARY_PATH; fi; \
cd /home/svnrm/subversion-1.14.2/subversion/bindings/swig/python; \
  /usr/bin/python
/home/svnrm/subversion-1.14.2/subversion/bindings/swig/python/tests/run_all.py
Traceback (most recent call last):
  File 
"/home/svnrm/subversion-1.14.2/subversion/bindings/swig/python/tests/run_all.py",
line 23, in <module>
    import mergeinfo, core, client, delta, checksum, pool, fs, ra, wc,
repository, \
  File 
"/home/svnrm/subversion-1.14.2/subversion/bindings/swig/python/tests/pool.py",
line 30, in <module>
    class PoolTestCase(unittest.TestCase):
  File 
"/home/svnrm/subversion-1.14.2/subversion/bindings/swig/python/tests/pool.py",
line 251, in PoolTestCase
    @unittest.skipIf(not utils.IS_PY3,
AttributeError: 'module' object has no attribute 'IS_PY3'
make: *** [Makefile:944: check-swig-py] Error 1

So I am guessing that I am still missing a step in terms of what I am
supposed to do to build a release tarball on Linux with Python 2. I am
sure it is documented, it is just more than I have been able to
decipher.

I could go back to a Python 3 distribution but then I will need a
different setup to roll any older releases.

Mark

Reply via email to