Spec URL: https://download.copr.fedorainfracloud.org/results/ppfeister/torrequest/fedora-40-x86_64/07435126-python-torrequest/python-torrequest.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/ppfeister/torrequest/fedora-40-x86_64/07435126-python-torrequest/python-torrequest-0.1.0-1.fc40.src.rpm Description: Simple Python interface for HTTP(s) requests over Tor Fedora Account System Username: ppfeister
Copr build: https://copr.fedorainfracloud.org/coprs/build/7435136 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2280050-python-torrequest/fedora-rawhide-x86_64/07435136-python-torrequest/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
This is the first package of a few that would be submitted to the repository. I plan to package one or two other Python dependencies that are available via PyPi, and then package a Python OSINT tool where I currently stand as a maintainer.
Disregard. Closing for now as there is a discovered change to eligibility. Will re-address after fix.
Re-opening request for review and sponsorship. There were some concerns raised that the license type may have been entered incorrectly, but those concerns have been addressed. The applicable license is in fact MIT as we had originally documented, and there is no conflict. _Apologies for the stacked updates!_
The license text is not present in the PyPI sdist, nor even in the upstream git repository https://github.com/erdiaker/torrequest/, but the terms of the chosen license (MIT, https://spdx.org/licenses/MIT.html) would require it to be reproduced in “all copies or substantial portions of the Software.” Please read https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text for instructions on dealing with this situation. By far the best choice would be if you could manage to contact upstream and get them to agree to add a license file, even if they fail to produce a new release and you have to patch it in. Since it sounds like you are involved in the sherlock project upstream, you should be aware that there are some potentially significant known issues in torrequest, including https://github.com/erdiaker/torrequest/issues/17, and that torrequest appears to be effectively unmaintained upstream at this point. That doesn’t mean you can’t package it in Fedora, but does put an additional burden on you as packager.
Note that https://github.com/erdiaker/torrequest/pull/3 was merged upstream, and should probably be backported as a patch, but that there are some additional changes in https://github.com/erdiaker/torrequest/pull/20/commits/482285416be1af7a6ca32b0f2a2df03f46c93ee4 that may also be necessary. The addition of a LICENSE file in that PR is not OK to patch in downstream as-is, however, because there is no copyright statement for the original author.
> The license text is not present in the PyPI sdist, nor even in the upstream git repository https://github.com/erdiaker/torrequest/, but the terms of the chosen license (MIT, https://spdx.org/licenses/MIT.html) would require it to be reproduced in “all copies or substantial portions of the Software.” > > Please read https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text for instructions on dealing with this situation. By far the best choice would be if you could manage to contact upstream and get them to agree to add a license file, even if they fail to produce a new release and you have to patch it in. The License text is available, but it was indicated to be MIT in the Readme. I figured then this was the best was to meet that burden according to the linked document, but I agree now that patching would probably be the more ~proper~ method, if anything. > The addition of a LICENSE file in that PR is not OK to patch in downstream as-is, however, because there is no copyright statement for the original author. Would the reliance on the author's note in the Readme that the project is covered by the MIT License be sufficient for this or would the actual full text be necessary in the upstream? ___ We ARE looking at replacing this, though, due to reasons that you also mentioned. I believe that we may put this one on hold for that reason, removing the depend from the main project where necessary. Will address that here once a decision is made.
> Would the reliance on the author's note in the Readme that the project is > covered by the MIT License be sufficient for this or would the actual full > text be necessary in the upstream? The MIT license specifically requires the full text to be included in order to comply with the license. There are some licenses where just referring to the license is good enough, and the license text is just “nice to have,” but MIT is not one of them. Per https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text, “in situations where upstream is unresponsive, unable, or unwilling to provide proper full license text as part of the source code, and the indicated license requires that the full license text be included,” you have the option to make a good-faith guess at the intended license text and add that downstream. You should really read the linked guidelines section in its entirety before attempting that, and you’re expected to make a serious effort to get upstream to provide the correct license text first, but it is an option.
Heard. I was (initially) relying on this section from the docs: > However, in situations where upstream is unresponsive [...] and the indicated license requires that the full license text be included, Fedora Packagers must either: > > Include a copy of what they believe the license text is intended to be, as part of the Fedora package in %license, in order to remain in compliance. taking into account the original author's radio silence as well. I do see that the text itself isn't included here, though, and %license doesn't expand into anything, which wouldn't technically satisfy the requirement. This was the first package of the bunch and it had a good few issues. Those have been somewhat worked out with through repetition on the other packages and via some good feedback. I could fix this package but I may now opt out due to the earlier discussed concerns.
Considering the license concern, upstream abandonment, etc, this isn't a great candidate for packaging. I've successfully patched out this dependency and will be working to move that change upstream on sherlock-project. With this being a less than ideal package and no longer a hard blocker, I'm closing this request once and for all and will be shifting focus to sherlock and exrex.