Bug 834070 - Review Request: perl-qpid - Perl bindings for the Qpid messaging framework
Summary: Review Request: perl-qpid - Perl bindings for the Qpid messaging framework
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Lemenkov
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 450912 853856 853859
TreeView+ depends on / blocked
 
Reported: 2012-06-20 18:26 UTC by Darryl L. Pierce
Modified: 2015-06-22 00:08 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-09-12 15:36:15 UTC
Type: Bug
Embargoed:
lemenkov: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)

Description Darryl L. Pierce 2012-06-20 18:26:59 UTC
Spec URL: http://mcpierce.fedorapeople.org/rpms/perl-qpid.spec
SRPM URL: http://mcpierce.fedorapeople.org/rpms/perl-qpid-0.16-1.fc17.src.rpm
Description: Perl bindings for the Qpid messaging framework.
Fedora Account System Username: mcpierce

Comment 1 Jose Pedro Oliveira 2012-06-29 15:03:14 UTC
Daryl,

This is quick first review:

Blocker:
 * The tarball isn't published by the upstream project [1].

   A note in the specfile explaining how it is generated should be imperative
   so that the source files can be verified.
   (although I believe it's a subset of the main qpid-0.16 tarball).

Minor:
 * Remove the comments in the %build and %install sections: this a binary RPM
   and not a noarch one (and perl packagers should be able to review either 
   type).
 * There is a empty %doc line in the %files section

Wishlist:
 * ship the examples as documentation files
   (%doc examples/)
 * contact the perl bindings author so that the patch in the upstream ticket
   QPID-3313 [2] can be applied (see comments in the upstream ticket)


Regards,
jpo

[1] - https://www.apache.org/dyn/closer.cgi/qpid/0.16/
[2] - Update example scripts for perl binding.
      https://issues.apache.org/jira/browse/QPID-3313

Comment 2 Jose Pedro Oliveira 2012-06-29 15:33:34 UTC
This is annoying:

 * You are not authorized to access bug #450912.

Comment 3 Darryl L. Pierce 2012-06-29 15:55:49 UTC
(In reply to comment #1)
> Daryl,
> 
> This is quick first review:
> 
> Blocker:
>  * The tarball isn't published by the upstream project [1].
>
>    A note in the specfile explaining how it is generated should be imperative
>    so that the source files can be verified.
>    (although I believe it's a subset of the main qpid-0.16 tarball).

I'm on the upstream team. We're going to be publishing the Perl sources separately with an upcoming release. Previously the Perl bindings were a part of our monolithic qpid-cpp package but we want to break it out to be its own package.

This is now noted in the specfile.

> Minor:
>  * Remove the comments in the %build and %install sections: this a binary RPM
>    and not a noarch one (and perl packagers should be able to review either 
>    type).

Done.

>  * There is a empty %doc line in the %files section

Done

> 
> Wishlist:
>  * ship the examples as documentation files
>    (%doc examples/)

Done.

>  * contact the perl bindings author so that the patch in the upstream ticket
>    QPID-3313 [2] can be applied (see comments in the upstream ticket)

I'll take care of this after the package finishes review. I wouldn't want to introduce patches to the process at this point.

> 
> 
> Regards,
> jpo
> 
> [1] - https://www.apache.org/dyn/closer.cgi/qpid/0.16/
> [2] - Update example scripts for perl binding.
>       https://issues.apache.org/jira/browse/QPID-3313


New SPEC: http://mcpierce.fedorapeople.org/rpms/perl-qpid.spec
New SRPM: http://mcpierce.fedorapeople.org/rpms/perl-qpid-0.16-1.fc17.1.src.rpm

Comment 4 Jose Pedro Oliveira 2012-06-30 00:18:53 UTC
(In reply to comment #3)
> (In reply to comment #1)
> > Daryl,
> > 
> > This is quick first review:
> > 
> > Blocker:
> >  * The tarball isn't published by the upstream project [1].
> >
> >    A note in the specfile explaining how it is generated should be imperative
> >    so that the source files can be verified.
> >    (although I believe it's a subset of the main qpid-0.16 tarball).
> 
> I'm on the upstream team. We're going to be publishing the Perl sources
> separately with an upcoming release. Previously the Perl bindings were a
> part of our monolithic qpid-cpp package but we want to break it out to be
> its own package.

Great. The current installation Perl procedure was broken, or to be fair, the current uninstallation procedure was broken as there is no reliable way to remove a perl module via ExtUtils::Makemaker.

Will this tarball split be in place for the 0.18 beta?  The qpid-perl tarball
isn't available in the 0.18 alpha release (https://people.apache.org/~jross/qpid-0.18-alpha/).


> 
> This is now noted in the specfile.


> >  * contact the perl bindings author so that the patch in the upstream ticket
> >    QPID-3313 [2] can be applied (see comments in the upstream ticket)
> 
> I'll take care of this after the package finishes review. I wouldn't want to
> introduce patches to the process at this point.

I've already tried to have it committed for qpid 0.14 but the patch author (who also made the Qpid perl bindings) forgot to check the license checkbox :(


> 
> > 
> > 
> > Regards,
> > jpo
> > 
> > [1] - https://www.apache.org/dyn/closer.cgi/qpid/0.16/
> > [2] - Update example scripts for perl binding.
> >       https://issues.apache.org/jira/browse/QPID-3313
> 
> 
> New SPEC: http://mcpierce.fedorapeople.org/rpms/perl-qpid.spec
> New SRPM:
> http://mcpierce.fedorapeople.org/rpms/perl-qpid-0.16-1.fc17.1.src.rpm

Blocker:

 * The change from "%{perl_vendorarch}/*" to "%{perl_vendorarch}" is a blocker
   as it makes the perl-qpid package own the perl_vendorarch directory.

Note:

 * You no longer need to add a defattr line to the %files section
   The %files section can be something like:
   ------
   %files
   %doc LICENSE examples/
   %{perl_vendorarch}/*
   %exclude %dir %{perl_vendorarch}/auto/
   ------

 * any particular reason why the release bump was not 2.fc17? 

/jpo

Comment 5 Darryl L. Pierce 2012-07-02 12:50:52 UTC
(In reply to comment #4)
> Great. The current installation Perl procedure was broken, or to be fair,
> the current uninstallation procedure was broken as there is no reliable way
> to remove a perl module via ExtUtils::Makemaker.
> 
> Will this tarball split be in place for the 0.18 beta?  The qpid-perl tarball
> isn't available in the 0.18 alpha release
> (https://people.apache.org/~jross/qpid-0.18-alpha/).

I don't think so. I have a patch set that's pending review still in JIRA, but our 0.18 alpha has already been cut. Since this isn't critical path for 0.18, it'll likely be a part of our 0.20 release.

> > This is now noted in the specfile.
> 
> 
> > >  * contact the perl bindings author so that the patch in the upstream ticket
> > >    QPID-3313 [2] can be applied (see comments in the upstream ticket)
> > 
> > I'll take care of this after the package finishes review. I wouldn't want to
> > introduce patches to the process at this point.
> 
> I've already tried to have it committed for qpid 0.14 but the patch author
> (who also made the Qpid perl bindings) forgot to check the license checkbox
> :(

Understood. I'll make it a priority post-review. :)

> > > Regards,
> > > jpo
> > > 
> > > [1] - https://www.apache.org/dyn/closer.cgi/qpid/0.16/
> > > [2] - Update example scripts for perl binding.
> > >       https://issues.apache.org/jira/browse/QPID-3313
> > 
> > 
> > New SPEC: http://mcpierce.fedorapeople.org/rpms/perl-qpid.spec
> > New SRPM:
> > http://mcpierce.fedorapeople.org/rpms/perl-qpid-0.16-1.fc17.1.src.rpm
> 
> Blocker:
> 
>  * The change from "%{perl_vendorarch}/*" to "%{perl_vendorarch}" is a
> blocker
>    as it makes the perl-qpid package own the perl_vendorarch directory.

Derp! Sorry, I didn't realize I'd removed the splat.

> 
> Note:
> 
>  * You no longer need to add a defattr line to the %files section
>    The %files section can be something like:
>    ------
>    %files
>    %doc LICENSE examples/
>    %{perl_vendorarch}/*
>    %exclude %dir %{perl_vendorarch}/auto/
>    ------
> 
>  * any particular reason why the release bump was not 2.fc17? 
> 
> /jpo

Since we're only modifying the specfile and not the underlying code, I'm only treating these as point releases on the spec.

Updated SPEC: http://mcpierce.fedorapeople.org/rpms/perl-qpid.spec
Updated SRPM: http://mcpierce.fedorapeople.org/rpms/perl-qpid-0.16-1.fc17.2.src.rpm

Thank you. :)

Comment 6 Darryl L. Pierce 2012-07-04 17:29:48 UTC
If the above changes are sufficient, could we wrap up the review?

Comment 7 Jose Pedro Oliveira 2012-07-06 15:30:30 UTC
(In reply to comment #6)
> If the above changes are sufficient, could we wrap up the review?

Sorry but I won't be able to resume the review until Monday. This week has been rather complicated and I will be offline during the weekend.

/jpo

Comment 8 Darryl L. Pierce 2012-07-06 17:48:31 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > If the above changes are sufficient, could we wrap up the review?
> 
> Sorry but I won't be able to resume the review until Monday. This week has
> been rather complicated and I will be offline during the weekend.

Not a problem, and thank you for your time. Have a good weekend. :)

Comment 9 Darryl L. Pierce 2012-07-10 18:36:17 UTC
Would it be possible to wrap this review up in the next day or so? Also, please move the status from NEW to ASSIGNED. Thanks. :)

Comment 10 Jose Pedro Oliveira 2012-07-13 12:21:45 UTC
Darryl L. Pierce,

Is upstream really splitting the qpid monolithic tarball? I'm asking his because I saw the answer you got to your mail

 * 0.18 inclusion request - Perl upstream tarball changes 
   http://qpid.2158936.n2.nabble.com/0-18-inclusion-request-Perl-upstream-tarball-changes-td7579593.html

in the qpid developer and having separated tarballs doesn't seem to be in the roadmap.


/jpo

Comment 11 Darryl L. Pierce 2012-07-13 12:32:48 UTC
(In reply to comment #10)
> Darryl L. Pierce,
> 
> Is upstream really splitting the qpid monolithic tarball? I'm asking his
> because I saw the answer you got to your mail
> 
>  * 0.18 inclusion request - Perl upstream tarball changes 
>   
> http://qpid.2158936.n2.nabble.com/0-18-inclusion-request-Perl-upstream-
> tarball-changes-td7579593.html
> 
> in the qpid developer and having separated tarballs doesn't seem to be in
> the roadmap.

Yes, it's the goal.

Comment 12 Darryl L. Pierce 2012-07-17 14:47:49 UTC
Please, can we wrap up this package review? I understand that other tasks can pull you away, but it seems that I've met all review expectations and would like to get this package done.

Comment 13 Darryl L. Pierce 2012-07-23 19:32:04 UTC
Just following up since another week has passed. I appreciate other things can come up, but can we go ahead an finish this review?

Comment 18 Peter Lemenkov 2012-09-12 04:47:24 UTC
I'll review it.

Comment 19 Peter Lemenkov 2012-09-12 10:25:17 UTC
Fails to build in Rawhide (this is a blocker):

* http://koji.fedoraproject.org/koji/taskinfo?taskID=4477233

Comment 20 Darryl L. Pierce 2012-09-12 11:27:00 UTC
(In reply to comment #19)
> Fails to build in Rawhide (this is a blocker):
> 
> * http://koji.fedoraproject.org/koji/taskinfo?taskID=4477233

Ugh, I was afraid of this. The problem is that I rebased the Perl package on 0.18 of Qpid which is still only in testing ATM. I'm going to revert back to being based only on 0.16 so we can work against what is the current stable release.

Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=4477354

Reverted SPEC: http://mcpierce.fedorapeople.org/rpms/perl-qpid.spec
Reverted SRPM: http://mcpierce.fedorapeople.org/rpms/perl-qpid-0.16-1.2.fc17.src.rpm

Comment 21 Peter Lemenkov 2012-09-12 11:44:47 UTC
(In reply to comment #20)
> (In reply to comment #19)
> > Fails to build in Rawhide (this is a blocker):
> > 
> > * http://koji.fedoraproject.org/koji/taskinfo?taskID=4477233
> 
> Ugh, I was afraid of this. The problem is that I rebased the Perl package on
> 0.18 of Qpid which is still only in testing ATM. I'm going to revert back to
> being based only on 0.16 so we can work against what is the current stable
> release.

Yep, this sounds like a plan. Be right back - stay tuned.

Comment 22 Peter Lemenkov 2012-09-12 12:40:12 UTC
REVIEW:

Legend: + = PASSED, - = FAILED, 0 = Not Applicable

+ rpmlint is silent

work ~/Desktop: rpmlint perl-qpid-*
3 packages and 0 specfiles checked; 0 errors, 0 warnings.
work ~/Desktop: 

+ The package is named according to the  Package Naming Guidelines.
+ The spec file name matches the base package %{name}, in the format %{name}.spec.
+ The package meets the Packaging Guidelines.
+ The package is licensed with a Fedora approved license and meets the Licensing Guidelines.
+ The License field in the package spec file matches the actual license (Apache Software License v2).
+ The file, containing the text of the license(s) for the package, is included in %doc.
+ The spec file is written in American English.
+ The spec file for the package is legible.
+ The sources used to build the package, match the upstream source, as provided in the spec URL.

sulaco ~/rpmbuild/SOURCES: sha256sum perl-qpid-0.16.tar.gz*
266f0e187e9df43dc85422d4a1b934fcfbb15c83a50e1a8ac73a62ef47953ca4  perl-qpid-0.16.tar.gz
266f0e187e9df43dc85422d4a1b934fcfbb15c83a50e1a8ac73a62ef47953ca4  perl-qpid-0.16.tar.gz.1
sulaco ~/rpmbuild/SOURCES: 

+ The package successfully compiles and builds into binary rpms on at least one primary architecture. See koji link above.
+ All build dependencies are listed in BuildRequires.
0 No need to handle locales.
0 No shared library files in some of the dynamic linker's default paths.
+ The package does NOT bundle copies of system libraries.
0 The package is not designed to be relocatable.
+ The package owns all directories that it creates.
+ The package does not list a file more than once in the spec file's %files listings.
+ Permissions on files are set properly.
0 The package DOESN'T have a %clean section, so it won't build cleanly on systems with old rpm (EL-4 and EL-5, not sure about EL-6). Beware.
+ The package consistently uses macros. Well, almost consistently. You should change $RPM_BUILD_ROOT to %{buildroot} but this isn't a blocker from my PoV.
+ The package contains code, or permissible content.
0 No extremely large documentation files.
+ Anything, the package includes as %doc, does not affect the runtime of the application.
0 No C/C++ header files.
0 No static libraries.
0 No pkgconfig(.pc) files.
0 The package doesn't contain library files without a suffix (e.g. libfoo.so) in some of the dynamic linker's default paths.
0 No devel sub-package.
+ The package does NOT contain any .la libtool archives.
0 Not a GUI application.
+ The package does not own files or directories already owned by other packages.
0 At the beginning of %install, the package  does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) so it won't build cleanly on systems with old rpm (EL-4 and EL-5, not sure about EL-6). Beware.
+ All filenames in the package(s) are valid UTF-8.

APPROVED.


PS it will be great if you review this package in return:

* https://bugzilla.redhat.com/845221 - ilbc - Internet Low Bitrate Codec

Comment 23 Darryl L. Pierce 2012-09-12 14:59:06 UTC
Thank you, Peter!

New Package SCM Request
=======================
Package Name: perl-qpid
Short Description: Perl bindings for the Qpid messaging framework
Owners: mcpierce
Branches: f16 f17 f18
InitialCC: mcpierce

Comment 24 Gwyn Ciesla 2012-09-12 15:03:25 UTC
Git done (by process-git-requests).

Comment 25 Darryl L. Pierce 2012-09-12 15:36:15 UTC
Thank you, Jon and Peter!

Comment 26 Darryl L. Pierce 2013-06-17 11:18:49 UTC
Package Change Request
======================
Package Name: perl-qpid
New Branches: el5 el6
Owners: mcpierce

Comment 27 Gwyn Ciesla 2013-06-17 12:13:47 UTC
Git done (by process-git-requests).

Comment 28 Darryl L. Pierce 2014-02-18 18:30:19 UTC
Package Change Request
======================
Package Name: perl-qpid
New Branches: epel7
Owners: mcpierce

Comment 29 Gwyn Ciesla 2014-02-18 18:38:48 UTC
Git done (by process-git-requests).


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