Hi Josselin,
> Woah, looks like a neat solution. Do you think it would scale for all
> our Python packages without manual intervention? If so, this would
> definitely be the way forward.
I hope so, but haven’t tried it yet.
> I mostly agree with you, but for this rather common case of having
Hi Lars,
Lars-Dominik Braun writes:
> I think the problem is bigger than usercustomize. Any custom PYTHONPATH
> also slips through and causes this issue, as well as any custom
> GUIX_PYTHONPATH, because the executable wrapper appends it (think nested
> `guix shell` invokations with different
Hi,
there’s a similar issue #63912 and a thread on the guix-devel
mailinglist at
https://lists.gnu.org/archive/html/guix-devel/2023-06/msg00066.html
> So, looks like the default Python behavior is to load the usercustomize
> after the sitecustomize [1], which leads to exactly the behavior you're
Hi Athena,
Athena Martin writes:
> $ guix shell python-neovim-remote python -- python3
sys.path
> ['',
> '/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python310.zip',
> '/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python3.10',
>
> The nvr package in ~/.local seems to be used instead of a Guix
> package. That locally installed nvr package expects to use the
> host's libc, but since the python interpreter being used has a
> fixed RPATH and system search path it won't find it.
I've just checked and temporarily removing
> So it's not the LD_DEBUG output that hold a clue, but rather the
> Python traceback.
> The nvr package in ~/.local seems to be used instead of a Guix
> package. That locally installed nvr package expects to use the host's
> libc, but since the python interpreter being used has a fixed RPATH
>
Hi Athena,
So it's not the LD_DEBUG output that hold a clue, but rather the Python
traceback.
Athena Martin writes:
> File
> "/gnu/store/dsgxdqs620pp284bfm1drbsjqpb36i4n-python-neovim-remote-2.5.1/bin/.nvr-real",
> line 4, in
> import nvr.nvr as mod
> File
> Can you do `LD_DEBUG=libs nvr` so that we get a log of what ld's
> trying to load?
I've attached the full log. The first mention of musl is on line 200 and
everything seems to happen pretty fast, here's the most relevant
portion:
16405: find library=libc.musl-x86_64.so.1 [0];
Hi Athena,
Athena Martin via Bug reports for GNU Guix writes:
> On an Alpine Linux Edge host, I reproduce with:
>
> $ guix install python-neovim-remote
> $ nvr
>
> It's possible that there's some quirk of my specific environment.
>
> (I'm currently in the process of switching to Guix System so
> > ImportError: libc.musl-x86_64.so.1: cannot open shared object file:
> > No such file or directory
>
> Could you provide a command to reproduce this?
On an Alpine Linux Edge host, I reproduce with:
$ guix install python-neovim-remote
$ nvr
It's possible that there's some quirk of my
Hi,
Athena Martin skribis:
> I've had experiences now with multiple Guix packages, including gajim
> (bug 60235) and now python-neovim-remote, which have an issue where
> Python tries to dlopen() libc, but finds the system libc instead of
> Guix's, resulting on Alpine Linux hosts in a crash
I've had experiences now with multiple Guix packages, including gajim
(bug 60235) and now python-neovim-remote, which have an issue where
Python tries to dlopen() libc, but finds the system libc instead of
Guix's, resulting on Alpine Linux hosts in a crash with this message:
ImportError:
12 matches
Mail list logo
