Log message:
Updated to recent release to fix build problem with perl 5.14.

Log message:
Revision bump after updating perl5 to 5.14.1.

Log message:
Updated to 5.25. This fixes build problem due to API changes of devel/libev.

5.25  Thu Nov 11 01:08:39 CET 2010
        - try a different approach on netbsd - netbsd 5 finally has marginally
          working pthreads, but still broken ucontext/sigaltstack.
        - openbsd 4.8 finally got their act together, Coro works out of the box
          with asm, setjmp and pthreads (no change, just informational).

5.24  Sat Oct 23 11:27:12 CEST 2010
        - port to the EV 4.0 API.
        - work around bugs in mingw32, making strawberry perl work
          out of the box.
        - correctly modify Coro::AIO function prototypes
          so that they reflect the "no optional parameters" rule.
        - "ported" libcoro to C++.

Log message:
Bump the PKGREVISION for all packages which depend directly on perl,
to trigger/signal a rebuild for the transition 5.10.1 -> 5.12.1.

The list of packages is computed by finding all packages which end
up having either of PERL5_USE_PACKLIST, BUILDLINK_API_DEPENDS.perl,
or PERL5_PACKLIST defined in their make setup (tested via
"make show-vars VARNAMES=..."), minus the packages updated after
the perl package update.

sno@ was right after all, obache@ kindly asked and he@ led the
way. Thanks!

Log message:
Update p5-Coro from version 5.22 to version 5.23.

Upstream changes:
5.23  Mon May 17 18:50:42 CEST 2010
	- be more resistant to ordering changes when initialising
          Coro::AnyEvent, Coro::EV and Coro::Event (reported by Matthias
          Waldorf).
	- document that perl 5.12 deliberately removed support for cloning.

Log message:
Initial import of p5-Coro version 5.22 in the NetBSD Packages
Collection.

The Perl 5 module collection Coro manages continuations in general,
most often in the form of cooperative threads.The specific flavor
of thread offered by this module also guarantees you that it will
not switch between threads unless necessary, at easily-identified
points in your program, so locking and parallel access are rarely
an issue, making thread programming much safer and easier than using
other thread models.