headers
Jonathan Yu | 1 Jan 2011 14:57
Picon
Gravatar

Bug#608560: ITP: libcps-perl -- module to manage flow of control in Continuation Passing Style

Package: wnpp
Owner: Jonathan Yu <jawnsy <at> cpan.org>
Severity: wishlist
X-Debbugs-CC: debian-devel <at> lists.debian.org,debian-perl <at> lists.debian.org

* Package name    : libcps-perl
  Version         : 0.11
  Upstream Author : Paul Evans <leonerd <at> leonerd.org.uk>
* URL             : http://search.cpan.org/dist/CPS/
* License         : Artistic or GPL-1+
  Programming Lang: Perl
  Description     : module to manage flow of control in Continuation
Passing Style

CPS is a Perl module that enables developers to write code in Continuation
Passing Style, which is a style of writing code where the normal call/return
mechanism is replaced by explicit "continuations". It is useful whenever some
form of asynchronous or event-based programming is in use.

This module is required for upgrading IO::Async (libio-async-perl) to
version 0.34
Permalink | Reply | 0 comments |
headers
Jonathan Yu | 1 Jan 2011 15:32
Picon
Gravatar

Bug#608562: ITP: libcatalyst-engine-psgi-perl -- Catalyst engine for the PSGI protocol

Package: wnpp
Owner: Jonathan Yu <jawnsy <at> cpan.org>
Severity: wishlist
X-Debbugs-CC: debian-devel <at> lists.debian.org,debian-perl <at> lists.debian.org

* Package name    : libcatalyst-engine-psgi-perl
  Version         : 0.11
  Upstream Author : Tatsuhiko Miyagawa <miyagawa <at> bulknews.net>
* URL             : http://search.cpan.org/dist/Catalyst-Engine-PSGI/
* License         : Artistic or GPL-1+
  Programming Lang: Perl
  Description     : Catalyst engine for the PSGI protocol

Catalyst::Engine::PSGI is a Perl module that provides backend support for the
Catalyst MVC framework on any of a multitude of web servers that comply with
the Perl Web Server Gateway Interface (PSGI) specification.

It is commonly used with the Plack middleware (see libplack-perl).
Permalink | Reply | 0 comments |
headers
Jonathan Yu | 1 Jan 2011 15:54
Picon
Gravatar

Bug#608565: ITP: libmath-symbolic-perl -- module for performing symbolic calculations

Package: wnpp
Owner: Jonathan Yu <jawnsy <at> cpan.org>
Severity: wishlist
X-Debbugs-CC: debian-devel <at> lists.debian.org,debian-perl <at> lists.debian.org

* Package name    : libmath-symbolic-perl
  Version         : 0.606
  Upstream Author : Steffen Müller <smueller <at> cpan.org>
* URL             : http://search.cpan.org/dist/Math-Symbolic/
* License         : Artistic or GPL-1+
  Programming Lang: Perl
  Description     : module for performing symbolic calculations

Math::Symbolic is a Perl module for performing symbolic calculations, similar
to Computer Algebra Systems (CAS) like Maxima, Maple and Mathematica. Using
this software, algebraic expressions can be parsed from strings, manipulated
in Perl and even compiled into code references.
Permalink | Reply | 0 comments |
headers
Jonathan Yu | 1 Jan 2011 16:32
Picon
Gravatar

Bug#608567: ITP: libanyevent-http-perl -- simple non-blocking HTTP/HTTPS client

Package: wnpp
Owner: Jonathan Yu <jawnsy <at> cpan.org>
Severity: wishlist
X-Debbugs-CC: debian-devel <at> lists.debian.org,debian-perl <at> lists.debian.org

* Package name    : libanyevent-http-perl
  Version         : 1.5
  Upstream Author : Marc Lehmann <schmorp <at> schmorp.de>
* URL             : http://search.cpan.org/dist/AnyEvent-HTTP/
* License         : Artistic or GPL-1+
  Programming Lang: Perl
  Description     : simple non-blocking HTTP/HTTPS client

AnyEvent::HTTP is an simple non-blocking HTTP/HTTPS client implementation,
which uses AnyEvent under the hood for asynchronous I/O. It supports GET,
POST and other request methods, cookies and more. It is well suited to most
HTTP tasks, while retaining fine-grained control over request and response
headers to cater to more complex requirements.
Permalink | Reply | 0 comments |
headers
Michael Biebl | 1 Jan 2011 17:11
Picon
Favicon

devel files and libraries in /lib

Happy new year everyone.

First of all, thanks Andreas and Jonas for getting libgcrypt and libgpg-error
updated and moved to /lib.

There is one remaining issue though about the devel files, I'd like to raise.

For both libgpg-error-dev and libgcrypt11-dev you moved the .so symlink ,the *.a
and *.la libtool files to /lib too.

My original patch [1] for libcryptsetup (#604936) handled this diffently. It
only moved the *.so.* files to /lib and kept all devel related files in
/usr/lib. This looked like the right way to me.

Afaicr I've never seen this documentented somewhere to do it this way and I'm
wondering if this is indeed the agreed upon best practice and if we should
document it somehow (policy, devref, whatever).

Opinions?

Michael

[1]
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=move-libcryptsetup-to-lib.patch;att=1;bug=604936
--

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Permalink | Reply | 53 comments |
headers
Olaf van der Spek | 1 Jan 2011 17:54
Picon

Re: devel files and libraries in /lib

On Sat, Jan 1, 2011 at 5:11 PM, Michael Biebl <biebl <at> debian.org> wrote:
> For both libgpg-error-dev and libgcrypt11-dev you moved the .so symlink ,the *.a
> and *.la libtool files to /lib too.
>
> My original patch [1] for libcryptsetup (#604936) handled this diffently. It
> only moved the *.so.* files to /lib and kept all devel related files in
> /usr/lib. This looked like the right way to me.
>
> Afaicr I've never seen this documentented somewhere to do it this way and I'm
> wondering if this is indeed the agreed upon best practice and if we should
> document it somehow (policy, devref, whatever).

Isn't /lib only for files that should be available before /usr is mounted?

Olaf
Permalink | Reply | 0 comments |
headers
Olaf van der Spek | 1 Jan 2011 17:58
Picon

Re: Safe File Update (atomic)

On Fri, Dec 31, 2010 at 5:08 PM, Enrico Weigelt <weigelt <at> metux.de> wrote:
>> Not true. Renaming a running executable works just fine, for example.
>
> Well, has been quite a while since I last used Windows, but IIRC
> renaming an running executable was denied.

Maybe on FAT. However, that's OT.

>> >> > Why not designing an new (overlay'ing) filesystem for that ?
>> >>
>> >> Increased complexity, lower performance, little benefit.
>> >
>> > Why that ? Currently applications (try to) implement that all on
>> > their own, which needs great efforts for multiprocess synchronization.
>> > Having that in a little fileserver eases this sychronization and
>> > moves the complexity to a single point.
>>
>> I mean compared to implementing it properly in the kernel.
>
> Doing it in the kernel would be fine (maybe DLM could be used here),

What's DLM?

> but would be a nonportable solution for quite a long time ;-o

Since it's the only proper solution I don't think that's a problem.

Olaf
(Continue reading)

Permalink | Reply | 4 comments |
headers
Andreas Metzler | 1 Jan 2011 17:40

Re: devel files and libraries in /lib

On 2011-01-01 Michael Biebl <biebl <at> debian.org> wrote:
> First of all, thanks Andreas and Jonas for getting libgcrypt and
> libgpg-error updated and moved to /lib.

> There is one remaining issue though about the devel files, I'd like to raise.

> For both libgpg-error-dev and libgcrypt11-dev you moved the .so
> symlink ,the *.a and *.la libtool files to /lib too.

> My original patch [1] for libcryptsetup (#604936) handled this
> diffently. It only moved the *.so.* files to /lib and kept all devel
> related files in /usr/lib. This looked like the right way to me.

> Afaicr I've never seen this documentented somewhere to do it this
> way and I'm wondering if this is indeed the agreed upon best
> practice and if we should document it somehow (policy, devref,
> whatever).
[...]

Hello,
In the latest upload to experimental (-3 which is the NEW queue) I
have synced with Ubuntu. They also install everything to /lib (since
Nov. 2008 afaict from the changelog) with one exception: The la file
stays in /usr/lib and gets a symlink in /lib.  (I think the rationale
is to not break existing la files that list /usr/lib/libgcrypt.la in
deplibs.)

cu andreas
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julien Cristau | 1 Jan 2011 18:34
Picon
Favicon

Re: devel files and libraries in /lib

On Sat, Jan  1, 2011 at 17:11:17 +0100, Michael Biebl wrote:

> Afaicr I've never seen this documentented somewhere to do it this way and I'm
> wondering if this is indeed the agreed upon best practice and if we should
> document it somehow (policy, devref, whatever).
> 
Yes.  Arguably it's covered under
http://www.pathname.com/fhs/pub/fhs-2.3.html#LIBESSENTIALSHAREDLIBRARIESANDKERN

Cheers,
Julien
Permalink | Reply | 47 comments |

Gmane