[Bug 328161] Review Request: Harmony - Software to program the Logitech Harmony remote control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]