[Bug 458367] Review Request: ocaml-ocamlgraph - OCaml library for arc and node graphs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]