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

[Joachim Breitner]

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 Lang: Haskell
  Description : leksah tool kit

UI Framework used by leksah.

This is a dependency of leksah.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkuklGMACgkQ9ijrk0dDIGxAAACg0yYT9ckvkACTjF7ZdfHErxOU
SP8AoKAsrvryRFywPore5cK0Yxc94LlW
=1L2I
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100320092451.3741.91296.report...@kirk.ehbuehl.net

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

[Joachim Breitner]

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
  Programming Lang: Haskell
  Description : a documentation-generation tool for Haskell libraries

This is a copy of haddock, exporting more of the internal modules as a
library.

This is a dependency of leksah.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkukk5MACgkQ9ijrk0dDIGy3jgCfaYjYvHV3uQvrnpdnUxoJblFT
kpQAnROueN1Hi1TXvqBfz038WaGei7f/
=WAdi
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100320092125.3094.63581.report...@kirk.ehbuehl.net

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

[Joachim Breitner]

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
  Programming Lang: Haskell
  Description : metadata collection for leksah

leksah-server is a background server to offload the heavy work from the
leksah client.

This is a dependency of the leksah client.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkuklGYACgkQ9ijrk0dDIGz7RACeP8P1QOzBW4+CtL7u0sjbzG3R
3r8An0Y/abED3Hl+IBth2GEFeKI85Yl5
=bQeI
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100320092454.3049.66615.report...@kirk.ehbuehl.net

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

[Joachim Breitner]

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
  Programming Lang: Haskell
  Description : sharing for the binary package

A variant of the haskell binary packages with support for sharing.

This is a dependency of leksah.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkukk+sACgkQ9ijrk0dDIGwd5QCdE9h3DQ6UMuyzm88wooZXtJ9L
gzEAnA04LmbL+Iu565z3WBVVcj5QfzA1
=E3Pe
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100320092251.3300.25869.report...@kirk.ehbuehl.net

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

[Torsten Werner]

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 now.

Cheers,
Torsten


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ba4aba1.4000...@debian.org

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

[Stanislav Maslovski]

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.
> > Furthermore we would like to get an overview of the remaining transitions
> > that need to be done.
> It is not a classical transition but the Debian Science team would like
> to upload of BLAS / LAPACK and ATLAS this week.
> This is described here:
> http://wiki.debian.org/DebianScience/LinearAlgebraLibraries
> I sent an email to debian-release to double check my proposal:
> http://lists.debian.org/debian-release/2010/03/msg00051.html
> but I haven't received an answer yet.
> Updated packages are available in experimental. My tests show it is
> working smoothly and I am going to do more tests in the next few days.
> 
> These are common libraries in the numerical computing world. ATLAS (an
> high performance BLAS implementation) has 4 RCs in testing/unstable
> which are going to be fixed with this upload (with many others)
> I can provide more information if needed.

Good news! Does it fix libatlas3gf-sse2 bug #536686?

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100320112357.ga22...@kaiba.homelan

scons.mk is in latest cdbs package

[Jérémy Lal]

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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ba4b0f8.4000...@edagames.com

DASIP2010 > Call for Papers

[training]

==
   CALL FOR CONTRIBUTIONS
==

The 2010 Conference on Design and Architectures 
for Signal and Image Processing (DASIP)

26-28 October 2010
Edinburgh, United Kingdom

Details on author schedules, submission, registration, program and venue 
are available on the conference website: 

http://www.ecsi.org/dasip

==
Call for Papers

The historical city of Edinburgh, the capital of Scotland and home to some half 
a million people, will host the 2010 Conference on Design and Architectures for 
Signal and Image Processing (DASIP) from the 26th to the 28th of October 2010. 
DASIP provides an inspiring international forum for latest innovations and 
developments in the field of leading edge embedded signal processing systems. 
Prospective authors are invited to submit manuscripts on topics including, but 
not limited to:

Design methods and tools
- Design verification and fault tolerance
- Embedded system security and security validation
- System-level design and hardware/software co-design
- Communication synthesis, architectural and logic synthesis
- Embedded real-time systems and real-time operating systems
- Rapid system prototyping, performance analysis and estimation
- Formal models, transformations, algorithm transformations and metrics

Development platforms, architectures and technologies
- Embedded platforms for multimedia and telecom
- Many-core and multi-processor systems, SoCs, and NoCs
- Reconfigurable ASIPs, FPGAs, and dynamically reconfigurable systems
- Asynchronous (self-timed) circuits and analog and mixed-signal circuits
- Digital biosignal processing, biologically based and/or inspired systems

Use-cases and applications
- Ambient intelligence, ubiquitous and wearable computing
- Global navigation satellite systems, smart cameras, and PDAs
- Security systems, cryptography, object recognition and tracking
- Embedded systems for automotive, aerospace, and health applications

Smart sensing systems
- Sensor networks, environmental and system monitoring
- Vision, audio, fingerprint, health monitoring, and biosensors
- Structurally-embedded, distributed, and multiplexed sensors
- Sensing for active control systems, adaptive and evolutionary sensors

The conference program will include keynote speeches, contributed paper 
sessions, and demonstrations. Special session, for which a separate call for 
papers will be released shortly, will be kept on the topics of:
- Reliable multi-processor scheduling and  HW/SW resource management
- Reconfigurable (computing) architectures
- The open computing language (OpenCL)
- Reconfigurable video coding (RVC)
- Smart image sensors

Authors should submit their full papers (up to 8 pages, double-column IEEE 
format) in PDF through the web based submission system. Proceedings of DASIP 
2010 will be included in the IEEE Xplore Digital Library. Authors of the best 
papers will be invited to submit an extended version of their work to the 
International Journal of Embedded and Real-Time Communication Systems 
(IJERTCS), 
in which a special issue on DASIP will be published on the third quarter of 
2011.

--
Important Dates

Paper Submission: May 15, 2010
Acceptance Notification: July 15, 2010

--
Steering Committee

Mohamed Abid, Ecole nationale d'ingénieurs de Sfax, TN
Ahmet Erdogan, University of Edinburgh, UK
Guy Gogniat, Université de Bretagne Sud, FR
Bertrand Granado, Ecole Nationale Supérieure de l'Electronique et de ses 
Applications, FR
Jean-Didier Legat, Université catholique de Louvain, BE
Stéphane Mancini, Institut polytechnique de Grenoble, FR
Marco Mattavelli, Ecole Polytechnique Fédérale de Lausanne, CH
Dragomir Milojevic, Université Libre de Bruxelles, BE
Adam Morawiec, Electronic Chips & Systems design Initiative, FR
Michel Paindavoine, Université de Bourgogne, FR

--
Organizing Committee

General Chair: 
Tughrul Arslan, University of Edinburgh, UK

Program Co-Chairs:
Tapani Ahonen, Tampere University of Technology, FI
Jean-François Nezan, Institut National des Sciences Appliquées Rennes, FR

List of PC Members is Available at:
http://www.ecsi.org/dasip

Local Organizer:
The University of Edinburgh/School of Engineering

--
Secretariat

ECSI Office
off...@ecsi.org
Ph: +33 4 76 63 49 34

--

Please, transfer this message to persons interested in this topic!
We apologise if you've received multiple copies of this message!
If you don't wish to receive e-mails concerning DASIP, please reply 
to this m

Re: Bug#540215: Introduce dh_checksums

[Harald Braumann]

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 member
> >> that contains the signed checksums for control.tar.gz, or you document
> >> some convention so that you can combine both into the same signed
> >> checksum document.
> 
> > Wouldn't it be simpler to just extract *sums from control.tar.gz, create
> > a detached signature for it and put it in the ar archive, instead of
> > extracting data.tar.gz and generating the sums a second time? Or would
> > this replace dh_*sums during package build time?
> 
> 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 data members
> since that breaks, as Wouter points out, the ability to remove the
> signature and checksums and verify against the original *.changes file.
> And there's no need to include two copies of the checksums.

There would only be one additional file, containing a detached
signature for the checksum file. No duplication of checksums and it
can easily be removed from the ar. But doing everything in one step,
like you proposed, is better anyway.

> 
> > And then create a second signature over all files in the ar archive
> > directly. This one would be checked before extracting the containing
> > tar.gz files, and the other one would be installed along with the *sums
> > file.
> 
> I think you want to checksum the underlying contents, not the *.tar.gz
> files in the ar archive.  As Joey can attest to from writing pristine-tar,
> it's surprisingly difficult to reproduce a *.tar.gz file from its members.

Misunderstanding. Forget what I said.

To include checksums for control.tar.gz, just add them to the same
checksum file, but with the paths, the files will have after package
installation (/var/lib/dpkg/...).

harry


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100320122752.gd1...@nn.nn

Re: Bug#540215: Introduce dh_checksums

[Russ Allbery]

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 data
>> members since that breaks, as Wouter points out, the ability to remove
>> the signature and checksums and verify against the original *.changes
>> file.  And there's no need to include two copies of the checksums.

> There would only be one additional file, containing a detached
> signature for the checksum file. No duplication of checksums and it
> can easily be removed from the ar. But doing everything in one step,
> like you proposed, is better anyway.

Oh, I see what you're saying.  Yeah, that could work too.

> To include checksums for control.tar.gz, just add them to the same
> checksum file, but with the paths, the files will have after package
> installation (/var/lib/dpkg/...).

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-term changes, like adding other deb members later for some
reason that we want to sign.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878w9ncf11@windlord.stanford.edu

Re: Bug#540215: Introduce dh_checksums

[Harald Braumann]

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-term changes, like adding other deb members later for some
> reason that we want to sign.

But aren't we talking about checksums of installed files here? So
after package installation I'd like to have the file as
/var/lib/dpkg/info/.checksums, just like the md5sums now, only
that it's signed (preferably with a detached signature). This file has
to be included verbatim in the package. You can't strip the
data:/control: prefix on installation, as this would invalidate the
signature. And it shouldn't be installed containing these prefixes,
because then you can't use standard-tools to verify the checksums.

If other stuff should be added later, for instance debsigs like
signatures, then additional files can be added to the deb. I don't
think it's wise trying to define a catch-all format now and I don't
see why arbitray additional files for further extensions couldn't be
added to the deb later. All these files could be packed together in,
say, security.tar.gz, so you can always remove this single member from
the ar to get the classic deb.

harry


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100320154020.ge1...@nn.nn

Re: Status of kernel patch packages

[Hideki Yamane]

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 featured one yet. At least, I want to 
 provide it with squeeze.

 and hope kernel-package would enable patch support again... ;)


-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp
 http://wiki.debian.org/HidekiYamane


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100321001722.46742b9a.henr...@debian.or.jp

Re: Status of kernel patch packages

[Ola Lundqvist]

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 current recommended way of
> patching a kernel is using git).  My understanding was that those
> packages should then be simply removed from the archive.  However,
> there are still a couple of kernel patch packages in squeeze and sid,
> and some of them got recent updates.
> 
> 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 ?
> 
> [CC'd maintainers of the relevant packages]
> 
> Best regards,
> -- 
> Yann
> 
> 

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comAnnebergsslingan 37\
|  o...@debian.org   654 65 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100320145434.ga24...@inguza.net

Re: Status of kernel patch packages

[Jonas Smedegaard]

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 so that I 
> missed ?


 As linux-patch-tomoyo1.7 package maintainer, tomoyo is merged with 
 mainline, but it's not fully featured one yet. At least, I want to 
 provide it with squeeze.


 and hope kernel-package would enable patch support again... ;)


I won't speak for Manoj here, but I feel we should think about other 
ways to provide those patches.


One way could be simply to provide ensure those patches in some git 
tree, that users can easily fetch and merge before running make-kpkg.


Lots of possibilities arise if we do not constrain ourselves to the 
Debian ideal of a fully self-contained distribution usable while 
offline.


I happen to like that ideal, also for kernel patches.


 - Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

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

[Sylvestre Ledru]

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
> > > upstream versions you want to see in squeeze which are not ready yet.
> > > Furthermore we would like to get an overview of the remaining transitions
> > > that need to be done.
> > It is not a classical transition but the Debian Science team would like
> > to upload of BLAS / LAPACK and ATLAS this week.
> > This is described here:
> > http://wiki.debian.org/DebianScience/LinearAlgebraLibraries
> > I sent an email to debian-release to double check my proposal:
> > http://lists.debian.org/debian-release/2010/03/msg00051.html
> > but I haven't received an answer yet.
> > Updated packages are available in experimental. My tests show it is
> > working smoothly and I am going to do more tests in the next few days.
> > 
> > These are common libraries in the numerical computing world. ATLAS (an
> > high performance BLAS implementation) has 4 RCs in testing/unstable
> > which are going to be fixed with this upload (with many others)
> > I can provide more information if needed.
> 
> Good news! Does it fix libatlas3gf-sse2 bug #536686?
Yes, new releases of atlas packages fixes this issue.

Sylvestre





-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1269104171.20313.214.ca...@zlarin

Re: libgcrypt brain dead?

[Richard A Nelson]

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
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 negotiation

* GnuTLS has other issues (fairly old, but still interesting):
  http://www.openldap.org/lists/openldap-devel/200802/msg00072.html

* Couple this with the fact that our OpenLDAP packages are not new
  enough for multi-master support, and even one of the maintainers
  recommends not using Debian slapd package for 'Production use' -
  and you wind up with a variant of 'DLL Hell', but at least dpkg
  properly reports all failing/conflicting dependencies.

  Note: This would be so much easier if I only needed slapd compiled
  against OpenSSL ... but alas, that is not the case :(


What is the solution? Should we go back to using openssl, at least
with libraries such as openldap that are commonly used in pam and nss
modules?


That would certainly help folks who choose to build their servers on
Debian and must operate in a heterogenous environment (mostly of older
crap based on older OpenSSL/OpenLDAP/Apache/etc.)


Or is there another way?


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 switch everything
back to it ... if there was concensus


Alternatively, have I got something wrong?


Exactly correct from my PoV :(

--
Rick Nelson
 what's the difference between chattr and chmod?
 SomeLamer: man chattr > 1; man chmod > 2; diff -u 1 2 | less
-- Seen on #linux on irc


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.2.00.1003201039320.25...@hygvzn-guhyr.pnirva.bet

Re: Bug#540215: Introduce dh_checksums

[Russ Allbery]

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 flexible for
>> possible long-term changes, like adding other deb members later for
>> some reason that we want to sign.

> But aren't we talking about checksums of installed files here? So after
> package installation I'd like to have the file as
> /var/lib/dpkg/info/.checksums, just like the md5sums now, only
> that it's signed (preferably with a detached signature). This file has
> to be included verbatim in the package. You can't strip the
> data:/control: prefix on installation, as this would invalidate the
> signature. And it shouldn't be installed containing these prefixes,
> because then you can't use standard-tools to verify the checksums.

I agree with all of that; I'm just not sure the last bit actually
matters.  It's trivial to write a tiny tool that would verify the
checksums using other tools.  But I can see the appeal, and I wouldn't
argue against using the installed path either.

Note, though, that if only installed files can be listed in the signature,
the signature doesn't cover DEBIAN/control file, which seems like a bad
idea.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k4t6bz3q@windlord.stanford.edu

Re: libgcrypt brain dead?

[Russ Allbery]

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 negotiation

> * GnuTLS has other issues (fairly old, but still interesting):
>   http://www.openldap.org/lists/openldap-devel/200802/msg00072.html

> * Couple this with the fact that our OpenLDAP packages are not new
>   enough for multi-master support, and even one of the maintainers
>   recommends not using Debian slapd package for 'Production use' -
>   and you wind up with a variant of 'DLL Hell', but at least dpkg
>   properly reports all failing/conflicting dependencies.

>   Note: This would be so much easier if I only needed slapd compiled
>   against OpenSSL ... but alas, that is not the case :(

I am certain that all of the problems with the Debian OpenLDAP packages
are resolvable without switching away from GnuTLS.  The problem is that
the OpenLDAP packaging team in Debian has almost no resources.  Neither
Steve nor I have any time to spend on it, and I at least got involved only
out of self-defense since the package in danger of being unmaintained.  (I
think the same may also be true of Steve.)  There's a long-standing RFH
which has gotten a fair number of responses, but no one involved on the
team really has time to mentor people in how to work on Debian packaging
either and so far the responses haven't translated into people with free
time and the necessary skills to jump in and help.

We would greatly appreciate the help of an experienced Debian packager to
bring the package up to date and to track down the TLS interaction
problems with GnuTLS.  Upstream for GnuTLS is quite responsive, and
upstream for OpenLDAP, while not very fond of GnuTLS, has always been
willing to take patches if someone can clearly explain the issue.

>> Or is there another way?

> 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 switch everything
> back to it ... if there was concensus

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.  The
first step would be to reach consensus on removing from our archive the
traditional LDAP NSS and PAM modules and replacing them with the ldapd
versions, which talk to a system daemon over a protocol rather than pull
all the libraries into the same executable.

Once that's been done, the problem of getting license exceptions for all
other GPL packages that link directly to OpenLDAP might be tractable.  (Or
it might not; I haven't done any of the necessary investigative work.)

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fx3ubytu@windlord.stanford.edu

Re: libgcrypt brain dead?

[Ben Hutchings]

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 switch everything
> > back to it ... if there was concensus
> 
> 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.
[...]

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 copyleft licences of applications
using NSS/PAM can possibly extend to them.

Ben.

-- 
Ben Hutchings
Power corrupts.  Absolute power is kind of neat.
   - John Lehman, Secretary of the US Navy 1981-1987


signature.asc
Description: This is a digitally signed message part

Re: libgcrypt brain dead?

[Russ Allbery]

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.
> [...]

> 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 copyleft licences of applications
> using NSS/PAM can possibly extend to them.

My understanding is that that's not the standard that Debian has
historically applied, and I don't think it's particularly useful for
anyone who isn't a lawyer (such as myself) to debate it.

I know lots of people have strong opinions on where the line should be
drawn with license compatibility when shared libraries and dynamic loading
are involved.  I personally don't believe I have any idea what an actual
legal judgement is likely to say and just try to follow the most recent
and credible legal advice that I've seen, since expressing any opinion
would be pure speculation on my part.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aau2u40o@windlord.stanford.edu

Re: libgcrypt brain dead?

[Marco d'Itri]

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?

[Florian Weimer]

* 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 does, of course).

> 4. Must not change any global attributes of the process or of any other
>libraries it uses;

Strictly speaking, this precludes creating child processes, which is
rather drastic. 8-(


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y6hm3bcu@mid.deneb.enyo.de

Re: libgcrypt brain dead?

[Kevin Mark]

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-licensed) package in the distribution in one way or another.
> > [...]
> 
> > 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 copyleft licences of applications
> > using NSS/PAM can possibly extend to them.
> 
> My understanding is that that's not the standard that Debian has
> historically applied, and I don't think it's particularly useful for
> anyone who isn't a lawyer (such as myself) to debate it.
should there be a usertag 'lawyer' to note which bugs should not be decided by
a hacker but a real lawyer? Has a real lawyer even been used to solve a bug
in Debian?  
-- 
|  .''`.  == Debian GNU/Linux == | http://kevix.myopenid.com  |
| : :' : The Universal OS| mysite.verizon.net/kevin.mark/ |
| `. `'   http://www.debian.org/ | http://counter.li.org [#238656]|
|___`-Unless I ask to be CCd, assume I am subscribed _|


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100320210232.ga24...@horacrux

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

[Ana Guerrero]

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++
  Description : dump and organize the content of your brain to your computer

Braindump is a collection of whiteboards on which you can put your notes 
or ideas, whether they are text notes, or drawing. It is entirely based on 
KOffice 
technologies.

Ana



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100320223817.25063.66671.report...@pryan.ekaia.org

Re: libgcrypt brain dead?

[Ben Hutchings]

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-licensed) package in the distribution in one way or another.
> > [...]
> 
> > 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 copyleft licences of applications
> > using NSS/PAM can possibly extend to them.
> 
> My understanding is that that's not the standard that Debian has
> historically applied, and I don't think it's particularly useful for
> anyone who isn't a lawyer (such as myself) to debate it.
[...]

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.

Ben.

-- 
Ben Hutchings
Power corrupts.  Absolute power is kind of neat.
   - John Lehman, Secretary of the US Navy 1981-1987


signature.asc
Description: This is a digitally signed message part

Re: libgcrypt brain dead?

[Russ Allbery]

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)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sk7uoaaq@windlord.stanford.edu

Re: libgcrypt brain dead?

[Richard A Nelson]

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 consensus on removing from our archive the
traditional LDAP NSS and PAM modules and replacing them with the ldapd
versions, which talk to a system daemon over a protocol rather than pull
all the libraries into the same executable.


Oh Hell yeah,  I've been neglecting libnss-ldap and libpam-ldap whilst
investigating and moving all my usage to Arthur's excellent
nss-pam-ldapd package ...  It now has enough support that I've been
trying to find a 'nice way' to ask for the deprecation and/or removal of
the older and very problematical PADL packages.

The early boot issues are gone, as are shutdown (due to bash/library)
issues, proper filtering and attribute request, password changing works
now - krb5 support seems to work, ...


Once that's been done, the problem of getting license exceptions for all
other GPL packages that link directly to OpenLDAP might be tractable.  (Or
it might not; I haven't done any of the necessary investigative work.)


Ditto, being stuck between idiology, and needing to actually get my work
done can be a rough spot - it becomes too easy to blame others for work
I've neglected getting involved in :(

--
Rick Nelson
<_Anarchy_> Argh.. who's handing out the paper bags  8)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.2.00.1003201614300.2...@hygvzn-guhyr.pnirva.bet

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

[David Caldwell]

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, Git, Mercurial, Bazaar, 
Subversion, or CVS repositories

 Normally version control systems don't allow fine grained
 commits. commit-patch allows the user to control exactly what gets
 committed by letting the user supply a patch to be committed rather than
 using the files in the current working directory.

 Also included is an Emacs interface to commit-patch. It allows you to just
 hit C-c C-c in any patch buffer to apply and commit only the changes
 indicated by the patch, regardless of the changes in your working
 directory.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100321002236.7170.40233.report...@porkrind.org

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

[antoine beaupre]

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
  Description : FreeBSD Point-to-Point Protocol (PPP) userland daemon

The Point-to-Point Protocol provides a standard way to transmit
datagrams over a serial link, as well as a standard way for the machines
at either end of the link to negotiate various optional characteristics
of the link.

This package provides both a server and a client PPP daemon that runs in
userland. It has been ported from FreeBSD to function specifically with
the Debian GNU/kFreeBSD distribution.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100320204525.17503.91506.report...@loony.anarcat.ath.cx

Re: libgcrypt brain dead?

[Brian May]

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 copyleft licences of applications
> using NSS/PAM can possibly extend to them.

Yes, that is my understanding of how Debian has made decisions too. I
should be able to dig up references if required.

Also I do note that there are a number of PAM modules currently in the
Debian archive that do link against openssl. Not to mention
applications that use both PAM and openssl - there are GPLed PAM
modules in our archive too. I hope I haven't started a witch hunt...
-- 
Brian May 


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/3c5cf5261003201844v271807eex611eef23dafd5...@mail.gmail.com

Re: libgcrypt brain dead?

[Russ Allbery]

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.  So I don't see that copyleft licences of applications
>> using NSS/PAM can possibly extend to them.

> Yes, that is my understanding of how Debian has made decisions too. I
> should be able to dig up references if required.

> Also I do note that there are a number of PAM modules currently in the
> Debian archive that do link against openssl. Not to mention
> applications that use both PAM and openssl - there are GPLed PAM
> modules in our archive too. I hope I haven't started a witch hunt...

No, I suspect I was just completely wrong.  Thank you for the corrections,
all!

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zl22mn9u@windlord.stanford.edu

Re: libgcrypt brain dead?

[Steve Langasek]

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-licensed) package in the distribution in one way or another.
> > [...]

> > 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 copyleft licences of applications
> > using NSS/PAM can possibly extend to them.

> My understanding is that that's not the standard that Debian has
> historically applied, and I don't think it's particularly useful for
> anyone who isn't a lawyer (such as myself) to debate it.

I've always taken care to ensure the PAM modules enabled by default on the
system have licenses compatible with everything that might be above them in
the stack, which means no GPL- or OpenSSL-licensed library dependencies.
However, we've had a number of PAM modules packaged for some time which fall
on one side or the other of the GPL divide, and I think these are perfectly
reasonable to have in the archive *as long as* we aren't shipping any
packages that pull in incompatibly-licensed PAM modules and binaries as
dependencies.

The real problem with using OpenSSL with OpenLDAP is the software that is
GPL-licensed and links to libldap *directly*.  Samba and GNOME come to mind.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature