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=598058 --- Comment #9 from huwang <huwang@xxxxxxxxxx> 2010-06-03 04:35:29 EDT --- (In reply to comment #8) > NEEDSWORK: rpmlint must be run on every package. The output should be posted in > the review. > maven-docck-plugin.src: W: invalid-url Source0: maven-docck-plugin-1.0.tar.gz > maven-docck-plugin.noarch: W: self-obsoletion maven2-plugin-docck <= 0:2.0.8 > obsoletes maven2-plugin-docck = 1.0-1.fc13 > maven-docck-plugin.noarch: W: no-documentation > maven-docck-plugin.noarch: W: non-conffile-in-etc > /etc/maven/fragments/maven-docck-plugin > 3 packages and 0 specfiles checked; 0 errors, 4 warnings. > > Everything except self-obsoletion is false-positive. You need to fix > that self-obsoletion (by adding epoch 1 to provides) though. > > OK: The package must be named according to the Package Naming Guidelines . > OK: The spec file name must match the base package %{name}, in the format > %{name}.spec unless your package has an exemption. . > OK: The package must meet the Packaging Guidelines . > OK: The package must be licensed with a Fedora approved license and meet the > Licensing Guidelines . > OK: The License field in the package spec file must match the actual license. > OK: 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: The spec file must be written in American English. > OK: The spec file for the package MUST be legible. > OK: 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: The package MUST successfully compile and build into binary rpms on at > least one primary architecture. > OK: 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 MUST have a bug filed in > bugzilla, describing the reason that the package does not compile/build/work on > that architecture. The bug number MUST be placed in a comment, next to the > corresponding ExcludeArch line. > OK: 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: The spec file MUST handle locales properly. This is done by using the > %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden. > OK: 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. > OK: A Fedora package must not list a file more than once in the spec file's > %files listings. > OK: 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: Each package must consistently use macros. > OK: The package must contain code, or permissable content. > OK: Large documentation files must 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). > OK: 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: 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: All filenames in rpm packages must be valid UTF-8. > > Other notes: > You are using gzip compression to create tarball from SVN. Using xz > compression creates smaller archives (saving space on dist machines) > and is fully supported. You can create xz archive by doing: > tar acf maven-docck-plugin-1.0.tar.xz maven-docck-plugin-1.0/ > (don't forget to change Source0 URL afterwards) > > Another (tiny) thing to be careful about for future is to try to be > consistent in every way possible. For example you are using 0755 in > one place and few lines down you use 755. Pick one style and stick > with it. > > A small tip. It's also possible to install file and create all the > directories in one step. For example: > > install -d -m 0755 %{buildroot}%{_javadir} > install -m 644 target/%{name}-%{version}.jar > %{buildroot}%{_javadir}/%{name}-%{version}.jar > > could be rewritten as (with preserving file timestamps): > > install -Dpm 644 target/%{name}-%{version}.jar > %{buildroot}%{_javadir}/%{name}-%{version}.jar > > > So summarized: > * self-obsoletes > * compression > * consistency > > At least first two points are necessary for approval, but I would > suggest making spec file as consistent as possible while you are > editing it. Fixed all. Please review again, thanks. Spec URL: http://huwang.fedorapeople.org/packages/maven-docck-plugin/maven-docck-plugin.spec SRPM URL: http://huwang.fedorapeople.org/packages/maven-docck-plugin/maven-docck-plugin-1.0-2.src.rpm scratch built in koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=2226745 -- 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. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review