Re: RFS: taxbird (updated package)

2011-07-30 Thread Michael Tautschnig
Hi Olaf,

[...]
 
 I added NMU-diffs for the debian changes only, because I think adding
 the upstream diffs from libgeier 0.11 to 0.12 and taxbird from 0.15 to
 0.16 don't add any value.
 
[...]

I suppose that's fine. I've now done the following:

- Built libgeier and uploaded to DELAYED/5.
- Fixed the build-dep of taxbird to use glade instead of glade-gnome as there is
  some semi-broken transition going on. Noted the change in the changelog.
- Built and uploaded taxbird to DELAYED/7.

Thanks a lot for your work and patience,
Michael



pgpmdEJHV0aE3.pgp
Description: PGP signature


RFS: wmmoonclock (updated package)

2011-07-30 Thread Rodolfo kix Garcia

Dear mentors,

I am looking for a sponsor for the new version 1.27-30
of my package wmmoonclock.

It builds these binary packages:
wmmoonclock - WindowMaker moon phase dockapp

The package appears to be lintian clean.

The upload would fix these bugs: 588837

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/w/wmmoonclock
- Source repository: deb-src http://mentors.debian.net/debian unstable 
main contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/w/wmmoonclock/wmmoonclock_1.27-30.dsc


I would be glad if someone uploaded this package for me.

Kind regards
kix
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/fa3ffed06ed8ce4148097e15bc890...@kix.es



Re: RFS: dbxml

2011-07-30 Thread Daniel de Kok
Hi Killian,

Thanks for the feedback! One question:

On Sat, Jul 30, 2011 at 12:14 AM, Kilian Krause kil...@debian.org wrote:
 Apart from that I only would prefer to have a -1 without a patch for the
 initial upload so that I won't have to repackage your upload to make it
 fit for putting into the archive.

Without patches, dbxml does not build (it will not find db5.1), so how
do I proceed here?

With kind regards,
Daniël de Kok


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAL=mtGiSBw-B9vC44v=rQ-fqGdgxhE50Di+k1di47nQBWb5n=q...@mail.gmail.com



Re: RFS: taxbird (updated package)

2011-07-30 Thread Olaf Dietsche
Hi Michael,

Michael Tautschnig m...@debian.org writes:

 - Built libgeier and uploaded to DELAYED/5.
 - Fixed the build-dep of taxbird to use glade instead of glade-gnome as there 
 is
   some semi-broken transition going on. Noted the change in the changelog.
 - Built and uploaded taxbird to DELAYED/7.

 Thanks a lot for your work and patience,

Thank you for your support.

Regards, Olaf


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y5zg124y@rat.lan



Re: RFS: dbxml

2011-07-30 Thread Kilian Krause
Hi Daniel,

Am 30.07.2011 um 12:56 schrieb Daniel de Kok m...@danieldk.eu:

 Thanks for the feedback! One question:
 
 On Sat, Jul 30, 2011 at 12:14 AM, Kilian Krause kil...@debian.org wrote:
 Apart from that I only would prefer to have a -1 without a patch for the
 initial upload so that I won't have to repackage your upload to make it
 fit for putting into the archive.
 
 Without patches, dbxml does not build (it will not find db5.1), so how
 do I proceed here?
 

Ah, I see. Name that patch correctly then and put a DEP-3 header. 

-- 
Best regards,
Kilian


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/947ab069-f76c-4721-9342-948c9a29b...@verfaction.de



Re: RFS: l2tp-ipsec-vpn

2011-07-30 Thread Michael Tautschnig
Hi Werner,

[...]

I've taken another look at your package. For reference, I've used

http://mentors.debian.net/debian/pool/main/l/l2tp-ipsec-vpn/l2tp-ipsec-vpn_1.0.0-1.dsc

dated 29-Jul-2011 09:46.

The first thing I stumbled upon was the orig.tar.gz that doesn't match the
upstream one. Not only do md5sums differ, but the actual contents does:

(... diffstat output)
125 files changed, 116 insertions(+), 404 deletions(-)

Although these changes only concern revision control ids, it is IMHO not
acceptable to have orig.tar.gz differ in such a way from upstream's tar.gz.

Further comments:

- The description is clearly improved and the first stanza is appropriate;
  others, however, should probably only go in some README file. Please see
  Debian Policy about this, Section 3.4, which provides a very nice guideline
  what should (not) be included.
  (http://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions)
- debian/postinst:
  * service rsyslog restart || true   -- no, there is no service command in
general in Debian. And why restart a foreign service!?
  * Why use gksu when su should do the trick? I really wouldn't want
to do system administration remotely with GUI su popping up.
- The package build-depends on (and indeed appears to require) libopensc2-dev,
  which unfortunately is no longer available in Debian. Could you find a way
  around that, given that you are upstream? Otherwise please speak to the opensc
  maintainer in Debian about this.

Thanks a lot for your work,
Michael



pgpEneVgXRNic.pgp
Description: PGP signature


Re: RFS: acsccid (Updated)

2011-07-30 Thread Michael Tautschnig
Hi,

 Dear mentors,
 
 I am looking for a sponsor for my package acsccid. Actually, I posted the 
 request about 1 month ago and I did not receive any response here.
 
 The package had been updated and fix the following problems:
 1. The project is hosted in sourceforge now and watch file is updated.
 2. Remove dh_makeshlibs from rules file.
 3. Fix non-redistributable reference manual problem.
 
 * Package name: acsccid
   Version : 1.0.2-1
   Upstream Author : Advanced Card Systems Ltd.
 * URL : http://acsccid.sourceforge.net/
 * License : LGPL-2.1
   Section : libs
 
 It builds these binary packages:
 libacsccid - PC/SC driver for ACS USB CCID smart card readers
 
 The package appears to be lintian clean.
 
[...]

This may be true, but it doesn't build :-/

Well, to start out in proper order, here's my review results:

- Please use DEP-5 format for debian/copyright and please make extra-sure you
  don't miss any copyright holders as the package seems to have quite a number
  of them. DEP-5 format will make this much easier to check.
- You probably want to add a Depends: on udev instead of merely recommending it
  in some README file.
- configure yields the following result:

  ...
  udev support:no
  ...
  I'm not sure this is intended.
- Your package fails to build from source:
ifdhandler.c: In function ‘IFDHControl’:
ifdhandler.c:1416:22: error: ‘FEATURE_MCT_READERDIRECT’ undeclared (first use 
in this function)
ifdhandler.c:1416:22: note: each undeclared identifier is reported only once 
for each function it appears in
make[3]: *** [libacsccid_la-ifdhandler.lo] Error 1
make[3]: Leaving directory `/home/tautschnig/debian/acsccid/acsccid-1.0.2/src'

Please get those fixed, then another more thorough package review will follow.

Best,
Michael





pgp05k30TMWKV.pgp
Description: PGP signature


Re: [done] RFS: libbs2b

2011-07-30 Thread Stephen Kitt
On Tue, 26 Jul 2011 15:35:40 +0300, Eugene V. Lyubimkin jac...@debian.org
wrote:
 One minor detail (for the next upload) I didn't notice before: there is
 no substitution variable '{misc:Pre-Depends}', so you can remove that
 Pre-Depends line of libbs2b0 altogether.

Actually there is, in particular for multiarch support...

Regards,

Stephen


signature.asc
Description: PGP signature


Re: [done] RFS: libbs2b

2011-07-30 Thread Sven Joachim
On 2011-07-30 19:58 +0200, Stephen Kitt wrote:

 On Tue, 26 Jul 2011 15:35:40 +0300, Eugene V. Lyubimkin jac...@debian.org
 wrote:
 One minor detail (for the next upload) I didn't notice before: there is
 no substitution variable '{misc:Pre-Depends}', so you can remove that
 Pre-Depends line of libbs2b0 altogether.

 Actually there is, in particular for multiarch support...

But libbs2b has not been converted to multiarch, so the substitution
variable is empty.

Sven


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87oc0bk4rd@turtle.gmx.de



Re: RFS: lebiniou, lebiniou-data (3rd try) (new upstream version)

2011-07-30 Thread Olivier Girondel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Kilian,

Thanks for reviewing the packages;

On 07/30/2011 12:28 AM, Kilian Krause wrote:
 what's the reason to have:
 
 1. dh-autoreconf (none of the patches requires this)

There is a dependency on the ttf-freefont package;

The patch path-to-freemono-font.diff removes the fonts/ directory from
the build: it modifies configure.ac and the top-level Makefile.am
(and sets the correct path to /usr/share/fonts/truetype/freefont/)

dh-autoreconf is therefore needed, otherwise the package will end up
containing a copy of FreeMono.ttf, and lintian will complain with a:
W: lebiniou: duplicate-font-file usr/share/lebiniou/fonts/FreeMono.ttf
also in ttf-freefont

 2. OSS as default audio driver upstream (and thus Debian patch)

lebiniou also builds on FreeBSD and NetBSD, and for these systems only
OSS is available

 3. extra -O3 when -O2 is already set as the Debian default?

Some optimizations (eg. -finline-functions, -funswitch-loops,
- -fpredictive-commoning) are set by -O3

 4. a different lebiniou tarball than the one from your upstream website

The tarballs have possibly gone out-of-sync, I just re-uploaded them.
(the .orig.tar.gz is a symbolic link to the .tar.gz generated by 'make
dist')

 Regarding fonts/FreeMono.ttf I'm not sure whether that one needs to be
 removed from the source tarball too.

The previous suggestions I received were to remove it from the tarball
and add a dependency on ttf-freefont

 1. The public domain license is not printed verbatim in debian/copyright.
Needs to be added.

The copyright has been set to Public Domain and the license to CC0,
included in the 'copyright' file (I hope the text/formating is ok)

 2. Won't built for me with pdebuild -- --twice due to:
 Making all in sequences
 make[2]: Entering directory `/tmp/buildd/lebiniou-data-3.9/sequences'
 ./make-tar.sh
 /bin/bash: ./make-tar.sh: No such file or directory
 make[2]: *** [sequences.tar.gz] Error 127

This is now fixed

 Thanks for your work. Please fix these and ping me when you have updated
 this.

New packages have been uploaded to m.d.n

Thanks again for your time
Best regards,

- --
Olivier
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk40WYcACgkQpqVXaJzJYNKuMwCfaqejgKQSZ+dv3wfSdK4UAcTp
d30AnAumvZ5a6OCJ2BcPw9DUxz5hVaQO
=fieL
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e345993.2010...@biniou.info



Re: RFS: lebiniou, lebiniou-data (3rd try) (new upstream version)

2011-07-30 Thread Arno Töll
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Oliver,

On 30.07.2011 21:20, Olivier Girondel wrote:
 2. OSS as default audio driver upstream (and thus Debian patch)
 
 lebiniou also builds on FreeBSD and NetBSD, and for these systems only
 OSS is available
 

That's perfectly fine, but please note Debian also supports kFreeBSD
which builds a GNU user land around the FreeBSD kernel. Your patch
effectively breaks such systems, as there is no Alsa available as you
said yourself. Nonetheless I agree with you, that defaulting to ALSA is
a good idea for Linux.

Is there some conditional to override this compiled in choice upon build
time? If so, you might consider making use of it, to make your package
build on kFreeBSD with different defaults than Linux.

For autotools based build systems, you could make use of
dpkg-architecture plus conditional branching around it and pass host
architecture dependent flags to its configure script.

Alternatively you could do the same branching based on compiler
preprocessor flags.

- -- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJONF6NAAoJEMcrUe6dgPNtxdgQAIgYutl/M9QMfGaSmpC8Odxv
fr284zDxlExblXIAYyfNuEg/cwNnoZzRP4FAcHijdkG0YCFZRQi3mmQgvRJbvpRm
zw69rr326PDHxEP3L8u3TSI2mVQIXPsvrmua8XpNCH86Yk3oFeXWeVS0kDSJJACm
VZdFm3hz2RUwlmz1WyzY9rWHD1HTgzq8GYiLTct+MqomLuifuV0UngNlu8G7WkKm
iVrqScsRl3RGubYwoKgub8QqWZeaTbBe4VC1dyW78XL0/h0goj1jKobWgux4ZuhM
a6w3p3IhqFpcB80UzzWMow/5kIkMoM7fIKIcCDgKEGzZLPsDn9uniCWdNT8s9CDo
9EVouyobXodKFTDtHhUR/Y7gghd/hkg+mBv9O5jZ+QUi5Zla0UeFLSTMnsVct7K9
NxsbjaYyU7e7Vl1JGK1fBMFn62g85ZOwslfyIVNEjQACbRG5ZcOYNWkn2LY1Rs+o
UsHtkvT/eqRAPL4UVbB3KDKEi8ZFHNgbFNgZQm+1C+aTGCMdE52/M//25UanBO59
K03DVLmjy19w9YFqi/GINmKjVHoCjYeinYFutAJ3wNk1Xqft3C4HVUh2BYflklvj
4vdxLa+qoWsk1Li288NzUwOT5r84kOkVq/KY3Ymfp9kXmS0JzdvTb3kugXVlzPFh
OUuQBUR48C0y8zI+cwXO
=x8ug
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e345e8d.5070...@toell.net



RFS: libstring-tokenizer-perl

2011-07-30 Thread Ben Webb
Dear mentors,

I am looking for a sponsor for my package libstring-tokenizer-perl.

* Package name: libstring-tokenizer-perl
  Version : 0.05-2
  Upstream Author : Stevan Little, ste...@iinteractive.com
* URL : http://search.cpan.org/dist/String-Tokenizer/
* License : Artistic or GPL-1+
  Section : perl

It builds these binary packages:
libstring-tokenizer-perl - A simple string tokenizer.

The package appears to be lintian clean. (Except for not having an ITP bug).

My motivation for maintaining this package is: It is one of the
dependencies for Evergreen (http://evergreen-ils.org/). Having the
dependencies in repositories will make the installation process
easier, and lead to the possibility of Evergreen packages in DEbian.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/l/libstring-tokenizer-perl
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/l/libstring-tokenizer-perl/libstring-tokenizer-perl_0.05-2.dsc

I would be glad if someone uploaded this package for me.

Kind regards
 Ben Webb


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caa-u+ps1nu3ft1gat8mibnf8pmq3q1djspkp69qdoocleiz...@mail.gmail.com



Re: RFS: libstring-tokenizer-perl

2011-07-30 Thread Niels Thykier
On 2011-07-30 21:47, Ben Webb wrote:
 Dear mentors,
 
 I am looking for a sponsor for my package libstring-tokenizer-perl.
 
 * Package name: libstring-tokenizer-perl
   Version : 0.05-2
   Upstream Author : Stevan Little, ste...@iinteractive.com
 * URL : http://search.cpan.org/dist/String-Tokenizer/
 * License : Artistic or GPL-1+
   Section : perl
 
 It builds these binary packages:
 libstring-tokenizer-perl - A simple string tokenizer.
 
 The package appears to be lintian clean. (Except for not having an ITP bug).
 
 My motivation for maintaining this package is: It is one of the
 dependencies for Evergreen (http://evergreen-ils.org/). Having the
 dependencies in repositories will make the installation process
 easier, and lead to the possibility of Evergreen packages in DEbian.
 
 The package can be found on mentors.debian.net:
 - URL: http://mentors.debian.net/debian/pool/main/l/libstring-tokenizer-perl
 - Source repository: deb-src http://mentors.debian.net/debian unstable
 main contrib non-free
 - dget 
 http://mentors.debian.net/debian/pool/main/l/libstring-tokenizer-perl/libstring-tokenizer-perl_0.05-2.dsc
 
 I would be glad if someone uploaded this package for me.
 
 Kind regards
  Ben Webb
 
 

Hi

Have you considered joining or asking the Perl team?  They have more
experience with Perl packages and they can probably also help you
finding a sponsor with future uploads of this package.

~Niels


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e346044.7050...@thykier.net



Plan for managing the SWISS EPHEMERIS data, virtual packages.

2011-07-30 Thread Paul Elliott

Dear Debian Mentors,

I am planing to package the SWISS EPHEMERIS library and its data.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635672
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636089

The SWISS EPHEMERIS data is 36 Meg in 54 files. The Swiss Ephemeris library
can be used with out installed data if the user has a private copy of the 
data. I would like to encourage data sharing which is the reason for packaging 
the Swiss Ephemeris data. Any of the 54 data files could be needed or not 
needed depending on what the user is doing.

For more info about the Swiss Ephemeris see:
http://www.astro.com/swisseph/
http://www.astro.com/swisseph/swisseph.htm
http://swissephauto.blackpatchpanel.com/

I believe that for desktop users the cost of managing this is less than the 
cost of installing all the data. It costs for people, either administrators or 
users to think about things and storage is getting cheap.

However some day some one may want to put say, a astrology web server on a low 
memory device such as home router hardware. These people will want to control 
exactly what data they will install.

I plan to create a package that will include all the data, but I want to 
provide for people to come a long later and take a more fine grained approach.

I propose that each file have its own VIRTUAL PACKAGE. A package with a 
combination of files would provide and conflict with each virtual package for 
each file it includes. That way people could create a more fine grained 
approach 
to this problem with no risk of two packages providing the same file being 
installed as the same time.

I would like to ask if this is an appropriate use of the virtual package 
concept? How should I choose the virtual package names?

I understand there is a procedure involving Debian-devel consensus
for using virtual packages.
http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt

However, there is an exception:
 Packages MUST NOT use virtual package names (except privately, amongst
 a cooperating group of packages) unless they have been agreed upon and
 appear in this list.

Since all packages using these virtual names would be astrology programs using 
the Swiss Ephemeris or the Swiss Ephemeris library, could this use be viewed 
as privately, amongst a cooperating group of packages?

If so, I could skip the debian-devel consensus step.

If I need to go the debian-devel I want to get the bugs out of my plan first.

I thank everyone for their input and comments.

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


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