https://bugzilla.redhat.com/show_bug.cgi?id=1908526 noon@xxxxxxxxxxx changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(noon@xxxxxxxxxxx) | --- Comment #8 from noon@xxxxxxxxxxx --- > Can you tell me exactly how to see the “link anchor” that is “not > found”? If I know exactly what you’re talking about, maybe I can > figure out what is going wrong. I mean in the output from fedora-review: Texinfo files are installed using install-info in %post and %preun if package has .info files. Note: Texinfo .info file(s) in python3-opentracing See: https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_texinfo This URL has an anchor part (#_texinfo) which is not resolved inside the HTML page (because that section has been deleted, as you explained). I guess fedora-review should be updated to not suggest this anymore... So I've created this PR, which is now merged: https://pagure.io/FedoraReview/pull-request/412 Concerning the tornado issue: failed to import class 'tornado.TornadoScopeManager' from module 'opentracing.scope_managers'; the following exception was raised: No module named 'tornado.stack_context' > There is also a problem importing opentracing.scope_managers.tornado > because upstream is still not properly compatible with Tornado 6 and > later: https://github.com/opentracing/opentracing-python/issues/136. > This is not just a documentation problem, of course. In fact, depending on the versions of Python and of Tornado, some scope managers from OpenTracing can or can't be used. See https://github.com/opentracing/opentracing-python/pull/118 https://github.com/opentracing-contrib/python-tornado/pull/10 Basically, upstream's TornadoScopeManager is useful for contexts with a Tornado 4 or 5 based on gen.coroutine. With Tornado 5 or 6 based on async/await, the correct ScopeManager would rather be ContextVarsScopeManager. TornadoScopeManager cannot even be imported with Tornado 6. As long as upstream wants to support older Tornados based on gen.coroutine, they won't delete TornadoScopeManager. But that's basically a question for users of the opentracing library, who should make the correct choice. For building this package, the only impact is a few sphinx warnings. The error using sphinx seems to be some race condition due to the use of %make_build which inserts a -j12. I've removed it, and now it works correctly. I think I have now fixed all reported issues and remarks. The result is: Copr: https://copr.fedorainfracloud.org/coprs/noon/python-opentracing/build/2022866/ Koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=62701779 Spec: https://download.copr.fedorainfracloud.org/results/noon/python-opentracing/fedora-rawhide-x86_64/02022866-python-opentracing/python-opentracing.spec SRPM: https://download.copr.fedorainfracloud.org/results/noon/python-opentracing/fedora-rawhide-x86_64/02022866-python-opentracing/python-opentracing-2.4.0-1.fc35.src.rpm -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
