https://bugzilla.redhat.com/show_bug.cgi?id=794923 Garrett Holmstrom <gholms@xxxxxxxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |gholms@xxxxxxxxxxxxxxxxx Assignee|nobody@xxxxxxxxxxxxxxxxx |gholms@xxxxxxxxxxxxxxxxx Flags| |fedora-review? --- Comment #5 from Garrett Holmstrom <gholms@xxxxxxxxxxxxxxxxx> --- 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 -- 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