Hello, Please note that this comment was generated automatically. If you feel that this output has mistakes, please contact me via email (mhroncok). Your package (python-spyder-kernels) Fails To Install in Fedora 36: can't install python3-spyder-kernels: - nothing provides (python3.10dist(jupyter-client) < 7 with python3.10dist(jupyter-client) >= 5.3.4) needed by python3-spyder-kernels-1:2.1.1-1.fc36.noarch If you know about this problem and are planning on fixing it, please acknowledge so by setting the bug status to ASSIGNED. If you don't have time to maintain this package, consider orphaning it, so maintainers of dependent packages realize the problem. If you don't react accordingly to the policy for FTBFS/FTI bugs (https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/), your package may be orphaned in 8+ weeks. P.S. The data was generated solely from koji buildroot, so it might be newer than the latest compose or the content on mirrors. P.P.S. If this bug has been reported in the middle of upgrading multiple dependent packages, please consider using side tags: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages Thanks!
A whole lot of spyder related packages have completely messed up version dependencies in Fedora. Very unfortunate.
I've updated the jupyter-client package to the latest upstream version. Interesting is that I've tried to build spyder-kernels with the lastest jupyter-client in COPR and it worked, see: https://copr.fedorainfracloud.org/coprs/lbalhar/jupyter-client/build/2832831/ This is caused by the fact that there is no limit for jupyter-client version in the specfile but the generated requirements take the limit from the upstream metadata. The best thing we can do here is to test the package with the latest jupyter-client and if it works, open a PR to change the version upstream.
*** Bug 2008855 has been marked as a duplicate of this bug. ***
This currently blocks Fedora-Astronomy_KDE-Live and Fedora-Scientific_KDE-Live https://koji.fedoraproject.org/koji/taskinfo?taskID=76454150 https://koji.fedoraproject.org/koji/taskinfo?taskID=76454280
(In reply to Lumír Balhar from comment #2) > I've updated the jupyter-client package to the latest upstream version. > Interesting is that I've tried to build spyder-kernels with the lastest > jupyter-client in COPR and it worked, see: > https://copr.fedorainfracloud.org/coprs/lbalhar/jupyter-client/build/2832831/ > > This is caused by the fact that there is no limit for jupyter-client version > in the specfile but the generated requirements take the limit from the > upstream metadata. The best thing we can do here is to test the package with > the latest jupyter-client and if it works, open a PR to change the version > upstream. Most of the packages maintain, I just let RPM generate dependencies via metadata. The strategy to build is fine by me. Will you be able to commit directly or should I go ahead and do it? Thanks Lumír
(In reply to Mukundan Ragavan from comment #5) > Most of the packages maintain, I just let RPM generate dependencies via > metadata. That's the correct way. Python packages must use the automatic generator and should not repeat dependencies manually in the specfile. > The strategy to build is fine by me. Will you be able to commit directly or > should I go ahead and do it? I'm not sure I understand you. There is no problem in the build. What we can do now is to release the upper limit in the upstream metadata during the build and then test the package. If it works, we can submit the same change to upstream. I can prepare a PR for this. Are you able to test the package?
Note that it seems that the upstream intentionally added version constraint for jupyter-client: https://github.com/spyder-ide/spyder-kernels/commit/e31282b6488fad5d0a69d9c9e398b2a15fd249db I don't know what "how to support it" means, but interpreting literally, current spyder-kernels does not support "jupyter-client >=7" in some way (I don't know the detail).
(In reply to Lumír Balhar from comment #6) > > > The strategy to build is fine by me. Will you be able to commit directly or > > should I go ahead and do it? > > I'm not sure I understand you. There is no problem in the build. What we can > do now is to release the upper limit in the upstream metadata during the > build and then test the package. If it works, we can submit the same change > to upstream. I can prepare a PR for this. Are you able to test the package? I should have been clearer. I will test the package and build it with relaxed versions later today.
(In reply to Mamoru TASAKA from comment #7) > Note that it seems that the upstream intentionally added version constraint > for jupyter-client: > > https://github.com/spyder-ide/spyder-kernels/commit/ > e31282b6488fad5d0a69d9c9e398b2a15fd249db > > I don't know what "how to support it" means, but interpreting literally, > current spyder-kernels does not support "jupyter-client >=7" in some way (I > don't know > the detail). Yeah, in my experience spyder tends to be slow to catch up to latest versions of its dependencies and Fedora, of course, moves fast. That's the reason I carry this patch in spyder - https://src.fedoraproject.org/rpms/spyder/blob/rawhide/f/spyder-5.1.5-relax-versions.patch In my experience, my "strategy" (if you can call it that) provides a *working* spyder in Fedora. There are some errors (typically Qt stuff) though.
built on rawhide.
Hello, Please note that this comment was generated automatically. If you feel that this output has mistakes, please contact me via email (mhroncok). All subpackages of a package against which this bug was filled are now installable or removed from Fedora 36. Thanks for taking care of it!