Bug 800102 - Review Request: perl-WWW-Google-Contacts - Use Perl to access, list and edit Google Contacts
Review Request: perl-WWW-Google-Contacts - Use Perl to access, list and edit ...
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Ken Dreyer
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-03-05 13:21 EST by Avi Alkalay
Modified: 2012-03-31 11:48 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-03-26 13:02:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
ktdreyer: fedora‑review+
limburgher: fedora‑cvs+

Attachments (Terms of Use)

  None (edit)
Description Avi Alkalay 2012-03-05 13:21:46 EST
Spec and RPMs: http://avi.alkalay.net/software/perl-WWW-Google-Contacts/

This module implements 'Google Contacts Data API' according to
Comment 1 Avi Alkalay 2012-03-05 13:24:36 EST
The spec file was generated by cpanspec. I made some edits to improve summary and description and to add a BuildRequires.
Comment 2 Ken Dreyer 2012-03-16 13:45:16 EDT
Hi Avi, thanks for contributing to Fedora. I'll take this review.
Comment 3 Ken Dreyer 2012-03-16 14:53:44 EDT
Package Review, generated by fedora-review 0.1.2

- = N/A
x = Pass
! = Fail
? = Not evaluated

==== Generic ====
[x]: MUST Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Yes, GPL+ or Artistic.
[x]: MUST Package successfully compiles and builds into binary rpms on at
     least one supported primary architecture.
     Yes, mocked for F18 (rawhide).
[x]: MUST All build dependencies are listed in BuildRequires, except for any
     that are listed in the exceptions section of Packaging Guidelines.
[!]: MUST Buildroot is not present
     Note: Buildroot is not needed unless packager plans to package for EPEL5
[x]: MUST Package contains no bundled libraries.
[x]: MUST Changelog in prescribed format.
[x]: MUST Package has no %clean section with rm -rf %{buildroot} (or
     Note: Clean would be needed if support for EPEL is required
[x]: MUST Sources contain only permissible code or content.
[!]: MUST Each %files section contains %defattr if rpm < 4.4
     Note: defattr(....) present in %files section. This is OK if packaging
     for EPEL5. Otherwise not needed
[x]: MUST Macros in Summary, %description expandable at SRPM build time.
[x]: MUST Package requires other packages for directories it uses.
[x]: MUST Package uses nothing in %doc for runtime.
[x]: MUST Package is not known to require ExcludeArch.
[x]: MUST Permissions on files are set properly.
[x]: MUST Package does not contain duplicates in %files.
[x]: MUST Spec file lacks Packager, Vendor, PreReq tags.
[x]: MUST Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
     Note: rm -rf would be needed if support for EPEL5 is required
[x]: 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 is included in %doc.
[x]: MUST License field in the package spec file matches the actual license.
[x]: MUST Package consistently uses macros (instead of hard-coded directory
[x]: MUST Package meets the Packaging Guidelines.
[x]: MUST Package is named according to the Package Naming Guidelines.
[x]: MUST Package does not generates any conflict.
[x]: MUST Package obeys FHS, except libexecdir and /usr/target.
[x]: MUST Package must own all directories that it creates.
[x]: MUST Package does not own files or directories owned by other packages.
[x]: MUST Package installs properly.
     Installed into F15 mock chroot.
[x]: MUST Requires correct, justified where necessary.
     ...please see below regarding duplicate requires.
[!]: MUST Rpmlint output is silent.

$ rpmlint perl-WWW-Google-Contacts-0.33-2.fc18.src.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint perl-WWW-Google-Contacts-0.33-2.fc18.noarch.rpm
perl-WWW-Google-Contacts.noarch: E: incorrect-fsf-address /usr/share/doc/perl-WWW-Google-Contacts-0.33/LICENSE
1 packages and 0 specfiles checked; 1 errors, 0 warnings.

[x]: MUST Sources used to build the package match the upstream source, as
     provided in the spec URL.
WWW-Google-Contacts-0.33.tar.gz :
  MD5SUM this package     : 3e33a1d0dc9f50fdd45652783b461383
  MD5SUM upstream package : 3e33a1d0dc9f50fdd45652783b461383

[x]: MUST Spec file is legible and written in American English.
[x]: MUST Spec file name must match the spec package %{name}, in the format
[-]: MUST Package contains a SysV-style init script if in need of one.
[x]: MUST File names are valid UTF-8.
[x]: SHOULD Reviewer should test that the package builds in mock.
[-]: SHOULD If the source package does not include license text(s) as a
     separate file from upstream, the packager SHOULD query upstream to
     include it.
[x]: SHOULD Dist tag is present.
[x]: SHOULD No file requires outside of /etc, /bin, /sbin, /usr/bin,
[!]: SHOULD Final provides and requires are sane (rpm -q --provides and rpm -q

There are nine duplicate Requires here:
rpm -qp --requires perl-WWW-Google-Contacts-0.33-2.fc18.noarch.rpm 

These are duplicates because RPM automatically detects some Perl requirements, but cpanspec can be overzealous in listing the requirements also. You can remove these explicit Requires from your .spec file, and RPM will still put them into the built package.

There is an odd Provides here:
rpm -qp --provides perl-WWW-Google-Contacts-0.33-2.fc18.noarch.rpm 
perl(Moose::Meta::Attribute::Custom::Trait::XmlField) = 0.33

From what I can tell, this is an artifact of how Moose works, combined with RPM's automatic provider generator. I'm not familiar enough with Moose to know if the package's source code is correct on this point, but regardless, it is so obscure that I wouldn't worry about it.

[x]: SHOULD Package functions as described.
     The tests pass during the build :)
[x]: SHOULD Package does not include license text files separate from
[x]: SHOULD SourceX is a working URL.
[-]: SHOULD Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: SHOULD Package should compile and build into binary rpms on all supported
[x]: SHOULD %check is present and all tests pass.
[x]: SHOULD Packages should try to preserve timestamps of original installed
[x]: SHOULD Spec use %global instead of %define.

Avi, please take care of the following issues:
1) Let me know if you intend to package this for EPEL 5 or 6. If so, you'll need to add the buildroot tag as described above, and keep the defattr() section. If not, you can remove the defattr() section.

2) Fix the Requires duplicates, as described above.

3) File a bug in the upstream CPAN bug tracker to fix the FSF address, and paste the link here. (You don't have to patch your package for this; an upstream bug is enough.)

If you do these, I'll approve this package and proxy sponsor you as a co-maintainer.
Comment 4 Avi Alkalay 2012-03-21 23:10:59 EDT
Upstream bug related to wrong FSF address:


Will send other updates in the next days.
Comment 5 Avi Alkalay 2012-03-21 23:33:17 EDT
There are updates on the original URL following your recommendations.


I can't see a reason why not to support this in EPEL too. So let's keep the attributes and BuildRoot.
Comment 6 Ken Dreyer 2012-03-22 00:30:28 EDT
One last, minor thing: I recommend dropping dist.ini from your package, since it's of little value to users. Don't sweat re-rolling an SRPM just for this; you can take care of it when you're importing it into Fedora.

EPEL doesn't currently have all the dependencies necessary, so it will more work there (see eg. http://koji.fedoraproject.org/koji/taskinfo?taskID=3921241).

Thanks for addressing all the concerns in the review. This package is approved. What's your FAS username? I'll open a ticket with FESCo to get you sponsored into the packager group.
Comment 7 Avi Alkalay 2012-03-22 05:02:40 EDT
Thanks for approving. Rally, cpanspec made most of the work.

I`m http://koji.fedoraproject.org/koji/userinfo?userID=aviram
Comment 8 Ken Dreyer 2012-03-22 08:40:38 EDT
By the way, until FAS gets the ability to have a dedicated "Bugzilla Email Address" field, you'll probably want to line up your FAS email address with your Bugzilla email address. Right now your FAS email is avibrazil gmail.com, but you post to Bugzilla with avi unix.sh.
Comment 9 Avi Alkalay 2012-03-22 09:13:40 EDT
Ken, thank you for sponsoring.

What happens now if there are upstream updates or there is a need to update the package in the future?

I'll manage to merge my e-mails on both systems.

What about these other submissions, please consider sponsoring them too! They are basically the same for Google Spreadsheets and Google Calendar:


And here is also AtomicParsley to edit MPEG-4 tags. The review started on RPMFusion but we decided it belongs to main Fedora:


Thank you again
Comment 10 Ken Dreyer 2012-03-22 09:45:12 EDT
(In reply to comment #9)
> Ken, thank you for sponsoring.

Well, a member of FESCo or another sponsor still needs to approve the request. Fingers crossed.

> What happens now if there are upstream updates or there is a need to update the
> package in the future?

There is a Package Update HOWTO on the wiki. See https://fedoraproject.org/wiki/Package_update_HOWTO#Build_a_package_for_Rawhide . Fedora also has a tool that can monitor upstream releases. You can set that up once you're sponsored.

> I'll manage to merge my e-mails on both systems.

Ok, please do this soon. Once you're sponsored into the packagers group, it's important that the accounts match so that your Bugzilla privileges stay in sync with Fedora's package database.

> What about these other submissions

Once you're sponsored and someone reviews these Perl packages, you'll be allowed to import them into Fedora also. Maybe we can work out some review swaps once you're sponsored. I have two open myself, at Bug 713313 and Bug 790215 .
Comment 11 Avi Alkalay 2012-03-22 10:05:56 EDT
Both systems have now same e-mail address.
Comment 12 Avi Alkalay 2012-03-26 09:37:12 EDT
New Package SCM Request
Package Name: perl-WWW-Google-Contacts
Short Description: Use Perl to access, list and edit Google Contacts
Owners: aviram
Branches: f16 f17 el6
InitialCC: perl-sig
Comment 13 Gwyn Ciesla 2012-03-26 09:37:26 EDT
Please submit an SCM request when setting the cvs flag, but not until you're
sponsored and the package is approved.  Thanks!
Comment 14 Avi Alkalay 2012-03-26 10:19:08 EDT
The package was approved at Comment 6 (https://bugzilla.redhat.com/show_bug.cgi?id=800102#c6)
Comment 15 Gwyn Ciesla 2012-03-26 10:41:35 EDT
Git done (by process-git-requests).
Comment 16 Avi Alkalay 2012-03-31 11:48:36 EDT
As of today, you can install this package on Fedora 16 from the updates-testing repo:

yum --enablerepo=updates-testing install perl-WWW-Google-Contacts

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