Bug 466974 - Review Request: vdr-remote - Extended remote control plugin for VDR
Review Request: vdr-remote - Extended remote control plugin for VDR
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ville-Pekka Vainio
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-14 16:13 EDT by Ville Skyttä
Modified: 2008-11-22 11:53 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-30 12:08:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
vpvainio: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Ville Skyttä 2008-10-14 16:13:58 EDT
http://scop.fedorapeople.org/packages/vdr-remote.spec
http://scop.fedorapeople.org/packages/vdr-remote-0.4.0-3.fc9.src.rpm

This plugin extends VDR's remote control capabilities, adding support
for Linux input devices, keyboards (tty), TCP connections, and LIRC.
Comment 1 Ville Skyttä 2008-10-25 04:23:13 EDT
http://scop.fedorapeople.org/packages/vdr-remote.spec
http://scop.fedorapeople.org/packages/vdr-remote-0.4.0-4.fc9.src.rpm

* Sat Oct 25 2008 Ville Skyttä <ville.skytta at iki.fi> - 0.4.0-4
- Use ATTRS, not SYSFS in example udev rules.
Comment 2 Ville-Pekka Vainio 2008-10-25 13:34:25 EDT
I'll take the review, it'll be my first review, though, but this isn't that different from any of the VDR plugins already in Fedora. I've only taken a quick look at this now, I'll need to spend some time going through all the guidelines a bit later.

I'm not quite happy with how the patches are handled now. You take the "combined" Debian patch and then use patch "manually" instead of using %patch. In Fedora 10 %patch doesn't allow any fuzz, but with your current solution the patches in debian/ need fuzz and they are still applied. It'd be better if you separated the needed patches from the debian patchset and applied those with %patchN. The patches would also need to be modified to not need any fuzz.

Do you know what's the upstream status of these patches?
Comment 3 Ville Skyttä 2008-10-25 14:27:29 EDT
I don't know the upstream status of the patches.  The only one of them that contains any fuzz is the "constness" patch which is pretty much cosmetic and can in principle be dropped if the fuzz makes people nervous.  Others just have some line offsets.  Note that even if the F-10 rpmbuild rejects fuzz by default, packagers can override that on will for the whole package or selectively on per patch basis.

The way the patching is currently set up is least work for me and least work when tracking/verifying patch origin, and I've verified that despite the line offsets and bit of fuzz in one patch, they do the right thing and I'm committed to verifying that in future as well.  Due to the way Debian patchkits are organized, if one wants to use them, not everything can be done with %patch.  The initial patchkit can be applied with that, but it contains other patches inside it for which the only option is to use plain "patch".

If recreating the patches from scratch and thus disconnecting them from their origin is a requirement for this package to pass review, I'll do it, but I don't see any real benefits in doing so, just some more work.
Comment 4 Ville Skyttä 2008-10-25 14:52:53 EDT
I just sent mail to upstream and the Debian patchkit author asking for status of the patches in it.

The i18ndetect patch is currently Fedora specific and non-upstreamable; upstream vdr does not have the *.pc file nor a -config script and I don't know a better upstreamable way of doing what it does so that it'd continue to work on Fedora.
Will add a comment to the specfile about this in the next package revision.
Comment 5 Ville-Pekka Vainio 2008-10-26 07:19:28 EDT
Since you have a plan on managing the patches, I won't consider using the debian patchkit or the offsets and fuzz a blocker for the review. I'll try to go through the packaging guidelines later today or tomorrow.
Comment 6 Ville-Pekka Vainio 2008-10-28 15:25:09 EDT
As it's my first review, I'll do a checklist style thing also, just to be sure
I haven't forgotten anything.

- MUST: rpmlint must be run on every package. The output should be posted in
  the review
  - OK, no output.
- MUST: The package must be named according to the Package Naming Guidelines
  - OK, it's also similar to all the other vdr plugins already in Fedora
- MUST: The spec file name must match the base package %{name}, in the format
  %{name}.spec
  - OK
- MUST: The package must be licensed with a Fedora approved license and meet
  the Licensing Guidelines
- MUST: The License field in the package spec file must match the actual
  license.
- 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. README says "Distributed under GPL", so GPL+ is OK, GPLv2 is in %doc as
    COPYING
- MUST: The spec file must be written in American English
  - OK, as far as I can judge
- MUST: The spec file for the package MUST be legible. If the reviewer is
  unable to read the spec file, it will be impossible to perform a review
  - OK
- MUST: The sources used to build the package must match the upstream source,
  as provided in the spec URL
  - OK
- MUST: The package must successfully compile and build into binary rpms on at
  least one supported architecture
  - OK, built as a scratch build on all architectures
- MUST: All build dependencies must be listed in BuildRequires
  - OK, since works in mock and Koji
- MUST: The spec file MUST handle locales properly
  - OK
- The shared library file rule doesn't affect a VDR plugin
- Not relocatable
- MUST: A package must own all directories that it creates. If it does not
  create a directory that it uses, then it should require a package which does
  create that directory
  - OK, the vdr package owns the plugindir and the udev package owns the rule
    dir
- MUST: A package must not contain any duplicate files in the %files listing
  - OK
- MUST: Permissions on files must be set properly. Executables should be set
  with executable permissions, for example. Every %files section must include
  a %defattr(...) line
  - OK
- MUST: Each package must have a %clean section, which contains rm -rf
  %{buildroot}
  - OK
- MUST: Each package must consistently use macros
  - OK
- MUST: The package must contain code, or permissable content.
  - OK
- Doesn't contain large documentation files
- MUST: If a package includes something as %doc, it must not affect the runtime
  of the application
  - OK
- Doesn't install any header files
- Has no static libs, .pc files, .so files, -devel package, .la archives, 
  subpackages, file dependencies or scriptlets
- Not a GUI app as such
- 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}
  - OK
- MUST: All filenames in rpm packages must be valid UTF-8
  - OK
- SHOULD: The description and summary sections in the package spec file should
  contain translations for supported Non-English languages, if available
  - OK, none seem to be available upstream
- SHOULD: The reviewer should test that the package builds in mock
  - OK, it does
- SHOULD: The package should compile and build into binary rpms on all
  supported architectures
  - OK, it does, I did a scratch build
- SHOULD: The reviewer should test that the package functions as described
  - It'd be a bit too cumbersome for me to test this package with my current
    VDR setup. I've used a previous version before and it worked, I believe
    this will work too.

I'd like to note that I'm no expert on udev rules, but I've used similar rules
myself as in Source2 and I believe they should work.

Ville, you mentioned you'll add a comment about the i18ndetect patch. Please
also add comments about the Debian patches and their upstream status if 
upstream or the Debian maintainer replies you. I won't consider this to be a
blocker, though.

Considering that this is my first review, to the best of my knowledge this
package is suitable for Fedora and I will approve it.
Comment 7 Ville Skyttä 2008-10-28 16:39:48 EDT
Thanks!

(In reply to comment #6)

> Ville, you mentioned you'll add a comment about the i18ndetect patch. Please
> also add comments about the Debian patches and their upstream status if 
> upstream or the Debian maintainer replies you.

Will do (no replies yet).  By the way, if you'd like to co-maintain this, feel free to ask for perms in pkgdb once the package is in.

New Package CVS Request
=======================
Package Name: vdr-remote
Short Description: Extended remote control plugin for VDR
Owners: scop
Branches: F-9 F-10
Comment 8 Kevin Fenzi 2008-10-29 17:32:04 EDT
cvs done.
Comment 9 Ville Skyttä 2008-10-30 12:08:54 EDT
Rawhide built, others are on their way.  Thanks again!
http://koji.fedoraproject.org/koji/taskinfo?taskID=912048
Comment 10 Fedora Update System 2008-10-30 12:35:52 EDT
vdr-remote-0.4.0-5.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/vdr-remote-0.4.0-5.fc9
Comment 11 Fedora Update System 2008-10-31 06:26:36 EDT
vdr-remote-0.4.0-5.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 12 Fedora Update System 2008-11-04 12:32:47 EST
vdr-remote-0.4.0-5.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/vdr-remote-0.4.0-5.fc10
Comment 13 Fedora Update System 2008-11-22 11:53:52 EST
vdr-remote-0.4.0-5.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.