https://bugzilla.redhat.com/show_bug.cgi?id=1908526 --- Comment #6 from code@xxxxxxxxxxxxxxxxxx --- > I was wondering why I had so much trouble finding how to register info files... Now I understand: it's implicit ;) It’s frustrating how hard it is to track changes in required scriptlets in Fedora. Sometimes there is a “Change” you can point to, like https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets, but sometimes there isn’t. You can see that it was a couple of years ago that the section about the texinfo scriptlets was removed from the Guidelines (https://pagure.io/packaging-committee/c/4485c124280cc138ba9f6cbda3b922a51ddd127e?branch=master). That history shows the scriptlets were last needed in Fedora 27. They were removed from the coreutils package, a major user of info pages, around the same time (https://src.fedoraproject.org/rpms/coreutils/c/9cc8a839e2dcb8ca42922452629941242f26150b?branch=rawhide, https://src.fedoraproject.org/rpms/coreutils/c/5decf6eab4c45e52d995f0223d9f9396fe09d821?branch=rawhide). And I can’t even point you to what it was that changed to make the scriptlets obsolete. 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 do know that there are some rough edges in the documentation build. It’s trying to download intersphinx inventory 'https://docs.python.org/objects.inv' to cross-link against other packages’ documentation, and failing because package builds can’t access the network from mock or koji. 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. > Concerning EPEL, this is not the target of this submission, but I will certainly try to make an EPEL8 package if and when this one succeeds. As far as I understood, in Fedora this is done by creating a specific branch, so I'll put changes like "python3-setuptools" in that branch. Some maintainers prefer “one true spec file” with conditionals for EPEL, while others prefer to let the branches diverge and keep the spec files cleaner. I sometimes do “one true spec file” when the differences are trivial, but more often find myself maintaining separate branches and cherry-picking commits as you intend to do, especially with Python packages where the RPM macro support has changed so much. > None of these two seem to exist as Fedora packages. So I think I'll stick to a manual list of BuildRequires... This is perfectly reasonable. I certainly wouldn’t package a linter plugin like flake8-quotes just for this purpose! Since %pyproject_buildrequires simply prints BR’s to stdout, you can filter them, e.g. %generate_buildrequires ( %pyproject_buildrequires -x tests ) | grep -vE 'doubles|flake8-quotes' or, more conventionally, patch setup.py to remove the unwanted BR’s. Any of these requires some attention during upstream updates, and falling back to manual BR’s is probably the simplest choice. > Thanks to your review, I've learned about fedora-review. After corrections from your input, it still complains about two particular things: a deprecated package, and Info documentation. Thanks for pushing the mock change upstream. This is the right thing to do (and I see your PR was accepted). Please link the upstream bug in a comment above your patch in the spec file (https://docs.fedoraproject.org/en-US/packaging-guidelines/PatchUpstreamStatus/). I believe the diagnostic on info pages is a fedora-review bug (like https://bugzilla.redhat.com/show_bug.cgi?id=1409315), and one of us should report it after we’re done here. > This is my first package: I need a sponsor. Unfortunately, it will be a couple more months until I am eligible to apply for sponsor status (https://fedoraproject.org/wiki/How_to_sponsor_a_new_contributor), so I can’t help out with this part in the short term. -- 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
