Spec URL: https://jjames.fedorapeople.org/ocaml-reactivedata/ocaml-reactivedata.spec SRPM URL: https://jjames.fedorapeople.org/ocaml-reactivedata/ocaml-reactivedata-0.2.2-1.fc36.src.rpm Fedora Account System Username: jjames Description: ReactiveData is an OCaml module for functional reactive programming (FRP) based on React. It adds support for incremental changes in data structures by reasoning on patches instead of absolute values.
- The opam file states that the license is "LGPL-3.0 with OCaml linking exception"; however, the included LICENSE file states that it is LGPL v2.1 with exceptions. Furthermore, the files "src/reactiveData.ml" and "src/reactiveData.mli" contain a header stating that it uses version v2.1 of LGPL, "or (at your option) any later version", so "LGPLv2+". Please clarify the license with upstream. - Please open a Pull Request on GitHub to upstream your patch, if possible. - I'm wondering if the package should not be named ocaml-reactiveData, with uppercase D (cf https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#_case_sensitivity and https://github.com/ocsigen/reactiveData/blob/0.2.2/pkg/META) Otherwise, - Version packaged is the latest tagged release (0.2.2) - Package builds in mock - Conforms to the Packaging Guidelines and the OCaml Packaging Guidelines Rpmlint results: ocaml-reactivedata-debuginfo.x86_64: W: unstripped-binary-or-object /usr/lib/debug/usr/lib64/ocaml/reactiveData/reactiveData.cmxs-0.2.2-1.fc36.x86_64.debug ocaml-reactivedata-devel.x86_64: E: static-library-without-debuginfo /usr/lib64/ocaml/reactiveData/reactiveData.a ocaml-reactivedata.x86_64: E: shared-library-without-dependency-information /usr/lib64/ocaml/reactiveData/reactiveData.cmxs ocaml-reactivedata-debuginfo.x86_64: E: shared-library-without-dependency-information /usr/lib/debug/usr/lib64/ocaml/reactiveData/reactiveData.cmxs-0.2.2-1.fc36.x86_64.debug ocaml-reactivedata-debuginfo.x86_64: W: no-documentation ocaml-reactivedata-debugsource.x86_64: W: no-documentation ocaml-reactivedata-debugsource.x86_64: E: incorrect-fsf-address /usr/src/debug/ocaml-reactivedata-0.2.2-1.fc36.x86_64/_build/src/reactiveData.ml ocaml-reactivedata-devel.x86_64: E: incorrect-fsf-address /usr/lib64/ocaml/reactiveData/reactiveData.mli ocaml-reactivedata-debuginfo.x86_64: W: dangling-relative-symlink /usr/lib/debug/.build-id/db/1f58092f7a192430959dc33593ca6be0f91cdd ../../../.build-id/db/1f58092f7a192430959dc33593ca6be0f91cdd
(In reply to Olivier Lemasle from comment #1) > - The opam file states that the license is "LGPL-3.0 with OCaml linking > exception"; however, the included LICENSE file states that it is LGPL v2.1 > with exceptions. > Furthermore, the files "src/reactiveData.ml" and "src/reactiveData.mli" > contain a header stating that it uses version v2.1 of LGPL, "or (at your > option) any later version", so "LGPLv2+". > Please clarify the license with upstream. Good catch. I have asked upstream about the license: https://github.com/ocsigen/reactiveData/issues/28 > - Please open a Pull Request on GitHub to upstream your patch, if possible. The patch isn't appropriate for upstream as is. That's the right patch for Fedora, because we have a new enough version of OCaml that the Pervasives to Stdlib move was made. However, upstream may want or need to support older versions of OCaml, prior to that change. The right patch for upstream would involve adding a dependency on stdlib-shims. However, we do not have the stdlib-shims package in Fedora, because we don't need it. Standard practice is to patch out such dependencies, so I would end up patching this package anyway. I can try suggesting the stdlib-shims approach to upstream. I will need a day or two to figure out how to test such a patch, though. > - I'm wondering if the package should not be named ocaml-reactiveData, with > uppercase D (cf > https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/ > #_case_sensitivity and > https://github.com/ocsigen/reactiveData/blob/0.2.2/pkg/META) I could go either way with the name. The files will be installed to %{_libdir}/ocaml/reactiveData in either case, so the OCaml tools will have the correct name, regardless of what we call the Fedora package. I don't have a strong opinion on the matter, so I'll default to what I already have unless you insist.
(In reply to Jerry James from comment #2) > > - Please open a Pull Request on GitHub to upstream your patch, if possible. > > The patch isn't appropriate for upstream as is. That's the right patch for > Fedora, because we have a new enough version of OCaml that the Pervasives to > Stdlib move was made. However, upstream may want or need to support older > versions of OCaml, prior to that change. The right patch for upstream would > involve adding a dependency on stdlib-shims. However, we do not have the > stdlib-shims package in Fedora, because we don't need it. Standard practice > is to patch out such dependencies, so I would end up patching this package > anyway. Ok, that's perfectly clear. > > - I'm wondering if the package should not be named ocaml-reactiveData, with > > uppercase D (cf > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/ > > #_case_sensitivity and > > https://github.com/ocsigen/reactiveData/blob/0.2.2/pkg/META) > > I could go either way with the name. The files will be installed to > %{_libdir}/ocaml/reactiveData in either case, so the OCaml tools will have > the correct name, regardless of what we call the Fedora package. I don't > have a strong opinion on the matter, so I'll default to what I already have > unless you insist. Ok, that's fine with me. We just have to wait from upstream for the license clarification (the incorrect FSF address is not blocker as soon as upstream is informed: https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address). I hope you'll get an answer, as the GitHub repo does not have much activity lately :-(
(In reply to Olivier Lemasle from comment #3) > We just have to wait from upstream for the license clarification (the > incorrect FSF address is not blocker as soon as upstream is informed: > https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address). > I hope you'll get an answer, as the GitHub repo does not have much activity > lately :-( It doesn't, but the committers to that repo have been active elsewhere. If they don't reply soon, I will try to contact them via email.
For the record, I sent email two days ago, on December 10. I will wait a few days to see if someone responds. If not, then since LGPLv3 is stricter than (and included in) LGPLv2+, I think we should go with that as the license.
I have not received any responses to my attempts to communicate with upstream. Can we proceed on the theory that, although some of the individual files are LGPLv2+, the project as a whole is LGPLv3?
We can wait a moment again? Maybe LGPLv2 is not strict.
(In reply to Jun.Miao from comment #7) > We can wait a moment again? Maybe LGPLv2 is not strict. I don't know what you mean by "Maybe LGPLv2 is not strict". Can you clarify, please? I have tried contacting upstream by email again. But I have to ask how long it is reasonable to wait. On what day do we give up and proceed without upstream's input? I don't see a problem with proceeding right now. The LGPLv3 license is compatible with the individual file licenses.
@o.lemasle can we proceed with the license as it is? I have attempted to contact upstream a third time, still with no response. As noted in comment 5 and comment 6, the LGPLv3 license given in the opam file is stricter than the LGPLv2+ license on some of the individual files. Can we proceed with the assumption that LGPLv3 is correct?
@o.lemasle do you intend to continue as reviewer?
Yes, I think it is ok to proceed. Package approved.
Package was never imported, resetting ticket status.
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.