Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=458367 --- Comment #8 from Alan Dunn <amdunn@xxxxxxxxx> 2008-08-13 14:03:33 EDT --- Your changes have been made in http://www.duke.edu/~amd34/ocamlgraph/ocaml-ocamlgraph.spec http://www.duke.edu/~amd34/ocamlgraph/ocaml-ocamlgraph-0.99c-2.fc9.src.rpm (I was waiting to make the former change until I got a list like this.) (In reply to comment #6) > See my previous comments for just "looking at the spec file overall". > Below is my review. The big issue is that the license is wrong, it's the > _LGPLv2_ not the _GPLv2_. It's actually the LGPLv2 + an additional permission; > see below on how I think you should handle that. > Using http://fedoraproject.org/wiki/Packaging/ReviewGuidelines : > - MUST: rpmlint must be run on every package. The output should be posted in > the review. > FAIL. As noted above, there's an rpmlint complaint not justified in the .spec > file. Justify or fix. > - MUST: The package must be named according to the Package Naming Guidelines > OK > - MUST: The spec file name must match the base package %{name}, in the format > %{name}.spec unless your package has an exemption on Package Naming Guidelines > OK > - MUST: The package must meet the Packaging Guidelines > OK (other than what I've noted elsewhere) > - MUST: The package must be licensed with a Fedora approved license and meet > the Licensing Guidelines > OK (claimed GPLv2, actually LGPLv2, see beow) > - MUST: The License field in the package spec file must match the actual > license. > FAIL. It's actually the LGPLv2, not the GPLv2. See LICENSE. > In _addition_, it's not really the stock LGPLv2 license. It's the LGPLv2, > _plus_ an additional permission granting additional privileges > (it looks a LOT like the GNAT additional privileges): > "As a special exception to the GNU Library General Public License, you > may link, statically or dynamically, a "work that uses the Library" > with a publicly distributed version of the Library to produce an > executable file containing portions of the Library, and distribute > that executable file under terms of your choice, without any of the > additional requirements listed in clause 6 of the GNU Library General > Public License. By "a publicly distributed version of the Library", we > mean either the unmodified Library as distributed, or a > modified version of the Library that is distributed under the > conditions defined in clause 3 of the GNU Library General Public > License. This exception does not however invalidate any other reasons > why the executable file might be covered by the GNU Library General > Public License." > The LGPLv2 is a free software and open source software license. > Since adding _additional_ permissions cannot remove that status, this > license is as well. So here's what I suggest: > 1. Use "LGPLv2 with exceptions" as the license, per > http://fedoraproject.org/wiki/Licensing In this case, it's not really an > "exception", it's an "additional privilege", but there's no standard way to > denote that; "with exceptions" is the best we can do. > 2. Don't bother reporting to fedora-legal-list at redhat.com. Since the > license only adds additional privileges it cannot possibly NOT be a FLOSS > license. > - MUST: If (and only if) the source package includes the text of the license(s) > in its own file, then that file, containing the text of the license(s) for the > package must be included in %doc. > OK, /usr/share/doc/ocaml-ocamlgraph-0.99c/LICENSE > - MUST: The spec file must be written in American English. > OK > - MUST: The spec file for the package MUST be legible. If the reviewer is > unable to read the spec file, it will be impossible to perform a review. Fedora > is not the place for entries into the Obfuscated Code Contest > (http://www.ioccc.org/). > OK > - MUST: The sources used to build the package must match the upstream source, > as provided in the spec URL. Reviewers should use md5sum for this task. If no > upstream URL can be specified for this package, please see the Source URL > Guidelines for how to deal with this. > OK. > 3aff22a06afaa105ca40e31a5e15cf21 ocamlgraph-0.99c.tar.gz > 3aff22a06afaa105ca40e31a5e15cf21 ../SOURCES/ocamlgraph-0.99c.tar.gz > - MUST: The package must successfully compile and build into binary rpms on at > least one supported architecture. > OK > - MUST: If the package does not successfully compile, build or work on an > architecture, then those architectures should be listed in the spec in > ExcludeArch. Each architecture listed in ExcludeArch needs to have a bug filed > in bugzilla, describing the reason that the package does not compile/build/work > on that architecture. The bug number should then be placed in a comment, next > to the corresponding ExcludeArch line. New packages will not have bugzilla > entries during the review process, so they should put this description in the > comment until the package is approved, then file the bugzilla entry, and > replace the long explanation with the bug number. The bug should be marked as > blocking one (or more) of the following bugs to simplify tracking such issues: > FE-ExcludeArch-x86 , FE-ExcludeArch-x64 , FE-ExcludeArch-ppc , > FE-ExcludeArch-ppc64 > N/A. > Tested with koji build --scratch dist-f9 > ../SRPMS/ocaml-ocamlgraph-0.99c-1.fc9.src.rpm > - MUST: All build dependencies must be listed in BuildRequires, except for any > that are listed in the exceptions section of the Packaging Guidelines ; > inclusion of those as BuildRequires is optional. Apply common sense. > OK. > Tested with koji build --scratch dist-f9 > ../SRPMS/ocaml-ocamlgraph-0.99c-1.fc9.src.rpm > - MUST: The spec file MUST handle locales properly. This is done by using the > %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden. > N/A > - MUST: Every binary RPM package which stores shared library files (not just > symlinks) in any of the dynamic linker's default paths, must call ldconfig in > %post and %postun. If the package has multiple subpackages with libraries, each > subpackage should also have a %post/%postun section that calls /sbin/ldconfig. > N/A; see OCaml guidelines for more about OCaml libraries. > - MUST: If the package is designed to be relocatable, the packager must state > this fact in the request for review, along with the rationalization for > relocation of that specific package. Without this, use of Prefix: /usr is > considered a blocker. > N/A. > - MUST: A package must own all directories that it creates. If it does not > create a directory that it uses, then it should require a package which does > create that directory. Refer to the Guidelines for examples. > OK. Checked rpmls and .spec file itself, looks good. > - MUST: A package must not contain any duplicate files in the %files listing. > OK. > - MUST: Permissions on files must be set properly. Executables should be set > with executable permissions, for example. Every %files section must include a > %defattr(...) line. > OK > - MUST: Each package must have a %clean section, which contains rm -rf > %{buildroot} ( or $RPM_BUILD_ROOT ). > OK > - MUST: Each package must consistently use macros, as described in the macros > section of Packaging Guidelines > OK > - MUST: The package must contain code, or permissable content. This is > described in detail in the code vs. content section of Packaging Guidelines > OK > - MUST: Large documentation files should go in a -doc subpackage. (The > definition of large is left up to the packager's best judgement, but is not > restricted to size. Large can refer to either size or quantity) > N/A > - MUST: If a package includes something as %doc, it must not affect the runtime > of the application. To summarize: If it is in %doc, the program must run > properly if it is not present. > OK > - MUST: Header files must be in a -devel package. > N/A > - MUST: Static libraries must be in a -static package. > N/A > - MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' > (for directory ownership and usability). > N/A > - MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), > then library files that end in .so (without suffix) must go in a -devel > package. > N/A > - MUST: In the vast majority of cases, devel packages must require the base > package using a fully versioned dependency: Requires: %{name} = > %{version}-%{release} > N/A > - MUST: Packages must NOT contain any .la libtool archives, these should be > removed in the spec. > N/A > - MUST: Packages containing GUI applications must include a %{name}.desktop > file, and that file must be properly installed with desktop-file-install in the > %install section. This is described in detail in the desktop files section of > the Packaging Guidelines . If you feel that your packaged GUI application does > not need a .desktop file, you must put a comment in the spec file with your > explanation. > N/A > - MUST: Packages must not own files or directories already owned by other > packages. The rule of thumb here is that the first package to be installed > should own the files or directories that other packages may rely upon. This > means, for example, that no package in Fedora should ever share ownership with > any of the files or directories owned by the filesystem or man package. If you > feel that you have a good reason to own a file or directory that another > package owns, then please present that at package review time. > OK > - MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot} > ( or $RPM_BUILD_ROOT ). See Prepping BuildRoot For %install for details. > OK > - MUST: All filenames in rpm packages must be valid UTF-8. > OK > SHOULD Items: > - SHOULD: If the source package does not include license text(s) as a separate > file from upstream, the packager SHOULD query upstream to include it. > N/A > - SHOULD: The description and summary sections in the package spec file should > contain translations for supported Non-English languages, if available. > N/A. Doesn't have any translations, but I don't see evidence of translations > easily available. > - SHOULD: The reviewer should test that the package builds in mock. See > MockTricks for details on how to do this. > OK. Builds in koji, thus builds in Mock. > - SHOULD: The package should compile and build into binary rpms on all > supported architectures. > OK. (Tested with Koji, above) > - SHOULD: The reviewer should test that the package functions as described. A > package should not segfault instead of running, for example. > OK. It has a %check section, which does that. > - SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, > and left up to the reviewers judgement to determine sanity. > N/A > - SHOULD: Usually, subpackages other than devel should require the base package > using a fully versioned dependency. > N/A > - SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and > this is usually for development purposes, so should be placed in a -devel pkg. > A reasonable exception is that the main pkg itself is a devel tool not > installed in a user runtime, e.g. gcc or gdb. > N/A > - SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, > /usr/bin, or /usr/sbin consider requiring the package which provides the file > instead of the file itself. Please see File Dependencies in the Guidelines for > further information. > N/A -- 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review