Hello, Please note that this comment was generated automatically by https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py If you feel that this output has mistakes, please open an issue at https://pagure.io/releng/ Your package (spyder) Fails To Install in Fedora 40: can't install python3-spyder: - nothing provides (python3.12dist(spyder-kernels) < 2.5~~ with python3.12dist(spyder-kernels) >= 2.4.4) needed by python3-spyder-5.4.5-23.fc40.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. To reproduce, use the koji/local repo only, e.g. in mock: $ mock -r fedora-40-x86_64 --config-opts mirrored=False install python3-spyder 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!
The python-spyder-kernels package was updated to a 3.0.0 beta release in https://src.fedoraproject.org/rpms/python-spyder-kernels/pull-request/2, but spyder 5.x still does support spyder-kernels 2.5 or later, even in the upstream 5.x branch—let alone spyder-kernels 3.x. Let’s try to double-check for versioned dependencies before updating packages in this stack, since many versions are tightly bounded. With the fedora-repos-rawhide package installed, this is enough to show that there are problems (but not point out where there are): $ repoquery -q --repo=rawhide{,-source} --requires -a | grep spyder-kernels | grep '<' (python3.12dist(spyder-kernels) < 2.5~~ with python3.12dist(spyder-kernels) >= 2.4.4) (python3dist(spyder-kernels) < 2.5~~ with python3dist(spyder-kernels) >= 2.4.4)
My bad! I should have known these were tied together. Since Spyder 6.0.0b2 won't be available anytime soon due to the newly introduced depenedency on `pyuca`, which requires a license review (bug 2242026), I think our options are: 1. Pull the update (releng doesn't like that) 2. Remove the upper bound for `spyder-kernels` in `spyder` (that builds fine, but I haven't tested the result) 3. Update `spyder` to `6.0.0a1`, which has no dependency on `pyuca` (requires tinkering with the upper bound a little) 4. Do nothing I'm strongly in favor of option 3. It keeps the path open for future updates and should be the least diversion from upstream. I have branches ready for option 2 and option 3. I will push them both to my fork in order to leverage on the extra CI testing. Once we decided on the way forward I can push an update to rawhide that will fix this.
It seems like option 3 could be OK, if we are reasonably confident that (1) you will drive the license review for pyuca to some sort of successful conclusion in a reasonable period, and (2) Spyder 6.0 final is likely to be released in time for F40 to ship a stable version. I think it would be unfortunate to be stuck on an early alpha for a long time even in Rawhide. I would be shocked if option 2 didn’t break something in Spyder. There is an option 5: downgrade python-spyder-kernels and introduce an Epoch. Nobody likes epochs, but if we aren’t very confident in option 3, it does offer a way to put things back as they were for now. Jonathan, what do you think we should do?
(In reply to Ben Beasley from comment #3) > It seems like option 3 could be OK, if we are reasonably confident that (1) > you will drive the license review for pyuca to some sort of successful > conclusion in a reasonable period, and (2) Spyder 6.0 final is likely to be > released in time for F40 to ship a stable version. I think it would be > unfortunate to be stuck on an early alpha for a long time even in Rawhide. Fingers crossed! I submitted the corresponding PR: https://src.fedoraproject.org/rpms/spyder/pull-request/9 > I would be shocked if option 2 didn’t break something in Spyder. Let me know if you'd like some shock therapy? ;) I have it ready, but I decided not to submit it as a PR yet. But I can easily do so or build it in Copr if requested. > There is an option 5: downgrade python-spyder-kernels and introduce an > Epoch. Nobody likes epochs, but if we aren’t very confident in option 3, it > does offer a way to put things back as they were for now. I think that's our "escape from jail" card. I'm keeping that up my sleeve if 6.x is not released before F40. > Jonathan, what do you think we should do? I'll wait for Jonathan to comment before doing anything with the PR.
Should we proceed with option 3 since Jonathan is not responding?
I'm setting needinfo flag for Jonathan. I'll leave that until the end of the week. If he still doesn't respond, I will merge https://src.fedoraproject.org/rpms/spyder/pull-request/9.
(In reply to Sandro from comment #6) > I'm setting needinfo flag for Jonathan. I'll leave that until the end of the > week. If he still doesn't respond, I will merge > https://src.fedoraproject.org/rpms/spyder/pull-request/9. PR has been merged.
FEDORA-2023-dbfbf4b0a1 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-dbfbf4b0a1
FEDORA-2023-dbfbf4b0a1 has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.