https://bugzilla.redhat.com/show_bug.cgi?id=1205376 Jeff Layton <jlayton@xxxxxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jlayton@poochiere | |ds.net) | --- Comment #14 from Jeff Layton <jlayton@xxxxxxxxxxxxxxx> --- (In reply to Björn Persson from comment #13) > > > Things to do: > ------------- > > · The only really blocking problem is that the licensing is unclear. It is > stated quite clearly that Bob Jenkins has placed his C++ code in the public > domain, but nothing clear is said about the licensing of Andi Kleen's and > Ziga Zupanec's C code. Even in the C files, the only place where the words > "public domain" occur is right next to "by Bob Jenkins". As I understand the > policy you need to contact Andi and if possible get a new release with a > license statement, or else include his reply in the package as a license > file. > > https://fedoraproject.org/wiki/Packaging: > LicensingGuidelines#License_Clarification > Good point. I emailed Andi to get some clarification. Hopefully we can sort it out soon. I mentioned that if he really wanted a PD license then using the CC0 license might be better. > · Development/Libraries is the right group for the -devel subpackage, but I > think the main package should be in System Environment/Libraries. > Ok, I'll fix that. > · Add a comment about the manpage patch. > Yep, will do since I'm respinning for other reasons. > > Additional notes: > ----------------- > > · The warnings from RPMlint are all false alarms. > > · I don't think you're required to define shortcommit if you don't use it. > Fair enough. I'll remove it. > · The modification time of spooky-c.h is not preserved, but that's not > because of anything the spec file does. I guess it's the Autoconf-generated > makefile that doesn't preserve the modification times of files it installs. > Yes, I expect so. > · I tried running the test program with "make check". It consumed 100% of > one CPU core until I killed it. I don't know whether it's supposed to do > that or not. Thus I can't tell whether the library functions as described. > If it's meant to be a reasonably quick function test, then you should > probably run it in %check. If it's a benchmark, then you probably shouldn't. Yes, it's more of a benchmark than an test program. I stuck it in TESTS when I did the autotools patches for the thing, but I don't think we want to run that on each build. Thanks for review so far! I'll update the package once I get clarification from Andi. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review