https://bugzilla.redhat.com/show_bug.cgi?id=2432762
--- Comment #8 from [email protected] --- JL: It seems that many of the project files don't explicitly mention a license that doesn't change the overall project license which notes it is licensed as LGPL if statically linked with libdwarf, but that isn't the case with the current build. The Readme mentiones explicitly that it is MIT. It is a bit confusing that they spend more text talking about the implications of linking, than about their license. JL: Changelog includes some bogus email/commit and should be cleaned up before final check-in. I do not intend to import the git history, so that should be fine, once it is imported. JL: The use of rpmautospec/etc has created a few comment/style issues that while I don't believe are wrong could use some minor tweaking before final. Just at the beginning and end? That will be resolved once it is imported. If there is something else in the main part of the spec, I am happy for comments, so I can improve. JL: I don't see an upstream signature, so I'm not going to fail this, but i personally tend to believe in these cases that using the release git SHA and downloading it that way: ex: https://github.com/jeremy-rifkin/cpptrace/archive/%{cpptrace_tag}.tar.gz tends to kill a few of the obvious version shenanigans (knowing of course that the look-aside also solves this to a certain extent) You mean with %{cpptrace_tag} the sha1 hash of the upsteam commit, that got tagged? If so, I think this is not particularly helpful. Sha1 is not super secure, and that only helps for tempering with the release, after it is released. At which point it is already in the lookaside cache. So we would not see the modified files. In addition, we store the sha512 signature, any changes here would fail the build anyway. To me that seems like a lot of extra work, with no benefit. If at all, it makes it for a casual reviewer harder to spot a mismatch between the official release and the commit sha. I have not checked this also true for the `archive` API endpoint, but if you reference a commit from a fork in the main repo, you can fool people into thinking that is part of the official repo, while it is not. This would allow someone to send a PR to "update to the newest upstream release", but instead of the official hash, reference a bogus commit from there fork, that includes whatever. With sha1, it should even be possible to match the parts of the beginning or end, to make even a manual check of that hash potentially pass. JL: Gonna fail this one, because gtest is already packaged and there are packages that depend on it, maybe a quick tweak allows the tests to run? Indeed, thanks. I have added the unit tests. Here are the updated files: Spec URL: https://download.copr.fedorainfracloud.org/results/davidsch/testa/fedora-rawhide-aarch64/10404971-cpptrace/cpptrace.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/davidsch/testa/fedora-rawhide-aarch64/10404971-cpptrace/cpptrace-1.0.4-1.fc45.src.rpm -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2432762 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202432762%23c8 -- _______________________________________________ package-review mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
