Bug 2224870
| Summary: | F39FailsToInstall: python3-pynn | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Fedora Fails To Install <fti-bugs> |
| Component: | python-pynn | Assignee: | Ankur Sinha (FranciscoD) <sanjay.ankur> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | gui1ty, mtasaka, neuro-sig, sanjay.ankur |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | python-pynn-0.10.1-5.fc39 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-07-27 10:26:35 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 2168845 | ||
|
Description
Fedora Fails To Install
2023-07-23 18:15:30 UTC
Hmm. I guess something's missing in the spec file. The mentioned library is part of the package: $ dnf --cache --repo=rawhide repoquery --list python3-pynn | grep 'lib.*so' /usr/lib64/nest/libpynn_extensions.so /usr/lib64/nest/pynn_extensions.so /usr/lib64/python3.11/site-packages/pyNN/neuron/nmodl/poisson_stim_refractory.mod /usr/lib64/python3.11/site-packages/pyNN/neuron/nmodl/stdwa_softlimits.mod /usr/lib64/python3.11/site-packages/pyNN/neuron/nmodl/stdwa_songabbott.mod /usr/lib64/python3.11/site-packages/pyNN/neuron/nmodl/stochastic_tsodyksmarkram.mod /usr/lib64/python3.11/site-packages/pyNN/neuron/nmodl/tsodyksmarkram.mod /usr/lib64/python3.11/site-packages/pyNN/neuron/nmodl/x86_64/.libs/libnrnmech.so --> /usr/lib64/python3.11/site-packages/pyNN/neuron/nmodl/x86_64/libnrnmech.so <-- /usr/lib64/python3.11/site-packages/pyNN/neuron/nmodl/x86_64/poisson_stim_refractory.c /usr/lib64/python3.11/site-packages/pyNN/neuron/nmodl/x86_64/poisson_stim_refractory.o /usr/lib64/python3.11/site-packages/pyNN/neuron/nmodl/x86_64/stdwa_softlimits.c /usr/lib64/python3.11/site-packages/pyNN/neuron/nmodl/x86_64/stdwa_softlimits.o /usr/lib64/python3.11/site-packages/pyNN/neuron/nmodl/x86_64/stdwa_songabbott.c /usr/lib64/python3.11/site-packages/pyNN/neuron/nmodl/x86_64/stdwa_songabbott.o /usr/lib64/python3.11/site-packages/pyNN/neuron/nmodl/x86_64/stochastic_tsodyksmarkram.c /usr/lib64/python3.11/site-packages/pyNN/neuron/nmodl/x86_64/stochastic_tsodyksmarkram.o /usr/lib64/python3.11/site-packages/pyNN/neuron/nmodl/x86_64/tsodyksmarkram.c /usr/lib64/python3.11/site-packages/pyNN/neuron/nmodl/x86_64/tsodyksmarkram.o /usr/lib64/python3.11/site-packages/pyNN/serialization/__pycache__/sonata.cpython-311.opt-1.pyc /usr/lib64/python3.11/site-packages/pyNN/serialization/__pycache__/sonata.cpython-311.pyc /usr/lib64/python3.11/site-packages/pyNN/serialization/sonata.py But it's not provided: $ dnf --cache --repo=rawhide repoquery --provides python3-pynn | grep 'lib.*so' libpynn_extensions.so()(64bit) And why is `pynn_extensions.so` not provided? Oops! I may have closed bug 2220437 prematurely. While the package was built in Koji succesfully during the mass rebuild for f39, it does fail to install. Right now I'm not able to rebuild it in rawhide getting: `error: 'invalid_port_' is not a member of 'nest'; did you mean 'invalid_port'?` I suppose that's due to the recently updated NEST. Should I reopen bug 2220437? Or do we continue with this bug? There's a PR for updating PyNN to 0.11.0, which requires the newer NEST. Before pushing that we should make sure the package installs properly. Let's continue here. Yeh, upstream changed their build system a little and now the nest etc. extensions are not built as part of the build. I'm looking at how to build those to include in the package now. I've also run into this: https://github.com/NeuralEnsemble/PyNN/issues/781 Alright. Since you are more involved in the update than I am, I'll re-assign to you. I was looking at this bug mostly because it surprised me that there was a new FTI bug filed against PyNN. A. > I'm not able to rebuild it in rawhide getting: `error: 'invalid_port_' is not a member of 'nest'; did you mean 'invalid_port'? For python-pynn 0.10.1, to compile with nest-simulator 3.4 and higher, backporting the following is needed: https://github.com/NeuralEnsemble/PyNN/commit/b45ef114410dd978f4198e416d0e098e8d23f870 (This was due to https://github.com/nest/nest-simulator/commit/5d85811af7a6aebb8de75adb3930a4a5a575f887 ) B. > nothing provides libnrnmech.so()(64bit) needed by python3-pynn-0.10.1-3.fc39.x86_64 libnrnmech.so is not in standard path (i.e. /usr/lib64 or so), so rpmbuild does not add them to Provides. Then the reason why python3-pynn-0.10.1-3.fc39.x86_64 now Requires "libnrnmech.so()(64bit)" while python3-pynn-0.10.1-2.fc38 did not have such Requires is that python3-pynn-0.10.1-2.fc38 was built with neuron simulator 8.0.2 while python3-pynn-0.10.1-3.fc39.x86_64 was built with simulator 8.2.2. With neuron 8.0.2, the created file /usr/lib64/python3.11/site-packages/pyNN/neuron/nmodl/x86_64/special was shell script, but with neuron 8.2.2, the created file /usr/lib64/python3.12/site-packages/pyNN/neuron/nmodl/x86_64/special (python version changed) is now binary, linking against libnrnmech.so, but this "special" file does not have rpath or so, so I am not sure if this file is working correctly. Note that in python3-pynn-0.10.1-2.fc38 , the script /usr/lib64/python3.11/site-packages/pyNN/neuron/nmodl/x86_64/special mentions invalid path /builddir/build/BUILD/PyNN-0.10.0/build/lib/pyNN/neuron/nmodl/x86_64/.libs/libnrnmech.so , so apparently this file was broken. So my question is that is this "special file" needed? If not, for now I will just remove this file and make python3-pynn installable (with version 0.10.1) for now. Oops. I was wrong. libnrnmech.so() Provides were just filtered out. https://src.fedoraproject.org/rpms/python-pynn/blob/521d65f4510f20fa1560bc23fff85850925b2189/f/python-pynn.spec#_15 For now, I will just also filtering out Requires for libnrnmech.so(). Thank you Mamoru for helping out. I don't know the history of why the Provides was filtered out. Ankur (FranciscoD_) or Ben (music) may have some insight on that. I sure missed that line looking at the spec file. Since the package now, without filtering, requires the library, would it make sense to disable the filter, so the Provides works correctly? Of course, the very special `special` file still needs looking into. We might need some advice from upstream on that. Since Ankur is already involved in getting the package updated, I'll leave it to him to decide on what to do with your findings. But your help and expertise is greatly appreciated. Thank you again! Hello! Thanks for all the help! I don't think the special file is required in this particular case, it's a launcher that may be used to launch neuron instead of nrniv: https://nrn.readthedocs.io/en/latest/scripting.html#advanced-usage I'm working on the update now, and will build and test it locally to confirm all of these files that it needs/generates. Closing this one, will track progress in https://bugzilla.redhat.com/show_bug.cgi?id=2209829 > Since the package now, without filtering, requires the library, would it make sense to disable the filter, so the Provides works correctly?
Well, some people prefer to filter out Requires / Provides for libraries installed into non-standard path (i.e. not in /usr/lib{,64} or so),
some people don't filter out. For this package case, I think both is acceptable.
|