Discussion:
Handling python venv packages breaking on glibc update
(too old to reply)
Oon-Ee Ng via arch-general
2017-08-21 09:41:31 UTC
Permalink
Raw Message
I use psycopg2 for postgres access in my pyramid web-app, and like most
(all?) python developers all the dependencies are in a virtualenv,
including psycopg2 itself.

This means, of course, that the psycopg2 wheel is precompiled.

With the recent glibc-2.26 update, I can no longer import psycopg2. This is
the error message I get on the file libresolv-2-c4c53def.5.so:

symbol __res_maybe_init, version GLIBC_PRIVATE not defined in file
libc.so.6 with link time reference

I'm not sure why the psycopg2 pip package bundles in libresolv (which is
part of glibc in Arch, explaining why the Arch psycopg2 package works fine,
even without a recompile). Where's the right place for me to fix this? With
the psycopg2 pip maintainers or somewhere else?
Damjan Georgievski via arch-general
2017-08-21 09:48:19 UTC
Permalink
Raw Message
Post by Oon-Ee Ng via arch-general
I use psycopg2 for postgres access in my pyramid web-app, and like most
(all?) python developers all the dependencies are in a virtualenv,
including psycopg2 itself.
This means, of course, that the psycopg2 wheel is precompiled.
With the recent glibc-2.26 update, I can no longer import psycopg2. This is
symbol __res_maybe_init, version GLIBC_PRIVATE not defined in file
libc.so.6 with link time reference
I'm not sure why the psycopg2 pip package bundles in libresolv (which is
part of glibc in Arch, explaining why the Arch psycopg2 package works fine,
even without a recompile). Where's the right place for me to fix this? With
the psycopg2 pip maintainers or somewhere else?
why not just use the Arch package? I prefer that for pacakges that
link to system libraries.
--
damjan
Oon-Ee Ng via arch-general
2017-08-21 09:50:05 UTC
Permalink
Raw Message
On Mon, Aug 21, 2017 at 5:48 PM, Damjan Georgievski via arch-general <
Post by Damjan Georgievski via arch-general
Post by Oon-Ee Ng via arch-general
I use psycopg2 for postgres access in my pyramid web-app, and like most
(all?) python developers all the dependencies are in a virtualenv,
including psycopg2 itself.
This means, of course, that the psycopg2 wheel is precompiled.
With the recent glibc-2.26 update, I can no longer import psycopg2. This
is
Post by Oon-Ee Ng via arch-general
symbol __res_maybe_init, version GLIBC_PRIVATE not defined in file
libc.so.6 with link time reference
I'm not sure why the psycopg2 pip package bundles in libresolv (which is
part of glibc in Arch, explaining why the Arch psycopg2 package works
fine,
Post by Oon-Ee Ng via arch-general
even without a recompile). Where's the right place for me to fix this?
With
Post by Oon-Ee Ng via arch-general
the psycopg2 pip maintainers or somewhere else?
why not just use the Arch package? I prefer that for pacakges that
link to system libraries.
Well, venvs are just cleaner (and I've tried venvs with some system libs,
gets messy quickly). Also venvs allow easy freeze etc. which I need because
my deployments are not on Arch machines (fortunately, they're still
working).

Oon-Ee Ng via arch-general
2017-08-21 09:48:56 UTC
Permalink
Raw Message
So reinstalling psycopg2 with `pip install --no-binary :all: psycopg2`
works. Still wondering whether this is an issue to raise upstream.
Post by Oon-Ee Ng via arch-general
I use psycopg2 for postgres access in my pyramid web-app, and like most
(all?) python developers all the dependencies are in a virtualenv,
including psycopg2 itself.
This means, of course, that the psycopg2 wheel is precompiled.
With the recent glibc-2.26 update, I can no longer import psycopg2. This
symbol __res_maybe_init, version GLIBC_PRIVATE not defined in file
libc.so.6 with link time reference
I'm not sure why the psycopg2 pip package bundles in libresolv (which is
part of glibc in Arch, explaining why the Arch psycopg2 package works fine,
even without a recompile). Where's the right place for me to fix this? With
the psycopg2 pip maintainers or somewhere else?
Loading...