Spec URL: https://fdedden.fedorapeople.org/ghc-monadLib.spec SRPM URL: https://fdedden.fedorapeople.org/ghc-monadLib-3.10.1-1.fc41.src.rpm Description: A collection of monad transformers. Fedora Account System Username: fdedden
This package built on koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=120245001
Copr build: https://copr.fedorainfracloud.org/coprs/build/7720589 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2296801-ghc-monadlib/fedora-rawhide-x86_64/07720589-ghc-monadLib/fedora-review/review.txt Found issues: - No gcc, gcc-c++ or clang found in BuildRequires Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/C_and_C++/ Please know that there can be false-positives. --- 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.
Looks like a License inconsistency here. The License file is MIT (according to licensecheck) but the .cabal file says BSD3. Can you please verify this with upstream/maintainer?
https://github.com/yav/monadlib/issues/11
As a workaround perhaps we could go with "MIT or BSD-3-Clause" for now? With a hope/plan to update the tag once it is confirmed, unless you have some way to contact the author? (Older example https://github.com/yav/haskell-lexer/issues/5 was MIT, so one might expect the same outcome here possibly.)
I have sent an email to the package maintainer for clarification. Let's wait on that for a while.
Thanks - the license changed to ISC in git and maybe there will be a release too.
Nice. What do we do for this release? 1. Wait for the release on hackage, and (as an exception) base the package on the hackage version instead of the stackage release? 2. Manually adjust the license file or field. This way we would deviate from upstream. 3. Just package it as is: it won't be correct, but atleast we stay true to upstream. This will be fixed when the next version hits stackage.
(In reply to Frank Dedden from comment #8) > Nice. What do we do for this release? > > 1. Wait for the release on hackage, and (as an exception) base the package > on the hackage version instead of the stackage release? > 2. Manually adjust the license file or field. This way we would deviate from > upstream. > 3. Just package it as is: it won't be correct, but atleast we stay true to > upstream. This will be fixed when the next version hits stackage. Well I am assuming it would just be a minor version bump. Maybe let's see how long 1 takes. Otherwise maybe a patch from github could be applied I think. From the Fedora perspective I would prefer 1 or patching, that would be better I think. It is okay to use "cabal-rpm spec --stream hackage" in this case, though actually it seems monadLib is not in Stackage currently, so I think cabal-rpm will pick it from Hackage anyway.
https://hackage.haskell.org/package/monadLib-3.10.3
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.
*** This bug has been marked as a duplicate of bug 2318531 ***