Bug#574692: ITP: haskell-ltk -- leksah tool kit

Package: wnpp Severity: wishlist Owner: Joachim Breitner -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: haskell-ltk Version : 0.8 Upstream Author : Juergen "jutaro" Nicklisch-Franken * URL : http://www.leksah.org/ * License : GPL Programming

Bug#574690: ITP: haddock-leksah -- a documentation-generation tool for Haskell libraries

Package: wnpp Severity: wishlist Owner: Joachim Breitner -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: haddock-leksah Version : 2.6.0 Upstream Author : Juergen "jutaro" Nicklisch-Franken * URL : http://leksah.org/ * License : BSD3 Programmin

Bug#574693: ITP: haskell-leksah-server -- metadata collection for leksah

Package: wnpp Severity: wishlist Owner: Joachim Breitner -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: haskell-leksah-server Version : 0.8.0.2 Upstream Author : Juergen "jutaro" Nicklisch-Franken * URL : http://leksah.org * License : GPL Pro

Bug#574691: ITP: binary-shared -- sharing for the binary package

Package: wnpp Severity: wishlist Owner: Joachim Breitner -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: binary-shared Version : 0.8 Upstream Author : Juergen "jutaro" Nicklisch-Franken * URL : http://www.leksah.org/ * License : GPL Programmin

Re: Bug#562143: apt is no longer in base system created by debootstrap?

Hi, Frans Pop schrieb: > Right, and existing tools depend on the fact that it has always been tagged > Build-Essential. You can argue about changing that, but if you do you will > also need to agree on a transition period. debootstrap has been fixed and that is why I am closing this bug report

Re: Bits from the Release Team: What should go into squeeze?

On Mon, Mar 15, 2010 at 07:31:42PM +0100, Sylvestre Ledru wrote: > > We would like to know what needs attention, what bugs still need to be > > fixed in your package before squeeze is released, which features or new > > upstream versions you want to see in squeeze which are not ready yet. > > Furth

scons.mk is in latest cdbs package

Hi, i just realized latest cdbs now contains the scons.mk file, and i wonder if there should be some notice sent to all package maintainers who use a custom debian/cdbs/scons.mk file, to make them use the one provided by cdbs now ? Regards, Jérémy Lal -- To UNSUBSCRIBE, email to debian-devel-re

DASIP2010 > Call for Papers

== CALL FOR CONTRIBUTIONS == The 2010 Conference on Design and Architectures for Signal and Image Processing (DASIP) 26-28 October 20

Re: Bug#540215: Introduce dh_checksums

On Fri, Mar 19, 2010 at 05:56:40PM -0700, Russ Allbery wrote: > Harald Braumann writes: > > On Thu, Mar 18, 2010 at 04:52:07PM -0700, Russ Allbery wrote: > > >> You add an additional ar member that contains the signed checksums of > >> all of the files in data.tar.gz, possibly another additional

Re: Bug#540215: Introduce dh_checksums

Harald Braumann writes: > On Fri, Mar 19, 2010 at 05:56:40PM -0700, Russ Allbery wrote: >> I think it would replace dh_*sums during package build time and make >> obsolete including md5sums in the control.tar.gz. You don't really >> want the signature and checksums to be inside one of the other

Re: Bug#540215: Introduce dh_checksums

On Sat, Mar 20, 2010 at 06:13:14AM -0700, Russ Allbery wrote: > Yeah, that would be one such convention. I don't know if that's better or > if adding a prefix of data: and control: to the path names would be > better. My guess is that the latter may be a bit more flexible for > possible long-ter

Re: Status of kernel patch packages

Hi, On Sat, 20 Mar 2010 15:14:59 +0100 Yann Dirson wrote: > So the question is, is it time to request removal of those packages, > or is there any remaining reason not to do so that I missed ? As linux-patch-tomoyo1.7 package maintainer, tomoyo is merged with mainline, but it's not fully feat

Re: Status of kernel patch packages

Hi Yann Thanks for the reminder. Yes it is time to remove at least the openvz kernel patch package. Best regards, // Ola On Sat, Mar 20, 2010 at 03:14:59PM +0100, Yann Dirson wrote: > Since April 2009, kernel-package has no use any more for the > {kernel,linux}-patch-* packages (AFAIK the curre

Re: Status of kernel patch packages

On Sat, Mar 20, 2010 at 05:28:33PM +0100, Yann Dirson wrote: On Sun, Mar 21, 2010 at 12:17:22AM +0900, Hideki Yamane wrote: On Sat, 20 Mar 2010 15:14:59 +0100 Yann Dirson wrote: > So the question is, is it time to request removal of those > packages, or is there any remaining reason not to do

Re: Bits from the Release Team: What should go into squeeze?

Le samedi 20 mars 2010 à 14:23 +0300, Stanislav Maslovski a écrit : > On Mon, Mar 15, 2010 at 07:31:42PM +0100, Sylvestre Ledru wrote: > > > We would like to know what needs attention, what bugs still need to be > > > fixed in your package before squeeze is released, which features or new > > > ups

Re: libgcrypt brain dead?

On Tue, 9 Mar 2010, Brian May wrote: Unfortunately, gcrypt is used by gnutls, which is used in ldap, which is frequently used in PAM and NSS. So this is an issue. There might be other NSS and PAM modules that use it too. Indeed, and this causes significant pain for Debian users in a lot of env

Re: Bug#540215: Introduce dh_checksums

Harald Braumann writes: > On Sat, Mar 20, 2010 at 06:13:14AM -0700, Russ Allbery wrote: >> Yeah, that would be one such convention. I don't know if that's better >> or if adding a prefix of data: and control: to the path names would be >> better. My guess is that the latter may be a bit more fl

Re: libgcrypt brain dead?

Richard A Nelson writes: > Indeed, and this causes significant pain for Debian users in a lot of > environments. > * GnuTLS does not negotiate well with some corporate SSL libraries and > the kluge patches applied to products like OpenLDAP don't offer the > ability to turn of TLS 1.1 negotiat

Re: libgcrypt brain dead?

On Sat, 2010-03-20 at 12:03 -0700, Russ Allbery wrote: > Richard A Nelson writes: [...] > > For interoperability, OpenSSL is much better, but there is apparently > > still some amount of work to be done on license exemptions (how much?), > > and even if that were done, it'd take a bit of work to s

Re: libgcrypt brain dead?

Ben Hutchings writes: > On Sat, 2010-03-20 at 12:03 -0700, Russ Allbery wrote: >> The primary problem with using OpenSSL with OpenLDAP is NSS and PAM >> modules, which pull the libraries into just about any GPL'd (or >> other-licensed) package in the distribution in one way or another. > [...] >

Re: libgcrypt brain dead?

On Mar 20, Russ Allbery wrote: > My understanding is that that's not the standard that Debian has > historically applied, This is not my understanding as well. -- ciao, Marco signature.asc Description: Digital signature

Re: libgcrypt brain dead?

* Henrique de Moraes Holschuh: > 2. Must be thread-safe, and fully reentrant both at the function and at >the _library_ level; This does not include the async-signal-safe property, right? I'm also not sure if the function needs to be reentrant within the same thread (depending on what it doe

Re: libgcrypt brain dead?

On Sat, Mar 20, 2010 at 01:33:43PM -0700, Russ Allbery wrote: > Ben Hutchings writes: > > On Sat, 2010-03-20 at 12:03 -0700, Russ Allbery wrote: > > >> The primary problem with using OpenSSL with OpenLDAP is NSS and PAM > >> modules, which pull the libraries into just about any GPL'd (or > >> oth

Bug#574780: ITP: braindump -- dump and organize the content of your brain to your computer

Package: wnpp Severity: wishlist Owner: Ana Guerrero Owner: Ana Guerrero * Package name: braindump Version : 0.8.0 Upstream Author : Cyrille Berger and others * URL : http://bitbucket.org/cyrille/braindump/ * License : LGPL v2 or later Programming Lang: C++

Re: libgcrypt brain dead?

On Sat, 2010-03-20 at 13:33 -0700, Russ Allbery wrote: > Ben Hutchings writes: > > On Sat, 2010-03-20 at 12:03 -0700, Russ Allbery wrote: > > >> The primary problem with using OpenSSL with OpenLDAP is NSS and PAM > >> modules, which pull the libraries into just about any GPL'd (or > >> other-lice

Re: libgcrypt brain dead?

Ben Hutchings writes: > It also isn't very useful for us to spend a lot of time working around a > legal issue that doesn't exist, so this may well be a case where it is > worth asking for legal advice through SPI. Yes, agreed. -- Russ Allbery (r...@debian.org)

Re: libgcrypt brain dead?

On Sat, 20 Mar 2010, Russ Allbery wrote: Hrm, I've been swamped with work, and have neglected most of my packages for far too long (though some intentional), I'll give the idea some thought, though, OpenLDAP is *very* critical to both my home and work setup ! The first step would be to reach co

Bug#574787: ITP: commit-patch -- Commit patches to Darcs, Git, Mercurial, Bazaar, Subversion, or CVS repositories

Package: wnpp Severity: wishlist Owner: David Caldwell * Package name: commit-patch Version : 2.3 Upstream Author : David Caldwell * URL : http://porkrind.org/commit-patch/ * License : GPL Programming Lang: Perl Description : Commit patches to Darcs,

Bug#574789: ITP: freebsd-ppp -- FreeBSD Point-to-Point Protocol (PPP) userland daemon

Package: wnpp Severity: wishlist Owner: antoine beaupre Owner: antoine beaupre * Package name: freebsd-ppp Version : 8.0 Upstream Author : Brian Somers * URL : http://www.freebsd.org/doc/handbook/userppp.html * License : BSD Programming Lang: C Descripti

Re: libgcrypt brain dead?

On 21 March 2010 06:59, Ben Hutchings wrote: > Applications that use NSS/PAM, and individual NSS/PAM modules, are > useful without the other and it is a matter of user configuration > whether they are used together at all.  The OpenLDAP modules are not > used by default.  So I don't see that copyl

Re: libgcrypt brain dead?

Brian May writes: > On 21 March 2010 06:59, Ben Hutchings wrote: >> Applications that use NSS/PAM, and individual NSS/PAM modules, are >> useful without the other and it is a matter of user configuration >> whether they are used together at all.  The OpenLDAP modules are not >> used by default.

Re: libgcrypt brain dead?

On Sat, Mar 20, 2010 at 01:33:43PM -0700, Russ Allbery wrote: > Ben Hutchings writes: > > On Sat, 2010-03-20 at 12:03 -0700, Russ Allbery wrote: > >> The primary problem with using OpenSSL with OpenLDAP is NSS and PAM > >> modules, which pull the libraries into just about any GPL'd (or > >> other