https://bugzilla.redhat.com/show_bug.cgi?id=851279 --- Comment #26 from Garrett Holmstrom <gholms@xxxxxxxxxxxxxxxxx> --- That looks good to me. The cc package requires euca_conf twice, but that isn't going to break anything. Nice job! === Review of eucalyptus-3.1.2-0.5.20120917gitb8c109b4 === Mandatory review guidelines: ok - rpmlint output (attached) 13 packages and 0 specfiles checked; 20 errors, 243 warnings. The issues here are bogus or already addressed in the spec or this bug. ok - License is acceptable (GPLv3, LGPLv2+, ASL 2.0, BSD, Public Domain) ok - License field in spec is correct It might be worth double-checking with spot to ensure this is correct. ok - License files included in package %docs if included in source package ok - License files installed when any subpackage combination is installed Upstream does not include license files for the BSD sub-packages ok - Spec written in American English ok - Spec is legible -- - Sources match upstream unless altered to fix permissibility issues Built directly from upstream git 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: ok - Query upstream about including license files -- - Translations of description, summary ok - Builds in mock no - Builds on all arches (Standard no-java-on-ppc disclaimer) ok - Scriptlets are sane ok - 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 ok - 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 ok - Pre-built binaries, libs removed in %prep 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 -- - 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) ok - Code compilable with gcc is compiled with gcc ok - Build honors applicable compiler flags or justifies otherwise ok - PIE used for long-running/root daemons, setuid/filecap programs ok - Useful -debuginfo package or disabled and justified -- - Package with .pc files Requires pkgconfig on < EL6 ok - No static executables ok - Rpath absent or only used for internal libs ok - Config files marked with %config(noreplace) or justified %config ok - 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) -- - Macro files named /etc/rpm/macros.%name ok - Build uses only python/perl/shell+coreutils/lua/BuildRequired langs ok - %global, not %define -- - Package translating with gettext BuildRequires it -- - Package translating with Linguist BuildRequires qt-devel ok - File ops preserve timestamps no - Parallel make Noted in spec ok - No Requires(pre,post) notation ok - User, group creation handled correctly (See Packaging:UsersAndGroups) Note that the packaging guidelines require shadow-utils, not paths. ok - 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 -- - Available test suites executed in %check ok - tmpfiles.d used for /run, /run/lock on >= F15 Systemd guidelines: ok - Traditional service uses a unit file ok - Non-standard service commands converted to standalone scripts ok - Unit names are sane ok - Description= lines do not exceed 80 characters -- - Documentation field has correct URI format ok - Service Types= are correct ok - Requires=, Wants= used only when necessary ok - Units do not refer to runlevel*.target ok - Symlinks used instead of Name= ok - StandardOutput=, StandardError= used only when necessary -- - Socket-activated service has FESCo approval, correct unit files ok - Unit files go in %_unitdir ok - BuildRequires: systemd-units for %_unitdir macro ok - Packaged unit files are not %config files ok - Unit file scriptlets are correct Java guidelines: -- - Javadocs go in javadoc subpackage ok - Prefer split JARs over monolithic ok - JAR file names correct ok - JAR files go in %{_javadir} or %{_javadir}-$version ok - Multiple JAR files go in a %{name} subdirectory -- - Javadocs go in unversioned %{_javadocdir}/%{name} -- - javadoc subpackage is noarch on > EL5 ok - BuildRequires java-devel, jpackage-utils ok - Requires java, jpackage-utils ok - 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 -- - pom.xml files, if any, installed with %add_maven_depmap ok - JNI shared objects, JARs that require them go in %{_libdir}/%{name} ok - 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 Perl guidelines: ok - Module requirements use virtual perl(modname) syntax ok - Spec BuildRequires correct core modules, not perl-devel -- - Spec contains correct MODULE_COMPAT Requires ok - Requires/Provides are sane -- - CPAN URL tag is not versioned -- - All tests enabled where possible -- - Use Build.PL if present unless justified otherwise -- - .h files not split into -devel package Python guidelines: ok - Runtime Requires correct -- - Python macros declared on < EL6 ok - All .py files packaged with .pyc, .pyo counterparts -- - Includes .egg-info files/directories when generated ok - Provides/Requires properly filtered -- - Code that invokes gtk.gdk.get_pixels_array() Requires numpy -- 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