Bug#1064508: RFP: ior -- parallel storage IO benchmark

[Luca Capello]

Package: wnpp
Severity: wishlist
User: stor...@unige.ch
Usertags: unige.ch-storage

* Package name: ior
  Version : 3.3.0
  Upstream Contact: Los Alamos National Laboratory
(Lawrence Livermore National Laboratory
  William Loewe ,
  Tyce McLarty ,
  Christopher Morrone )
* URL : https://github.com/hpc/ior
(https://github.com/LLNL/ior)
* License : GPL-2
  Programming Lang: C
  Description : parallel storage IO benchmark
   IOR is a parallel IO benchmark that can be used to test the performance
   of parallel storage systems using various interfaces and access
   patterns.
   .
   The IOR package also includes the mdtest benchmark which specifically
   tests the peak metadata rates of storage systems under different
   directory structures.
   .
   Both benchmarks use a common parallel I/O abstraction backend and rely on
   MPI for synchronization.

I have just packaged it, since I need it for a short-lived HPC project I
am working on as part of the storage team at the University of Geneva
(Switzerland).

However, given that I do not plan to continue to use it after this
project, I wonder if someone else would like to maintain it, probably as
part of the "Debian Science Distributed Computing packages" (Cc:ed)?

  <https://blends.debian.org/science/tasks/distributedcomputing>

I will provide the packaging sources once this bug get a number.

Thx, bye,
Gismo / Luca

-- 
Dr. Luca Capello
Ingénieur stockage | Recherche et Information Scientifique
Division du Système et des Technologies de l'Information et de la Communication
Université de Genève | 66, Boulevard Carl-Vogt | 1205 Genève
Tél +41 22 379 77 69 | Bureau D624
mailto:luca.cape...@unige.ch


signature.asc
Description: PGP signature

Bug#745025: Looking for sponsor

[Luca Capello]

block 745025 by 745027
usertags 745025 + pca.it-synchronization
thanks

Hi Filip,

On Fri, 29 Jan 2016 16:13:48 +0100, Filip Pytloun wrote:
> I have prepare khal package:
> http://mentors.debian.net/package/khal
> 
> Is there anyone interested in sponsoring it?

I am, since I am looking for a CLI CalDAV client for jessie, so I am
also interested in a jessie-backports.

A quick build of your package reveals:

- a non-versioned Depends:

  - python-click (>= 3.2) [jessie-backports: simple rebuild]

- missing Depends:

  - python-tzlocal (>= 1.0) [jessie-backports: simple rebuild]
  - vresyncdir, as you know:

  
  
Thus marking that this bug is blocked until vresyncdir enters Debian.  I

will come back with a more detailed review.

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#810835: ITP: let-alist -- let-bind values of an assoc-list by their names in Emacs Lisp

[Luca Capello]

Hi there!

On Sat, 16 Jan 2016 19:47:53 -0700, Sean Whitton wrote:
> On Sat, Jan 16, 2016 at 10:34:04PM +0100, Luca Capello wrote:
> > Nothing against you, but a .deb for an 89-line macro sounds a bit
> > overkill to me.
> 
> I want to package emacs-pdf-tools [1]
[...]
> > JFTR, I needed it as well as a dependency for Flycheck and ended up
> > installing everything from (M)ELPA :-(
> 
> That's what I want to avoid!

Look, I completely understand your point, still I think that such a
small package (I guess less than 10kb in the end) for a single file
which has not changed since 2014-12-23 should be avoided.

But I have just discovered that there is already another similar-in-size
package in the archive, so forget my remark:

  <https://packages.debian.org/jessie/sass-elisp>

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#810835: ITP: let-alist -- let-bind values of an assoc-list by their names in Emacs Lisp

[Luca Capello]

Hi there,

On Tue, 12 Jan 2016 10:39:00 -0700, Sean Whitton wrote:
> * Package name: let-alist
>   Version : 1.0.4
>   Upstream Author : Artur Malabarba 
> * URL : https://elpa.gnu.org/packages/let-alist.html
[...]
> let-alist is a useful macro for programming in Emacs Lisp.

Nothing against you, but a .deb for an 89-line macro sounds a bit
overkill to me:
=
$ wget http://elpa.gnu.org/packages/let-alist-1.0.3.el
[...]
$ wc -l let-alist-1.0.3.el 
162 let-alist-1.0.3.el
$ grep -v '^;' -c let-alist-1.0.3.el 
89
$
=

JFTR, I needed it as well as a dependency for Flycheck and ended up
installing everything from (M)ELPA :-(

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#772674: RFP: xul-ext-mail-redirect -- Redirect mail to other recipients

[Luca Capello]

user cont...@itopie.ch
usertags 772674 + itopie.ch-installation
thanks

Hi Dominik,

On Tue, 09 Dec 2014 22:36:42 +0100, Dominik George wrote:
> * Package name: xul-ext-mail-redirect
>   Version : 0.8.5
>   Upstream Author : Paweł Krześniak 
> * URL : http://mailredirect.sf.net

JFTR, the corresponding URL in the extension list is:

  

...and the corresponding upstream bug is:

  
  
> * License : MPL 2.0
>   Programming Lang: JavaScript (XUL)
>   Description : Redirect mail to other recipients
> 
> The Mailredirect extension for Mozilla Thunderbird (version 6.0 and
> above) and SeaMonkey adds the ability to redirect one or more emails to
> one or more recipients. The feature of mail redirecting is also known as
> bouncing forward or resending.

I use this extension for a while now and thus I am willing to package
it, would you like to co-maintain it (I can sponsor, if needed)?

Cc:ing the pkg-mozilla-maintainers@ mailing list: should such an
extension be (team) maintained there or in collab-maint or it does not
matter?

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#692984: Expected upload of sogo-connector

[Luca Capello]

forcemerge 692984 659291
reassign 705488 wnpp
forcemerge 692984 705488
user cont...@itopie.ch
usertags 692984 + itopie.ch-installation
user i...@codha.ch
usertags 692984 + codha.ch-installation
thanks

Hi there!

Merging all relevant/duplicate bugs and Cc:ing all the interested
people.

On Wed, 30 Apr 2014 13:46:26 +0200, Carsten Schoenert wrote:
> Am 30.04.2014 12:41, schrieb Boris Barbour:
> > I'm interested in obtaining the sogo-connector, as this seems to be the 
> > only way to sync contacts with owncloud. I'd prefer to get it through 
> > the debian repositories. The messages above suggest that it could be (or 
> > has been) uploaded, which is good news. When might we expect it to appear?
> 
> thanks for your interests!
> I don't know then the FTP Team will allow the upload of the package, so
> sorry, I can't say something promising right now.

The package is still in the NEW queue, please remember to close this bug
when the package will enter Debian, since the current debian/changelog
does not automatically close any bug:

  

> You can rebuild the package by yourself using the current repository
> which will be found on
> 
>   https://github.com/tijuca/sogo-connector

Any reason why this is not on Alioth?

> You will probably need a sid chroot to build the package, right know I
> always used git-pbuilder and doesn't have cared about backports or so.
> But that should not be a big problem to created a wheezy-backport
> package too.

Actually, using a *plain* wheezy chroot is not enough:
=
[...]
Setting up pbuilder-satisfydepends-dummy (0.invalid.0) ...
Reading package lists...
Building dependency tree...
Reading state information...
Initializing package states...
Writing extended state information...
The following NEW packages will be installed:
  bsdmainutils{a} debhelper{a} file{a} gettext{a} gettext-base{a}
  groff-base{a} html2text{a} intltool-debian{a} libasprintf0c2{a}
  libcroco3{a} libffi5{a} libgettextpo0{a} libglib2.0-0{a} libmagic1{a}
  libpcre3{a} libpipeline1{a} libunistring0{a} libxml2{a} man-db{a}
  po-debconf{a}
0 packages upgraded, 20 newly installed, 0 to remove and 0 not upgraded.
Need to get 9191 kB/9656 kB of archives. After unpacking 25.6 MB will be used.
The following packages have unmet dependencies:
 pbuilder-satisfydepends-dummy : Depends: icedove-dev (>= 24~) but it is not 
going to be installed.
 Depends: mozilla-devscripts (>= 0.32~) but it 
is not going to be installed.
 Depends: python-ply but it is not going to be 
installed.
Unable to resolve dependencies!  Giving up...
[...]
Abort.
E: pbuilder-satisfydepends failed.
=

Here is the reason:
=
$ rmadison icedove-dev | grep wheezy
 icedove-dev | 10.0.12-1  | wheezy| amd64, armel, armhf, 
i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, 
sparc
 icedove-dev | 17.0.10-1~deb7u1   | wheezy-security   | ia64, kfreebsd-amd64, 
kfreebsd-i386, mips, mipsel
 icedove-dev | 24.5.0-1~deb7u1| wheezy-security   | s390, sparc
 icedove-dev | 24.6.0-1~deb7u1| wheezy-security   | amd64, armel, armhf, 
i386, powerpc, s390x
$ 
=

I confirm that adding the wheezy-security repository is enought to build
a wheezy-backports without changing anything in the current Debian
sources on GitHub.

Since we currently use this extension, I am interested in a
wheezy-backports and I could maintain it by myself, but only once it
reaches testing and anyway not before the next 3 months.

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#504058: Zotero Update

[Luca Capello]

merge 504058 639025
usertags 504058 + debian-packaging
thanks

Hi there!

On Sun, 27 Jan 2013 17:46:50 +0100, Benj. Mako Hill wrote:
> I'm not likely to get around to packaging soon this so I hope somebody
> else can take this over. The package is not trivial and I have no done
> a xulrunner package before. I thought this going to be trivial and
> haven't found the time to address it. It may in fact be trivial for
> someone familiar with packaging xulrunner applications.

I also thought so given my previous experience with conkeror, but it is
actually more complicated than a "simple" xulrunner application (hint:
look at the build.sh script).

> And just to be clear: xul-ext-zotero is already in Debian but this is
> a different package. The
> suggestion here is for the standalone version of Debian (i.e., "Zotero
> Standalone").
>
> Since they are built from what is essentially the same source and have
> most of the same dependencies, I think we should probably build both
> pieces of software from the same source package. In that sense, I
> think my first preference would be for Theodore Lytras (who already
> maintains xul-ext-zotero) to take this on.
>
> At the very least, whoever *does* take this on should coordinate with
> Theodore.

While I agree that both packages should come from the same source, after
having heavily discussed with Michele Cane (who actually offered help in
this same ITP [1]) we went ahead and both packages (zotero-standalone
and the LO integration) are on their way to be uploaded [2].  The merge
can be done later on, also considering that the last uploaded version
for xul-ext-zotero is 10-month-old.

[1] 
[2] 

Thx, bye,
Gismo / Luca


pgplfk9XOYjtH.pgp
Description: PGP signature

Bug#691479: ITP: pcalendar -- application to track women menstrual cycles

[Luca Capello]

Hi there!

On Fri, 26 Oct 2012 08:35:21 +0200, Dmitry Smirnov wrote:
>Package name: pcalendar
> Version: 3.3.0
> Upstream Author: Mar'yan Rachynskyy 
> URL: http://linuxorg.sourceforge.net/
> License: GPL-3+
> Description: application to track women menstrual cycles

Debian already ships it (Cc:ing its maintainer):

  

=
$ rmadison pcalendar
 pcalendar | 3.2.0-2 | wheezy   | source, all
 pcalendar | 3.2.0-2 | sid  | source, all
 pcalendar | 3.3.0-1 | experimental | source, all
=

Thx, bye,
Gismo / Luca


pgpM6oaFViuSz.pgp
Description: PGP signature

Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop

[Luca Capello]

Hi there!

On Sun, 09 Sep 2012 20:09:11 +0200, Jean-Christophe Dubacq wrote:
> On 09/09/2012 19:54, Alessio Treglia wrote:
>> On Sun, Sep 9, 2012 at 7:39 PM, David Paleino  wrote:
>>> It would be nice if you could use a less generic name. :)
>> 
>> Honestly, I've been thinking about that even before you raised your
>> objection :-)
>> 
>> Any suggestions? Would 'maps-client' be a good name?
>> 
> gnome-maps ?

Or, if this is tightened to OSM, 'gnome-osm-maps'.

Thx, bye,
Gismo / Luca


pgpt0cPd0BHf0.pgp
Description: PGP signature

Bug#675626: ITP: lutok -- Lightweight C++ API library for Lua

[Luca Capello]

Hi there!

On Fri, 15 Jun 2012 01:00:10 +0200, Julio Merino wrote:
> On Thu, Jun 14, 2012 at 3:45 AM, Luca Capello  wrote:
>> Do you know that there is a Debian Lua Team (Cc:ed) for (ideally)
>> packaging Lua software?  IMHO the package should be maintained by you
>> under that umbrella:
>
> Thanks for the information.
>
> Based on the policy and the web page, the team you reference seems to
> focus on packaging Lua modules.  Lutok is a C++ library that just so
> happens to interface with Lua... so I'm not sure it qualifies.  That
> said, I'm obviously open to any feedback and reviews from the team!

Enrico Tassi has the last word on the focus of the team, but:

- the project description on Alioth does not exclude non-module packages

This project is for development and maintenance of Debian packages
and infrastructure related to the Lua programming language.

- based on my experience in previous teams (especially on the Debian
  Common Lisp one), having a single point of contact for questions
  related to all $LANGUAGE packages is really useful.

Thx, bye,
Gismo / Luca


pgpfNNmv3GYXl.pgp
Description: PGP signature

Bug#677425: ITP: xserver-xorg-video-modesetting -- X.Org X server -- Generic modesetting driver

[Luca Capello]

Hi Cyril!

On Thu, 14 Jun 2012 10:12:28 +0200, Cyril Brulebois wrote:
> Luca Capello  (14/06/2012):
>> [...] Thus, I would be a bit more verbose in the long
>> description, to be clear when this driver is useful.
>
[very useful explanation]
> The plan was updating the long description once things are a bit more
> settled.

Thank you very much for the prompt reply, I have really appreciated and
everything is now clear.

Thx, bye,
Gismo / Luca


pgp8mbQzq7Fe1.pgp
Description: PGP signature

Bug#677425: ITP: xserver-xorg-video-modesetting -- X.Org X server -- Generic modesetting driver

[Luca Capello]

usertags 677425 + debian-packaging
thanks

Hi there!

On Wed, 13 Jun 2012 23:23:19 +0200, Cyril Brulebois wrote:
> Long description:
> ---
>  This package provides a generic modesetting driver.
>  .
>  More information about X.Org can be found at:
>  http://www.X.org>
>  .
>  This package is built from the X.org xf86-video-modesetting driver module.
> ---

According to upstream README:

  

  The idea is to piggy-back the X driver on top of the DRM and Gallium3D
  drivers (DRM for modesetting and Gallium3D for Exa acceleration)

Does this mean that I could (hypothetically) replace the -intel driver
with -modesetting?  This is what I understand from the long description
and from the README.  Thus, I would be a bit more verbose in the long
description, to be clear when this driver is useful.

Thx, bye,
Gismo / Luca


pgpCoF2SOspkU.pgp
Description: PGP signature

Bug#677388: ITP: pinentry-x2go -- GnuPG-card authentication dialog window for X2Go Client

[Luca Capello]

usertags 677388 + debian-packaging
thanks

Hi there!

On Wed, 13 Jun 2012 16:10:39 +0200, Mike Gabriel wrote:
>   Description : GnuPG-card authentication dialog window for X2Go Client
  ^^
AFAIK there is no GnuPG-card, instead it is called OpenPGP (smart)card:

  
  

Please fix the package description and notice upstream, if needed.

Thx, bye,
Gismo / Luca


pgpeGe383zBNB.pgp
Description: PGP signature

Bug#675626: ITP: lutok -- Lightweight C++ API library for Lua

[Luca Capello]

usertags 675626 + debian-packaging
thanks

Hi there!

Cc:ing debian-mentors@ since you already uploaded the package there.

On Sat, 02 Jun 2012 17:35:07 +0200, Julio Merino wrote:
>   Description : Lightweight C++ API library for Lua

Do you know that there is a Debian Lua Team (Cc:ed) for (ideally)
packaging Lua software?  IMHO the package should be maintained by you
under that umbrella:

  

Thx, bye,
Gismo / Luca


pgpGQNmWuVY3O.pgp
Description: PGP signature

Bug#670549: ITP: lua-ldap -- LDAP library for the Lua language

[Luca Capello]

Hi there!

On Wed, 02 May 2012 21:18:57 +0200, Luca Capello wrote:
> On Thu, 26 Apr 2012 20:07:26 +0200, Enrico Tassi wrote:
>> On Thu, Apr 26, 2012 at 06:26:01PM +0200, Luca Capello wrote:
>>> * Package name: lua-ldap
>>
>> On another topic, thanks to lua-cyrussasl I think prosody is already
>> able to use LDAP: http://prosody.im/doc/cyrus_sasl
>>
>> But I guess the module you mentioned is simpler/better.
[...]
> I anyway tried to configure Prosody LDAP authentication via SASL (tested
> with empathy_3.2.2-1+b3, gajim_0.15-1 and pidgin_2.10.2-1 on an
> up-to-date squeeze), following the instructions at the following links
> (I Cc:ed the author of the last one):
>
>   <http://prosody.im/doc/cyrus_sasl>
>   
> <http://blog.marc-seeger.de/2009/12/30/setting-up-prosody-to-authenticate-against-ldap/>
>   <https://wiki.koumbit.net/ProsodyConfiguration>

Here is the configuration for prosody_0.8 and mod_auth_ldap at:

  <http://code.google.com/p/prosody-modules/wiki/mod_auth_ldap>

--8<---cut here---start->8---
root@debian:~# apt-get install prosody
[at least!]
root@debian:~# apt-get install liblua5.1-sec1
[Prosody SASL requires TLS]
root@debian:~# cat /etc/prosody/prosody.cfg.lua
authentication = "ldap"
ldap_server = "ldap.example.com"
ldap_rootdn = "cn=admin,dc=example,dc=com"
ldap_bind_pw: "PASSWORD"
ldap_base = "ou=people,dc=example,dc=com"
root@debian:~# service prosody restart
Restarting Prosody XMPP Server: prosody.
--8<---cut here---end--->8---

Your JID will be 'ldap_...@example.com': ATM there is no way to
configure that with the mod_auth_ldap.lua version in prosody-modules.
However, as Stefan Hepp's found out, ldap-search will silently fail
without ldap_scope, so I backported Stefan's "patch":

  
<https://groups.google.com/group/prosody-dev/browse_thread/thread/282e876116ae4177/906121492495ad35>

The attached hg patch is enough for mod_auth_ldap.lua to authenticate
using LDAP_UID and no TLS: lua-ldap does work (even on squeeze), so I
uploaded it.  With this email I am also stopping providing feedback
about Prosody and LDAP, I will continue elsewhere :-)

Thx, bye,
Gismo / Luca

# HG changeset patch
# User Luca Capello 
# Date 1335992664 -7200
# Node ID 2d18d807eb8488b6c909a9ab8a48d1ab6505c4e9
# Parent  a826b61c8f3a555b28fba6147e47f72af4565017
mod_auth_ldap/mod_auth_ldap.lua: add ldap_scope

Without ldap_scope in provider.test_password(username, password), the
ldap-search silently fails.

This was taken from Stefan Hepp's improved mod_auth_ldap.lua.

diff -r a826b61c8f3a -r 2d18d807eb84 mod_auth_ldap/mod_auth_ldap.lua
--- a/mod_auth_ldap/mod_auth_ldap.lua	Mon Apr 30 17:25:09 2012 +0200
+++ b/mod_auth_ldap/mod_auth_ldap.lua	Wed May 02 23:04:24 2012 +0200
@@ -8,6 +8,7 @@
 local ldap_password = module:get_option("ldap_password") or "";
 local ldap_tls = module:get_option("ldap_tls");
 local ldap_base = assert(module:get_option("ldap_base"), "ldap_base is a required option for ldap");
+local ldap_scope = module:get_option("ldap_scope") or "onelevel";
 
 local lualdap = require "lualdap";
 local ld = assert(lualdap.open_simple(ldap_server, ldap_rootdn, ldap_password, ldap_tls));
@@ -26,6 +27,9 @@
 	return do_query({
 		base = ldap_base;
 		filter = "(&(uid="..ldap_filter_escape(username)..")(userPassword="..ldap_filter_escape(password)..")(accountStatus=active))";
+		-- <https://groups.google.com/group/prosody-dev/browse_thread/thread/282e876116ae4177/906121492495ad35>
+		-- we need to set scope here, else ldap-search may fail (silently!!)
+		scope = ldap_scope;
 	});
 end
 function provider.user_exists(username)


pgpWBn9j88Z1P.pgp
Description: PGP signature

Bug#670549: ITP: lua-ldap -- LDAP library for the Lua language

[Luca Capello]

affects 671015 + prosody
thanks

Hi Enrico!

On Thu, 26 Apr 2012 20:07:26 +0200, Enrico Tassi wrote:
> On Thu, Apr 26, 2012 at 06:26:01PM +0200, Luca Capello wrote:
>> * Package name: lua-ldap
>
> On another topic, thanks to lua-cyrussasl I think prosody is already
> able to use LDAP: http://prosody.im/doc/cyrus_sasl
>
> But I guess the module you mentioned is simpler/better.

I see two "problems" in this case:

1) it seems that Prosody only supports authentication against Cyrus
   SASL.  If you have Dovecot, however, you can use its SASL
   implementation for external services, for example for Postfix (as I
   do on the server where I want to install Prosody):

 <http://wiki.dovecot.org/HowTo/PostfixAndDovecotSASL>

2) at a first glance it seems that the Cyrus SASL LDAP filtering, while
   complete, is quite difficult to set up and does not resemble any
   ldapsearch's filter.

I anyway tried to configure Prosody LDAP authentication via SASL (tested
with empathy_3.2.2-1+b3, gajim_0.15-1 and pidgin_2.10.2-1 on an
up-to-date squeeze), following the instructions at the following links
(I Cc:ed the author of the last one):

  <http://prosody.im/doc/cyrus_sasl>
  
<http://blog.marc-seeger.de/2009/12/30/setting-up-prosody-to-authenticate-against-ldap/>
  <https://wiki.koumbit.net/ProsodyConfiguration>

=
root@debian:~# apt-get install prosody
[at least!]
root@debian:~# apt-get install sasl2-bin
[the Cyrus SASL authentication daemon]
root@debian:~# cat /etc/default/saslauthd
START=yes
MECHANISMS="ldap"
root@debian:~# cat /etc/saslauthd.conf
# see also #671015 for the available options
ldap_servers: ldap://ldap.example.com
ldap_search_base: ou=people,dc=example,dc=com
ldap_scope: one
ldap_auth_method: bind
ldap_bind_dn: cn=admin,dc=example,dc=com
ldap_bind_pw: PASSWOD
# uid=NAME.SURNAME, while mail=n...@example.com
ldap_filter: mail=%u
root@debian:~# testsaslauthd -u MAIL -p PASSWORD
0: OK "Success."

root@debian:~# apt-get install libsasl2-modules-ldap
[let local servers use Cyrus SASL LDAP authentication]

root@debian:~# apt-get install liblua5.1-sec1
[Prosody SASL requires TLS]

root@debian:~# apt-get install liblua5.1-cyrussasl0
[let Prosody authenticate against Cyrus SASL]
root@debian:~# cat /etc/prosody/prosody.cfg.lua
sasl_backend = "cyrus"
cyrus_application_name = "prosody"
root@debian:~# cat /etc/sasl/prosody.conf
# see also #465569 for /etc/sasl2 (from sasl2-bin >= 2.1.24~rc1.dfsg1-1)
pwcheck_method: saslauthd
mech_list: plain
root@debian:~# adduser prosody sasl
[let Prosody access the Cyrus SASL socket]
Adding user `prosody' to group `sasl' ...
Adding user prosody to group sasl
Done.
root@debian:~# service prosody restart
Restarting Prosody XMPP Server: prosody.
--8<---cut here---end--->8---

At this point authentication will not work, because Prosody passes
'NAME and not 'MAIL' (thus 'n...@example.com'), so you need a better
LDAP "filter":

--8<---cut here---start->8---
root@debian:~# vi /etc/saslauthd.conf
ldap_filter: mail=%u@%d
root@debian:~# testsaslauthd -r DOMAIN -u MAIL -p PASSWORD
0: OK "Success."
root@debian:~# service prosody restart
Restarting Prosody XMPP Server: prosody.
root@debian:~# cat /var/log/auth.log
[errors, but authentication works]
Apr 28 20:12:20 jabber prosody[2527]: auxpropfunc error invalid parameter 
supplied
Apr 28 20:12:20 jabber prosody[2527]: _sasl_plugin_load failed on 
sasl_auxprop_plug_init for plugin: ldapdb
--8<---cut here---end--->8---

I also tested that with prosody_0.8 via the backport package at (soon to
be uploaded to squeeze-backports, see #631265):

  <http://people.debian.org/~gismo/tmp/prosody/>

There are no changes needed for Cyrus SASL, but only for Prosody:

--8<---cut here---start->8---
root@debian:~# cat /etc/prosody/prosody.cfg.lua
authentication = "cyrus"
-- <http://prosody.im/doc/cyrus_sasl>
-- The service name to pass to Cyrus SASL.
--cyrus_service_name = "xmpp"
-- The realm to pass to Cyrus SASL, the virtual host the user is signing into
-- if not specified.
--cyrus_service_realm = (auto)
-- If true then Prosody requires user accounts to exist in Prosody, even if
-- successfully authenticated via SASL
--cyrus_require_provisioning = false
-- The application name to pass to Cyrus SASL. Determines the Cyrus SASL
-- configuration file name.
--cyrus_application_name = "prosody"
--8<---cut here---end--->8---

Thx, bye,
Gismo / Luca


pgpZDBo3ystRz.pgp
Description: PGP signature

Bug#670549: ITP: lua-ldap -- LDAP library for the Lua language

[Luca Capello]

Hi there!

On Tue, 01 May 2012 11:08:58 +0200, Luca Capello wrote:
> The package is ready (the same lintian warning as lua-zip), but the
> included test does not seem to work:
>
>   <http://people.debian.org/~gismo/tmp/prosody/>
>
> =
> $ lua test.lua LDAP_SERVER LDAP_BASE
> basic checking ..
> Warning!  Couldn't connect with TLS.  Trying again without 
> it.. OK !
> lua: attempt to concatenate a nil value
> stack traceback:
> [C]: in function 'f'
> test.lua:134: in function 'check_future'
> test.lua:147: in function '?'
> test.lua:396: in main chunk
> [C]: ?
> checking compare operation $
> =
>
> Instead of debugging the above (I do not know if this is because my LDAP
> server does not support TLS), I am now trying it with Prosody to be sure
> everything is fine (at which point I will go on with the upload).

The above output actually means that LuaLDAP works (see the 'OK' at the
end).  Another confirmation came from the first for loop in the upstream
example:

  <http://www.keplerproject.org/lualdap/manual.html#examples>

--8<---cut here---start->8---
ld = assert (lualdap.open_simple ("db.debian.org", "", ""))

for dn, attribs in ld:search { base = "dc=debian,dc=org", scope = "subtree" } do
--8<---cut here---end--->8---

I will upload it in the following days :-)
 
Thx, bye,
Gismo / Luca


pgpLM9Uy5VVI8.pgp
Description: PGP signature

Bug#670549: ITP: lua-ldap -- LDAP library for the Lua language

[Luca Capello]

Hi there!

On Fri, 27 Apr 2012 11:24:37 +0200, Luca Capello wrote:
> On Thu, 26 Apr 2012 19:48:18 +0200, Enrico Tassi wrote:
>> JFYI: all projects previously hosted on luaforge are now on github: 
>>   https://github.com/luaforge/lualdap
>> even if the are no tarballs for this project, just tags, that is fine
>> too.
>
> ...so enjoy the temporary repository:
>
>   <http://anonscm.debian.org/gitweb/?p=users/gismo/lua-ldap.git>

The above has been moved to collab-maint for the meantime:

  <http://anonscm.debian.org/gitweb/?p=collab-maint/lua-ldap.git>

The package is ready (the same lintian warning as lua-zip), but the
included test does not seem to work:

  <http://people.debian.org/~gismo/tmp/prosody/>

=
$ lua test.lua LDAP_SERVER LDAP_BASE
basic checking ..
Warning!  Couldn't connect with TLS.  Trying again without it.. 
OK !
lua: attempt to concatenate a nil value
stack traceback:
[C]: in function 'f'
test.lua:134: in function 'check_future'
test.lua:147: in function '?'
test.lua:396: in main chunk
[C]: ?
checking compare operation $
=

Instead of debugging the above (I do not know if this is because my LDAP
server does not support TLS), I am now trying it with Prosody to be sure
everything is fine (at which point I will go on with the upload).

Thx, bye,
Gismo / Luca


pgp47rp2RPfRd.pgp
Description: PGP signature

Bug#670549: ITP: lua-ldap -- LDAP library for the Lua language

[Luca Capello]

Hi Enrico!

On Thu, 26 Apr 2012 19:48:18 +0200, Enrico Tassi wrote:
> On Thu, Apr 26, 2012 at 06:26:01PM +0200, Luca Capello wrote:
>> * Package name: lua-ldap
>> * URL or Web page : <http://www.keplerproject.org/lualdap/>
>> 
>> I Cc:ed Enrico Tassi (the maintainer of most Lua packages in Debian and
>> also the author of dh-lua) and the upstream authors for their
>> information.  The package follows the Debian Lua policy:
>
> I'd suggest to put the package in the alioth svn repository pkg-lua.
> If you agree I'll add you to the team members. I had a plan to migrate
> all of that to git, so if you prefer the latter vcs I'm with you and you
> should use that.

I already started in that direction, because...

> JFYI: all projects previously hosted on luaforge are now on github: 
>   https://github.com/luaforge/lualdap
> even if the are no tarballs for this project, just tags, that is fine
> too.

...so enjoy the temporary repository:

  <http://anonscm.debian.org/gitweb/?p=users/gismo/lua-ldap.git>

> To get started, I think the package should be very very close to
> lua-zip, that you could use as a template.

Thank you for the hint, I am thus adapting the lua-zip's debian/
directory to lua-ldap :-)

Thx, bye,
Gismo / Luca


pgpTd27lvH1D6.pgp
Description: PGP signature

Bug#670549: ITP: lua-ldap -- LDAP library for the Lua language

[Luca Capello]

Package: wnpp
Owner: Luca Capello 
Severity: wishlist
Usertags: pca.it-authentication

* Package name: lua-ldap
  Version : 1.1.0
  Upstream Author : Kepler Project (copyright holder)
* URL or Web page : <http://www.keplerproject.org/lualdap/>
* License : MIT
  Description : LDAP library for the Lua language
  This package contains the Lua LDAP library to:
   * Connect to an LDAP server (OpenLDAP or ADSI/WinLDAP);
   * Execute any operation (search, add, compare, delete, modify
 and rename);
   * Retrieve entries and references of the search result.
  .
  This package contains the runtime library.

The license is word-by-word the MIT license, while not explicitly
referring to it:

  <http://www.opensource.org/licenses/mit-license.php>

This package is needed for LDAP authentication in prosody:

  <http://code.google.com/p/prosody-modules/wiki/mod_auth_ldap>

I Cc:ed Enrico Tassi (the maintainer of most Lua packages in Debian and
also the author of dh-lua) and the upstream authors for their
information.  The package follows the Debian Lua policy:

  <http://pkg-lua.alioth.debian.org/policy.html>

Thx, bye,
Gismo / Luca


pgp8RTMwCfNmJ.pgp
Description: PGP signature

Bug#666990: ITP: fingerprint-gui -- Use fingerprint readeers to login.

[Luca Capello]

Hi there!

On Tue, 03 Apr 2012 09:33:07 +0200, Nikolai Lusan wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Nikolai Lusan 
>
>   Package name: fingerprint-gui

Some questions:

1) are you aware of the Debian FingerForce Team?  Any
   fingerprint-related packaging should be done there...

2) given that fingerprint-gui depends on fprint, how this integrates
   with the fprint status in Debian, especially #599188?

    Description : Use fingerprint readeers to login.
  
There is a typo: s/readeers/readers/ .

> fingerprint-gui is a program that allows you to use a fingerprint reader
> (either usb attached or built-in) to login to GNU/Linux machines. It uses
> the libfprint library and can interface with PAM an policykit-1.

IIRC GNOME provides a module integrated with the 'account' preferences,
how does fingerprint-gui integrate with this?

Thx, bye,
Gismo / Luca


pgpIdt0av4RUe.pgp
Description: PGP signature

Bug#643874: RFP: python-fisher -- simple and fast implementation of Fisher's exact test

[Luca Capello]

Package: wnpp
Severity: wishlist
Usertags: unige.ch-jmlab

Hi there!

* Package name: python-fisher
  Version : 0.1.4
  Upstream Author : Haibao Tang ,
Brent Pedersen 
* URL or Web page : 

* License : BSD
  Description : simple and fast implementation of Fisher's exact test
  Fisher's exact test is a statistical significance test used in the
  analysis of contingency tables where sample sizes are small.
  .
  This package implements the Fisher's exact test as a Python Extension
  Module.

I cc:ed the debian-python@l.d.o mailing list, maybe someone there is
interested in packaging it.

The src/cfisher.pyx file contains the following statement:

  "some of this code is originally from the internet. (thanks)"

I also cc:ed the upstream authors for their comments on that sentence,
FTR the file contains references to three URLs, so I guess this is the
code taken from the Internet.  What is its license?

l009: Logarithm of n! with algorithmic approximation
  Reference:
Lanczos, C. 'A precision approximation of the gamma function',
J. SIAM Numer. Anal., B, 1, 86-96, 1964."
http://www.matforsk.no/ola/fisher.htm 

l097: http://docs.cython.org/docs/special_methods.html
  < 0 | <= 1 | == 2 | != 3 |  > 4 | >= 5

l157: found these tests on this ticket. (thanks).
  http://projects.scipy.org/scipy/ticket/956
  these values were taken from R as a means to test the code in that ticket.

Thx, bye,
Gismo / Luca


pgpcmPJm8c4ov.pgp
Description: PGP signature

Bug#612296: bacula and bacula-doc

[Luca Capello]

Hi Jan!

On Thu, 14 Apr 2011 15:21:31 +0200, Jan Hauke Rahm wrote:
> On Thu, Apr 14, 2011 at 03:13:27PM +0200, Luca Capello wrote:
>> On Thu, 14 Apr 2011 10:11:48 +0200, Jan Hauke Rahm wrote:
>> > So what's the status of this? I need bacula and want to help (just
>> > requested to join),
>> 
>> Just out of my curiosity, do you strictly need 5.0.3 (the current
>> upstream version) or could you work with 5.0.2 (the one currently in
>> Debian)?  I am simply asking because if 5.0.3 is *necessary* for most of
>> the users, maybe we should ask for it as a stable-proposed-update,
>> instead of simply relying on backports.d.o.
>
> No, or to be more clear: I didn't check yet. I'm still running lenny
> systems with bacula. Considering #606262, I'm not going to upgrade
> before I tested that and possibly even worked on a lenny-update to fix
> that.

Good point, I have not checked all the bugs in the BTS yet.

About #606262, I think we should start integrating the provided script
with the Debian package and then different people (I would say at least
three) should test the upgrade path on different machines and
configurations.  I just replied to the bug, including the upstream
bacula-user@ mailing list for comments.  Anyway, IMHO this is not a
showstopper for a new Bacula version in sid ;-)

>> For sure we are interested, the more people are looking at a package the
>> better it is, but there is an overlapping effort going on: José planned
>> to prepare an update version for this week-end, so I guess you should
>> contact him and check to not do any duplicate work anymore.
>> 
>> I have not done anything yet, given that José promptly replied me (in
>> private), so I decided to let him doing the work and jump in later.  I
>> have some complaints/improvements in my head, I will come back ;-)
>
> Okay, I'm in contact with him. Seems, I'm the only one who's commited
> anything yet. As soon as I have a git history that doesn't need rebasing
> anymore, I'll push it to alioth.

Thank you very much.

BTW, please note that I already set up the Git repository to push
commit notices to the pkg-bacula-commits@ mailing list ;-)

> Then I hope you're alright with my changes and we can go on from
> there...

Well, Debian is a do-ocracy, so you are entitled to any change as much
as I am, thus please go on!

Thx, bye,
Gismo / Luca


pgp7AGuDqHDzG.pgp
Description: PGP signature

Bug#612296: bacula and bacula-doc

[Luca Capello]

Hi Jan!

Re-adding the people who showed interest in helping as Cc:, please keep
them since I am not the only one working on Bacula.

On Thu, 14 Apr 2011 10:11:48 +0200, Jan Hauke Rahm wrote:
> On Tue, Apr 12, 2011 at 12:56:41AM +0200, Luca Capello wrote:
>> I am now part of this project, the next thing I will ask for is two
>> mailing lists: read-only -commits and -devel, the latter to be used as
>> Maintainers: in debian/control.  And I will also ask for a Git
>> repository, which will be the succession of John's repository at
>> <http://git.debian.org/?p=users/jgoerzen/bacula>.

Well, everything was done:

  <http://lists.alioth.debian.org/mailman/listinfo/pkg-bacula-commits>
  <http://lists.alioth.debian.org/mailman/listinfo/pkg-bacula-devel>
  <http://git.debian.org/?p=pkg-bacula/bacula.git;a=summary>

> So what's the status of this? I need bacula and want to help (just
> requested to join),

Just out of my curiosity, do you strictly need 5.0.3 (the current
upstream version) or could you work with 5.0.2 (the one currently in
Debian)?  I am simply asking because if 5.0.3 is *necessary* for most of
the users, maybe we should ask for it as a stable-proposed-update,
instead of simply relying on backports.d.o.

> I even -- since I started to look at bugs in the package first before
> looking here :-/ -- started to work on bacula, i.e.  I have a clone of
> john's git repo here and have a few commits on it. I changed a bit,
> upgraded to 5.0.3 and am now trying to bring it a bit up2date
> packaging-wise. You're interested or do we have overlapping efforts
> now?

For sure we are interested, the more people are looking at a package the
better it is, but there is an overlapping effort going on: José planned
to prepare an update version for this week-end, so I guess you should
contact him and check to not do any duplicate work anymore.

I have not done anything yet, given that José promptly replied me (in
private), so I decided to let him doing the work and jump in later.  I
have some complaints/improvements in my head, I will come back ;-)

Thx, bye,
Gismo / Luca


pgpKaajcyEpZP.pgp
Description: PGP signature

Bug#612296: bacula and bacula-doc

[Luca Capello]

Hi there!

For the debian-backports@ people, please read at the end.

On Mon, 11 Apr 2011 17:06:43 +0200, José Luis Tallón wrote:
> On Fri, 08 Apr 2011 12:36:58 +0200, Luca Capello  wrote:
>> On Fri, 11 Feb 2011 19:29:15 +0100, José Luis Tallón wrote:
>>>>> Chuck, would you be happy to co-maintain bacula together with
>>>>> José Luis?
>>>> 
>>>> Sure not a problem.
>>>> 
>
> Luca, would you mind sponsoring/reviewing a new version during this week?
>
> As there was no activity from others, this tasks fell a bit in my todo
> list.
> Moreover, I didn't want to overload Anibal if at all possible.

No problem at all, please continue it privately.

>> There is no Alioth project and I was thinking about creating one named
>> 'pkg-bacula'.

I clearly remember I had looked for such a project before sending my
last email and found none, now that I was asking for it I found out that
one has existed since 2006-05-10.  I cc:ed the other three members: what
is your status in this project?  John already demoted himself from
'Admin' to 'Developer', I guess he wants to come back in the future ;-),
what about Christoph and Turbo?

I am now part of this project, the next thing I will ask for is two
mailing lists: read-only -commits and -devel, the latter to be used as
Maintainers: in debian/control.  And I will also ask for a Git
repository, which will be the succession of John's repository at
<http://git.debian.org/?p=users/jgoerzen/bacula>.  Given that it must be
editable by every one in the project, it should be created with `umaks
002`, as explained at:

  <http://wiki.debian.org/Alioth/Git#Separate_project>.

>>  Maybe I will ask on debian-devel@ and then decide about that.
>> Anyway, if no one will complain in three days, I will ask for such a new
>> Alioth project.
>
> Ok, let's use Alioth
>  (though I'd prefer some repo hosted somewhere or whatever)

Anything else than Alioth is a no-op for me, sorry, as I do not see the
point in keeping Debian work on a non-Debian resource.  And if Alioth
misses something that other resources have, please file bugs into the
Alioth bug tracker ;-)

On Mon, 11 Apr 2011 15:38:29 +0200, Gerfried Fuchs wrote:
> * Bernd Holzinger  [2011-04-11 14:55:27 CEST]:
>> Any plans to update the bacula packages to version 5.0.3 for squeeze?
>
>  A backport of 5.0.3 can only be produced if the bacula version in
> testing got updated to said version.
[...]
>  I myself have a too tight schedule to do all the stuff I do anyway, so
> I opt out from doing that voluntarily. My relation to the package was
> work-related (same as with John) and actually dropped from me two years
> ago. So someone from the upcoming maintenance team would be a perfect
> fill-in here.

FWIW, I started to use Bacula on production systems, i.e. on squeeze,
thus if none of the other upcoming maintainers will do, I will for sure
provide backports for squeeze, since I need them anyway.

Thx, bye,
Gismo / Luca


pgp9hYXpKcYQO.pgp
Description: PGP signature

Bug#612296: bacula and bacula-doc

[Luca Capello]

Hi there!

On Fri, 11 Feb 2011 19:29:15 +0100, José Luis Tallón wrote:
>>> Chuck, would you be happy to co-maintain bacula together with
>>> José Luis?
>> 
>> Sure not a problem.
>> 
>
> Thanks many, Anibal. As usual.
>
> Chuck: when do you want to start? Just e-mail me directly and we'll
> coordinate it.

I am interested as well and given that I am a DD there will be needed no
help from Anibal for uploads (obviously, Anibal, you are more than
welcome if you were interested in actual maintenance).

There is no Alioth project and I was thinking about creating one named
'pkg-bacula'.  I thought about a general 'pkg-backup' project, but then
given the different backup solution I am not sure it would be a good
idea.  Maybe I will ask on debian-devel@ and then decide about that.
Anyway, if no one will complain in three days, I will ask for such a new
Alioth project.

Thx, bye,
Gismo / Luca


pgpiPLZCmvYPt.pgp
Description: PGP signature

Bug#503529: marked as done (ITA: udhcp -- very small DHCP client)

[Luca Capello]

Hi Geert!

On Sat, 14 Nov 2009 17:21:04 +0100, Debian Bug Tracking System wrote:
> Your message dated Sat, 14 Nov 2009 16:17:42 +
> with message-id 
> and subject line Bug#503529: fixed in udhcp 0.9.8cvs20050303-3
> has caused the Debian Bug report #503529,
> regarding ITA: udhcp -- very small DHCP client
> to be marked as done.
[...]
> From: Geert Stappers 
> Subject: Bug#503529: fixed in udhcp 0.9.8cvs20050303-3
> To: 503529-cl...@bugs.debian.org
> Date: Sat, 14 Nov 2009 16:17:42 +
>
> Source: udhcp
> Source-Version: 0.9.8cvs20050303-3
>
> We believe that the bug you reported is fixed in the latest version of
> udhcp, which is due to be installed in the Debian FTP archive:

Can you please explain me the reason for this hijack without any
announce?  There was no hurry in adopting this package (it was broken
since a while) and moreover there is a real plan going on to completely
replace a stand-alone package with one which use the busybox version
instead:

  http://bugs.debian.org/537623

Note that I do not care to maintain this package, but I care about the
above plan, which also reduces duplicate code in the Debian archive.

Thx, bye,
Gismo / Luca


pgpgCPC5OU0QS.pgp
Description: PGP signature

Bug#540702: RFA: qbook -- create HTML/LaTeX versions of Common Lisp source code

[Luca Capello]

Package: wnpp
Severity: normal

Hi there!

As I explained on the pkg-common-lisp-devel@ mailing list, I have no
more interest in maintaining qbook:

  
http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/2009-July/001337.html

If no one will step in and adopt qbook, I will ask for its removal in
two weeks.  Package description is below.

Thx, bye,
Gismo / Luca

=
Homepage: http://common-lisp.net/project/bese/qbook.html
Description: create HTML/LaTeX versions of Common Lisp source code
 qbook is a Common Lisp tool to create HTML/LaTeX versions of
 source code.
 .
 Features:
  * Very simple (easy to learn and use).
  * It can produce HTML or LaTeX.
 .
 In order to produce LaTeX documents, you need to install the
 texlive-latex-base package.


pgpAUUPPRiYzL.pgp
Description: PGP signature

Bug#540703: RFA: yaclml -- Yet Another Common Lisp Markup Language

[Luca Capello]

Package: wnpp
Severity: normal

Hi there!

As I explained on the pkg-common-lisp-devel@ mailing list, I have no
more interest in maintaining yaclml:

  
http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/2009-July/001337.html

If no one will step in and adopt yaclml, I will ask for its removal in
two weeks.  Package description is below.

Thx, bye,
Gismo / Luca

=
Homepage: http://common-lisp.net/project/bese/yaclml.html
Description: Yet Another Common Lisp Markup Language
 YACLML is a collection of macros and utilities for generating
 XML/HTML like markup from lisp code.
 .
 Features:
  * Constant folds as much as possible.
  * Macros for generating HTML from within lisp code.
  * Templating system for generating HTML from designer templates.
 .
 The recommended packages add documentation via cl-qbook or a test
 suite with cl-fiveam.


pgpSGaIkhOCqo.pgp
Description: PGP signature

Bug#540704: RFA: parenscript -- JavaScript embedded in a Common Lisp host

[Luca Capello]

Package: wnpp
Severity: normal

Hi there!

As I explained on the pkg-common-lisp-devel@ mailing list, I have no
more interest in maintaining Parenscript:

  
http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/2009-July/001337.html

The package is outdated mostly because of a bug with the Debian Darcs
repositories, as explained at:

  
http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/2008-October/001042.html

If no one will step in and adopt Parenscript, I will ask for its removal in
two weeks.  Package description is below.

Thx, bye,
Gismo / Luca

=
Homepage: http://www.cliki.net/Parenscript
Description: JavaScript embedded in a Common Lisp host
 Parenscript is a small lispy language that can be compiled to
 JavaScript.
 .
 It also comes with an embedded CSS representation in Common Lisp.
 This simplifies the development of web applications in Common Lisp
 by allowing the Common Lisp programmer to write all the documents
 in Common Lisp syntax.
 .
 HTML pages, CSS files and JavaScript code can be generated with
 the full power of Common Lisp and its macros.
 .
 The recommended packages add extra features: test suite with
 cl-ppcre and cl-fiveam.
 .
 Single file documentation is provided via the texlive-latex-base,
 texlive-latex-recommended, texlive-fonts-recommended and python
 packages.


pgpV4PMZsEcoc.pgp
Description: PGP signature

Bug#540699: RFA: arnesi -- small Common Lisp utilities

[Luca Capello]

Package: wnpp
Severity: normal

Hi there!

As I explained on the pkg-common-lisp-devel@ mailing list, I have no
more interest in maintaining arnesi:

  
http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/2009-July/001337.html

If no one will step in and adopt arnesi, I will ask for its removal in
two weeks.  Package description is below.

Thx, bye,
Gismo / Luca

=
Homepage: http://common-lisp.net/project/bese/arnesi.html
Description: small Common Lisp utilities
 arnesi is a Common Lisp utility suite.  It contains various "bits 'n
 pieces" of code.
 .
 Features:
  * Flow control macros - while, whichever, if-bind, etc.
  * A simple logging facility - kind-of/sort-of/maybe like log4j.
  * HTTP/HTML utilities - URL and HTML escaping.
  * Pattern matching - fare-matcher style pattern matcher and "regular"
list matcher.
  * Accumulation - collecting and reducing macros.
  * Cps transformer - an ad-hoc, bug ridden implementation of half of
call/cc.
  * Decimal arithmetic - convert floats to exact rationals and vice
versa with a given precision; standard rounding functions.
  * MOP compatibility package - The MOPP package provides the MOP's
symbols on various implementations.  Currently OpenMCL, CMUCL,
SBCL, Lispworks and CLISP are supported.
 .
 The recommended packages add extra features: documentation via
 cl-qbook, test suite with cl-fiveam, add-ons for cl-ppcre and
 integration with SLIME swank with cl-swank.


pgpfhSRwcM9tF.pgp
Description: PGP signature

Bug#540700: RFA: fiveam -- simple regression testing framework

[Luca Capello]

Package: wnpp
Severity: normal

Hi there!

As I explained on the pkg-common-lisp-devel@ mailing list, I have no
more interest in maintaining FiveAM:

  
http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/2009-July/001337.html

If no one will step in and adopt FiveAM, I will ask for its removal in
two weeks.  Package description is below.

Thx, bye,
Gismo / Luca

=
Homepage: http://common-lisp.net/project/bese/FiveAM.html
Description: simple regression testing framework
 FiveAM is a simple (as far as writing and running tests goes)
 regression testing framework.  It has been designed with Common
 Lisp's interactive development model in mind.
 .
 Features:
  * Test and test suite hierarchies allow test to be organized into
hierarchies to ease running
  * Functions for re-running recently run tests.
  * Inter-test dependencies.
 .
 The documentation is provided via the cl-qbook package.


pgpRwfJxWXWv2.pgp
Description: PGP signature

Bug#359348: cl-rfc2109: requesting comments

[Luca Capello]

tags 359348 + wontfix
close 359348
thanks

Hi there!

On Sun, 25 Nov 2007 19:33:03 +0100, Luca Capello wrote:
> I need some legal advices about one of my packages, rfc2109 [1][2].

The above request was never fulfilled and in the meantime I have lost
interest and free time for everything UCW-related:

  
http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/2009-July/001337.html

Thus, I tagged this bug as wontfix and closed it.

Thx, bye,
Gismo / Luca


pgp04Ang4XqBw.pgp
Description: PGP signature

Bug#503529: O: udhcp -- very small DHCP client

[Luca Capello]

retitle 503529 ITA: udhcp -- very small DHCP client
user pkg-fso-ma...@lists.alioth.debian.org
usertags 503529 + package-dependencies
thanks

Hi there!

On Mon, 27 Oct 2008 15:52:45 +0100, Luca Bruno wrote:
> Citing from udhcp upstream website:
> «Note that the standalone udhcp client/server is not maintained anymore.
> It was moved to busybox. Use the udhcp in busybox instead. (The rest of
> this page was last updated in 2003 and is now obsolete).»
>
> It looks like this source package could be dropped, if QA team wants.
> Popcon report 122/143 install; busybox maintainers could consider
> providing binary packages for this, if feasible.

Axel Beckert is working on providing busybox-* binary packages:

  http://bugs.debian.org/#537623

I suggested that the same should be applied to at least udhcpc and thus
I will take care of the udhcp source package: in one way or another it
will be removed from the archive, since it duplicates code for no real
reason.

Thx, bye,
Gismo / Luca


pgprmAb2Ekhkm.pgp
Description: PGP signature

Bug#537623: ITP: busybox-syslogd -- Provides syslogd and klogd using busybox' implementation

[Luca Capello]

user pkg-fso-ma...@lists.alioth.debian.org
usertags 537623 + package-dependencies
thanks

Hi there!

On Sun, 19 Jul 2009 23:41:24 +0200, Axel Beckert wrote:
> * Package name: busybox-syslogd
>   Version : 0.1

May I suggest to use the same version number as busybox?

>   Description : Provides syslogd and klogd using busybox' implementation
>
> Debian's busybox package has the syslogd and klogd functionalities
> already compiled in, but to use them, a little bit more than a few
> symbolic links is needed.
>
> This package provides the appropriate dependencies, the symbolic links
> for syslogd and klogd, man pages (also symlinks), and init.d scripts.

I like very much this idea, which to some extents I would like to see
implemented for another busybox binary, udhcpc (which should probably
generate from the very same source package).

This because the udhcpc package contains is a duplication of code
already included in busybox and nowadays that busybox provides the
udhcpc binary I do not see the reason for an external package.  The same
applies to the udhcpd package.

Thx, bye,
Gismo / Luca



pgpMGMw66iSPF.pgp
Description: PGP signature

Bug#520955: [pkg-fso-maint] Bug#520955: ITP: xserver-xorg-video-glamo -- X.Org X server --, SMedia Glamo display driver

[Luca Capello]

Hi Enrico!

On Tue, 12 May 2009 22:40:48 +0200, Luca Capello wrote:
> On Mon, 04 May 2009 21:01:42 +0200, Enrico Zini wrote:
>> How about 0~20090503.gitb5eb5f79-1, so it can go to 0.1 if upstream
>> eventually decides to start making releases?
>
> Good point, I will do like you suggested, thanks!

There is a problem:
=
l...@gismo:~/working/pkg-fso/git/xf86-video-glamo(git)[master]
$ git tag -s -m "Upstream version 0~20090224.git703acea1" 
upstream/0~20090224.git703acea1
fatal: 'upstream/0~20090224.git703acea1' is not a valid tag name.
l...@gismo:~/working/pkg-fso/git/xf86-video-glamo(git)[master]
=

According to configure.ac:
--8<---cut here---start->8---
# Process this file with autoconf to produce a configure script

AC_PREREQ(2.57)
AC_INIT([xf86-video-glamo],
0.4.0,
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg],
xf86-video-glamo)
--8<---cut here---end--->8---

However, src/glamo-driver.c contains
--8<---cut here---start->8---
#define GLAMO_VERSION   1000
#define GLAMO_NAME  "Glamo"
#define GLAMO_DRIVER_NAME   "Glamo"
--8<---cut here---end--->8---

To avoid any future problem, I went with version
0.0.0+20090224.git703acea1, because of:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520955#78

I will sort this out with upstream together with the license issues.

Thx, bye,
Gismo / Luca


pgpEPCMXZ605v.pgp
Description: PGP signature

Bug#520955: [pkg-fso-maint] Bug#520955: ITP: xserver-xorg-video-glamo -- X.Org X server --, SMedia Glamo display driver

[Luca Capello]

Hi Timo!

On Tue, 12 May 2009 23:14:51 +0200, Timo Juhani Lindfors wrote:
> Luca Capello  writes:
>>   commit 9491d818583114e429db1330dc5e07b4668dfa35
[...]
>> Can you confirm/deny that the above fixes your problem?
>
> This fixes
>
> #2281 xf86-video-glamo/0f03b39435910: odd graphical artifacts
>
> but does not fix
>
>>   http://docs.openmoko.org/trac/ticket/2258
>
> I talked with Lars and it seems that the 703a version has bug #2258
> too but does not trigger it very easily. The new version triggers it
> every time with new kernel:

This is indeed bad :-(

>>   http://docs.openmoko.org/trac/ticket/2263
>
> That is not fixed yet either.

>>   commit 25c4b0e80e93e04e6f7d4b8bca6d007fb9de6da8
[...]
> Hmm, I wrote your email before this version existed so I have not done
> extensive testing on it yet. Please don't pacckage it without asking
> Lars first if he thinks it'd be a stable version. (My understanding is
> that we have no real fix for the issue yet...)

OK, in this case I will package the one you suggested:

  commit 703acea131caf72e71f04a0ad40f540fe236be89
  Author: Lars-Peter Clausen 
  Date:   Tue Feb 24 21:01:29 2009 +0100

Mark the mode of the framebuffer which was set before the xserver
was started as
preferred.

Before going to main I still need to sort out the license issues, thus
the first upload will be anyway to the pkg-fso repository.  I will then
contact Lars about the license and future upgrades.

Thx, bye,
Gismo / Luca


pgpbXdw6cp85a.pgp
Description: PGP signature

Bug#520955: [pkg-fso-maint] Bug#520955: ITP: xserver-xorg-video-glamo -- X.Org X server --, SMedia Glamo display driver

[Luca Capello]

Hi Enrico!

On Mon, 04 May 2009 21:01:42 +0200, Enrico Zini wrote:
> On Mon, May 04, 2009 at 04:37:48PM +0200, Luca Capello wrote:
>
>> > I named it 0.1.0 due to the fact that there are no tags yet in the
>> > upstream git repository.
>> 
>> This is wrong, sorry, because it will conflict if upstream will release
>> a 0.1.0 version.  I would prefer something similar to the
>> linux-2.6-openmoko package and indeed the Debian Git repository has an
>> upstream tag, 20090302.git451398a2:
> [...]
>> the Debian package version should be 20090503.gitb5eb5f79-1.
>
> How about 0~20090503.gitb5eb5f79-1, so it can go to 0.1 if upstream
> eventually decides to start making releases?

Good point, I will do like you suggested, thanks!

Thx, bye,
Gismo / Luca


pgp6aTN4AnmxV.pgp
Description: PGP signature

Bug#520955: [pkg-fso-maint] Bug#520955: ITP: xserver-xorg-video-glamo -- X.Org X server --, SMedia Glamo display driver

[Luca Capello]

Hi Timo!

On Tue, 05 May 2009 01:02:30 +0200, Timo Juhani Lindfors wrote:
> Johannes Schauer  writes:
>>> the Debian package version should be 20090503.gitb5eb5f79-1.
>
> Please don't package this version. It has a known regression that is
> being worked on: http://docs.openmoko.org/trac/ticket//2281

I cannot see anything new about the above ticket, but one of the last
commits suggests the contrary:

  commit 9491d818583114e429db1330dc5e07b4668dfa35
  Author: Lars-Peter Clausen 
  Date:   Tue May 5 01:07:10 2009 +0200

Only waiting for the cmdq engine to be finished when dispatching the queue
causes visual artifactes sometimes. Waiting for all engines to be finished 
seems
to fix the issue.

Can you confirm/deny that the above fixes your problem?

> If you want to package something that reliably works and has been
> tested for a while, consider packaging git revision 703acea131caf72e
> instead. I have been using that revision extensively for more than a
> month without trouble.

What about the following ones?  ;-)

  http://docs.openmoko.org/trac/ticket/2258
  http://docs.openmoko.org/trac/ticket/2263

Since it seems that recent commits have fixed some problems, I would
prefer to package the last one:

  commit 25c4b0e80e93e04e6f7d4b8bca6d007fb9de6da8
  Author: Lars-Peter Clausen 
  Date:   Sat May 9 15:27:17 2009 +0200

Don't wait when disabling the cmdq. it causes a wsod for some users.
thanks to lindi for tracking it down.

Thx, bye,
Gismo / Luca


pgp2NHgRSn4K4.pgp
Description: PGP signature

Bug#520955: ITP: xserver-xorg-video-glamo -- X.Org X server --, SMedia Glamo display driver

[Luca Capello]

tags 520955 + patch
thanks

Hi Johannes!

Quickly reply, before the package reaches a too much wider audience.

On Mon, 04 May 2009 15:58:08 +0200, Johannes Schauer wrote:
> I build a preliminary package for xf86-video-glamo.

Thank you!

> I named it 0.1.0 due to the fact that there are no tags yet in the
> upstream git repository.

This is wrong, sorry, because it will conflict if upstream will release
a 0.1.0 version.  I would prefer something similar to the
linux-2.6-openmoko package and indeed the Debian Git repository has an
upstream tag, 20090302.git451398a2:

  
http://git.debian.org/?p=pkg-fso/xf86-video-glamo.git;a=tag;h=16b5d5811976df103796924809786a0a86a93e03

> I build the orig.tar.gz from git revision
> b8b594393cb85c7c940f22456036d45e598d344e

OK, based on the corresponding commit

  
http://git.openmoko.org/?p=xf86-video-glamo.git;a=commit;h=b5eb5f79245bebe7857a4857dda996f82fecf5e5

the Debian package version should be 20090503.gitb5eb5f79-1.

> and did `autoreconf -i` on the source.
>
> The package was mainly inspired by the xserver-xorg-video-fbdev
> package.

This is exactly what I tried from the Debian Git repository above and
then I ended up with a compilation error.  I did not investigated
further because of lack of time, sorry.

> I tried to compile a license file that is accurate enough to cover all
> source code comments about copyright and licensing.
>
> Maybe you could fix things and add the missing bits there (Maintainer
> and Uploaders fields are still empty) to have the package uploaded into
> the pkg-fso repository?

Sure, do you want to co-maintain the package?

> I uploaded the source package and a binary for debian lenny armel here:
> http://rabenfrost.net/openmoko/xserver-xorg-video-glamo/

I would remove them ASAP, simply because the version problem is a
serious one IMHO.

Thx, bye,
Gismo / Luca


pgpSseA01Dtwb.pgp
Description: PGP signature

Re: Processed: fixed 520955 in 1:3.0.1-9, fixed 520955 in 1:3.0.1-9, fixed 521035 in 1:3.0.1-9 ...

[Luca Capello]

notfixed 520955 1:3.0.1-9
thanks

Hi Rene!

On Mon, 06 Apr 2009 00:27:06 +0200, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
>
>> # Automatically generated email from bts, devscripts version 2.10.35lenny3
>> fixed 520955 1:3.0.1-9
> Bug#520955: ITP: xserver-xorg-video-glamo -- X.Org X server -- SMedia Glamo 
> display driver
> Bug marked as fixed in version 1:3.0.1-9.

I guess you made a typo in the bug number ;-)

Thx, bye,
Gismo / Luca


pgpOkrSXcUEyR.pgp
Description: PGP signature

Bug#520955: ITP: xserver-xorg-video-glamo -- X.Org X server -- SMedia Glamo display driver

[Luca Capello]

Package: wnpp
Owner: Luca Capello 
Severity: wishlist
User: pkg-fso-ma...@lists.alioth.debian.org
Usertags: package-creation

* Package name: xserver-xorg-video-glamo
  Version : MMDD.gitCOMMIT (read below)
  Upstream Author : mainly Lars-Peter Clausen 
* URL or Web page : http://git.openmoko.org/?p=xf86-video-glamo.git;a=summary
* License : multiple, mostly XFree86 (full texts below)
  Description : X.Org X server -- SMedia Glamo display driver
 This package provides the driver for the SMedia Glamo 3362 chipset,
 mostly found on the Openmoko Neo FreeRunner (GTA02).
 .
 More information about X.Org can be found at:
 http://www.X.org>
 http://xorg.freedesktop.org>
 http://lists.freedesktop.org/mailman/listinfo/xorg>
 .
 This package is built from the X.Org xf86-video-glamo driver module.
=

NB, I cc:ed a lot of lists: please refrain to discuss non-Debian issues
on all of them.  Except for general issues, pkg-fso-maint@ is the most
relevant one, which should always be cc:ed, TIA.

This driver is based on the XFree86 fbdev driver, then adapted to the
SMedia Glamo chipset, more information are available at

  http://wiki.openmoko.org/wiki/Smedia_Glamo_3362

In my plan, this supersedes the Xglamo kdrive X11 server, which AFAIK is
not update anymore, ATM available in the pkg-fso repository at

  http://pkg-fso.alioth.debian.org

The xserver-xorg-video-glamo package as well will be maintained under
the pkg-fso umbrella, but I would like to work as close as possible with
the X Strike Force, to be sure the package conforms their standards.  If
the X Strike Force would like to take care of the package, I would more
than glad to "offer" it to them...


In src/glamo-driver.c, GLAMO_VERSION is set to 1000: however, this
driver has not seen any public release yet, thus my intent to use the
date of the last Git commit plus the first 8 letters of the Git commit
itself as upstream version.


The full license texts are:

- from COPYING file
  ==
  Copyright (C) 1994-2003 The XFree86 Project, Inc.  All Rights Reserved.

  Permission is hereby granted, free of charge, to any person obtaining
  a copy of this software and associated documentation files (the
  "Software"), to deal in the Software without restriction, including
  without limitation the rights to use, copy, modify, merge, publish,
  distribute, sublicense, and/or sell copies of the Software, and to
  permit persons to whom the Software is fur- nished to do so, subject
  to the following conditions:

  The above copyright notice and this permission notice shall be
  included in all copies or substantial portions of the Software.

  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
  MERCHANTABILITY, FIT- NESS FOR A PARTICULAR PURPOSE AND
  NONINFRINGEMENT.  IN NO EVENT SHALL THE XFREE86 PROJECT BE LIABLE FOR
  ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
  CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CON- NECTION
  WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

  Except as contained in this notice, the name of the XFree86 Project
  shall not be used in advertising or otherwise to promote the sale, use
  or other deal- ings in this Software without prior written
  authorization from the XFree86 Project.
  =


- from C source files
  =
  [copyrights holders mainly Openmoko Inc, Lars-Peter Clausen and Eric
   Anholt]

  Permission to use, copy, modify, distribute, and sell this software
  and its documentation for any purpose is hereby granted without fee,
  provided that the above copyright notice appear in all copies and that
  both that copyright notice and this permission notice appear in
  supporting documentation, and that the name of the copyright holders
  not be used in advertising or publicity pertaining to distribution of
  the software without specific, written prior permission.  The
  copyright holders make no representations about the suitability of
  this software for any purpose.  It is provided "as is" without express
  or implied warranty.

  THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
  SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
  FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
  SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
  RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
  CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
  CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  =


- exceptions
  =
  * src/glamo-driver.c
  no license bits, authors Alan Hourihane and Michale Dänzer

  * src/glamo-regs.h
  GPL-2+, author Harald Welte


I think that not only the two exceptions, but everything about the
license needs further investigation, with for sure advices from
upstream.

I will s

Bug#518494: ITP: pythm -- media players (e.g. mpd, gstreamer, mplayer) GUI frontend

[Luca Capello]

user pkg-fso-ma...@lists.alioth.debian.org
usertags 518494 + package-creation
thanks

Hi Yaroslav!

Please keep the pkg-fso-maint mailing list cc:ed, TIA.

On Fri, 06 Mar 2009 16:25:16 +0100, Yaroslav Halchenko wrote:
> * Package name: pythm
>   Version : 0.5.5-dmr (fork developed by Dylan)
>   Upstream Author : Matthias Hans , Dylan Reilly 
> , and others ;)
> * URL : http://github.com/negi/pythm/tree/master

What are the advantages of this one WRT the original project [1]?  Is
there any chance that development on the original project will continue?
In this case, I would say that the fork should not be packaged with the
original name.

> Pythm (Python + Rhythm) is a media player frontend, designed to
> control gstreamer, mplayer or mpd with one GUI on mobile devices such
> as OpenMoko's FreeRunner.
 ^
Do you mind maintaining your package under the pkg-fso umbrella [2],
which is the team behind any Debian effort for Openmoko devices?

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://projects.openmoko.org/projects/pythm/
[2] http://wiki.debian.org/Teams/DebianFSO


pgpP16ZECHksI.pgp
Description: PGP signature

Bug#469982: Trivial Garbage package

[Luca Capello]

Hi Barry!

On Wed, 19 Nov 2008 05:04:28 +0100, Barry deFreese wrote:
> Luca Capello wrote:
>> 
>> I do not like to pollute the debian/ folder with single-line files.
>> Obviously, this is my opinion on this matter, so feel free to follow it
>> or not.
>>
>> Now that I think of it, one advantage of using .docs and .install files
>> is that their content can be automatically parsed, but AFAIK there has
>> not been such a tool yet.
>
> I've left them for now.

Fine as well.

>> 
>> You are a DD, thus your Alioth login is now "bdefreese" [1].  Since
>> Alioth uses the developer SSH keys by default [2], you should already be
>> able to access to Alioth with "bdefreese" as well.
>>
>> I would prefer to add you as "bdefreese", since this is fixed while your
>> -guest account will eventually disappear.  Is there any reason I should
>> add you with your old -guest account?
>
> OK, I fixed my bdefreese account so that is fine.  Though I'm sad to
> lose all the stuff tied to me for the hurd and games teams to date. :(

I added you to the Debian CL team: welcome!

Thx, bye,
Gismo / Luca


pgppQVLex5l1R.pgp
Description: PGP signature

Bug#469982: Trivial Garbage package

[Luca Capello]

Hi Barry!

On Tue, 18 Nov 2008 20:21:36 +0100, Barry deFreese wrote:
> Luca Capello wrote:
>> 1) debian/changelog
[...]
>>In this specific case, Matthias Benkard (cc:ed) opened the ITP [4]
>>(cc:ed as well): Matthias, do you want to maintain trivial-garbage?
>
> Fixed.  Though I guess I'm somewhat "hijacking" it.

I do not think you are hijacking anything, Matthias (again cc:ed) can
join your effort later.  And since you explicitly asked for a
maintainer, then the situation will cleanly solve by itself :-)

>> 2) debian/control
[...]
>>* Maintainer/Uploaders
[...]
> Added myself.

Have you removed Peter Van Eynde?  If not, please do so.  If you want at
least one member of the Debian CL team there, just add myself.  But as
you will read later on this post, you are now officially part of the
Debian CL team ;-)

>>* Description
>>
>>  While it is correct, I would expand it a bit more to include some
>>  features, similar to cl-arnesi [11].
>
> Hmm, I could probably use some help there.

Sure.

>> 4) debian/docs
>>
>>I tend to avoid useless files when possible, which means that I
>>prefer adding to debian/rules:
>>
>>  dh_installdocs README
>
> Why is this advantageous over just using debian/docs?
[...]
>> 5) debian/install
[...]
> Fixed the path but left it in debian/install.  Again, what's the
> advantage of not using an install file?

I do not like to pollute the debian/ folder with single-line files.
Obviously, this is my opinion on this matter, so feel free to follow it
or not.

Now that I think of it, one advantage of using .docs and .install files
is that their content can be automatically parsed, but AFAIK there has
not been such a tool yet.

> OK, so I used darcs get and added my debian dir but I cannot push it.
> Do I need some type of permissions?

Yes, you need to be part of the Debian CL team.

> My alioth user is still bddebian-guest. :-(

You are a DD, thus your Alioth login is now "bdefreese" [1].  Since
Alioth uses the developer SSH keys by default [2], you should already be
able to access to Alioth with "bdefreese" as well.

I would prefer to add you as "bdefreese", since this is fixed while your
-guest account will eventually disappear.  Is there any reason I should
add you with your old -guest account?

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://alioth.debian.org/users/bdefreese
[2] http://lists.debian.org/debian-devel-announce/2008/05/msg8.html


pgpj5DBgLjjk9.pgp
Description: PGP signature

Bug#469982: Trivial Garbage package

[Luca Capello]

Hi Barry!

I am sorry for the long mail, but I can be very verbose sometime...

Since we discussed on IRC, you know why I was late ;-)

On Mon, 10 Nov 2008 21:52:48 +0100, Barry deFreese wrote:
> I apologize for posting to the development list but I've been trying
> to catch someone on IRC to no avail.

FWIW, I *always* prefer discussions to take place on mailing lists,
since they are archived and can be referenced later.

> I had a friend of mine ask me to package trivial garbage.  I have
> created a package but I really would hate to be the maintainer as I am
> not much of a lisp person.  Would you folks possibly be interested in
> maintaining it?

I will speak for myself here, but I think Peter's opinion is not so far
From mine: I would be glad to have another CL library under the team
umbrella.  However, I am not sure I will ever use trivial garbage [1],
which means that if your friend use it and you provide some sort of
support to him, you can become a team member and maintain it by
yourself.  The team can take care of it, but this should be the last
option.

> If not would you mind at least looking over my package to see if I am
> doing the right thing with it?

Sure, here my comments on the package available on mentors.d.o [2].  For
the list readers, most of these comments will end up in the long-overdue
"Debian Common Lisp Policy", which I still need to write.


1) debian/changelog

   I do not like to retroactively modify previously released files,
   which means that if you do not have an ITP number when your package
   goes public, just ignore it.  I do not consider the corresponding
   lintian warning [3] so important, since AFAIK the ITP is not
   mandatory and sometime I do not see the point in it.

   In this specific case, Matthias Benkard (cc:ed) opened the ITP [4]
   (cc:ed as well): Matthias, do you want to maintain trivial-garbage?


2) debian/control

   * Build-Depends

 SBCL is not needed, only debhelper and dh-lisp.

   * Maintainer/Uploaders

 Please always use the Debian CL team for the Maintainer: field (as
 you did, thank you) and your name for the Uploaders: one: it does
 not matter if you are not the real uploader, but you are the one
 who did the packaging work and you deserve credits for that.

   * Homepage

 Is there any reason for using a specific revision for the Cliki
 homepage?  I would use instead the "plain" link [5]: if you use a
 specific revision, we will need to change it every time there is a
 new Debian version.

   * Vcs-*

 trivial-garbage is maintained upstream in darcs [6], before any
 upload to main the Debian package should be converted to darcs and
 put into the pkg-c-l darcs.d.o space [7].  Then you can check
 cl-arnesi for the corresponding Vcs-* fields [8].

 Since you need to be part of the team to work on the pkg-c-l
 darcs.d.o space, I already did it for the trivial-garbage.upstream
 repository [9]:

  [alioth]
   everything as explained at [7], except that I commented out the
   bcc: mail to [EMAIL PROTECTED] since the package is
   not yet in Debian

  [local]
   $ darcs get --tag 0.17 \
  http://common-lisp.net/~loliveira/darcs/trivial-garbage/ \
  trivial-garbage.upstream
   $ cd trivial-garbage.upsream
   $ darcs tag UPSTREAM_trivial-garbage_0.17
   $ darcs push \
  [EMAIL PROTECTED]:/darcs/pkg-common-lisp/trivial-garbage.upstream

 Now you should get the upstream repository, import your first
 debian/ folder effort and then fix it:

   $ darcs get \
  
http://darcs.debian.org/darcs/pkg-common-lisp/trivial-garbage.upstream \
  trivial-garbage
   $ cd trivial-garbage
   $ cp -r /path/to/trivial-garbage-0.17/debian .
   $ darcs record -A "Barry deFreese <[EMAIL PROTECTED]>" \
  -m "Import Debian version 0.17-1"
   $ darcs tag DEBIAN_trivial-garbage_0.17-1
   $ [start fixing] 

 I can import your first Debian effort if you want, but if you do it
 you will practise a bit with darcs as well ;-)

 Since the team packages are maintained with the $VCS-buildpackage
 tools, please read the darcs-buildpackage [10] documentation or just
 check cl-arnesi [8].

 I will not care too much about the upstream original .tar.gz: since
 we track upstream VCS repository and upstream correctly tags each
 release, we will just tag the Debian upstream one accordingly.
 Thus, while the .orig.tar.gz generated by darcs-buildpackage will
 not be exactly the same as upstream one, the contents will.  Or we
 can use upstream one and feed it to darcs-buildpackage.  Obviously,
 I am open to any discussion on this subject ;-)

   * Description

 While it is correct, I would expand it a bit more to include some
 features, similar to cl-arnesi [11].


3) debian/copyright

   Please enclose every e-mail address between < and >, you missed that
   fo

Bug#503096: ITP: alpaca -- GnuPG file handling for Emacs

[Luca Capello]

Hi Tatsuya!

On Wed, 22 Oct 2008 15:58:11 +0200, Tatsuya Kinoshita wrote:
> * Package name: alpaca
[...]
> * URL : http://www.mew.org/~kazu/proj/cipher/

I think that a package for one single file is too much.

>   Description : GnuPG file handling for Emacs
>  `alpaca' is an Emacs Lisp package to edit GnuPG files encrypted with
>  shared-key cryptography on GNU Emacs.
>  .
>  If this package is installed, when handling of a file whose suffix
>  is ".gpg", this package asks your passphrase and then the file is
>  automatically decrypted/encrypted.

What are the advantages of alpaca over EasyPG [1]?  FWIW with EasyPG you
get the same behavior when you handle a .gpg file and I was thinking
that (finally) EasyPG was the Emacs choice for everything GPG related.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://www.easypg.org/


pgpdr2i3hW3QE.pgp
Description: PGP signature

Bug#394566: Status update on conkeror in Debian

[Luca Capello]

Hi Axel!

On Tue, 06 May 2008 16:39:28 +0200, Axel Beckert wrote:
> On Tue, May 06, 2008 at 12:43:13PM +0200, Luca Capello wrote:
>>> On Sun, Nov 18, 2007 at 02:57:48AM +0100, Axel Beckert wrote:
>>> ... but depends on xulrunner 1.9 which is not yet in Debian...
>>
>> xulrunner-1.9 is now in experimental, do you want to wait until it lands
>> in unstable or will we see conkeror in experimental as well?
>
> Since it's still in heavy developement I plan to put it into
> experimental first.

Fully ACK.

> My current plan is to rebuild the package from scratch again (and
> based on the newest version of xulrunner), now that I know that more
> local installation steps than I expected are unnecessary for packaging
> and the package will become leaner.
[...]
> It will btw give two packages: conkeror and
> conkeror-spawn-process-helper,
[...]
> (conkeror will recommend conkeror-spawn-process-helper and the package
> description will refer to that package, too.)

Yeah, I followed your posts on the conkeror mailing list [1] ;-)

> I can notify you, as soon as I have the new package ready for the NEW
> queue, so that you can have a look on it as soon as possible (and
> maybe even sponsor it... ;-)

I'm here for everything you need, testing, package checking and
sponsoring: you know how to contact me!

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://thread.gmane.org/gmane.comp.mozilla.conkeror/729/focus=757


pgpcns8zogcH7.pgp
Description: PGP signature

Bug#394566: Status update on conkeror in Debian

[Luca Capello]

Hi Axel!

On Sun, 23 Mar 2008 15:26:56 +0100, Axel Beckert wrote:
> On Sun, Nov 18, 2007 at 02:57:48AM +0100, Axel Beckert wrote:
>> The new version calls itself conkeror-xr and is no more a Firefox
>> plugin but a xulrunner based standalone web browser.

Since the old Firefox extension is no more [1], do you still plan to
call it conkeror-xr or simply conkeror?  I prefer the latter and anyway
without the mozilla- prefix.

> ... but depends on xulrunner 1.9 which is not yet in Debian...

xulrunner-1.9 is now in experimental, do you want to wait until it lands
in unstable or will we see conkeror in experimental as well?

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://conkeror.org/


pgpQn6Br01acW.pgp
Description: PGP signature

Bug#438922: Bug#460493: ITP: libfprint -- fingerprint library of fprint project

[Luca Capello]

Hi Philipp!

I'm sorry for the lag, I promptly read your mail and then forgot to
answer it.

On Sat, 26 Jan 2008 15:04:14 +0100, Philipp Kern wrote:
> On Mon, Jan 14, 2008 at 03:42:13PM +0100, Luca Capello wrote:
>> Now, since Emfox asked how to solve this situation [6], I think the best
>> thing would be the FTP team to reject Emfox's packages (at the moment of
>> writing this mail still in NEW).  Then Emfox can join the Debian
>> FingerForce Team and work from there on the fprint packages :-)
>
> Will the fprint packages be uploaded to unstable/experimental soonishly
> or are they available elsewhere for evaluation?

Even if I'm not fully involved with fprint yet...

If you aren't aware of, fprint is waiting in NEW [1][2] and targets
experimental.  Hope it's a good news for you ;-)

Thx, bye,
Gismo / Luca

Footnotes: 
[1] 
http://lists.alioth.debian.org/pipermail/fingerforce-devel/2008-February/91.html
[2] 
http://lists.alioth.debian.org/pipermail/fingerforce-devel/2008-February/95.html



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#438922: Bug#460493: ITP: libfprint -- fingerprint library of fprint project

[Luca Capello]

Hello,

I'm directly writing to the Debian FTP Team to solve the issue with
fprint.  Since the discussion started on debian-devel, I set the R-T and
M-F-T headers to point to debian-devel and bug #438922 [1].  This
because the latter is the first ITP for fprint and it's owned by the
FingerForce team (the primary place for discussion about fingerprint
software on Debian).

On Sun, 13 Jan 2008 22:55:42 +0100, Evgeni Golov wrote:
> On Sun, 13 Jan 2008 13:25:04 +0800 Emfox Zhou wrote:
>
>>   Description : fingerprint library of fprint project
>
> Just some comments from me:
> 1. fprint needs imagemagick 6.3.*, which is not yet in Debian

I've never checked that yet, but read below.

> 2. you probably want to have a look at Debian FingerForce
> http://wiki.debian.org/FingerForce and have a talk with its members

The situation is even worse:

1) another ITP (#438922 [1]) already existed for fprint and it was
   worked on [2].  Debian distribution at which fprint is targeted
   hasn't been decided yet: I'm in favor of experimental, while other
   group members are OK with unstable

2) Kenshi Muto packaged fprint to use the AES2501 fingerprint reader in
   his new Fujitsu LOOX U50 ultra mobile PC [3]

3) Emfox Zhou's packages were updated to NEW [4] no more than 6 hours
   after his ITP (#460493 [5]), effectively giving no time to reply to
   the ITP with the concerns above

Now, since Emfox asked how to solve this situation [6], I think the best
thing would be the FTP team to reject Emfox's packages (at the moment of
writing this mail still in NEW).  Then Emfox can join the Debian
FingerForce Team and work from there on the fprint packages :-)

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438922
[2] 
http://lists.alioth.debian.org/pipermail/fingerforce-devel/2008-January/56.html
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438922#16
[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=9;bug=460493
[5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460493
[6] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438922#25


pgpr6ESOk8Gwp.pgp
Description: PGP signature

Bug#438922: fprint in Debian (was Fwd: Kenshi Muto: LOOX U50, nice gadget)

[Luca Capello]

Hi Kenshi!

I read from your blog [1] that you packaged fprint [2] because you
wanted to try the AES2501 fingerprint reader in your new Fujitsu LOOX
U50 ultra mobile PC.

This mail is to inform you that an ITP [3] already opened for it, owned
by the Debian FingerForce team [4]: would you like to join and
co-maintain fprint within the team?

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://kmuto.jp/b.cgi/debian/looxu50.htm
[2] http://www.reactivated.net/fprint/
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438922
[4] http://wiki.debian.org/FingerForce


pgpQNes4AM8B0.pgp
Description: PGP signature

Bug#451975: ITP: cl-plplot -- A CFFI based interface to the PLplot scientific plotting library

[Luca Capello]

Hi Philipp!

On Mon, 19 Nov 2007 16:26:26 +0100, Philipp Benner wrote:
> * Package name: cl-plplot
>   Version : 0.4.0
>   Upstream Author : Hazen Babcoc <[EMAIL PROTECTED]>
> * URL : http://common-lisp.net/project/cl-plplot/

Are you going to maintain the package under the CL-Debian umbrella [1]?

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://cl-debian.alioth.debian.org



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#359348: cl-rfc2109: requesting comments

[Luca Capello]

Hello all!

Please Cc: me, I'm not subscribed to the list.  Moreover, please keep at
least the bug entry cc:ed, so people don't need to search in other
locations.

I need some legal advices about one of my packages, rfc2109 [1][2].

The main problem is that rfc2109.lisp contains verbatim parts of
RFC2109, RFC2068 and the Netscape cookie spec, documents that are not
free per the DFSG.  When I removed them [2], I forgot the parts in the
function descriptions, thus the package was rejected.

Soon after the rejection, upstream committed a sed script [3] to easily
remove the same RFC parts I removed (thus not the ones in the function
descriptions).  I find upstream solution (which replaces the RFC parts
with empty lines) better than mine because it doesn't change line
numbers and avoids conflicts when pulling from upstream.  The latter,
however, means that every time I pull from upstream, I need to re-apply
the sed script (just a minor annoyance).

However as already written, upstream solution, as mine, suffers the RFC
parts in the function descriptions.  Back in October 2006, Pierre
Thierry asked if these parts could be allowed even if not-free [4], but
no one answered him.  Since I'm not a license nor an RFC expert, here I
am :-)

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=359348
[2] http://cl-debian.alioth.debian.org/repository/lcapello/
[2] Thu Jul 20 23:04:07 CEST 2006  Luca Capello <[EMAIL PROTECTED]>
  * remove the non-DFSG documents from rfc2109.lisp
20060720210407-f6b0c-b84ff59374546e09173fadd6ec1b249db30b6fd2.gz
[3] Wed Aug  9 21:58:18 CEST 2006  Alan Shields <[EMAIL PROTECTED]>
  * easily strip RFC from rfc2109 for copyright concerns
20060809195818-df180-565dcf76a4cfffa29341ff033cbe3bb4362ab878.gz
[4] http://common-lisp.net/pipermail/cl-debian/2006-October/001957.html



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#446971: ITP: zpb-exif -- Common Lisp package to access EXIF metadata

[Luca Capello]

Hi Pierre!

Could you also X-Debbugs-CC: the CL-Debian mailing list [1] the
next ITP about CL software, please?

On Wed, 17 Oct 2007 03:32:31 +0200, Pierre THIERRY wrote:
> * Package name: zpb-exif
[...]
> EXIF is a standard for embedding information in an image file
> created by a digital camera. ZPB-EXIF is a library that makes Exif
> data accessible to Common Lisp programs.

I'd call the binary cl-zpb-exit, similar to S-XML [2], since as far as
I understand it it's not intended to be used stand-alone.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://cl-debian.alioth.debian.org
[2] http://packages.qa.debian.org/s/s-xml.html



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#442194: ThinkFinger already in experimental (was Re: RFP: thinkfinger -- SGS Thompson Microelectronics fingerprint reader utilities)

[Luca Capello]

forcemerge 409563 442194
thanks

Hello!

On Fri, 14 Sep 2007 02:37:52 +0200, Todd Troxell wrote:
> Package: wnpp
> Severity: wishlist
>
> * Package name: thinkfinger

The package had an ITP [1] already closed when you reported the RFP,
thus merging the two bugs.

On Sat, 15 Sep 2007 11:03:22 +0200, Thomas Huriaux wrote:
> #package found in experimental
> tag 442194 fixed-in-experimental

Thomas, my advice is to always notify at least the maintainer, even if
I'd go also for the submitter.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409563



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#436106: ITP: cl-ltk -- A Common Lisp binding to the Tk toolkit

[Luca Capello]

Hello!

On Sun, 05 Aug 2007 15:56:56 +0200, Oleg Belozeorov wrote:
> * Package name: cl-ltk
>   Version : 0.90
>   Upstream Author : Peter Herth <[EMAIL PROTECTED]> 
> * URL : http://www.peter-herth.de/ltk
> * License : LLGPL
>   Programming Lang: Common Lisp
>   Description : A Common Lisp binding to the Tk toolkit

Do you plan to add it under the CL-Debian umbrella [1]?

BTW, this doesn't mean that the package will be group-maintained, but
just that you follow the Debian CL guidelines at [2].

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://cl-debian.alioth.debian.org
[2] http://cl-debian.alioth.debian.org/clid/clid.html/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#409563: current state of thinkfinger-ITP?

[Luca Capello]

Hello!

On Sun, 29 Jul 2007 16:09:16 +0200, Micha Lenk wrote:
> Michael Prokop wrote:
>> any news from the ITP/packaging of thinkfinger? Do you need help
>> and/or some testing?
>
> I would be interested too... anything new?

The package is sitting in NEW and it's targeted at experimental [1].
I'll probably prepare an etch backport as soon as it enters Debian.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] 
http://lists.alioth.debian.org/pipermail/fingerforce-devel/2007-May/01.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#433812: ITP: pssh -- Parallel versions of the OpenSSH tools

[Luca Capello]

Hello!

On Thu, 19 Jul 2007 18:02:02 +0200, Andrew Pollock wrote:
> * Package name: pssh
[...]
>  Parallel scp (pscp)

FYI (and if you don't already know) /usr/bin/pscp is also provided by
putty-tools.

Thx, bye,
Gismo / Luca


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#409563: ITP: thinkfinger -- library and utility for the SGS Thomson Microelectronics fingerprint reader

[Luca Capello]

Hello!

This is for bug readers and d-d's information.

On Thu, 08 Feb 2007 14:24:55 +0100, Rafael Laboissiere wrote:
> * Luca Capello <[EMAIL PROTECTED]> [2007-02-08 12:04]:
>
>> On Thu, 08 Feb 2007 01:38:42 +0100, Guillem Jover wrote:
>> > Please do not include it in the lib package, it's a pain afterwards
>> > when a new version with a different soname is introduced and
>> > disallows parallel installation of those.
>> 
>> With my non-yet-skilled-library packager hat on, I don't see why one
>> should want to install an old binary version with the new library
>> one, as both are coming from the same source, thus the same version
>> number.
>
> I am not sure I understand your rebuttal above,

I was mostly focusing on:

- libthinkfinger0 is installed with tf-tool v0

- libhtinkfinger1 comes out and it contains tf-tool v1

Upgrading to libthinkfinger1 necessarily means that tf-tool v1 needs
to be upgraded as well (because they come from the same source and
version).

> but I think Guillem was referring to a scenario similar to the
> following:
>
> Package bar has Depends: libfoo0.  Let us say that the developers of
> libfoo release a new version with the SOVERSION bumped.  In Debian,
> the package will be called, say, libfoo1.  New packages, like
> e.g. baz, will depend on libfoo1.  Now, if bar is a legacy program
> and does not compile against libfoo1 (since backward
> incompatibilites may have been introduced), then it has to keep its
> dependency on libfoo0.

OK, now reading again Guillem's reply I clearly see the problem.
Mostly, I didn't see any other use for the fingerprint reader than
authenticating someone.  However, from [1] I can see that there're
already fingerprint projects other than authentication, e.g. a SANE
backend.

> If, by an error in design, libfoo1 and libfoo0 conflict with each
> other (e.g. by having both a binary /usr/bin/foo-tool), then it will
> be impossible to have both bar and baz installed in the system.
> That is the pain Guillem was referring to.

Full ACK, I agree that we need separate packages.

Thank to both for the explanation!

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://wiki.debian.org/FingerForce


pgpsD1TdRWMbd.pgp
Description: PGP signature

Bug#409563: ITP: thinkfinger -- library and utility for the SGS Thomson Microelectronics fingerprint reader

[Luca Capello]

Hello!

Please keep d-d in the cc: header.

On Thu, 08 Feb 2007 09:28:33 +0100, Marcus Better wrote:
>> libpam-thinkfinger (depends on libthinkfinger0)
>> libthinkfinger0
>> libthinkfinger-dev
>> thinkfinger (depends on libpam-thinkfinger)
>
> (What is the thinkfinger package for, if the tool is in the library
> package?)

Joshua and I are working together in the package, but I'm a bit busy
until the end of the week, thus we haven't finished yet the planning.
Please be patient.

> I really think the binary should not go in the library package, see
[...]
> But I don't have much experience with library packaging. Why not ask
> debian-mentors?

I think d-d is a better place than d-mentors in this specific case.
Anyway, it seems that what I was proposing was really a bad thing.

> About the short description: Perhaps the manufacturer can be dropped
> entirely.  Most users don't know or care about the manufacturer, but
> they know they have a Thinkpad:
>
> "thinkfinger -- driver for the fingerprint reader found on some
> Thinkpad laptops"

No, this fingerprint reader is present in some ThinkPad, but not only
ThinkPad [1].  What's really specific here is the manufacturer, as
it's what you can find in /proc/bus/usb/devices [2].

Now it's just a question of patience ;-)

Thx, bye,
Gismo / Luca

Footnotes: 
[1] it was discussed upstream if changing the name would have been
indeed necessary, but we ended up liking this name and not so
biased about ThinkPad ;-)
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409563;msg=53;archive=yes


pgp4SSlEmBALh.pgp
Description: PGP signature

Bug#409563: ITP: thinkfinger -- library and utility for the SGS Thomson Microelectronics fingerprint reader

[Luca Capello]

Hello!

On Thu, 08 Feb 2007 01:38:42 +0100, Guillem Jover wrote:
> Please do not include it in the lib package, it's a pain afterwards
> when a new version with a different soname is introduced and
> disallows parallel installation of those.

With my non-yet-skilled-library packager hat on, I don't see why one
should want to install an old binary version with the new library
one, as both are coming from the same source, thus the same version
number.

> (This will also be a problem for multi-arch).

I should admit that I don't know anything about multi-arch, but I
think I got your point.

So, once for all, tf-tool will be in thinkfinger-tools :-)

Thx, bye,
Gismo / Luca


pgpzl4zXK15r1.pgp
Description: PGP signature

Bug#409563: ITP: thinkfinger -- library and utility for the SGS Thomson Microelectronics fingerprint reader

[Luca Capello]

Hello!

On Thu, 08 Feb 2007 10:38:08 +0100, Jon Dowland wrote:
> Luca Capello wrote:
>> ATM I don't really see any reason to create a separate package just
>> for tf-tool, because libthinkfinger + tf-tool (binary and manpage)
>> should generate a package around less than 50K in size.  In case
>> new tools will be added, we can split the package.
>>
>> Is a strong reason against this?
>
> Can I reverse the question and ask why *not* a separate binary
> package? Is it just to the additional difficulty with initial
> packaging?

FWIW, there's on difficulty in packagin ThinkFinger.

I was wondering if having two packages with only one or two files [1]
was worth it, because in this case we have 4 times [2] the same
changelog.gz, changelog.Debian.gz, copyright and README.

As I already said, however, there're going to be two separated
packages.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] one in libthinkfinger0, two in thinkfinger-tools (binary and manpage)
[2] libthinkfinger0, libthinfinger-dev, libpam-thinkfinger,
thinfinger-tools 


pgpX3J0iQo8gE.pgp
Description: PGP signature

Bug#409563: ITP: thinkfinger -- library and utility for the SGS Thomson Microelectronics fingerprint reader

[Luca Capello]

Hello!

On Thu, 08 Feb 2007 00:13:02 +0100, James Westby wrote:
> On (07/02/07 23:39), Luca Capello wrote:
>>>> [2] I still have a problem, because e.g. "PAM module for the SGS
>>>> Thomson Microelectronics fingerprint reader" is longer than
>>>> the expected 60 characters for the short description.
>>>> Suggestions welcome!
>>>
>>> Perhaps you can drop the word "Microelectronics" from the short
>>> description.
>> 
>> Yes, this was my choice after Rafael Laboissiere privately
>> suggested.
>
> Is it really manufactured by SGS Thompson? Is it not from ST
> Microelectronics? I didn't think the SGS Thompson name was used any
> more, even if it still exists.

From Wikipedia [1]

  The ST group was formed in June 1987 from the merger of two
  semiconductor companies Società Generale Semiconduttori (SGS)
  Microelettronica of Italy and Thomson Semiconducteurs, the
  semiconductor arm of France's Thomson. In May 1998, the company
  changed its name from SGS-THOMSON to STMicroelectronics following
  the withdrawal of Thomson SA.

While it seems that the driver is manufactured by UPEK [2], indeed on
my X60 with BIOS 2.05 and Debian kernel 2.6.18-4-amd64 I've:
=
[EMAIL PROTECTED]:~$ cat /proc/bus/usb/devices
[...]

T:  Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 13 Spd=12  MxCh= 0
D:  Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0483 ProdID=2016 Rev= 0.01
S:  Manufacturer=STMicroelectronics
S:  Product=Biometric Coprocessor
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=83(I) Atr=03(Int.) MxPS=   4 Ivl=20ms

[...]
[EMAIL PROTECTED]:~$ 
=

So, it seems the best name would be STMicroelectronics, I'll bring
this up to upstream ;-)

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://en.wikipedia.org/wiki/STMicroelectronics
[2] http://www.thinkwiki.org/wiki/Integrated_Fingerprint_Reader


pgpfsuCwDSFiK.pgp
Description: PGP signature

Bug#409563: ITP: thinkfinger -- library and utility for the SGS Thomson Microelectronics fingerprint reader

[Luca Capello]

Hello!

I'm adding again the bug report, please keep it cc:ed.

On Thu, 08 Feb 2007 00:28:24 +0100, Evgeni Golov wrote:
> On Wed, 07 Feb 2007 23:39:39 +0100 Luca Capello wrote:
>
>> ATM I don't really see any reason to create a separate package just
>> for tf-tool, because libthinkfinger + tf-tool (binary and manpage)
>> should generate a package around less than 50K in size.  In case new
>> tools will be added, we can split the package.
>> 
>> Is a strong reason against this?
>
> Is tf-tool to be used by the user directly? If so, I would place it
> in an own package. If it's only a binary used in scripts/whatever -
> ship it in lib*.

tf-tool requires root privileges because it needs to access the USB
device.  Moreover, practically speaking as a normal user you couldn't
do anything more than acquire/verify your fingerprint, but stored in
/tmp/test.bir.  As root, however, you can automatically acquire a
fingerprint for a login user (because it stores the fingerprint in
/etc/pam_thinkfinger/).

This is another reason I'd go for libthinkfinger only.

> The point is, the user might want to read something about the tool he
> is using. There is a manpage and /usr/share/doc//, the last
> one would be ugly for libthinkfinger, because user would expect
> packagename==binaryname.
> Hope you understand what I mean ;)

I understand, but packagename==binaryname is already not respected and
it'll be the case with the package name proposed by Marcus,
i.e. thinkfinger-tools.

Moreover, the presence of tf-tool in libthinkfinger will be advised in
the package description and if necessary in README.Debian, but I'm
against that (take xbase-clients as an example...).

> By the way, are there any prerelease packags for testing? This
> UPEK-blob gets on my nerves ;)

The package is still in preparation, Joshua and I are working in a
co-maintenance.  I'll privately drop you a mail as soon as the package
is ready.

Thx, bye,
Gismo / Luca


pgpx0O6X4sRUp.pgp
Description: PGP signature

Bug#409563: ITP: thinkfinger -- library and utility for the SGS Thomson Microelectronics fingerprint reader

[Luca Capello]

Hello!

I'm cc:ing Joshua Rubin (the ThinkFinger co-maintinaer) and d-d to
have more comments.

On Wed, 07 Feb 2007 12:24:29 +0100, Marcus Better wrote:
> Luca Capello wrote:
>> Am I correct?  Is tf-tool worth a single package or can I include
>> it in libthinkfinger (as I'd prefer)?
>
> I think it's common practice to put the tools in a separate package,
> and suggest the name thinkfinger-tools instead of tf-tool, since
> it's easier for the user to identify what the package is for, and
> since other tools may be added in the future.

I'm aware of the common practice and this is the reason why I
specifically asked for an advice.

ATM I don't really see any reason to create a separate package just
for tf-tool, because libthinkfinger + tf-tool (binary and manpage)
should generate a package around less than 50K in size.  In case new
tools will be added, we can split the package.

Is a strong reason against this?

BTW, thanks for your suggestion about the package name,
thinkfinger-tools would be definitively better.

>> [2] I still have a problem, because e.g. "PAM module for the SGS
>> Thomson Microelectronics fingerprint reader" is longer than the
>> expected 60 characters for the short description.  Suggestions
>> welcome!
>
> Perhaps you can drop the word "Microelectronics" from the short
> description.

Yes, this was my choice after Rafael Laboissiere privately suggested.

Thx, bye,
Gismo / Luca


pgpJjSO7I6jJd.pgp
Description: PGP signature

Bug#409563: ITP: thinkfinger -- library and utility for the SGS Thomson Microelectronics fingerprint reader

[Luca Capello]

Hello!

On Sun, 04 Feb 2007 07:34:03 +0100, Joshua Rubin wrote:
> I have already begun packaging this. I realize that this bug report
> is an ITP, so I don't want to step on your toes.

Please read below.

> I have already emailed my package to your thinkfinger-devel on your
> sourceforge project.

Apart from the fact that ThinkFinger isn't my project, I haven't see
your mail yet on the mailing-list.  Are you subscribed to the list or
are you waiting for moderator's approval?

BTW, a small advice for your next package: as soon as you realize that
you want to package something, please file an ITP, thus other people
interested in the package can check the WNPP page before [1] ;-)

> I just wanted to let you know that I would be happy to help in any
> way I can.

Again, please read below.

> Since I am not a Debian developer and you are, perhaps you could
> sponsor this package since I would like to begin the process of
> becoming a Debian developer?

I'm not a Debian developer yet [2], so I need a sponsor, too.

Now, either we maintain it as a team or I could step back :-D

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://bugs.debian.org/wnpp
[2] https://nm.debian.org/nmstatus.php?email=luca%40pca.it


pgp9xnEuPk3MK.pgp
Description: PGP signature

Bug#409563: ITP: thinkfinger -- library and utility for the SGS Thomson Microelectronics fingerprint reader

[Luca Capello]

Package: wnpp
Owner: Luca Capello <[EMAIL PROTECTED]>
Severity: wishlist

* Package name: thinkfinger
  Version : 0.2.2 [1]
  Upstream Author : Timo Hoenig <[EMAIL PROTECTED]>, Pavel Machek <[EMAIL 
PROTECTED]>
* URL or Web page : http://thinkfinger.sourceforge.net
* License : GPL
  Description : $PACKAGE for the SGS Thomson Microelectronics fingerprint 
reader

ThinkFinger is a driver for the UPEK/SGS Thomson Microelectronics
fingerprint reader.  The device is being found either as a standalone
USB device, built into USB keyboards or built into laptops (usually
From Dell, IBM/Lenovo and Toshiba).

Here it will be the second part of the long description, read below.
Moreover, $PACKAGE in the short description will reflect the package
contents [2].

ThinkFinger is devided into two parts: libthinkfinger and
pam_thinkfinger.  libthinkfinger is a library to be used in order to
communicate with the fingerprint reader.  The utility 'tf-tool' can be
used to acquire and to verify fingerprints.

Now, I don't really know the best way to package ThinkFinger.  In
theory, I guess we should have (file size in bytes, not stripped):

- libthinkfinger, depends on libusb
/usr/lib/libthinkfinger.so (31751)

- libthinkfinger-dev
/usr/include/libthinkfinger.h (4732)
/usr/lib/libthinkfinger.a (40484)
/usr/lib/libthinkfinger.la (876)
/usr/lib/pkgconfig/libthinkfinger.pc (324)

- tf-tool, depends on libthinkfinger
/usr/sbin/tf-tool (23152)
/usr/share/man/man1/tf-tool.1.gz (1052)

- libpam-thinkfinger, depends on libthinkfinger [3]
/etc/pam_thinkfinger/ [where the login fingerprint are stored]
/lib/security/pam_thinkfinger.so (27724)
/usr/share/man/man8/pam_thinkfinger.8.gz (782)

Am I correct?  Is tf-tool worth a single package or can I include it
in libthinkfinger (as I'd prefer)?

Thx, bye,
Gismo / Luca

Footnotes: 
[1] the package version will be greater than 0.2.2, because I'll wait
for the inclusion of the manpages as of 
  http://thread.gmane.org/gmane.linux.drivers.thinkfinger/111
[2] I still have a problem, because e.g. "PAM module for the SGS
Thomson Microelectronics fingerprint reader" is longer than the
expected 60 characters for the short description.  Suggestions
welcome!
[3] strictly speaking, the PAM module doesn't depend on tf-tool,
because it uses libthinkfinger to access the fingerprint reader.
However, it should recommends tf-tool because the latter is
necessary to acquire the fingerprint for a login user


pgppg5vPawcUY.pgp
Description: PGP signature

Bug#407273: ITP: lhapdf -- Les Houches Accord PDF Interface

[Luca Capello]

Hello!

Please the next time use the X-Debbugs-CC: header [1] instead of
directly writing to d-d so the ITP will be sent to debian-devel only
after a number has been assigned to the bug (and if any one wants to
answer to the bug, he doesn't need to search for the correct bug
number).

On Wed, 17 Jan 2007 11:07:51 +0100, Gürkan Sengün wrote:
> * Package name: lhapdf
[...]
> * URL : http://projects.hepforge.org/lhapdf/

There's a problem with the upstream URL, tested on two machines with
different Internet connections:
=
Forbidden

You don't have permission to access /lhapdf on this server.

Additionally, a 403 Forbidden error was encountered while trying to
use an ErrorDocument to handle the request.
=

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://www.debian.org/Bugs/Reporting, section "Sending copies of
bug reports to other addresses"


pgpZ26OlhPlqX.pgp
Description: PGP signature

Bug#399739: [cl-debian] Bug#399739: ITP: cl-elephant -- object database for Common Lisp

[Luca Capello]

Hello!

As most of the replies should be CL-specific, I set M-F-T and R-T to
the bug submitter, the BTS and the CL-Debian mailing list.

On Tue, 21 Nov 2006 18:42:58 +0100, Pierre THIERRY wrote:
>   Description : object database for Common Lisp
[...]
>   See 

As per the Developer Reference §6.2.4 [1], this should be:

-   See 
+Homepage: http://common-lisp.net/project/elephant/


BTW, are you going to maintain it under the CL-Debian umbrella [2]?
If yes, please contact Peter Van Eynde, René van Bevern or myself in
order to be added to the Alioth group ;-)

Thx, bye,
Gismo / Luca

Footnotes: 
[1] 
http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-upstream-info
[2] http://cl-debian.alioth.debian.org


pgp744Lv0seVT.pgp
Description: PGP signature

Bug#394163: [cl-debian] Bug#394163: ITP: cl-hunchentoot -- The Common Lisp web server formerly known as TBNL

[Luca Capello]

Hello!

On Thu, 19 Oct 2006 20:15:08 +0200, Peter Van Eynde wrote:
> * Package name: cl-hunchentoot
[...]
>  you like, e.g. (shameless self-plug) CL-WHO or HTML-TEMPLATE.
>  .
>  Homepage: http://weitz.de/hunchentoot/

As per the Developer Reference §6.2.4 [1], you should leave an empty
space before starting the line.

This applies also to #394223 [2], #394171 [3] and #394161 [4].

Thx, bye,
Gismo / Luca

Footnotes: 
[1] 
http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-upstream-info
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394223
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394171
[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394161


pgpZVgzSfVTmh.pgp
Description: PGP signature

Bug#359348: Status of cl-rfc2109

[Luca Capello]

Hello,

a small report about the status of this ITP.

The upstream package contains some part of the RFC2109 into the source
code and this is the main reason this ITP hasn't been closed yet.

Upstream submitted a patch to easily strip the RFC parts [1], but
after applying the sed script [2], there are still RFC bits in some
function descriptions.

As soon as this last problem will be solved, the package will be
uploaded (but obviously this won't be for etch).

Thx, bye,
Gismo / Luca

Footnotes: 
[1] Wed Aug  9 21:58:18 CEST 2006  Alan Shields <[EMAIL PROTECTED]>
  * easily strip RFC from rfc2109 for copyright concerns

[2] $ sed -f stripdoc.sed > rfc2109.lisp_stripped


pgpFh8mZ7ShW8.pgp
Description: PGP signature

Bug#392122: ITP: php-suhosin -- Suhosin is an advanced protection system for PHP installations.

[Luca Capello]

Hello!

On Tue, 10 Oct 2006 14:57:38 +0200, Jan Wagner wrote:
> * Package name: php-suhosin
>   Version : 0.9.6

There's already ITP #392119 [1] (cc:ing its submitter), I guess the
two should be merged.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392119


pgptEUekzX8Tp.pgp
Description: PGP signature

Bug#350464: ITP: picard -- album-based MusicBrainz tagger

[Luca Capello]

Hello!

On Sun, 29 Jan 2006 20:47:07 +0100, Decklin Foster wrote:
> Owner: Decklin Foster <[EMAIL PROTECTED]>
>
> * Package name: picard

Any news for this package?

It was blocked by bug #340122 [1], which is now closed.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=yes&bug=340122


pgpwejQRm1ApM.pgp
Description: PGP signature

Bug#359348: ITP: cl-rfc2109 -- a cookie library for Common Lisp based on RFC 2109

[Luca Capello]

Hello!

On Mon, 27 Mar 2006 17:18:50 -0500, Luca Capello wrote:
> * Package name: cl-rfc2109
>   Version : 0.3
[...]
> A darcs repository with minor changes not yet included upstream is
> available at [4].
[...]
> [4] http://cl-debian.alioth.debian.org/repository/lcapello/rfc2109-gismo

Since I got no answer from the upstream author about the minor
changes, I included them in the Debian package as dpatches (and add a
note in the README.Debian file as well).

The package is lintian- and linda-clean, build on pbuilder and it's
available on the CL-Debian darcs repository on alioth.

BTW, the version changed: actually, upstream tagged version 0.3.2, but
then two other darcs commits were applied, to I decided to use the
darcs checkout date as version (like similar packages like cl-arnesi
or cl-s-xml).

Thx, bye,
Gismo / Luca


pgpERGhzhHZM6.pgp
Description: PGP signature

Bug#359339: ITP: cl-trivial-sockets -- a Common Lisp socket interface

[Luca Capello]

Hello!

On Tue, 28 Mar 2006 00:22:16 +0200, Luca Capello wrote:
> * Package name: cl-trivial-sockets
>   Version : 0.3
[...]
> As the upstream author is a Debian maintainer, I've tried to contact
> him before this ITP, but without any success.  I cc:ed him and I'll
> wait a month before asking for my sponsor to uploading the package.

I discussed with the upstream author and we agreed that I'll be the
Debian maintainer.

The package is ready to be uploaded, linda and lintian clean.  It can
be found in the CL-Debian darcs repository [1].

Peter, can you upload it when you find some spare time, please?

Thx, bye,
Gismo / Luca

[1] 
http://cl-debian.alioth.debian.org/cgi-bin/darcsweb.cgi?r=trivial-sockets;a=summary


pgpEH8j5aD1Aa.pgp
Description: PGP signature

Bug#359348: ITP: cl-rfc2109 -- a cookie library for Common Lisp based on RFC 2109

[Luca Capello]

Package: wnpp
Severity: wishlist

* Package name: cl-rfc2109
  Version : 0.3
  Upstream Author : Alan Shields <[EMAIL PROTECTED]>
* URL or Web page : http://common-lisp.net/project/rfc2109/
* License : BSD
  Description : a cookie library for Common Lisp based on RFC 2109
 rfc2109 implements the original cookie specification as defined by
 the RFC 2109 document.
 .
 It can be used to generate (and eventually parse) cookies in an
 RFC-compliant way.
 .
 The recommended package adds extra features: test suite with
 cl-fiveam.

=

This is necessary as dependency for UCW [1].  The package will be
included in the CL-Debian repository [2] and will follow the "Common
Lisp in Debian Manual" [3].

A darcs repository with minor changes not yet included upstream is
available at [4].

Thx, bye,
Gismo / Luca

[1] http://common-lisp.net/project/ucw/
[2] http://cl-debian.alioth.debian.org/cgi-bin/darcsweb.cgi
[3] http://cl-debian.alioth.debian.org/clid/clid.html/
[4] http://cl-debian.alioth.debian.org/repository/lcapello/rfc2109-gismo


pgpjjaj1c8wlk.pgp
Description: PGP signature

Bug#359339: ITP: cl-trivial-sockets -- a Common Lisp socket interface

[Luca Capello]

Package: wnpp
Severity: wishlist

* Package name: cl-trivial-sockets
  Version : 0.3
  Upstream Author : Daniel Barlow <[EMAIL PROTECTED]>
* URL or Web page : http://www.cliki.net/trivial-sockets
* License : see below
  Description : a Common Lisp socket interface
 trivial-sockets is a portable socket interface that allows Common
 Lisp programs to open connected (client) stream sockets to network
 service (for example HTTP, FTP or SMTP servers) and communicate with
 them.  It's intended mostly for "scripting" and interactive use.
 .  
 Note that in the interests of simplicity and ease of porting, the
 functionality available through TRIVIAL-SOCKETS has been deliberately
 restricted.



Here is the license:
 Copyright (c) 2004 Daniel Barlow and contributors

 Permission is hereby granted, free of charge, to any person obtaining
 a copy of this software and associated documentation files (the
 ``Software''), to deal in the Software without restriction, including
 without limitation the rights to use, copy, modify, merge, publish,
 distribute, sublicense, and/or sell copies of the Software, and to
 permit persons to whom the Software is furnished to do so, subject to
 the following conditions:

 The above copyright notice and this permission notice shall be
 included in all copies or substantial portions of the Software.

 THE SOFTWARE IS PROVIDED ``AS IS'', WITHOUT WARRANTY OF ANY KIND,
 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
 NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
 BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
 ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
 CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.

=

As the upstream author is a Debian maintainer, I've tried to contact
him before this ITP, but without any success.  I cc:ed him and I'll
wait a month before asking for my sponsor to uploading the package.

This is necessary as dependency for UCW [1].  The package will be
included in the CL-Debian repository [2] and will follow the "Common
Lisp in Debian Manual" [3].

Thx, bye,
Gismo / Luca

[1] http://common-lisp.net/project/ucw/
[2] http://cl-debian.alioth.debian.org/cgi-bin/darcsweb.cgi
[3] http://cl-debian.alioth.debian.org/clid/clid.html/


pgp3LyaMzw0RS.pgp
Description: PGP signature

Bug#349607: ITP: cl-parenscript -- JavaScript embedded in a Common Lisp host

[Luca Capello]

Hello!

On Sun, 26 Feb 2006 23:28:01 +0100, Luca Capello wrote:
> On Tue, 24 Jan 2006 00:54:30 +0100, Luca Capello wrote:
>> * Package name: cl-parenscript
[...]
> Now it's ok, lintian and linda clean and it's available in the
> CL-Debian repository [1].
>
> Peter, can you upload it, if it's OK for you?

Peter, any news on this?

Thx, bye,
Gismo / Luca


pgptRbmwrczCn.pgp
Description: PGP signature

Bug#349607: ITP: cl-parenscript -- JavaScript embedded in a Common Lisp host

[Luca Capello]

Hello!

On Tue, 24 Jan 2006 00:54:30 +0100, Luca Capello wrote:
> * Package name: cl-parenscript
[...]
> The package will be sit in the CL-Debian repository [2] and will
> follow the "Common Lisp in Debian Manual" [3].  I'm resolving some
> minor problems concerning the documentation, so it'll be ready in a
> couple of days.

I'm sorry for the late, but I needed to have some patches accepted
before finishing the packaging.

Now it's ok, lintian and linda clean and it's available in the
CL-Debian repository [1].

Peter, can you upload it, if it's OK for you?

Thx, bye,
Gismo / Luca

[1] http://cl-debian.alioth.debian.org/repository/lcapello/parenscript/


pgpvnrj8kEMCv.pgp
Description: PGP signature

Bug#352064: ITP: wormux -- A clone of the Worms game

[Luca Capello]

Hello!

On Thu, 09 Feb 2006 15:39:29 +0100, Moritz Muehlenhoff wrote:
> Previous versions of Wormux depended on a development version of clanlib,
> that's why a previous ITP never made it into a real package and was later
> closed due to inactivity.

So, simple question: why not re-open the ancient ITP, instead of a new
one? ;-)

Thx, bye,
Gismo / Luca


pgpwBwls1o12s.pgp
Description: PGP signature

Bug#350909: ITP: ekiga -- A VoIP softphone

[Luca Capello]

Hello!

On Wed, 01 Feb 2006 16:59:08 +0100, Santiago José Ruano Rincón wrote:
>
> * Package name: ekiga
>   Version : 1.99.0
>   Upstream Author : Damien Sandras  <[EMAIL PROTECTED]>
> * URL : http://www.ekiga.org/
> * License : GPL
>   Description : A VoIP softphone
>
>  Ekiga is a softphone with full support for SIP and H.323.

Some questions:

1) this is Gnomemeeting renamed, so have you asked to the Gnomemeeting
   maintainer (Jose Carlos Garcia Sogo <[EMAIL PROTECTED]>) if he would
   like to package it?

2) will the package be based on the unofficial Debian (but official
   Ekiga) snapshot available at [1]?

Thx, bye,
Gismo / Luca

[1] http://snapshots.gnomemeeting.net


pgpzmtASTjn0X.pgp
Description: PGP signature

Bug#349607: ITP: cl-parenscript -- JavaScript embedded in a Common Lisp host

[Luca Capello]

Package: wnpp
Severity: wishlist

* Package name: cl-parenscript
  Version : 1:20060122-1
  Upstream Author : Manuel Odendahl <[EMAIL PROTECTED]>
Edward Marco Baringer <[EMAIL PROTECTED]>
* URL or Web page : http://common-lisp.net/project/ucw/repos/parenscript
* License : BSD
  Description : JavaScript embedded in a Common Lisp host

 Parenscript is a small lispy language that can be compiled to
 JavaScript.
 .
 It also comes with an embedded CSS representation in Common Lisp.
 This simplifies the development of web applications in Common Lisp
 by allowing the Common Lisp programmer to write all the documents
 in Common Lisp syntax.
 .
 HTML pages, CSS files and JavaScript code can be generated with
 the full power of Common Lisp and its macros.

=

This is necessary as dependency for UCW [1].

The package will be sit in the CL-Debian repository [2] and will
follow the "Common Lisp in Debian Manual" [3].  I'm resolving some
minor problems concerning the documentation, so it'll be ready in a
couple of days.

Thx, bye,
Gismo / Luca

[1] http://common-lisp.net/project/ucw/
[2] http://cl-debian.alioth.debian.org/cgi-bin/darcsweb.cgi
[3] http://cl-debian.alioth.debian.org/clid/clid.html/


pgpQUg7hdlwAn.pgp
Description: PGP signature

Bug#337666: ITP: cl-qbook -- create HTML/LaTeX versions of Common Lisp source code

[Luca Capello]

Package: wnpp
Severity: wishlist

* Package name: cl-qbook
  Version : 1:20051105-1
  Upstream Author : Edward Marco Baringer <[EMAIL PROTECTED]>
* URL or Web page : http://common-lisp.net/project/bese/qbook.html
* License : BSD
  Description : create HTML/LaTeX versions of Common Lisp source code

 qbook is a Common Lisp tool to create HTML/LaTeX versions of
 source code.
 .
 Features:
  * Very simple (easy to learn and use).
  * It can produce HTML or LaTeX.

=

Continuation of the series of CL software started with bug #337646.

As soon as this bug will get a number by the BTS, I'll add the package
to the CL-Debian repository [1]. The package is linda and lintian
free and it follows the "Common Lisp in Debian Manual" [2].

Thx, bye,
Gismo / Luca

[1] http://cl-debian.alioth.debian.org/cgi-bin/darcsweb.cgi
[2] http://cl-debian.alioth.debian.org/clid/clid.html/


pgprYDt8TKVCh.pgp
Description: PGP signature

Bug#337662: ITP: cl-yaclml -- Yet Another Common Lisp Markup Language

[Luca Capello]

Package: wnpp
Severity: wishlist

* Package name: cl-yaclml
  Version : 1:20051105-1
  Upstream Author : Edward Marco Baringer <[EMAIL PROTECTED]>
* URL or Web page : http://common-lisp.net/project/bese/yaclml.html
* License : BSD
  Description : Yet Another Common Lisp Markup Language

 YACLML is a collection of macros and utilities for generating
 XML/HTML like markup from lisp code.
 .
 Features:
  * Constant folds as much as possible.
  * Macros for generating HTML from within lisp code.
  * Templating system for generating HTML from designer templates.
 .
 The recommended packages add documentation via cl-qbook or a test
 suite with cl-fiveam.

=

Continuation of the series of CL software started with bug #337646.

As soon as this bug will get a number by the BTS, I'll add the package
to the CL-Debian repository [1]. The package is linda and lintian
free and it follows the "Common Lisp in Debian Manual" [2].

Thx, bye,
Gismo / Luca

[1] http://cl-debian.alioth.debian.org/cgi-bin/darcsweb.cgi
[2] http://cl-debian.alioth.debian.org/clid/clid.html/


pgpiYjyQ65cmD.pgp
Description: PGP signature

Bug#337657: ITP: cl-fiveam -- simple regression testing framework

[Luca Capello]

Package: wnpp
Severity: wishlist

* Package name: cl-fiveam
  Version : 1:20051105-1
  Upstream Author : Edward Marco Baringer <[EMAIL PROTECTED]>
* URL or Web page : http://common-lisp.net/project/bese/FiveAM.html
* License : BSD
  Description : simple regression testing framework

 FiveAM is a simple (as far as writing and running tests goes)
 regression testing framework. It has been designed with Common
 Lisp's interactive development model in mind.
 .
 Features:
  * Test and test suite hierarchies allow test to be organized into
hierarchies to ease running
  * Functions for re-running recently run tests.
  * Inter-test dependencies.
 .
 The documentation is provided via the cl-qbook package.

=

Continuation of the series of CL software started with bug #337646.

As soon as this bug will get a number by the BTS, I'll add the package
to the CL-Debian repository [1]. The package is linda and lintian
free and it follows the "Common Lisp in Debian Manual" [2].

Thx, bye,
Gismo / Luca

[1] http://cl-debian.alioth.debian.org/cgi-bin/darcsweb.cgi
[2] http://cl-debian.alioth.debian.org/clid/clid.html/


pgpSwX0OpNm3k.pgp
Description: PGP signature

Bug#337646: ITP: cl-arnesi -- small Common Lisp utilities

[Luca Capello]

Package: wnpp
Severity: wishlist

* Package name: cl-arnesi
  Version : 1:20051105-1
  Upstream Author : Edward Marco Baringer <[EMAIL PROTECTED]>
* URL or Web page : http://common-lisp.net/project/bese/arnesi.html
* License : BSD
  Description : small Common Lisp utilities

 arnesi is a Common Lisp utility suite. It contains various "bits 'n
 pieces" of code.
 .
 Features:
  * Flow control macros - while, whichever, if-bind, etc.
  * A simple logging facility - kind-of/sort-of/maybe like log4j.
  * HTTP/HTML utilities - URL and HTML escaping
  * Pattern matching - fare-matcher style pattern matcher and "regular"
list matcher
  * Accumulation - collecting and reducing macros
  * Cps transformer - an ad-hoc, bug ridden implementation of half of
call/cc.
  * Decimal arithmetic - convert floats to exact rationals and vice
versa with a given precision; standard rounding functions.
  * MOP compatibility package - The MOPP package provides the MOP's
symbols on various implementations. Currently OpenMCL, CMUCL, SBCL,
Lispworks and CLISP are supported.
 .
 The recommended packages add extra features: documentation via
 cl-qbook, test suite with cl-fiveam and add-ons for cl-ppcre.
 .
 This is the development version.

=

This is the first of a series of ITPs for Common Lisp software that is
necessary as dependency for UCW [1].

As soon as this bug will get a number by the BTS, I'll add the package
to the CL-Debian repository [2]. The package is linda and lintian
free and it follows the "Common Lisp in Debian Manual" [3].

Thx, bye,
Gismo / Luca

[1] http://common-lisp.net/project/ucw/
[2] http://cl-debian.alioth.debian.org/cgi-bin/darcsweb.cgi
[3] http://cl-debian.alioth.debian.org/clid/clid.html/


pgpU1juFOGQHu.pgp
Description: PGP signature

Bug#310665: ITP: cl-rfc2388 -- an implementation of RFC 2388 in Common Lisp

[Luca Capello]

owner 310665 !
thanks

On Sat 22 Oct 2005 22:45 +0200, David Moreno Garza wrote:
> On Fri, 2005-10-21 at 16:55 +0200, Luca Capello wrote:
>> Sorry for the traffic, I forgot the bug number :-(
>
> What do you mean?

As I'm the real maintainer of cl-rfc2388 (but not a DD) and after
having discussed with Peter, we decided that the bug should refer to
me, so I change the 'submitter' field. In doing this, however, the
first time I used 'submitter !' (without the bug number) and I needed
to send again the correct command (thus generating traffic, because of
two mails instead of one).

Anyway, I forgot to change also the owner field, doing now.

Thx, bye,
Gismo / Luca


pgpCmTdcBYvq0.pgp
Description: PGP signature

Bug#310665: ITP: cl-rfc2388 -- an implementation of RFC 2388 in Common Lisp

[Luca Capello]

submitter 310665 !
thanks

On Fri 21 Oct 2005 16:32 +0200, Luca Capello wrote:
> submitter !

Sorry for the traffic, I forgot the bug number :-(

Thx, bye,
Gismo / Luca


pgp9hPCmi5Rup.pgp
Description: PGP signature

Bug#310665: ITP: cl-rfc2388 -- an implementation of RFC 2388 in Common Lisp

[Luca Capello]

submitter !
thanks

On Thu 18 Aug 2005 15:37 +0200, Luca Capello wrote:
> So, while the cl-rfc2388's CVS (and, unfortunately, version 1.0)
> contains a debian/ folder, I'm going to ask Janis to delete it.
>
> An then I'll finish packaging cl-rfc2388, so it could finally enter
> Debian official.

The package is ready in the CL-debian repository, lintian and linda
clean.

Peter, you can upload it :-)

Thx, bye,
Gismo / Luca


pgpyMig6KGRjv.pgp
Description: PGP signature

Bug#310665: ITP: cl-rfc2388 -- an implementation of RFC 2388 in Common Lisp

[Luca Capello]

Hello Adrian!

I'm sorry, but I didn't receive your mail, so I saw your post only
now.

On Mon 06 Jun 2005 17:15 +0200, Adrian Bunk wrote:
> On Sat, Jun 04, 2005 at 12:06:14PM +0200, Luca Capello wrote:
>>...
>> BTW, the CVS source already contains a debian/ folder, as the author
>> accepted to let rfc2388 become a Debian native package :-)
>
> Please don't package it as a native Debian package.

That was the conclusion we (Janis, cl-rfc2388's author, Peter and me)
arrived after having discussed in the last months. And that was also
the conclusion the cl-debian mailing-list arrived, please see posts
[1] and [2].

So, while the cl-rfc2388's CVS (and, unfortunately, version 1.0)
contains a debian/ folder, I'm going to ask Janis to delete it.

An then I'll finish packaging cl-rfc2388, so it could finally enter
Debian official.

> This avoids several problems like e.g. an NMU uploading a new
> upstream version having a higher version number than the maintainer
> upload of this version.

Those were exactly what we had fear of ;-)

Thx, bye,
Gismo / Luca

PS, Peter, sorry for the double mail, but I wasn't sure the BTS
will forward my mail to the bug submitter.

[1] http://common-lisp.net/pipermail/cl-debian/2005-June/45.html
[2] http://common-lisp.net/pipermail/cl-debian/2005-July/000177.html


pgpl16sViiVFZ.pgp
Description: PGP signature

Bug#310665: ITP: cl-rfc2388 -- an implementation of RFC 2388 in Common Lisp

[Luca Capello]

Hello!

On Wed 25 May 2005 07:17 +0200, Peter Van Eynde wrote:
> * Package name: cl-rfc2388
>   Version : x.y.z

0.9

>   Upstream Author : Name <[EMAIL PROTECTED]>

Janis Dzerins <[EMAIL PROTECTED]>

> * URL : http://www.example.org/

http://common-lisp.net/project/rfc2388/

> * License : (GPL, LGPL, BSD, MIT/X, etc.)

BSD

The only problem with this package is that the source contains the
rfc2388 text, which cannot be included in a free package. As the
rfc2388 text is already included in the doc-rfc-std-proposed package
(which is in not-free), IMO the cl-rfc2388 should suggest the
doc-rfc-std-proposed package.

BTW, the CVS source already contains a debian/ folder, as the author
accepted to let rfc2388 become a Debian native package :-)

Thx, bye,
Gismo / Luca


pgpvOz59MklBt.pgp
Description: PGP signature

Bug#272264: Tomboy

[Luca Capello]

Hello again!

On Thu 24 Feb 2005 17:14, Eric Gaumer wrote:
> With so many people wanting this package, I can't believe it isn't
> available from Debian yet. I've been a bit reserved about
> maintaining it because I didn't want to step on any toes but here we
> are six months later and still no results. I was forced to make my
> own package because I need binaries for PPC.

Well, I don't have a PPC so I never built tomboy for other arch than
i386, but noone asked me for that ;-)

Anyway, as Ben already stated, the problem is that the TinTin icon is
copyrighted and so until a new icon is chosen, Tomboy cannot enter
Debian.

> At this point my main concern is that Tomboy make its way into
> Sid. If you are looking for a commitment then here it is... I will
> take responsibility for this package. If this is acceptable then
> please contact me. If it's not, then please someone, step up and
> make this app part of Debian.

As I already posted, I'm giving up!

Thx, bye,
Gismo / Luca


pgpWspllamP9g.pgp
Description: PGP signature

Bug#272264: Tomboy

[Luca Capello]

Hi all!

On Wed 23 Feb 2005 20:16, Ben Hill wrote:
>> So... What should we do? I'm still willing to sponsor/comaintain the package,
>> but since I'm a bit short in free time I'd rather comaintain starting from 
>> what
>> I have (so I don't have to check the package, and we can build on top of 
>> it). ;)
>> 
>
> I'd be happy to maintain the package - it would be great if you could
> sponsor it.

Ok, I'm giving up, as I'm discovering the Emacs-related world and so
I think I won't use Tomboy anymore.

> I'll upload 0.3.1 into mentors anyway, and we can go from there I
> guess.

Ben, please let me know as soon as your 0.3.1 Debian package (not the
sources) will be available, so I can delete mine from my repository
and point to your package.

Have a good work!

Thx, bye,
Gismo / Luca


pgpq4ANm39awB.pgp
Description: PGP signature

Bug#289307: marked as done (ITP: pwc -- Free Philips USB Webcam driver for Linux replacing the old pwcx module.)

[Luca Capello]

Hello!

On Sat 19 Feb 2005 14:45, Victor Seva wrote:
> Oh!... I thought that Sean wants me to close the bug right now... so
> Thanks fEnIo.

Even if my Logitech QuickCam Notebook Pro will arrive this night, I
tried the latest pwc-source_10.0.6a-9, but there's a problem with
'make-kpkg modules_image'.

I usually compile my modules on a kernel different from that I'm
running and while other modules like ALSA, ipw2100 and thinkpad
compile correctly, pwc compiles for the current running kernel:
=
[EMAIL PROTECTED]:~/src/linux-2.6.11-rc4-acpi$ make-kpkg modules_image

Module /usr/src/modules/alsa-driver processed fine
make[1]: Entering directory `/home/luca/src/modules/pwc'

#dh_clean /home/luca/src/modules/pwc/debian/control
for templ in ; do \
cp $templ `echo $templ | sed -e 's/_KVERS_/2.6.11-rc4/g'` ; \
  done

# Build the module
/usr/bin/make
make[2]: Entering directory `/home/luca/src/modules/pwc'
/usr/bin/make -C /lib/modules/2.6.10-mh4/source
SUBDIRS=/home/luca/src/modules/pwc modules
make[3]: Entering directory
`/home/luca/src/linux-2.6.10-mh4-acpi.bluez.trackpoint'
  CC [M]  /home/luca/src/modules/pwc/pwc-if.o

# Install the module
/usr/bin/make install DESTDIR=/home/luca/src/modules/pwc/debian/tmp
make[2]: Entering directory `/home/luca/src/modules/pwc'
/usr/bin/make -C /lib/modules/2.6.10-mh4/source
SUBDIRS=/home/luca/src/modules/pwc modules
make[3]: Entering directory
`/home/luca/src/linux-2.6.10-mh4-acpi.bluez.trackpoint'
  Building modules, stage 2.

#dh_builddeb --destdir=/home/luca/src/linux-2.6.11-rc4-acpi/..
dh_builddeb --destdir=/home/luca/src/linux-2.6.11-rc4-acpi/..
dpkg-deb: building package `pwc-modules-2.6.11-rc4' in
`/home/luca/src/linux-2.6.11-rc4-acpi/../pwc-modules-2.6.11-rc4_10.0.6a-9+01.acpi.20050218_i386.deb'.
dh_clean

make[1]: Leaving directory `/home/luca/src/modules/pwc'
Module /usr/src/modules/pwc processed fine
make[1]: Entering directory `/home/luca/src/modules/thinkpad'
[EMAIL PROTECTED]:~/src/linux-2.6.11-rc4-acpi$
=

I'm quite sure this problem is caused by the missing KSRC and KVERS
parameters passed to the 'make' and 'make install' command. The
attached trivial patch fix this problem:
=
[EMAIL PROTECTED]:~/src/linux-2.6.11-rc4-acpi$ make-kpkg modules_image

make[1]: Entering directory `/home/luca/src/modules/pwc'

for templ in ; do \
cp $templ `echo $templ | sed -e 's/_KVERS_/2.6.11-rc4/g'` ; \
  done
# Build the module
/usr/bin/make KSRC=/home/luca/src/linux-2.6.11-rc4-acpi
KVER=2.6.11-rc4
make[2]: Entering directory `/home/luca/src/modules/pwc'
/usr/bin/make -C /lib/modules/2.6.11-rc4/source
SUBDIRS=/home/luca/src/modules/pwc modules
make[3]: Entering directory `/home/luca/src/linux-2.6.11-rc4-acpi'
  CC [M]  /home/luca/src/modules/pwc/pwc-if.o

# Install the module
/usr/bin/make install DESTDIR=/home/luca/src/modules/pwc/debian/tmp
KSRC=/home/luca/src/linux-2.6.11-rc4-acpi KVER=2.6.11-rc4
make[2]: Entering directory `/home/luca/src/modules/pwc'
/usr/bin/make -C /lib/modules/2.6.11-rc4/source
SUBDIRS=/home/luca/src/modules/pwc modules
make[3]: Entering directory `/home/luca/src/linux-2.6.11-rc4-acpi'
  Building modules, stage 2.

dh_builddeb --destdir=/home/luca/src/linux-2.6.11-rc4-acpi/..
dpkg-deb: building package `pwc-modules-2.6.11-rc4' in
`/home/luca/src/linux-2.6.11-rc4-acpi/../pwc-modules-2.6.11-rc4_10.0.6a-9+01.acpi.20050218_i386.deb'.

Module /usr/src/modules/pwc processed fine
[EMAIL PROTECTED]:~/src/linux-2.6.11-rc4-acpi$
=

Please consider for inclusion. TIA.

BTW, module-assistant correctly works with pwc-source, so shouldn't
the entry in /usr/share/doc/pwc-source/TODO.Debian be removed?

Thx, bye,
Gismo / Luca

--- pwc/debian/rules.ORIG	2005-02-19 02:07:26.0 +0100
+++ pwc/debian/rules	2005-02-20 17:48:34.902598776 +0100
@@ -186,10 +186,10 @@
 	dh_clean -k
 
 	# Build the module
-	$(MAKE)
+	$(MAKE) KSRC=$(KSRC) KVER=$(KVERS)
 
 	# Install the module
-	$(MAKE) install DESTDIR=$(CURDIR)/debian/tmp
+	$(MAKE) install DESTDIR=$(CURDIR)/debian/tmp KSRC=$(KSRC) KVER=$(KVERS)
 
 	dh_installdebconf
 	dh_installdocs


pgplZuIiX2AdB.pgp
Description: PGP signature

Bug#292643: ITP: cl-s-xml -- simple Common Lisp XML parser

[Luca Capello]

Hi David!

On Wed 02 Feb 2005 00:29, D. Starner wrote:
> I don't really care, personally. But given that even the maintainer
> of the package doesn't know what it means, I don't believe it's a
> useful phrase to have in the package description. Furthermore, I think
> that fact that I would have to go to a mailing list to find what 
> character sets it supports is a documentation bug; that is something
> that should be well documented.

Ok, I asked on the S-XML-devel mailing-list for an explanation [1] and
I modified the Debian cl-s-xml package (BTW, there's a new upstream
version).

I removed the character sets limitation in the package description and
I added a README.Debian:
=
README for the Debian cl-s-xml package
--

* Supported character sets

While S-XML authors do not make any efforts to support anything but the
basic Common Lisp character type (and string or stream type), any
character set which is implemented by the underlying Common Lisp should
be supported by S-XML as well.


 -- Luca Capello <[EMAIL PROTECTED]>, Thu,  3 Feb 2005 22:36:33 +0100
=

What do you think?

BTW, I searched on the net for a standard /definition/ for
simple/complex character sets and the only I found was in the MIME
specifications [2]:
=
2.2.  Character Set

   The term "character set" is used in MIME to refer to a method of
   converting a sequence of octets into a sequence of characters. Note
   that unconditional and unambiguous conversion in the other direction
   is not required, in that not all characters may be representable by a
   given character set and a character set may provide more than one
   sequence of octets to represent a particular sequence of
   characters.

   This definition is intended to allow various kinds of character
   encodings, from simple single-table mappings such as US-ASCII to
   complex table switching methods such as those that use ISO 2022's
   techniques, to be used as character sets.  However, the definition
   associated with a MIME character set name must fully specify the
   mapping to be performed.  In particular, use of external profiling
   information to determine the exact mapping is not permitted.

   NOTE: The term "character set" was originally to describe such
   straightforward schemes as US-ASCII and ISO-8859-1 which have a
   simple one-to-one mapping from single octets to single characters.
   Multi-octet coded character sets and switching techniques make the
   situation more complex. For example, some communities use the term
   "character encoding" for what MIME calls a "character set", while
   using the phrase "coded character set" to denote an abstract
   mapping
   from integers (not octets) to characters.
=

Thx, bye,
Gismo / Luca

[1] http://common-lisp.net/pipermail/s-xml-devel/2005-February/07.html
[2] http://www.ietf.org/rfc/rfc2045.txt


pgpSfsD2lpXdI.pgp
Description: PGP signature

Bug#292643: ITP: cl-s-xml -- simple Common Lisp XML parser

[Luca Capello]

Hi Peter,

On Fri 28 Jan 2005 16:16, Peter Van Eynde wrote:
> On Fri, 28 Jan 2005 15:07:55 +0100, "Luca Capello" <[EMAIL PROTECTED]> said:
>> This is my first *official* Debian package, it will be follow ASAP by
>> cl-gtk (which needs to be checked for some little Debian things). I
>> haven't wrote to the sponsor list yet, because AFAIK most of the cl-*
>> packages are updated by Kevin M. Rosenberg <[EMAIL PROTECTED]>, so maybe
>> he'd be direct interested in sponsoring me (or whatever the best for
>> this and the other cl-* packages I'm going to ITP).
>
> If he is unavailable I would be happy to sponsor your package.

In Italy, we have an aphorism that says: "Someone who doesn't say
anynothing agrees". So, as Kevin Rosenberg hasn't replied yet, I guess
he agrees about your sponsorship ;-)

If you are still happy to sponsor me, please contact me in private.

BTW, I updated the package to a new version, which actually doesn't
reflect any changes in the software, but some adjustements in the
Debian files.

Thx, bye,
Gismo / Luca


pgpE2WbrcFyHo.pgp
Description: PGP signature

Bug#292643: ITP: cl-s-xml -- simple Common Lisp XML parser

[Luca Capello]

Hi all!

On Tue 01 Feb 2005 15:55, Luca Capello wrote:
> Ciao bello...

> Grazie ancora,

I'm sorry for my last post, I made a mistake replying Starner's post.

Anyway, even if the answer the question was already in my last fault
post, here it is again :-)

On Fri 28 Jan 2005 22:30, D. Starner wrote:
>> This XML parser implementation has the following limitations:
>>  * It does not support CDATA.
>>  * Only supports simple character sets.
>
> What do you mean, "simple" character sets? What's the difference
> between a simple character set and a complex character set?

I don't know precisely and if you want to have a more complete and
claryfing answer, you should better ask on the S-XML mailing lists (at
the bottom of [1]).

The only explanation I'm aware of is the same as you can found in the
MySQL Reference Manual [2]. But I could be wrong :-(

Thx, bye,
Gismo / Luca

[1] http://common-lisp.net/project/s-xml/
[2] http://dev.mysql.com/doc/mysql/en/adding-character-set.html


pgp1O5SR0sJdC.pgp
Description: PGP signature

Bug#292643: ITP: cl-s-xml -- simple Common Lisp XML parser

[Luca Capello]

Ciao bello...

Scusa se ti disturbo sempre, ma [sei stato|sei|sarai] il mio GNU/Linux
guru, quindi fino a che l'allievo non superera' il maestro...

On Fri 28 Jan 2005 22:30, D. Starner wrote:
>> This XML parser implementation has the following limitations:
>>  * It does not support CDATA.
>>  * Only supports simple character sets.
>
> What do you mean, "simple" character sets? What's the difference
> between a simple character set and a complex character set?

La mia risposta sara' la seguente:
=
I don't know precisely and if you want to have a more complete and
claryfing answer, you should better ask on the S-XML mailing lists (at
the bottom of [1]).

The only explanation I aware of is same as you can found in the MySQL
Reference Manual [2]. But I could be wrong :-(

[1] http://common-lisp.net/project/s-xml/
[2] http://dev.mysql.com/doc/mysql/en/adding-character-set.html
=

Cosa ne dici?

Appena ricevuta la tua risposta, posto sul Debian BTS e dal momento
che kmr non ha risposto (chi tace acconsente), chiedo a Peter Van
Eynde di sponsorizzarmi (cosi' cl-s-xml entra in Debian). Poi faccio
lo stesso procedimento per cl-gtk (che non sara' piu' cl-gtk-cmucl, ma
semplicemente cl-gtk dipendente da cmucl).

Grazie ancora,
Luca


pgp2ZSOxWY029.pgp
Description: PGP signature

Bug#292643: ITP: cl-s-xml -- simple Common Lisp XML parser

[Luca Capello]

Package: wnpp
Severity: wishlist
Owner: Luca Capello <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: cl-s-xml
  Version : 3+cvs.2005.01.27
  Upstream Author : Sven Van Caekenberghe <[EMAIL PROTECTED]>
* URL : http://common-lisp.net/project/s-xml/
* License : Lisp LGPL
  Description : simple Common Lisp XML parser

 S-XML is a Common Lisp implementation of a simple XML parser, with
 a SAX-like and DOM interface.
 .
 This XML parser implementation has the following features:
  * It works (handling many common XML usages).
  * It is very small (the core is about 400 lines of code, including
comments and whitespace).
  * It has a core API that is simple, efficient and pure functional, much
like that from SSAX (see also http://ssax.sourceforge.net).
  * It supports different DOM models: an XSML-based one, an LXML-based one
and a classic xml-element struct based one.
  * It is reasonably time and space efficient (internally avoiding garbage
generatation as much as possible).
 .
 This XML parser implementation has the following limitations:
  * It does not support CDATA.
  * Only supports simple character sets.
  * It does not support name spaces
  * It does not support any special tags (like processing instructions).
  * It is not validating, even skips DTD's all together.

=

I already packaged it, it's available on my unofficial Debian repository:
http://luca.pca.it/debian/

My GPG key is 6D742669, http://keyserver.linux.it or http://luca.pca.it,
key fingerprint 10CD 0397 6DBE 1E36 DEA3  72CC 540A 7B5E 6D74 2669

The package is based on other cl-* packages, I followed the "Debian
New Maintainers' Guide" and it's lintian checked.

This is my first *official* Debian package, it will be follow ASAP by
cl-gtk (which needs to be checked for some little Debian things). I
haven't wrote to the sponsor list yet, because AFAIK most of the cl-*
packages are updated by Kevin M. Rosenberg <[EMAIL PROTECTED]>, so maybe
he'd be direct interested in sponsoring me (or whatever the best for
this and the other cl-* packages I'm going to ITP).

I'm here for any other questions, suggestions, etc.

Thx, bye,
Gismo / Luca

- -- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-mh2
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

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

iD8DBQFB+kc7VAp7Xm10JmkRAtHnAJ4vHRNkq2ExV4u2spvXcIVHUV/brwCeNKeV
RHJ+E2xCFULUjEt6kP1QHxg=
=Kr35
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]