Spec URL: http://sochotni.fedorapeople.org/apache-commons-logging.spec SRPM URL: http://sochotni.fedorapeople.org/apache-commons-logging-1.1.1-1.fc12.src.rpm Description: Package was renamed and version-bumped from 1.0.4. The build system was changed to use maven instead of ant. apache-commons-logging is new name for jakarta-commons-logging - a simple, component oriented interface (org.apache.commons.logging.Log) together with wrappers for logging systems.
Created attachment 411642 [details] changes against original 1.0.4-9.10 spec file Just to see the changes made more easily
I'm taking this one.
*** Bug 225933 has been marked as a duplicate of this bug. ***
Unversioned javadoc directory should be created as a symlink in %install and there should be no %post/%postun for javadoc subpackage.
New SRPM URL: http://sochotni.fedorapeople.org/apache-commons-logging-1.1.1-2.fc12.src.rpm Spec URL: http://sochotni.fedorapeople.org/apache-commons-logging.spec Few other QA improvement changes noted in changelog as well
Review: OK: rpmlint must be run on every package. Output: apache-commons-logging.noarch: W: spelling-error %description -l en_US runtime -> run time, run-time, untimely apache-commons-logging.noarch: W: self-obsoletion jakarta-commons-logging <= 0:1.0.4 obsoletes jakarta-commons-logging = 0:1.0.4 apache-commons-logging.noarch: W: non-conffile-in-etc /etc/maven/fragments/apache-commons-logging False positives. 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. OK: The package MUST successfully compile and build into binary rpms on at least one primary architecture. 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: Packages must NOT bundle copies of system libraries. 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. NOTOK: Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. I don't see a reason why not using default %defattr(-,root,root,-) From the guidelines: Unless you have a very good reason to deviate from that, you should use %defattr(-,root,root,-) for all %files sections in your package. 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. OK: If a package includes something as %doc, it must not affect the runtime of the application. OK: Packages must not own files or directories already owned by other packages. OK: All filenames in rpm packages must be valid UTF-8. Please drop Package from the Summary. Also javadoc subpackage will be better tohave a description like "API documentation for %{name}." Please also use the default the permissions. I know that they will match in this case but we should use the defaults.
New SRPM URL: http://sochotni.fedorapeople.org/apache-commons-logging-1.1.1-3.fc12.src.rpm Spec URL: http://sochotni.fedorapeople.org/apache-commons-logging.spec Thanks
Thanks This package is APPROVED.
Thanks. Requesting CVS: New Package CVS Request ======================= Package Name: apache-commons-logging Short Description: Apache Commons Logging Owners: sochotni mbooth Branches: InitialCC:
CVS done (by process-cvs-requests.py).
Hi, Why is it necessary to specify: -Dmaven2.jpp.depmap.file="%{SOURCE1}" That is unnecessary for commons-codec, for example: http://cvs.fedoraproject.org/viewvc/rpms/jakarta-commons-codec/devel/jakarta-commons-codec.spec?revision=1.28&view=markup
(In reply to comment #11) > Hi, > > Why is it necessary to specify: > > -Dmaven2.jpp.depmap.file="%{SOURCE1}" > > That is unnecessary for commons-codec, for example: > > http://cvs.fedoraproject.org/viewvc/rpms/jakarta-commons-codec/devel/jakarta-commons-codec.spec?revision=1.28&view=markup It's needed for the avalon-* jars. And I didn't insisted on adding poms to dead packages. Time can be better spend freeing logging from avalon.
Package built, closing. Thanks Alexander & Kevin
I see here at least two indications that the package renaming process was not done correctly: http://fedoraproject.org/wiki/Package_Renaming_Process#Re-review_required Particularly of importance is this: http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Renaming.2Freplacing_existing_packages First, the reviewer never explicitly stated that he's aware of this being a renaming (and obviously wasn't) and second the Provides doesn't use macros. Also, this is _no_ false positive but a real problem: apache-commons-logging.noarch: W: self-obsoletion jakarta-commons-logging <= 0:1.0.4 obsoletes jakarta-commons-logging = 0:1.0.4 Now that the reviewer wasn't aware it's been a renaming doesn't matter as I filled that gap (and am well aware of it). But please correct the other two problems before you push this pkg to any repo.
I would say that summary with "rename of <oldpkg>" obviously pointed that this is re-review of existing package. Will keep in mind to be more explicit about it next time. I fixed problem with self-deprecation in r4. My original idea was that new packages that would want to do "Requires: jakarta-commons-logging >= 1.1.1" would fail (because we only provide version up until 1.0.4 - last version of old name). So new specfiles would have to be fixed in order to work. But since we also needed to replace current jakarta-commons-logging-1.0.4, there was that Obsoletes... >correct the other two problems I counted only one other problem (thank you for it pointing out btw), if there is anything else I missed let me know. Thanks
(In reply to comment #15) > I would say that summary with "rename of <oldpkg>" obviously pointed that this > is re-review of existing package. For me it's all clear and not your fault. You also stated that it's a renaming in the bug's description. But the reviewer MUST state that he's aware of the fact and that he checked for the special requirements (Provides/Obsoletes) - he didn't do either. > I counted only one other problem (thank you for it pointing out btw), if there > is anything else I missed let me know. The two problems: 1) Provides didn't use marcos 2) self-obsoletion ...where in your specific case fixing 1) fixes 2)