Bug 448613 - (perl-EV) Review Request: perl-EV - Wrapper for the libev high-performance event loop library
Review Request: perl-EV - Wrapper for the libev high-performance event loop l...
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Extras Quality Assurance
Depends On: 458785 672153
Blocks: perl-Coro
  Show dependency treegraph
Reported: 2008-05-27 16:40 EDT by Nicolas Chauvet (kwizart)
Modified: 2011-02-17 02:49 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-02-16 05:19:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
tibbs: fedora‑review?

Attachments (Terms of Use)

  None (edit)
Description Nicolas Chauvet (kwizart) 2008-05-27 16:40:57 EDT
Spec URL:
Description: Wrapper for the libev high-performance event loop library

This package seems to use libev internally. As there is no current release of libev, this seeems safer to me for now. We might reevaluate this later...

Note also that perl(AnyEvent) seems mentionned in the Makefile.PL, in doesn't seems to be used. Or maybe there is a circle dependency that will need a rebuild once perl(AnyEvent)is available.
Comment 1 Nicolas Chauvet (kwizart) 2008-05-29 13:00:54 EDT
Ok the AnyEvent circle dependency has been solved by newer version.
perl-EV isn't needed at build time for perl-AnyEvent, but can be used (or not :
thus will need to be filtered) at runtime.
Comment 2 Jason Tibbitts 2008-06-18 16:01:12 EDT
rpmlint says this:
  W: devel-file-in-non-devel-package 
  W: devel-file-in-non-devel-package 
but these are normal for binary Perl packages.

I'm not sure about the license.  libev itself has a (2-clause) BSD licence, but
the Perl module is the usual GPL+ or Artistic.  libev seems to be built
internally, and I've no idea whether it could be built standalone.  So I'm not
at all sure what the final license is.  I'll ask the Legal folks to take a look.

* source files match upstream:
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
? license field matches the actual license.
* license is open source-compatible.
* license text included in package.
* latest version is being packaged.
* BuildRequires are proper.
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* debuginfo package looks complete.
* rpmlint has acceptable complaints.
* final provides and requires are sane:
   perl(EV) = 3.42
   perl-EV = 3.42-1.fc10

* %check is present and all tests pass:
  All tests successful.
  Files=10, Tests=6823,  7 wallclock secs ( 0.18 cusr +  0.05 csys =  0.23 CPU)
* no shared libraries are added to the regular linker search paths.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* no scriptlets present.
* code, not content.
* documentation is small, so no -doc subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* headers are OK in the main package.
* no pkgconfig files.
* no static libraries.
* no libtool .la files.
Comment 3 Nicolas Chauvet (kwizart) 2008-06-19 07:58:24 EDT
I've got an answer from the upstream developer.
perl-AnyEvent doesn't need need any dependencies (some will need to be
filtered). So I guess perl-EV will BR perl-AnyEvent (or at least Requires at
Once perl-EV is installed, perl-AnyEvent will elect this module (instead of
perl(Glib) or others ,because it is the fastest.
And I guess the dependent modules will only requires perl(AnyEvent), so i still
need to sort this out, and submit perl-AnyEvent for review first...

About the libev be built internally, here is the upstream answer:
EV comes with it's own copy of libev and cannot possibly links against a
preinstalled system libev (they are ABI-incompatible).

Therefore, EV itself has no external dependencies (but of course it is
I don't know if it is how perl arch dependant modules will works.
Comment 4 Nicolas Chauvet (kwizart) 2008-06-23 10:30:24 EDT
Spec URL:
Description: Wrapper for the libev high-performance event loop library

This package seems to requires AnyEvent at buildtime (according to Makefile.PL)
but will be required by AnyEvent at runtime.
Comment 5 Nicolas Chauvet (kwizart) 2008-07-15 19:52:58 EDT
Spec URL:
Description: Wrapper for the libev high-performance event loop library

- Update to 3.431
- Update License to (GPL+ or Artistic) and (BSD or GPLv2+)
- Add libev README and LICENSE
Comment 6 Jason Tibbitts 2008-08-12 09:01:42 EDT
Hmm, this seems to be waiting on me.  Not sure how that happened; I'll try to get to this today.

But I note that someone has submitted libev for review; see bug 458785.  Do you think that should have any bearing on this package?
Comment 7 Tom "spot" Callaway 2008-09-02 12:12:51 EDT
The license tag is correct. You really should try to use the system libev rather than a bundled copy. Also, your SRPM in comment #5 doesn't seem to exist.

However, there is no need for FE-Legal here, so I'm lifting it.
Comment 8 Jason Tibbitts 2008-10-01 12:11:36 EDT
So, what's going on here?  The spec is still there but the SRPM isn't, and there's the open question of using the system libev.
Comment 9 Nicolas Chauvet (kwizart) 2008-10-01 12:22:46 EDT
Don't know why srpm isn't there anymore.
This bug depend on libev review...
Comment 10 Nicolas Chauvet (kwizart) 2008-10-14 06:40:11 EDT
Spec URL:
Description: Wrapper for the libev high-performance event loop library

- Update to 3.44
- WIP conditional --with systemlibev

The system libev cannot be picked at this time. At least it works from the Makefile.PL point of view. The EV.so is linked to -lev and make test showed that the library get loaded. But others tests are failing whereas they work with libev internal.
I will request upstream for advices.
Comment 11 Nicolas Chauvet (kwizart) 2009-11-08 14:25:33 EST
SPEC: http://kwizart.fedorapeople.org/review/perl-EV.spec
SRPM: http://kwizart.fedorapeople.org/review/perl-EV-3.8-1.fc12.src.rpm
Description: Wrapper for the libev high-performance event loop library

Update to 3.8
no progress on using the libev shared, upstream stop responding after saying it was not relevant for perl-EV to link a shared version of libev.
Comment 12 Jason Tibbitts 2009-11-08 14:34:19 EST
I suppose if you want to not use the system library, you can request an exemption from FESCo.  Personally I believe that given recent history it is very unlikely that you will receive one, but you're welcome to try.  I believe that at this point that is the only issue blocking this package.
Comment 13 Nicolas Chauvet (kwizart) 2009-11-08 14:41:24 EST
Fesco exeption are for static linking, are they for perl 'shared' pod libraries ?!
Comment 14 Jason Tibbitts 2009-11-08 15:27:04 EST
I can't parse that sentence as I'm not sure what a "pod library" is.  If you want to use the copy of the library included in the source code of this module instead of linking against the system copy of the library, you'll need to ask FESCo for an exception.
Comment 15 Mathieu Bridon 2011-01-20 05:02:02 EST
Nicolas, did you abandon this package?

I need it, so I am willing to take over the review request if you won't finish it.
Comment 16 Nicolas Chauvet (kwizart) 2011-01-20 05:14:08 EST
Hi Mathieu!
The problem probably remains unsolved in current release. But might have be evolved with the libev update that has appeared in rawhide recently.

Your help is welcomed, feel free to takeover.
Comment 17 Mathieu Bridon 2011-01-24 03:43:42 EST
I spoke about the issue with the libev/EV author and the problem is not in the sources (the bundled ones have always been identical to the system ones we use to build our libev package), but in that the built binaries are ABI-incompatible.

As such, I opened bug #672153 to ask for the addition of a libev-source subpackage, which perl-EV could then BuildRequire.

This is what is already done when building tigervnc (it BR the xorg-x11-server-source subpackage that contains the sources of the xorg-x11-server rpm).

Here are the new items for the review.
SPEC: http://bochecha.fedorapeople.org/packages/perl-EV.spec
SRPM: http://bochecha.fedorapeople.org/packages/perl-EV-4.03-1.fc15.src.rpm

I'm adding the "Depends On" flag, but I suppose the review can proceed without waiting for the other one to be fixed.
Comment 18 Mathieu Bridon 2011-02-07 21:44:38 EST
Bug #672153 has been fixed, the libev package now builds a libev-source subpackage that can be used to build this one:

Anybody up for finishing the review?
Comment 19 Jason Tibbitts 2011-02-07 22:26:10 EST
If Nicholas wants to produce an updated package I'll finish the review (since it's still assigned to me after all this time).
Comment 20 Mathieu Bridon 2011-02-08 03:39:26 EST
(In reply to comment #19)
> If Nicholas wants to produce an updated package I'll finish the review (since
> it's still assigned to me after all this time).

I took over the submission from Nicolas (see comment 16) and produced an updated package (see comment 17).

The srpm in comment 17 is the one I scratched built in Koji to show that it now uses the system libev (see comment 18).
Comment 21 Nicolas Chauvet (kwizart) 2011-02-16 05:19:04 EST
I will let Mathieu submit another review.
Comment 22 Mathieu Bridon 2011-02-17 02:49:31 EST
FWIW, I just opened a new review request for perl-EV:

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