Spec URL: https://ignatenkobrain.fedorapeople.org/for-review/python-django3-auth-saml2.spec SRPM URL: https://ignatenkobrain.fedorapeople.org/for-review/python-django3-auth-saml2-0.2.0-1.fc35.src.rpm Description: Django3 auth SAML2 integration. Fedora Account System Username: ignatenkobrain
FTI because it wants pysaml2 version 5 but Fedora has version 6.1.0. > DEBUG util.py:444: Error: > DEBUG util.py:444: Problem: conflicting requests > DEBUG util.py:444: - nothing provides python3.10dist(pysaml2) = 5 needed by python3-django3-auth-saml2-0.2.0-1.fc35.noarch
Also the %python_provide macro is obsolete in Fedora (and the replacement, %py_provides, is not needed for “conventionally-named” Python packages), so it should be dropped. As I understand it under https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text, you will have to wait for upstream to add license text in response to https://github.com/jeremyschulman/django3-auth-saml2/issues/10, or add what you believe to be the correct license text yourself. It doesn’t seem like packaging without license text is an option.
New Spec URL: https://ignatenkobrain.fedorapeople.org/for-review/python-django3-auth-saml2.spec New SRPM URL: https://ignatenkobrain.fedorapeople.org/for-review/python-django3-auth-saml2-0.2.0-1.fc35.src.rpm
(In reply to Ben Beasley from comment #2) > Also the %python_provide macro is obsolete in Fedora (and the replacement, > %py_provides, is not needed for “conventionally-named” Python packages), so > it should be dropped. I'd prefer to have this specific package compatible with EPEL8. > As I understand it under > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > LicensingGuidelines/#_license_text, you will have to wait for upstream to > add license text in response to > https://github.com/jeremyschulman/django3-auth-saml2/issues/10, or add what > you believe to be the correct license text yourself. It doesn’t seem like > packaging without license text is an option. I think it is fine for the time being… Esp. if upstream is not very responsive.
(In reply to Ben Beasley from comment #2) > As I understand it under > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > LicensingGuidelines/#_license_text, you will have to wait for upstream to > add license text in response to > https://github.com/jeremyschulman/django3-auth-saml2/issues/10, or add what > you believe to be the correct license text yourself. It doesn’t seem like > packaging without license text is an option. As far as I know, this is not correct. It's not up the packager to just "guess" which license text is applicable. So it's better to just specify which license upstream intended, file an issue with upstream that the license file is missing, and link that issue from the .spec file. fedora-review even has a checkbox for "does not include license files separate from those supplied by upstream".
> I'd prefer to have this specific package compatible with EPEL8. I think %python_provide is acceptable for this reason, although since it has slightly different semantics and “SHOULD NOT” be used in Fedora (https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_201x/), I think surrounding it with version conditionals (%if %{?el8}/%endif or similar) is ideal. (However, Fedora is full of packages that still use %python_provide, and it certainly isn’t causing any problems that I know of.) > I think it is fine for the time being… Esp. if upstream is not very responsive. > As far as I know, this is not correct. It's not up the packager to just "guess" which license text is applicable. This is not what the guidelines say for licenses that require the text to be included, of which ASL 2.0 is one. My summary applies to this situation, and not to the general case; e.g. for missing license text in a GPLv2+ package, reporting it upstream and moving on would be adequate under the same guidelines. I’ve quoted the relevant section below. https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text > In cases where the upstream has chosen a license that requires that a copy of the license text be distributed along with the binaries and/or source code, but does not provide a copy of the license text (in the source tree, or in some rare cases, anywhere), the packager should do their best to point out this confusion to upstream. This sometimes occurs when an upstream project’s only reference to a license is in a README (where they simply say "licensed under the FOO license"), on their website, or when they simply do not check a copy of the license into their Source tree. Common licenses that require including their texts with all derivative works include ASL 2.0, EPL, BSD and MIT. Packagers should point out to upstream that by not including a proper full license text, they are making it difficult or impossible for anyone to comply with their desired license terms. > > However, 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, 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. It is worth noting that this may place some additional risk on the packager, however, Fedora believes that this risk is minimized by the fact that if the upstream disagrees with what we have distributed as the full license text, they can easily remedy this by making full license text available in the source code. Packagers who choose to do this should ensure that they have exhausted all attempts to work with upstream to include the license text as part of the source code, or at least, to confirm the full license text explicitly with the upstream, as this minimizes the risk on the packager. Packagers should also take copies of license texts from reliable and canonical sources (such as the Fedora Software Licenses page, the FSF licenses page, or the OSI license list), whenever possible. > • Choose not to package that software for Fedora. > > It is important to reiterate that in situations where the indicated license does not imply a requirement that the license be distributed along with the source/binaries, Fedora packagers are NOT required to manually include the full license text when it is absent from the source code. but are still encouraged to point out this issue to upstream and encourage them to remedy it.
Taking this review.
(In reply to Fabio Valentini from comment #5) > (In reply to Ben Beasley from comment #2) > > As I understand it under > > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > > LicensingGuidelines/#_license_text, you will have to wait for upstream to > > add license text in response to > > https://github.com/jeremyschulman/django3-auth-saml2/issues/10, or add what > > you believe to be the correct license text yourself. It doesn’t seem like > > packaging without license text is an option. > > As far as I know, this is not correct. It's not up the packager to just > "guess" which license text is applicable. > So it's better to just specify which license upstream intended, file an > issue with upstream that the license file is missing, and link that issue > from the .spec file. fedora-review even has a checkbox for "does not include > license files separate from those supplied by upstream". When it comes to "standard" licenses, there is no guessing involved, so it's fine. The problem comes when something is BSD/MIT licensed. We *can't* ship anything that is supposedly BSD or MIT licensed without the original license text from the software because those can be anything. There's hundreds of license variants in that category. The Apache, GNU, and Mozilla licenses, on the other hand, are standardized and well-known, so it's not as much of an issue that the license text isn't in the repo, as long as the issue has been reported upstream or a patch has been submitted to add it. I know Tom does this quite a lot for packages that have missing license texts. As soon as upstream accepts the patch, he can ship it downstream in Fedora.
> as long as the issue has been reported upstream or a patch has been submitted to add it. I know Tom does this quite a lot for packages that have missing license texts. As soon as upstream accepts the patch, he can ship it downstream in Fedora. Note that this can also be done for BSD/MIT ones. Suggesting a license text and having them accept it is "good enough" in most cases.
This is an automatic check from review-stats script. This review request ticket hasn't been updated for some time, but it seems that the review is still being working out by you. If this is right, please respond to this comment clearing the NEEDINFO flag and try to reach out the submitter to proceed with the review. If you're not interested in reviewing this ticket anymore, please clear the fedora-review flag and reset the assignee, so that a new reviewer can take this ticket. Without any reply, this request will shortly be resetted.
This is an automatic action taken by review-stats script. The ticket reviewer failed to clear the NEEDINFO flag in a month. As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews we reset the status and the assignee of this ticket.
This is an automatic check from review-stats script. This review request ticket hasn't been updated for some time. We're sorry it is taking so long. If you're still interested in packaging this software into Fedora repositories, please respond to this comment clearing the NEEDINFO flag. You may want to update the specfile and the src.rpm to the latest version available and to propose a review swap on Fedora devel mailing list to increase chances to have your package reviewed. If this is your first package and you need a sponsor, you may want to post some informal reviews. Read more at https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group. Without any reply, this request will shortly be considered abandoned and will be closed. Thank you for your patience.
This is an automatic action taken by review-stats script. The ticket submitter failed to clear the NEEDINFO flag in a month. As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews we consider this ticket as DEADREVIEW and proceed to close it.