As in summary, xapian-bindings as of version 1.3.3 python3 is no longer experimental. Please, enable, if possible. From changelog: Xapian-bindings 1.3.3 (2015-06-01): * The Python3 bindings are no longer considered to be "experimental". Reproducible: Always
Okay, can you please test 1.3.7-r2 1.4.0-r1. I've tested using a system with both python2 and python3, but I'm not sure what will happen if a system has only one or the other. I think the configure script is smart enough to work that out, but I'd feel better if I had testing in the wild.
disregard the topic of this report. RESOLVED TEST-REQUEST is irritating (it's for infra guys to consider) it cannot be resolved until tested and confirmed. And it doesn't work, it builds fine, though getting this: Python 3.4.5 (default, Jul 23 2016, 10:18:53) [GCC 4.9.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import xapian Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python3.4/site-packages/xapian/__init__.py", line 37, in <module> _xapian = swig_import_helper() File "/usr/lib64/python3.4/site-packages/xapian/__init__.py", line 36, in swig_import_helper return importlib.import_module(mname) File "/usr/lib64/python3.4/importlib/__init__.py", line 109, in import_module return _bootstrap._gcd_import(name[level:], package, level) ImportError: No module named '_xapian' eselect python list Available Python interpreters: [1] python2.7 [2] python3.4 *
(In reply to Oleg from comment #2) > disregard the topic of this report. RESOLVED TEST-REQUEST is irritating > (it's for infra guys to consider) it cannot be resolved until tested and > confirmed. And it doesn't work, it builds fine, though getting this: I like the TEST-REQUEST part. I don't like the RESOLVED part. I guess I could just ask for testing without it, but I like using TEST-REQUEST as a search field. > > Python 3.4.5 (default, Jul 23 2016, 10:18:53) > [GCC 4.9.3] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> import xapian > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > File "/usr/lib64/python3.4/site-packages/xapian/__init__.py", line 37, in > <module> > _xapian = swig_import_helper() > File "/usr/lib64/python3.4/site-packages/xapian/__init__.py", line 36, in > swig_import_helper > return importlib.import_module(mname) > File "/usr/lib64/python3.4/importlib/__init__.py", line 109, in > import_module > return _bootstrap._gcd_import(name[level:], package, level) > ImportError: No module named '_xapian' > > eselect python list > Available Python interpreters: > [1] python2.7 > [2] python3.4 * Can you look into what's going on with that error and report back with a fix. Here's what I have. 1. It does generate the modules and it does install them on qmerge: # tree /var/tmp/portage/dev-libs/xapian-bindings-1.4.0-r1/image/ /var/tmp/portage/dev-libs/xapian-bindings-1.4.0-r1/image/ └── usr ├── lib64 │ ├── python2.7 │ │ └── site-packages │ │ └── xapian │ │ ├── __init__.py │ │ ├── __init__.pyc │ │ ├── __init__.pyo │ │ └── _xapian.so │ └── python3.4 │ └── site-packages │ └── xapian │ ├── __init__.cpython-34.pyc │ ├── __init__.cpython-34.pyo │ ├── __init__.py │ └── _xapian.cpython-34.so 2. I can't import the modules in either python2 or 3 even though they are installed. 3. I didn't use distutils-r1 eclass. The build system finds the python implementations fine. When I use python-singal-r1-pkg_setup, it breaks when trying to configure python2 stuff with python3.
a problem is that _xapian.so for python3.4 is not installed. /usr/lib64/python3.4/site-packages/xapian/__init__.py /usr/lib64/python3.4/site-packages/xapian/_xapian.cpython-34m.so /usr/lib64/python3.4/site-packages/xapian/__init__.cpython-34.pyo /usr/lib64/python3.4/site-packages/xapian/__init__.cpython-34.pyc /usr/lib64/python2.7/site-packages/xapian/__init__.py /usr/lib64/python2.7/site-packages/xapian/__init__.pyo /usr/lib64/python2.7/site-packages/xapian/__init__.pyc /usr/lib64/python2.7/site-packages/xapian/_xapian.so but _xapian.cpython-34m.so is installed. making simple symlink: ln -s _xapian.cpython-34m.so _xapian.so fixes
(In reply to Oleg from comment #4) > a problem is that _xapian.so for python3.4 is not installed. > > > > /usr/lib64/python3.4/site-packages/xapian/__init__.py > /usr/lib64/python3.4/site-packages/xapian/_xapian.cpython-34m.so > /usr/lib64/python3.4/site-packages/xapian/__init__.cpython-34.pyo > /usr/lib64/python3.4/site-packages/xapian/__init__.cpython-34.pyc > /usr/lib64/python2.7/site-packages/xapian/__init__.py > /usr/lib64/python2.7/site-packages/xapian/__init__.pyo > /usr/lib64/python2.7/site-packages/xapian/__init__.pyc > /usr/lib64/python2.7/site-packages/xapian/_xapian.so > > but _xapian.cpython-34m.so is installed. making simple symlink: > > ln -s _xapian.cpython-34m.so _xapian.so > > fixes does 2.7 work as is, or does it need anything?
apparently, python2.7 xapian module import failing with same error, despite the fact /usr/lib64/python2.7/site-packages/xapian/_xapian.so exist.
(In reply to Oleg from comment #6) > apparently, python2.7 xapian module import failing with same error, despite > the fact > > /usr/lib64/python2.7/site-packages/xapian/_xapian.so > > exist. any news on this? i feel like reverting the change until we get a proper fix.
news on what? your changes in ebuild does not help.
(In reply to Oleg from comment #8) > news on what? > your changes in ebuild does not help. i thought you might be working on a fix. if not i'm reverting.
(In reply to Anthony Basile from comment #9) > (In reply to Oleg from comment #8) > > news on what? > > your changes in ebuild does not help. > > i thought you might be working on a fix. if not i'm reverting. for 1.4.1, i reverted to just python2.7.
attempt2 for xapian-bindings. attach ebuild, full compilation log and content of installed package. i can import xapian for both python2 and python3. there are some errors in python files, which i believe are upstream.
Created attachment 454744 [details] xapian-bindings-1.4.1-r1.ebuild
Created attachment 454746 [details] complete compilation log
Created attachment 454748 [details] contents
DISTUTILS* calls can be removed from ebuild.
Note that some user had a sandbox violation issue: https://bugs.funtoo.org/secure/attachment/14072/build.log We figured out that is was due to the `local -x PYTHONDONTWRITEBYTECODE=` within `src_compile()`. We worked this around by adding this in `src_prepare()` sed -i 's/\$(SPHINX_BUILD)/-D $(SPHINX_BUILD)/' python{,3}/Makefile.in This bug is likely related to #596302 https://bugs.gentoo.org/show_bug.cgi?id=596302 By the way, `dev-python/sphinx` dependency should be `dev-python/sphinx[${PYTHON_USEDEP}]`
this sed fix is only for newer sphinx versions (1.4 and newer) so we cannot rely on it because it's not in portage tree.
Here's a proper solution for python2/python3 support. https://github.com/gentoo/gentoo/pull/2960
(In reply to Mike Gilbert from comment #18) > Here's a proper solution for python2/python3 support. > > https://github.com/gentoo/gentoo/pull/2960 okay i've committed this. Oleg, can you test and close this bug if everything works fine.
works good, thx everyone involved.
