Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libewf - Library for the Expert Witness Compression Format (EWF) https://bugzilla.redhat.com/show_bug.cgi?id=363741 tibbs@xxxxxxxxxxx changed: What |Removed |Added ---------------------------------------------------------------------------- Flag|fedora-review? |fedora-review+ ------- Additional Comments From tibbs@xxxxxxxxxxx 2007-11-03 14:28 EST ------- Lovely how upstream forces you to use https but has an expired certificate. The upstream web pages indicate that this is stable. Is the eight digit number looking suspiciously like a date actually the package's version? If so, then you could just use that as the version instead of treating the package as a snapshot with no version. Which would make your version "20070512" and your release as "1". Of course, this breaks (forcing you to use Epoch:) if upstream does decide to release version 1.0 in the future, so I'll leave this up to you. If upstream is still sufficiently active, you could ask them what they plan to do. The COPYING file seems to me to include the 4-clause BSD license, including the advertising clause, although they swapped two of the clauses for whatever reason. - All advertising materials mentioning features or use of this software must acknowledge the contribution by people stated in the acknowledgements. So, first off, your License: tag is wrong; it must be "BSD with advertising". Then, this program cannot link against anything which conflicts with BSD+advertising. zlib is OK, glibc is OK (LGPL), openssl/libcrypto is OK, and e2fsprogs has four different licenses. Looking in the source, libuuid (which is all that's being linked against here) is plain 3-clause BSD without advertising. So that should be OK as well. Running ldd against all binaries and libraries doesn't show anything else, so that should OK. When submitting packages with difficult licenses, you need to do this kind of review up front. We can't generally trust upstream to do this kind of thing properly, because it seems to be those that pick the "you must mention me in your advertising materials" clause who understand the implications of such a thing the least. You also need to make sure that the package doesn't grow additional dependencies in the future which would cause a licensing conflict, and that the licenses of your dependencies don't change and cause conflicts. Review: * source files match upstream: 5479bc06d0eb9a83c6dc793b87ee05a4c957fc73cb7c509b57ecc7dd5154ca0c libewf-20070512.tar.gz * package meets naming and versioning guidelines (but consider using date as version as detailed above). * specfile is properly named, is cleanly written and uses macros consistently. * summaries are OK. * descriptions are OK. * dist tag is present. * build root is OK. * license field matches the actual license. * license is open source-compatible. * license text included in package. * latest version is being packaged. * BuildRequires are proper. * compiler flags are appropriate. * %clean is present. * package builds in mock (rawhide, x86_64). * package installs properly * debuginfo package looks complete. * rpmlint complaints are OK. * final provides and requires are sane: ewftools-0-1.20070512.fc8.x86_64.rpm ewftools = 0-1.20070512.fc8 = libcrypto.so.6()(64bit) libewf = 0-1.20070512.fc8 libewf.so.1()(64bit) libuuid.so.1()(64bit) libz.so.1()(64bit) libewf-0-1.20070512.fc8.x86_64.rpm libewf.so.1()(64bit) libewf = 0-1.20070512.fc8 = /sbin/ldconfig libcrypto.so.6()(64bit) libewf.so.1()(64bit) libuuid.so.1()(64bit) libz.so.1()(64bit) libewf-devel-0-1.20070512.fc8.x86_64.rpm libewf-devel = 0-1.20070512.fc8 = libewf = 0-1.20070512.fc8 libewf.so.1()(64bit) pkgconfig * %check is not present; no test suite upstream. I have no existing EWF files to use test this, although I did run the tools and "acquired" a file and things seemed to work well enough. * shared libraries present; ldconfig called properly. * unversioned .so files are in the -devel package. * owns the directories it creates. * doesn't own any directories it shouldn't. * no duplicates in %files. * file permissions are appropriate. * scriptlets are OK (ldconfig calls) * code, not content. * documentation is small, so no -docs subpackage is necessary. * %docs are not necessary for the proper functioning of the package. * headers are in the -devel package. * pkgconfig file present in -devel package. * no static libraries. * no libtool .la files. APPROVED -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review