[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: python-enchant is not importable in python 2.6 on armhf. Any idea which package is at fault?

On Mon, Dec 26, 2011, peter green wrote:
> According to the launchpad "meta-bug" the python2.7 fix was already
> uploaded to
> unstable. This would fit with my test succeeding with python2.7 and
> failing with
> python2.6
> Python2.6 (ubuntu) in the launchpad meta-bug is marked as "won't fix"
> because python2.6 is "to be removed" are there any plans to fix
> python2.6 in
> debian or do they plan to remove it like ubuntu do?

 (python2.6 will eventually be removed from Debian but depending on how
 long it will stay, its maintainer might opt to use the patch in this

> > It would be best if we would patch python programs and modules to stop
> > using find_library.
> Should a bug be opened against python-enchant? and if so what should the package use instead of find_library?

 You would file a bug against the python-enchant package or the
 pyenchant source package.  The code using find_library is in
 enchant/_enchant.py, _e_path_possibilities() yields some pathnames
 where the library should be loaded from:

def _e_path_possibilities():
    """Generator yielding possible locations of the enchant library."""
    yield os.environ.get("PYENCHANT_LIBRARY_PATH")
    yield find_library("enchant")
    yield find_library("libenchant")
    yield find_library("libenchant-1")
    if sys.platform == 'darwin':
         # enchant lib installed by macports
         yield "/opt/local/lib/libenchant.dylib"

 as you can see, this doesn't encode the SONAME anywhere, so that if the
 ABI / SONAME change and the old and new ones are present, a random one
 will be chosen.  Ideally, the code would gain awareness of the
 ABIs / SONAMEs that pyenchant actually works with and do something
for soname in ('libenchant.so.1', 'libenchant.so.0'):
        e = cdll.LoadLibrary(soname)
    except OSError:
    if e:

 this could be used by default for all unixish systems, but I guess
 upstream would still want PYENCHANT_LIBRARY_PATH to be preferred in
 some way.

 (The above snippet would be used somewhere near line 119 "# Not found
 yet, search various standard system locations." in enchant/_enchant.py
 and would try libenchant.so.1 and fall back to libenchant.so.0).

Loïc Minier

Reply to: