Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2007627 - F36FailsToInstall: python3-spyder-kernels
Summary: F36FailsToInstall: python3-spyder-kernels
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: python-spyder-kernels
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Mukundan Ragavan
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 2008855 (view as bug list)
Depends On:
Blocks: F36FailsToInstall
TreeView+ depends on / blocked
 
Reported: 2021-09-24 12:40 UTC by Miro Hrončok
Modified: 2021-10-04 15:50 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-10-04 15:50:14 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Miro Hrončok 2021-09-24 12:40:14 UTC
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!

Comment 1 Mukundan Ragavan 2021-09-25 00:22:39 UTC
A whole lot of spyder related packages have completely messed up version dependencies in Fedora.

Very unfortunate.

Comment 2 Lumír Balhar 2021-09-29 09:17:27 UTC
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.

Comment 3 Mamoru TASAKA 2021-09-29 11:15:31 UTC
*** Bug 2008855 has been marked as a duplicate of this bug. ***

Comment 4 Mamoru TASAKA 2021-09-29 11:20:47 UTC
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

Comment 5 Mukundan Ragavan 2021-09-30 01:48:22 UTC
(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

Comment 6 Lumír Balhar 2021-09-30 06:29:07 UTC
(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?

Comment 7 Mamoru TASAKA 2021-09-30 07:09:38 UTC
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).

Comment 8 Mukundan Ragavan 2021-09-30 10:03:02 UTC
(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.

Comment 9 Mukundan Ragavan 2021-09-30 10:06:34 UTC
(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.

Comment 10 Mukundan Ragavan 2021-10-02 11:08:20 UTC
built on rawhide.

Comment 11 Miro Hrončok 2021-10-04 15:50:14 UTC
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!


Note You need to log in before you can comment on or make changes to this bug.