Name : stax-utils Version : 20110309 Group : Development/Libraries License : BSD URL : http://java.net/projects/stax-utils/ Summary : StAX utility classes Description : This is a set of utility classes that make it easy for developers to integrate StAX into their existing XML processing applications. SPEC: http://downloads.eucalyptus.com/devel/packages/fedora-17/SPECS/stax-utils.spec SRPM: http://downloads.eucalyptus.com/devel/packages/fedora-17/sources/stax-utils-20110309-1.fc17.src.rpm
I am taking this.
=== REQUIRED ITEMS === [!] Rpmlint output: Result of rpmlint of the SRPM: stax-utils.src: W: invalid-url Source0: stax-utils-20110309.tar.xz 1 packages and 0 specfiles checked; 0 errors, 1 warnings. Result of rpmlint of the binary RPMs: 2 packages and 0 specfiles checked; 0 errors, 0 warnings. [!] Package is named according to the Package Naming Guidelines[1]. Version should be 0 and release should be 0.1.20110309svn. [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. Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=3843082 [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]. [!] 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. Should include LICENSE instead of (or in addition to) COPYRIGHT.TXT. [x] All independent sub-packages have license of their own [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. [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. [-] 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 [x] Package uses %global not %define [x] If package uses tarball from VCS include comment how to re-create that tarball (svn export URL, git clone URL, ...) [!] If source tarball includes bundled jar/class files these need to be removed prior to building The following jar files are not removed before build: ./stax-utils-20110309/lib/src/jsr173_1.0_javadoc.jar ./stax-utils-20110309/lib/src/jsr173_1.0_src.jar ./stax-utils-20110309/lib/jars/junit.jar ./stax-utils-20110309/lib/jars/jsr173_1.0_api.jar ./stax-utils-20110309/lib/jars/jsr173_1.0_ri.jar [x] All filenames in rpm packages must be valid UTF-8. [x] Jar files are installed to %{_javadir}/%{name}.jar (see [1] 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. === Issues === 1. The rpmlint warning about the source URL is normal and acceptable. 2. The upstream project doesn't tag releases since 7 years ago, and those tags are apparently date based, so I think we should treat this as pre-release, putting 0 in the version tag and 0.1.20110309svn in the release tag. However there is a date used as version in the POM, so I am not completely against using this date as the version tag. Let me know what you think. 3. The file "LICENSE" contains an updated version of "COPYRIGHT.TXT" with two additional copyright holders. I think that this "LICENSE" file should be used instead of (or in addition to) "COPYRIGHT.TXT". 4. Jar files from the source tarball are not removed before build. === Final Notes === Comment on issue #2, fix #3 and #4 and I will review again.
I was actually wrong about this being a requirement for spring; it's actually only a requirement for mule, and since there are concerns about it not having very sane versioning and completely lacking any official release, I'm going to put it on hold for now.
I am moving it back to and removing to review flag.
Things mostly look sane to me. Here are the issues I ran across: * While the packages include docs/COPYRIGHT.TXT, they should also include LICENSE. * Since this is a pre/post-release snapshot the Release field needs to contain the usual svn snapshot info. If the date that would normally go there is the same as the Version info then I would argue that putting that date in the Release field is redundant and unnecessary. That should probably go by FPC, though. * lib/*/jsr173*.jar do not appear to have licenses that allow redistribution. If this is correct then you have to build sanitized source tarballs that don't include those files. :-( * Consider using cp's -p switch in the %install section. * The purpose of %{name}-build-fixes.patch is rather obvious, but the guidelines recommend adding descriptive commentary about it to the spec file. * Tests aren't getting run. Is it feasible to do so? * (nitpick) The Group, URL, and BuildRequires: jpackage-utils lines have trailing spaces. Review of stax-utils-20110309-1: Mandatory review guidelines: ok - rpmlint output: stax-utils.src: W: invalid-url Source0: stax-utils-20110309.tar.xz 3 packages and 0 specfiles checked; 0 errors, 1 warnings. ok - License is acceptable (BSD) ok - License field in spec is correct NO - License files included in package %docs if included in source package docs/COPYRIGHT.TXT is included, but LICENSE is not. ok - License files installed when any subpackage combination is installed ok - Spec written in American English ok - Spec is legible -- - Sources match upstream unless altered to fix permissibility issues Tarball built directly from upstream svn ok - Build succeeds on at least one primary arch ok - Build succeeds on all primary arches or has ExcludeArch + bugs filed ok - BuildRequires correct, justified where necessary -- - Locales handled with %find_lang, not %_datadir/locale/* -- - %post, %postun call ldconfig if package contains shared .so files ok - No bundled libs -- - Relocatability is justified ok - Package owns all directories it creates ok - Package requires others for directories it uses but does not own ok - No duplication in %files unless necessary for license files ok - File permissions are sane ok - Package contains permissible code or content ok - Large docs go in -doc subpackage ok - %doc files not required at runtime -- - Static libs go in -static package/virtual Provides -- - Development files go in -devel package -- - -devel packages Require base with fully-versioned dependency, %_isa ok - No .la files -- - GUI app uses .desktop file, installs it with desktop-file-install ok - File list does not conflict with other packages' without justification ok - File names are valid UTF-8 Optional review guidelines: -- - Query upstream about including license files no - Translations of description, summary ok - Builds in mock ok - Builds on all arches (Standard no-java-on-epel-ppc disclaimer) -- - Scriptlets are sane -- - Subpackages require base with fully-versioned dependency if sensible -- - .pc file subpackage placement is sensible ok - No file deps outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin -- - Include man pages if available Naming guidelines: ok - Package names use only a-zA-Z0-9-._+ subject to restrictions on -._+ ok - Package names are sane ok - No naming conflicts ok - Spec file name matches base package name ok - Version is sane Upstream also uses dates for versions. ok - Version does not contain ~ NO - Release is sane Since this is a svn snapshot the Release field needs to include the usual pre- or post-release info. If the date that would normally go there is the same as the Version then I would argue that putting that date here is redundant and unnecessary. That should probably be run by FPC to be sure, though. ok - %dist tag ok - Case used only when necessary -- - Renaming handled correctly Packaging guidelines: ok - Useful without external bits ok - No kmods no - Pre-built binaries, libs removed in %prep NO - Sources contain only redistributable code or content lib/*/jsr173*.jar are not redistributable ok - Spec format is sane Group, URL, and BuildRequires: jpackage utils have trailing spaces. ok - Package obeys FHS, except libexecdir, /run, /usr/target ok - No files in /bin, /sbin, /lib* on >= F17 -- - Programs run before FS mounting use /run instead of /var/run ok - Binaries in /bin, /sbin do not depend on files in /usr on < F17 ok - No files under /srv, /opt, /usr/local ok - Changelog in prescribed format ok - No Packager, Vendor, Copyright, PreReq tags ok - Summary does not end in a period -- - Correct BuildRoot tag on < EL6 -- - Correct %clean section on < EL6 ok - Requires correct, justified where necessary ok - Summary, description do not use trademarks incorrectly ok - All relevant documentation is packaged, appropriately marked with %doc ok - Doc files do not drag in extra dependencies (e.g. due to +x) -- - Code compilable with gcc is compiled with gcc -- - Build honors applicable compiler flags or justifies otherwise -- - PIE used for long-running/root daemons, setuid/filecap programs -- - Useful -debuginfo package or disabled and justified -- - Package with .pc files Requires pkgconfig on < EL6 ok - No static executables -- - Rpath absent or only used for internal libs -- - Config files marked with %config(noreplace) or justified %config -- - No config files under /usr -- - Third party package manager configs acceptable, in %_docdir -- - .desktop files are sane ok - Spec uses macros consistently ok - Spec uses macros instead of hard-coded names where appropriate ok - Spec uses macros for executables only when configurability is needed -- - %makeinstall used only when alternatives don't work -- - Macros in Summary, description are expandable at srpm build time ok - Spec uses %{SOURCE#} instead of $RPM_SOURCE_DIR and %sourcedir ok - No software collections (scl) ok - Build uses only python/perl/shell+coreutils/lua/BuildRequired langs -- - %global, not %define -- - Package translating with gettext BuildRequires it -- - Package translating with Linguist BuildRequires qt-devel no - File ops preserve timestamps Consider using cp's -p switch in the %install section. -- - Parallel make ok - No Requires(pre,post) notation -- - User, group creation handled correctly (See Packaging:UsersAndGroups) -- - Web apps go in /usr/share/%name, not /var/www -- - Conflicts are justified ok - One project per package ok - No bundled fonts no - Patches have appropriate commentary %{name}-build-fixes.patch is obvious, but commentary is recommended. no - Available test suites executed in %check -- - tmpfiles.d used for /run, /run/lock on >= F15 Java guidelines: ok - Javadocs go in javadoc subpackage -- - Prefer split JARs over monolithic ok - JAR file names correct ok - JAR files go in %{_javadir} or %{_javadir}-$version -- - Multiple JAR files go in a %{name} subdirectory ok - Javadocs go in unversioned %{_javadocdir}/%{name} ok - javadoc subpackage is noarch on > EL5 ok - BuildRequires java-devel, jpackage-utils ok - Requires java, jpackage-utils -- - Dependencies on java/java-devel >= 1.6.0 add epoch 1 -- - Package requiring maven2 Requires jpackage-utils for post and postun -- - Package requiring maven contains correct maven-specific code in spec -- - Wrapper script in %{_bindir} -- - GCJ AOT bits follow GCJ guidelines ok - No devel package ok - pom.xml files, if any, installed with %add_maven_depmap -- - JNI shared objects, JARs that require them go in %{_libdir}/%{name} -- - Calls to System.loadLibrary replaced w/ System.load w/ full .so path ok - Bundled JAR files not included or used for build I did a test build that removed the bundled jars, which succeeded. ok - No Javadoc %post/%ghost ok - No class-path elements in JAR manifests
I did a successful test build that removed the bundled jars in %prep. If you run the test suite then it might be worth removing them anyway just in case; given that junit is there I suspect that they're all there just for tests.
Updated: SRPM: http://arg.fedorapeople.org/reviews/stax-utils/0/0.1.20110309svn238/stax-utils-0-0.1.20110309svn238.fc18.src.rpm SPEC: http://arg.fedorapeople.org/reviews/stax-utils/0/0.1.20110309svn238/stax-utils.spec I did enable tests in the %check section, as is currently recommended. Three tests fail, but it still returns "BUILD SUCCESSFUL." I can patch out the known failures if that's better than having them there.
Great! What you do with the test output is up to you; I just suggested them because they're in the guidelines. There's just one more hangup: the instructions for building the source tarball delete only lib/jars, but you deleted all of lib in the tarball you uploaded. #fedora-devel denizens recommended removing the bundled source code in lib/src as well; would it make sense to simply remove "/jars" from the rm instruction? Nitpick: the spec file says, "skipping tests for now, as some are broken" and immediately follows that with "%check" and "ant test". Review of stax-utils-0-0.1.20110309svn238: Mandatory review guidelines: ok - rpmlint output: stax-utils.src: W: invalid-url Source0: stax-utils-svn238.tar.xz 3 packages and 0 specfiles checked; 0 errors, 1 warnings. ok - License is acceptable (BSD) ok - License field in spec is correct ok - License files included in package %docs if included in source package ok - License files installed when any subpackage combination is installed ok - Spec written in American English ok - Spec is legible -- - Sources match upstream unless altered to fix permissibility issues Tarball built directly from upstream svn ok - Build succeeds on at least one primary arch ok - Build succeeds on all primary arches or has ExcludeArch + bugs filed ok - BuildRequires correct, justified where necessary -- - Locales handled with %find_lang, not %_datadir/locale/* -- - %post, %postun call ldconfig if package contains shared .so files ok - No bundled libs -- - Relocatability is justified ok - Package owns all directories it creates ok - Package requires others for directories it uses but does not own ok - No duplication in %files unless necessary for license files ok - File permissions are sane ok - Package contains permissible code or content ok - Large docs go in -doc subpackage ok - %doc files not required at runtime -- - Static libs go in -static package/virtual Provides -- - Development files go in -devel package -- - -devel packages Require base with fully-versioned dependency, %_isa ok - No .la files -- - GUI app uses .desktop file, installs it with desktop-file-install ok - File list does not conflict with other packages' without justification ok - File names are valid UTF-8 Optional review guidelines: -- - Query upstream about including license files no - Translations of description, summary ok - Builds in mock ok - Builds on all arches (Standard no-java-on-epel-ppc disclaimer) -- - Scriptlets are sane -- - Subpackages require base with fully-versioned dependency if sensible -- - .pc file subpackage placement is sensible ok - No file deps outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin -- - Include man pages if available Naming guidelines: ok - Package names use only a-zA-Z0-9-._+ subject to restrictions on -._+ ok - Package names are sane ok - No naming conflicts ok - Spec file name matches base package name ok - Version is sane Upstream also uses dates for versions. ok - Version does not contain ~ ok - Release is sane ok - %dist tag ok - Case used only when necessary -- - Renaming handled correctly Packaging guidelines: ok - Useful without external bits ok - No kmods no - Pre-built binaries, libs removed in %prep NO - Sources contain only redistributable code or content lib/src/jsr173*.jar are not redistributable ok - Spec format is sane ok - Package obeys FHS, except libexecdir, /run, /usr/target ok - No files in /bin, /sbin, /lib* on >= F17 -- - Programs run before FS mounting use /run instead of /var/run ok - Binaries in /bin, /sbin do not depend on files in /usr on < F17 ok - No files under /srv, /opt, /usr/local ok - Changelog in prescribed format ok - No Packager, Vendor, Copyright, PreReq tags ok - Summary does not end in a period -- - Correct BuildRoot tag on < EL6 -- - Correct %clean section on < EL6 ok - Requires correct, justified where necessary ok - Summary, description do not use trademarks incorrectly ok - All relevant documentation is packaged, appropriately marked with %doc ok - Doc files do not drag in extra dependencies (e.g. due to +x) -- - Code compilable with gcc is compiled with gcc -- - Build honors applicable compiler flags or justifies otherwise -- - PIE used for long-running/root daemons, setuid/filecap programs -- - Useful -debuginfo package or disabled and justified -- - Package with .pc files Requires pkgconfig on < EL6 ok - No static executables -- - Rpath absent or only used for internal libs -- - Config files marked with %config(noreplace) or justified %config -- - No config files under /usr -- - Third party package manager configs acceptable, in %_docdir -- - .desktop files are sane ok - Spec uses macros consistently ok - Spec uses macros instead of hard-coded names where appropriate ok - Spec uses macros for executables only when configurability is needed -- - %makeinstall used only when alternatives don't work -- - Macros in Summary, description are expandable at srpm build time ok - Spec uses %{SOURCE#} instead of $RPM_SOURCE_DIR and %sourcedir ok - No software collections (scl) ok - Build uses only python/perl/shell+coreutils/lua/BuildRequired langs -- - %global, not %define -- - Package translating with gettext BuildRequires it -- - Package translating with Linguist BuildRequires qt-devel ok - File ops preserve timestamps -- - Parallel make ok - No Requires(pre,post) notation -- - User, group creation handled correctly (See Packaging:UsersAndGroups) -- - Web apps go in /usr/share/%name, not /var/www -- - Conflicts are justified ok - One project per package ok - No bundled fonts ok - Patches have appropriate commentary ok - Available test suites executed in %check -- - tmpfiles.d used for /run, /run/lock on >= F15 Java guidelines: ok - Javadocs go in javadoc subpackage -- - Prefer split JARs over monolithic ok - JAR file names correct ok - JAR files go in %{_javadir} or %{_javadir}-$version -- - Multiple JAR files go in a %{name} subdirectory ok - Javadocs go in unversioned %{_javadocdir}/%{name} ok - javadoc subpackage is noarch on > EL5 ok - BuildRequires java-devel, jpackage-utils ok - Requires java, jpackage-utils -- - Dependencies on java/java-devel >= 1.6.0 add epoch 1 -- - Package requiring maven2 Requires jpackage-utils for post and postun -- - Package requiring maven contains correct maven-specific code in spec -- - Wrapper script in %{_bindir} -- - GCJ AOT bits follow GCJ guidelines ok - No devel package ok - pom.xml files, if any, installed with %add_maven_depmap -- - JNI shared objects, JARs that require them go in %{_libdir}/%{name} -- - Calls to System.loadLibrary replaced w/ System.load w/ full .so path ok - Bundled JAR files not included or used for build ok - No Javadoc %post/%ghost ok - No class-path elements in JAR manifests
Sorry, forgot to change the comments... updated. Updated: http://arg.fedorapeople.org/reviews/stax-utils/0/0.2.20110309svn238/stax-utils.spec http://arg.fedorapeople.org/reviews/stax-utils/0/0.2.20110309svn238/stax-utils-0-0.2.20110309svn238.fc18.src.rpm
That looks great to me. Enjoy! Review of stax-utils-0-0.1.20110309svn238: Mandatory review guidelines: ok - rpmlint output: stax-utils.src: W: invalid-url Source0: stax-utils-svn238.tar.xz 3 packages and 0 specfiles checked; 0 errors, 1 warnings. ok - License is acceptable (BSD) ok - License field in spec is correct ok - License files included in package %docs if included in source package ok - License files installed when any subpackage combination is installed ok - Spec written in American English ok - Spec is legible -- - Sources match upstream unless altered to fix permissibility issues Tarball built directly from upstream svn ok - Build succeeds on at least one primary arch ok - Build succeeds on all primary arches or has ExcludeArch + bugs filed ok - BuildRequires correct, justified where necessary -- - Locales handled with %find_lang, not %_datadir/locale/* -- - %post, %postun call ldconfig if package contains shared .so files ok - No bundled libs -- - Relocatability is justified ok - Package owns all directories it creates ok - Package requires others for directories it uses but does not own ok - No duplication in %files unless necessary for license files ok - File permissions are sane ok - Package contains permissible code or content ok - Large docs go in -doc subpackage ok - %doc files not required at runtime -- - Static libs go in -static package/virtual Provides -- - Development files go in -devel package -- - -devel packages Require base with fully-versioned dependency, %_isa ok - No .la files -- - GUI app uses .desktop file, installs it with desktop-file-install ok - File list does not conflict with other packages' without justification ok - File names are valid UTF-8 Optional review guidelines: -- - Query upstream about including license files no - Translations of description, summary ok - Builds in mock ok - Builds on all arches (Standard no-java-on-epel-ppc disclaimer) -- - Scriptlets are sane -- - Subpackages require base with fully-versioned dependency if sensible -- - .pc file subpackage placement is sensible ok - No file deps outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin -- - Include man pages if available Naming guidelines: ok - Package names use only a-zA-Z0-9-._+ subject to restrictions on -._+ ok - Package names are sane ok - No naming conflicts ok - Spec file name matches base package name ok - Version is sane ok - Version does not contain ~ ok - Release is sane ok - %dist tag ok - Case used only when necessary -- - Renaming handled correctly Packaging guidelines: ok - Useful without external bits ok - No kmods -- - Pre-built binaries, libs removed in %prep Removed from tarball from upstream source control instead ok - Sources contain only redistributable code or content ok - Spec format is sane ok - Package obeys FHS, except libexecdir, /run, /usr/target ok - No files in /bin, /sbin, /lib* on >= F17 -- - Programs run before FS mounting use /run instead of /var/run ok - Binaries in /bin, /sbin do not depend on files in /usr on < F17 ok - No files under /srv, /opt, /usr/local ok - Changelog in prescribed format ok - No Packager, Vendor, Copyright, PreReq tags ok - Summary does not end in a period -- - Correct BuildRoot tag on < EL6 -- - Correct %clean section on < EL6 ok - Requires correct, justified where necessary ok - Summary, description do not use trademarks incorrectly ok - All relevant documentation is packaged, appropriately marked with %doc ok - Doc files do not drag in extra dependencies (e.g. due to +x) -- - Code compilable with gcc is compiled with gcc -- - Build honors applicable compiler flags or justifies otherwise -- - PIE used for long-running/root daemons, setuid/filecap programs -- - Useful -debuginfo package or disabled and justified -- - Package with .pc files Requires pkgconfig on < EL6 ok - No static executables -- - Rpath absent or only used for internal libs -- - Config files marked with %config(noreplace) or justified %config -- - No config files under /usr -- - Third party package manager configs acceptable, in %_docdir -- - .desktop files are sane ok - Spec uses macros consistently ok - Spec uses macros instead of hard-coded names where appropriate ok - Spec uses macros for executables only when configurability is needed -- - %makeinstall used only when alternatives don't work -- - Macros in Summary, description are expandable at srpm build time ok - Spec uses %{SOURCE#} instead of $RPM_SOURCE_DIR and %sourcedir ok - No software collections (scl) ok - Build uses only python/perl/shell+coreutils/lua/BuildRequired langs -- - %global, not %define -- - Package translating with gettext BuildRequires it -- - Package translating with Linguist BuildRequires qt-devel ok - File ops preserve timestamps -- - Parallel make ok - No Requires(pre,post) notation -- - User, group creation handled correctly (See Packaging:UsersAndGroups) -- - Web apps go in /usr/share/%name, not /var/www -- - Conflicts are justified ok - One project per package ok - No bundled fonts ok - Patches have appropriate commentary ok - Available test suites executed in %check -- - tmpfiles.d used for /run, /run/lock on >= F15 Java guidelines: ok - Javadocs go in javadoc subpackage -- - Prefer split JARs over monolithic ok - JAR file names correct ok - JAR files go in %{_javadir} or %{_javadir}-$version -- - Multiple JAR files go in a %{name} subdirectory ok - Javadocs go in unversioned %{_javadocdir}/%{name} ok - javadoc subpackage is noarch on > EL5 ok - BuildRequires java-devel, jpackage-utils ok - Requires java, jpackage-utils -- - Dependencies on java/java-devel >= 1.6.0 add epoch 1 -- - Package requiring maven2 Requires jpackage-utils for post and postun -- - Package requiring maven contains correct maven-specific code in spec -- - Wrapper script in %{_bindir} -- - GCJ AOT bits follow GCJ guidelines ok - No devel package ok - pom.xml files, if any, installed with %add_maven_depmap -- - JNI shared objects, JARs that require them go in %{_libdir}/%{name} -- - Calls to System.loadLibrary replaced w/ System.load w/ full .so path ok - Bundled JAR files not included or used for build ok - No Javadoc %post/%ghost ok - No class-path elements in JAR manifests
New Package SCM Request ======================= Package Name: stax-utils Short Description: StAX utility classes Owners: madsa arg Branches: f17 f18 InitialCC:
Git done (by process-git-requests).
This package is in Fedora 18.