Bug 751083

Package Review
==============

Key:
- = N/A
x = Check
! = Problem
? = Not evaluated

=== REQUIRED ITEMS ===
[x]  Rpmlint output:
rpmlint jetty-build-support-1.1-1.fc15.src.rpm
jetty-build-support.src: W: spelling-error %description -l en_US rulesets -> rule sets, rule-sets, runlets

That spelling is fine though.

[x]  Package is named according to the Package Naming Guidelines[1].
[x]  Spec file name must match the base package name, in the format %{name}.spec.
[x]  Package meets the Packaging Guidelines[2].
[x]  Package successfully compiles and builds into binary rpms.
[x]  Buildroot definition is not present
[x]  Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines[3,4].
[x]  License field in the package spec file matches the actual license.
License type:
[!]  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 is included in %doc.

It seems that jetty-distribution-remote-resources has text files of the licenses
jetty-distribution-remote-resources/src/main/resources/LICENSE-APACHE-2.0.txt
jetty-distribution-remote-resources/src/main/resources/LICENSE-ECLIPSE-1.0.html

Not sure what the right answer here is but I guess adding these in %doc would not hurt.

[!]  All independent sub-packages have license of their own
Hmm
jetty-build-support-1.1/jetty-version-maven-plugin does not seem to have a license.

[x]  Spec file is legible and written in American English.
[x]  Sources used to build the package matches the upstream source, as provided in the spec URL.
MD5SUM this package    : 997b7aa7e669e34ba15cd20e73e662db
MD5SUM upstream package: 997b7aa7e669e34ba15cd20e73e662db

[x]  All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines[5].
[x]  Package must own all directories that it creates or must require other packages for directories it uses.
[x]  Package does not contain duplicates in %files.
[x]  File sections do not contain %defattr(-,root,root,-) unless changed with good reason
[x]  Permissions on files are set properly.
[x]  Package does NOT have a %clean section which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT). (not needed anymore)
[x]  Package consistently uses macros (no %{buildroot} and $RPM_BUILD_ROOT mixing)
[x]  Package contains code, or permissable content.
$ file -b `find . *`  | sort | uniq
ASCII C++ program text
ASCII English text
ASCII English text, with very long lines
ASCII Java program text
ASCII text
ASCII text, with no line terminators
directory
exported SGML document, ASCII text
HTML document, ASCII text
HTML document, ASCII text, with very long lines
Java KeyStore
XML document text

[x]  Fully versioned dependency in subpackages, if present.
[-]  Package contains a properly installed %{name}.desktop file if it is a GUI application.
[x]  Package does not own files or directories owned by other packages.
[x]  Javadoc documentation files are generated and included in -javadoc subpackage
[x]  Javadocs are placed in %{_javadocdir}/%{name} (no -%{version} symlinks)
[x]  Packages have proper BuildRequires/Requires on jpackage-utils
[x]  Javadoc subpackages have Require: jpackage-utils
[-]  Package uses %global not %define
[!]  If package uses tarball from VCS include comment how to re-create that tarball (svn export URL, git clone URL, ...)

There are no git export instructions.

[-]  If source tarball includes bundled jar/class files these need to be removed prior to building
[x]  All filenames in rpm packages must be valid UTF-8.
[x]  Jar files are installed to %{_javadir}/%{name}.jar (see [6] for details)
[x]  If package contains pom.xml files install it (including depmaps) even when building with ant
[x]  pom files has correct add_maven_depmap

=== Maven ===
[x]  Use %{_mavenpomdir} macro for placing pom files instead of %{_datadir}/maven2/poms
[-]  If package uses "-Dmaven.test.skip=true" explain why it was needed in a comment
[-]  If package uses custom depmap "-Dmaven.local.depmap.file=*" explain why it's needed in a comment
[x]  Package DOES NOT use %update_maven_depmap in %post/%postun
[x]  Packages DOES NOT have Requires(post) and Requires(postun) on jpackage-utils for %update_maven_depmap macro

=== Other suggestions ===
[x]  If possible use upstream build method (maven/ant/javac)
[x]  Avoid having BuildRequires on exact NVR unless necessary
[x]  Package has BuildArch: noarch (if possible)
[x]  Latest version is packaged.
[x]  Reviewer should test that the package builds in mock.
Tested on:
F15 X86_64

=== Issues ===
1. [!]  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 is included in %doc.

It seems that jetty-distribution-remote-resources has text files of the licenses
jetty-distribution-remote-resources/src/main/resources/LICENSE-APACHE-2.0.txt
jetty-distribution-remote-resources/src/main/resources/LICENSE-ECLIPSE-1.0.html

Not sure what the right answer here is but I guess adding these in %doc would not hurt.

2. [!]  All independent sub-packages have license of their own
Hmm
jetty-build-support-1.1/jetty-version-maven-plugin does not seem to have a license.

3. [!]  If package uses tarball from VCS include comment how to re-create that tarball (svn export URL, git clone URL, ...)

There are no git export instructions.

================
*** REJECTED ***
================

[1] https://fedoraproject.org/wiki/Packaging:NamingGuidelines
[2] https://fedoraproject.org/wiki/Packaging:Guidelines
[3] https://fedoraproject.org/wiki/Packaging:LicensingGuidelines
[4] https://fedoraproject.org/wiki/Licensing:Main
[5] https://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2 
[6] https://fedoraproject.org/wiki/Packaging:Java#Filenames

Please ignore this itme 3 it is not applicable here.

3. [!]  If package uses tarball from VCS include comment how to re-create that
tarball (svn export URL, git clone URL, ...)

There are no git export instructions.

While it is true that source tarball has license files buried somewhere in it structure, if you notice the %build section, the first thing I do is:

pushd %{name}

I.e. I don't really use whole repository (see upstream bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=362571). There is also a separate bug about clarifying licensing situation (https://bugs.eclipse.org/bugs/show_bug.cgi?id=362646). 

So only the contents of main directory + %{name} subdirectory should be taken into account because I don't use/build/install other sources. 

I also believe you slightly misunderstood the "All independent sub-packages have license of their own" point. This rule is talking about RPM sub-packages (for example %package javadoc), not sub-directories/maven modules. It means that if sub-package (such as javadoc) doesn't have:

Requires: %{name}-%{version} ...

Then it should have a license of its own. This is meant to ensure that whichever package you install you always get the license with it. Of course this only applies if upstream provides separate license file (which the second upstream bug is about).

So to finalize...it would be quite OK to block this review until upstream provides clarification on the licensing. I believe it will be no problem for Eclipse devs to add license files to the top of toolchain repository and then we can proceed. I wouldn't feel comfortable infering licensing from contents of src/main/resources of one sub-module.

I see. Thanks for the clarification. So issue 1. is no longer applicable here.

As for issue 2. The sources you build here are clearly licensed (in the java files) but it would be nice to get a clarification on the jetty-version-maven-plugin part. So we'll wait for upstream to provide that.

Thanks

There is http://git.eclipse.org/c/jetty/org.eclipse.jetty.toolchain.git/commit/?id=722131aae94200f9f021cb977b49e971009c3f78 which seems to clarify the licensing.
There have been a number of times when having things fixed in the scm is enough for the package to proceed if the package has added link to the commit clarifing the issue.

I have re-uploaded spec/srpm with comment linking to upstream bug. I haven't raised the release tag since it was just a comment change, please re-download from same urls.

The clarification looks good to me. There are no other outstanding issues, so this is approved by me.

Setting fedora-review +

Thanks a bunch for the review

New Package SCM Request
=======================
Package Name: jetty-build-support
Short Description: Jetty build support files
Owners: sochotni
Branches: 
InitialCC: java-sig

Git done (by process-git-requests).

Thanks, build done:

http://koji.fedoraproject.org/koji/taskinfo?taskID=3657907