Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Harmony - Software to program the Logitech Harmony remote control https://bugzilla.redhat.com/show_bug.cgi?id=328161 ------- Additional Comments From nicolas.mailhot@xxxxxxxxxxx 2007-10-11 16:29 EST ------- OK MUST: rpmlint must be run on every package Just a few warnings: harmony.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/harmony-0.11/examples/Connectivity.EZHex harmony.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/harmony-0.11/examples/Update.EZHex harmony.x86_64: W: file-not-utf8 /usr/share/doc/harmony-0.11/examples/Update.EZHex harmony.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/harmony-0.11/examples/LearnIr.EZTut OK MUST: The package must be named according to the Package Naming Guidelines. OK MUST: The spec file name must match the base package %{name}, in the format %{name}.spec… OK MUST: The package must meet the Packaging Guidelines. OK MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines. OK MUST: The License field in the package spec file must match the actual license. NOK MUST: 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 MUST: The spec file must be written in American English. Well, i18n English at least as that's the only thing I can be judge of OK MUST: The spec file for the package MUST be legible… OK MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this. OK MUST: The package must successfully compile and build into binary rpms on at least one supported architecture. Builds on current x86_64 rawhide in mock — MUST: If the package does not successfully compile, build or work on an architecture… Not tested on exotic arches OK MUST: All build dependencies must be listed in BuildRequires… Builds on current x86_64 rawhide in mock N/A MUST: The spec file MUST handle locales properly… N/A MUST: Every binary RPM package which stores shared library files… N/A MUST: If the package is designed to be relocatable… N/A MUST: A package must own all directories that it creates… OK MUST: A package must not contain any duplicate files in the %files listing. NOK MUST: Permissions on files must be set properly… You rely entirely on upstream not messing up premissions. With such a simple package you can do better: please use a generic %defattr(0644, root, root, 0755) at the start of %files and then %attr the single binary so it's executable OK MUST: Each package must have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT). OK MUST: Each package must consistently use macros, as described in the macros section of Packaging Guidelines. NOK MUST: The package must contain code, or permissable content. This is described in detail in the code vs. content section of Packaging Guidelines. Skip the examples N/A MUST: Large documentation files should go in a -doc subpackage… OK MUST: If a package includes something as %doc, it must not affect the runtime of the application… N/A MUST: Header files must be in a -devel package. N/A MUST: Static libraries must be in a -static package. N/A MUST: Packages containing pkgconfig(.pc) files… N/A MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1)… N/A MUST: In the vast majority of cases, devel packages must require the base package… N/A MUST: Packages must NOT contain any .la libtool archives, these should be removed in the spec. N/A MUST: Packages containing GUI applications must include a %{name}.desktop file,… OK MUST: Packages must not own files or directories already owned by other packages… OK MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) OK MUST: All filenames in rpm packages must be valid UTF-8. N/A SHOULD: If the source package does not include license text(s) as a separate file from upstream… N/A SHOULD: The description and summary sections in the package spec file should contain translations… OK SHOULD: The reviewer should test that the package builds in mock. Builds on current x86_64 rawhide in mock — SHOULD: The package should compile and build into binary rpms on all supported architectures. SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example. /usr/sbin/harmony --get-time Harmony Control 0.11 Copyright 2007 Kevin Timmerman and Phil Dibowitz This software is distributed under the GPLv3. Requesting Identity: *********************done Model: Logitech Harmony 885 (Espresso) Firmware Version: 4.0 Hardware Version: 2.1 Config Flash Used: 23% (443 of 1920 KiB) The remote's time is currently 2007/10/11 Thu 22:22:12 +0 This bit is working at least N/A SHOULD: If scriptlets are used, those scriptlets must be sane… N/A SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency. N/A SHOULD: The placement of pkgconfig(.pc) files depends on their usecase… N/A SHOULD: If the package has file dependencies outside of /etc, /bin,… %<--------------------------------------- Additionnal freeform comments and requests: — please remove the commented Epoch – it'd nice to use the buildroot preferred variant of the day — it'd nice to respect the ordering and whitespacing of the fedora templates in rpmdevtools — please install the file yourself instead of relying on complex make install argument passing (it's one file! install is simpler and safer!) — please sprinkle the spec with ©®™ where appropriate so Logitech has no cause to complain — please include and install an udev/hal/policykit config file so harmony device nodes are owned by the current GUI user and the utility needn't be run by root from /usr/sbin — PackageReviewProcess asks to check other stuff like trademarks, and trademarks are clearly a concern for this package. This alone would cause the review to fail. I'll let the review run till this is corrected, as there's no need to involve legal in such a clear-cut case — The examples should probably be dropped – they're not really useful to end-users as upstream's readme explicitely states. Plus if they've been downloaded from logitech's site they legal status may be murky -- 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, or are watching someone who is. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review