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=502065 --- Comment #2 from Jerry James <loganjerry@xxxxxxxxx> 2009-06-09 16:23:54 EDT --- rpmlint output: slashem.x86_64: E: zero-length /var/games/slashem/record slashem.x86_64: E: non-standard-dir-perm /var/games/slashem 0775 slashem.x86_64: E: non-standard-executable-perm /usr/lib64/games/slashem/slashem 02755 slashem.x86_64: E: zero-length /var/games/slashem/perm slashem.x86_64: E: zero-length /var/games/slashem/logfile slashem.x86_64: E: non-standard-dir-perm /var/games/slashem/save 0775 slashem.x86_64: W: dangerous-command-in-%post ln slashem.x86_64: W: dangerous-command-in-%preun rm 1 packages and 1 specfiles checked; 6 errors, 2 warnings. The zero-length files are okay, because they will become nonzero as people play the game, and they are all marked %config(noreplace). The nonstandard dir permissions are copied from nethack, so they're fine. But the dangerous commands need to be dealt with. Looking through the scriptlets, it appears you need to add these to the spec file: Requires(post): coreutils, mkfontdir Requires(preun): coreutils Is mkfontdir really a BuildRequires? I only see it invoked in %post. MUST items: OK: package naming guidelines OK: spec file name X: packaging guidelines -- see the section on scriptlets. I believe that the body of your %post script should be wrapped in this: if [ $1 -eq 1 ]; then ... fi and the body of your %preun script should be wrapped in this: if [ $1 -eq 0 ]; then ... fi OK: licensing guidelines OK: license text matches actual license OK: license file included in %doc OK: spec file in American English OK: spec file legible OK: source file matches upstream OK: builds on at least one primary arch (x86_64) NA: appropriate use of ExcludeArch OK: all dependencies listed in BuildRequires NA: proper handling of locales NA: library installation => invoke ldconfig NA: relocatable package OK: package owns all directories it creates OK: no duplicate file listings OK: proper file permissions OK: %clean section OK: consistent use of macros OK: code or permissible content NA: large documentation in -doc OK: no runtime dependencies in %doc NA: header files in -devel NA: static libraries in -static NA: pkgconfig file => Requires: pkgconfig NA: .so files in -devel NA: -devel requires main package OK: no libtool archives OK: desktop file. However, not this sentence from the Packaging guidelines: For new packages, do not apply a vendor tag to desktop files. Existing packages that use a vendor tag must continue to do so for the life of the package. This is mostly for the sake of menu-editing (which bases off of .desktop file/path names). OK: do not own files/dirs already owned by other packages OK: remove buildroot first in %install OK: all filenames are valid UTF-8 SHOULD items: NA: ask upstream to include a license file NA: description and summary translations OK: package builds in mock (only checked fedora-rawhide-x86_64) --: package builds on all supported arches (unable to check) OK: package functions as described (only minimal testing ... just wait until later!) OK: sane scriptlets NA: subpackages require main package NA: placement of pkgconfig files NA: file dependencies -- 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review