Comments
music
For testing with python-fastapi, requires: FEDORA-2022-dbf6e00ba8
Requires: FEDORA-2022-de9ab3ee07
Fails to install:
Error:
Problem: cannot install the best candidate for the job
- nothing provides python3.9dist(scikit-learn) >= 1.0.1 needed by python3-imbalanced-learn-0.9.0-3.fc34.noarch
FEDORA-2022-117a79c82d has the same issue but is already stable.
Awesome! Glad it’s working as expected.
This would break c4core-devel, which has an arched dependency on debugbreak-devel.
This would break c4core-devel, which has an arched dependency on debugbreak-devel.
This update has been unpushed.
This update includes several breaking ABI and API changes, which shouldn’t generally occur in a stable release without an exception granted by FESCo. Similarly, a new major version of Blender that significantly changes the user experience doesn’t seem appropriate for a stable release without a FESCo exception.
It’s too late now, but this update included an ABI/soversion break in OpenVDB—which happens with every minor version. See https://bugzilla.redhat.com/show_bug.cgi?id=2031326. A rebuild of USD is probably the only path forward.
Works great with python-rpm-macros-3.10-20.fc33. Looking forward to seeing this in stable.
Works great with python-rpm-macros-3.10-41.fc34. Looking forward to seeing this in stable.
Works great with python-rpm-macros-3.10-10.fc35. Looking forward to seeing this in stable.
Thanks for testing!
Thanks for testing!
I can confirm the bugs are fixed, in that
mock -r fedora-35-s390x --enablerepo=local -i python3-sympy
now succeeds by installing python3-pyglet.
General pyglet functionality should not have changed, but I have not tested it.
Devhelp should be working again now, while still dealing with the JavaScript-related packaging policy issues. See also the corresponding update on cairomm.
Re-testing would be appreciated.
It looks like the approach I described worked to comply with packaging guidelines without breaking Devhelp. Thanks for noticing. Re-testing is appreciated.
I’ll be applying the same approach to keep Devhelp working in all releases for which I created a similar update, as well as for the cairomm1.16, gconfmm26, and libglademm24 packages.
I removed the Doxygen-generated HTML reference manual due to the issues raised in https://bugzilla.redhat.com/show_bug.cgi?id=2006555 and further discussed on the packaging mailing list at https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/thread/LLUAURXZVADATHK65HBPPBHKF4EM4UC3/. I built a PDF version instead, as it seems that may still be acceptable under the current guidelines. Unfortunately, now that the policy issue has been raised, doing nothing about it is not an option.
What I didn’t realize was that the devhelp XML file references the Doxygen HTML files, and is useless without them.
I’m going to try re-enabling the HTML documentation, but stripping out all the JavaScript, and see if that renders as expected in the Devhelp application, even if it’s degraded in the browser.
I removed the Doxygen-generated HTML reference manual due to the issues raised in https://bugzilla.redhat.com/show_bug.cgi?id=2006555 and further discussed on the packaging mailing list at https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/thread/LLUAURXZVADATHK65HBPPBHKF4EM4UC3/. I built a PDF version instead, as it seems that may still be acceptable under the current guidelines. Unfortunately, now that the policy issue has been raised, doing nothing about it is not an option.
What I didn’t realize was that the devhelp XML file references the Doxygen HTML files, and is useless without them.
I’m going to try re-enabling the HTML documentation, but stripping out all the JavaScript, and see if that renders as expected in the Devhelp application, even if it’s degraded in the browser.
This update has been unpushed.