Re: RFS: wav2cdr (updated package)

[Michael Tautschnig]

Hi Tony,

I finally got around to review this package.

 Dear mentors,
 
 I am looking for a sponsor for the new version 2.3.3-12
 of my package wav2cdr.
 
 It builds these binary packages:
 wav2cdr- Converts wav files into CD-ROM audio file format
 
 The package appears to be lintian clean.
 

[...]

The package is mostly ready for upload, I just noticed two issues:

- You updated the Standards-Version to 3.9.1 but did not document this in the
  changelog. Did you also check back with the checklist whether updating without
  changing anything was ok?
- Your watchfile isn't working. And in fact it would make much more sense to use
  the author's web page instead of some maybe up-to-date mirror. Looking at
  http://volker.top.geek.nz/soft/pck/ it actually seems there is some 2.3.4
  release!?

Furthermore it would be great if you could persuade upstream to fix all these
conversion errors that gcc reports while compiling.

Hope this helps,
Michael



pgpp0Q1XLmbP3.pgp
Description: PGP signature

Re: RFS: pyragua (updated package, 2nd try)

[Michael Tautschnig]

Hi,

 Dear mentors,
 
 I am looking for a sponsor for the new version 0.2.5-2 of my package
 pyragua.
 
 It builds these binary packages:
 pyragua- Very lightweight Python editor
 
 The package appears to be lintian clean.
 

[...]

In this new version you changed to debhelper's compact rules file, with a number
of overrides. Even though the results are still correct, I wonder why you do

- override_dh_installchangelogs, override_dh_installmenu: I think not overriding
  those targets would produce exactly the same results,
- override_dh_builddeb: is there a serious reason for doing that?

You might also want to re-inspect all the other overrides and possibly consider
to stay with debian/{docs,install,links,manpages} files instead of overriding
the targets.

Hope this helps,
Michael



pgp3PF2yUmWqf.pgp
Description: PGP signature

Re: RFS: mediadownloader

[Michael Tautschnig]

Hi Marco,

[...] (several previous reviews, you might want to acknowledge them in your
changelog)

Here's some more notes on your package:

- debian/control: I don't quite understand what you mean by , as well as mobile
  devices do. in your package description. You could probably also drop the
  URL, it's in the Homepage: field anyway.
- debian/copyright: To the best of my knowledge, a simple GPL3 is not
  acceptable. The optimal solution would be to even go for a DEP-5 formatted
  copyright file, see http://dep.debian.net/deps/dep5/
- debian/docs: lists README.txt twice
- debian/rules: A debian/install (and maybe debian/dirs) should help to simplify
  your rules, I think.
- A number of source files lack copyright- and license-information. As you are
  upstream, this should be fairly easy to fix.

Hope this helps,
Michael



pgpmpSRcVb4Y6.pgp
Description: PGP signature

Re: RFS: libgis - virtual globe library

[Benoît Knecht]

Hi Andy,

Andy Spencer wrote:
 I am looking for a sponsor for my package libgis.
 
 * Package name: libgis
   Version : 0.4.1-1
   Upstream Author : Andy Spencer (myself)
 * URL : http://lug.rose-hulman.edu/code/projects/libgis/wiki
 * License : GPL-3+
   Section : science
 
 It builds these binary packages:
 libgis - A Virtual Globe library
 libgis-bin - Example programs for libgis
 libgis-dev - Development files for libgis
 libgis-doc - HTML documentation for libgis

I didn't really look at your package yet, but I just wanted to point out
that you're not closing any bugs with this release. You're supposed to
file a bug against WNPP (Work-Needing and Prospective Packages) and note
in the debian/changelog entry that this package would be closing that
bug. See [1] for details about the procedure.

[1] http://www.debian.org/devel/wnpp/

Cheers,

-- 
Benoît Knecht


-- 
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/20101113092203.ga3...@debian.lan

Re: RFS: libgis - virtual globe library

[David Paleino]

Hello Andy,
apart from Benoît's remark, which is correct, here are some comments:

On Sat, 13 Nov 2010 07:19:39 +, Andy Spencer wrote:

 * Package name: libgis
   Version : 0.4.1-1
   Upstream Author : Andy Spencer (myself)
 * URL : http://lug.rose-hulman.edu/code/projects/libgis/wiki
 * License : GPL-3+
   Section : science
 
 It builds these binary packages:
 libgis - A Virtual Globe library
 libgis-bin - Example programs for libgis
 libgis-dev - Development files for libgis
 libgis-doc - HTML documentation for libgis

IMHO, the name of your project is rather too generic (libgis). It should be
changed to something more descriptive, but that's your choice as upstream at
the end.
Apart from this, you're very welcome to maintain it under the Debian GIS Team
umbrella. To join us, please join the pkg-grass [0] project on
alioth.debian.org.

[0]: https://alioth.debian.org/projects/pkg-grass/

Here are some comments:

- In debian/control, you misinterpreted the meaning of Vcs-* fields. Those
  should point to the location where the Debian packaging is kept, while you
  pointed at the upstream repository. You can choose to maintain the debian/
  dir there as well, or host it on Alioth within the Debian GIS Team (which
  would be better for team-maintainance).

- Library packaging in Debian has to follow certain policies. The binary
  package you're producing should be named libgisSONAME (i.e. libgis0, or
  similar). This ensures that any dependant package depends on the correct
  version of the library.

- Why is libgis-doc an arch:any package? I didn't check its contents, but I
  suspect it should be arch:all. ;)

- You might want to use DEP-5 format for your debian/copyright. Read more at
  http://dep.debian.net/deps/dep5/ . It's entirely optional, and it won't be a
  stopper if you leave it like it is now.

- In libgis-dev.install , please avoid installing *.a files. We (as Debian) are
  deprecating them, and installing them in a brand new package is a bad thing.

- Your package doesn't seem to be lintian clean ;-) -- you pasted lintian's
  output in debian/lintian.txt, and there it clearly says to a) close an ITP
  bug and b) use a proper name for the binary (point 2 of my comments). Next
  time please read it ;)

- Always in the lintian warning, it says you're missing a symbols file. Since
  it's a C project, I strongly suggest you to make one (I personally dislike
  C++ symbols files, but that's just me). Please read more at
  http://wiki.debian.org/UsingSymbolsFiles

Please re-ping me once you fixed all this, or if you have any doubt/question.

Thank you for your work,
David

-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: RFS: libgis - virtual globe library

[Benoît Knecht]

Hi Andy,

Andy Spencer wrote:
 I am looking for a sponsor for my package libgis.
 
 * Package name: libgis
   Version : 0.4.1-1
   Upstream Author : Andy Spencer (myself)
 * URL : http://lug.rose-hulman.edu/code/projects/libgis/wiki
 * License : GPL-3+
   Section : science
 
 It builds these binary packages:
 libgis - A Virtual Globe library
 libgis-bin - Example programs for libgis
 libgis-dev - Development files for libgis
 libgis-doc - HTML documentation for libgis

I had a closer look at your package, and additionally to David's
comments, I noticed the following:

 - In debian/control, libgis-bin should depend on ${shlibs:Depends}
   instead of listing all the libraries explicitly. And I don't think
   libgis-doc should Depend on libgis (but it could Recommend it, and
   libgis could Suggest libgis-doc).

 - In debian/docs, remove the ChangeLog entry; it is installed and
   gzipped automatically.

 - You should delete debian/lintian.txt (after reading it :-) ).

Cheers,

-- 
Benoît Knecht


-- 
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/20101113102747.gb3...@debian.lan

Re: RFS: dbxml

[Michael Tautschnig]

Hi Jeroen,

 Dear Mentors,
 
 I am looking for a sponsor for my package dbxml.
 
 * Package name: dbxml
   Version : 2.5.16-1
   Upstream Author : Oracle
 * URL : 
 http://www.oracle.com/technology/software/products/berkeley-db/db/index.html
 * License : BSD and Apache 1.1
   Section : unknown
 

[...]

Thank you for tackling this large piece of software.  I just did a review of the
most basic Debian packaging stuff, I did not check proper function.

- debian/changelog: squeeze is not a valid upload destination, you want
  unstable or even experimental.
- debian/control: Section: unknown is no good. Current Standards-Version would
  be 3.9.1. You want default-jdk, not default-jdk-builddep. All description are
  extremly short. Maybe a common text describing what Oracle Berkeley DB XML
  is, how it differs from other libraries, etc.  would be good for all packages.
  The current descriptions would then serve as second stanza.
- debian/copyright: You have no give the license of your packaging. It might
  also make sense to go for DEP-5 format (http://dep.debian.net/deps/dep5/)
- debian/dbxml-doc.{docs,install}: What does #DOCS# stand for?
- libdbxml-java-gcj.post{inst,rm}: You must handle the various arguments that
  the post{inst,rm} might be called with. See
  http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
- debian/README.{Debian,source}: Read their contents and act accordingly.

Package does not build:

cd dbxml  /usr/bin/make clean
make[1]: Entering directory `/home/tautschnig/debian/dbxml/dbxml-2.5.16/dbxml'
make[1]: *** No rule to make target `clean'.  Stop.
make[1]: Leaving directory `/home/tautschnig/debian/dbxml/dbxml-2.5.16/dbxml'
make: *** [clean] Error 2

You probably want to ignore errors in this step - a fresh download must be
configured before doing the make clean.

Hope this helps,
Michael



pgpgB85IXQGSZ.pgp
Description: PGP signature

RFS: icoutils (updated package)

[Markus Schölzel]

 Am 11.11.2010 17:46, schrieb Benoît Knecht:

Hi Markus,

Markus Schölzel wrote:

I am looking for a sponsor for the new version 0.29.1-0.1
of my package icoutils.

It builds these binary packages:
icoutils   - Create and extract MS Windows icons and cursors

The package appears to be lintian clean.

The upload would fix these bugs: 511944, 516170, 589377

Since you're fixing a man page typo in this release (bug #516170), do you think
you could fix those lintian warnings as well?

   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/extresso.1.gz:63
   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/extresso.1.gz:64
   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:65
   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:66
   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:83
   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:87
   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:91
   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:107
   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:115
   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:121
   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:163
   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:164
   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz 12 
more occurrences not shown
   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:44
   I: icoutils: spelling-error-in-manpage usr/share/man/man1/wrestool.1.gz 
preceeded preceded
   I: icoutils: spelling-error-in-manpage usr/share/man/man1/wrestool.1.gz 
preceeded preceded
   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:60
   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:80
   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:85
   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:174
   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:175
   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:176
   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:177
   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:178
   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:182
   I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz 2 
more occurrences not shown

There are also two lintian --pedantic warnings that should be easy
enough to fix:

   P: icoutils: copyright-refers-to-symlink-license 
usr/share/common-licenses/GPL
   P: icoutils: no-homepage-field

Thanks for your hint!
May you want to have a look at
- URL:http://mentors.debian.net/debian/pool/main/i/icoutils
- 
dgethttp://mentors.debian.net/debian/pool/main/i/icoutils/icoutils_0.29.1-0.2.dsc

Now there should not come up I: or P: warnings anymore.

Kind regards,
Markus Schölzel



--
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/4cde6d49.2000...@web.de

Re: RFS: libvdpau (updated package)

[Holger Levsen]

Hi Michael,

On Freitag, 12. November 2010, Michael Gilbert wrote:
 but
 is it really necessary to spend so much effort to contact the
 maintainer (bullets 2, 4, and 5)?

Yes.

Also, your NMU attempt was about a RC bug you filed yourself (and recently 
before). I think the wait longer to give maintainers time to reply part was 
covered well in this thread, but not the part because you filed that bug 
part.

It's one thing, to file a bug correctly. And it's another, to find the right 
fix. You provided both (nothing wrong with that alone!) and then asked for 
sponsoring the upload immediatly.

Thats not good.


cheers,
Holger, who wanted to do the same a few days ago (#602765) and was 
quickly 
convinced (on irc, not in the bug log) that was a bad idea. Today I'll NMU 
though.


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

Re: RFS: icoutils (updated package)

[Benoît Knecht]

Markus Schölzel wrote:
 May you want to have a look at
 - URL:http://mentors.debian.net/debian/pool/main/i/icoutils
 - 
 dgethttp://mentors.debian.net/debian/pool/main/i/icoutils/icoutils_0.29.1-0.2.dsc
 
 Now there should not come up I: or P: warnings anymore.

You seem to have a debian directory inside the debian directory
(debian/debian), not sure how that happened.

Other than that it seems okay, although I cannot comment on the software
itself, I didn't try to run it.

Cheers,

-- 
Benoît Knecht


-- 
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/20101113141314.gc3...@debian.lan

Re: RFS: 9menu (updated package, Second try)

[Benoît Knecht]

Hi,

epsilon wrote:
 I am looking for a sponsor for the new version 1.8-4
 of my package 9menu.
 
 It builds these binary packages:
 9menu  - Creates X menus from the shell

You can further simplify your debian/rules file by letting debhelper
know what to do through files in debian/ instead of overrides. For
example, instead of overriding dh_clean, you can list additional files
to be removed in debian/clean. Same thing for dh_installman and
dh_installdocs.

Cheers,

-- 
Benoît Knecht


-- 
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/20101113142557.gd3...@debian.lan

Re: RFS: libmatheval (updated package)

[Michael Tautschnig]

Hi Julian,

[...]

 
 Unfortunately I only just realized this probably changes the abi (function
 definition changed) and thus a soname bump. I'll have to look into this with
 more detail.
 So this RFS was probably a bit premature, but I would still be grateful for
 an review of what is already done as this is my first package.
 

[...]

Thank you very much for updating this package to match current packaging
best-practice. Having checked the debdiff to the package currently in the
archives, to me it looks pretty good, you should only fix one more thing:

I: libmatheval source: binary-control-field-duplicates-source field section 
in package libmatheval1

Once you have also done the soname bump, please also consider introducing symbol
control files. It could help to ensure you cannot accidentally miss such soname
bumps.

Hope this help,
Michael



pgp5fLz501rMO.pgp
Description: PGP signature

Re: RFS: sima (autoqueue MPD client, find similar artists to queue)

[Geoffroy Youri Berret]

Le 12/11/2010 10:55, Michal Čihař a écrit :
 Dne Fri, 12 Nov 2010 10:30:51 +0100
 Geoffroy Youri Berret ef...@azylum.org napsal(a):
 
 The package can be found on mentors.debian.net:
 - URL: http://mentors.debian.net/debian/pool/main/s/sima
 - Source repository: deb-src http://mentors.debian.net/debian unstable
 main contrib non-free
 - dget http://mentors.debian.net/debian/pool/main/s/sima/sima_0.6.0-1.dsc
 
 The upstream tarball name is mpd_sima, maybe you want to name source
 package same way?
 
 Why have you modified the source tarball?

I thought the underscore is not allowed.
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Source

Anyone to confirm?

In case it is, should I follow a specific policy to name the package?

Thanks for the review :)
Cheers
Geoff


-- 
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/4cdea6f5.70...@azylum.org

Re: RFS: bluecove, bluecove-gpl

[Michael Tautschnig]

Hi Chris,

 Dear mentors,
 
 I am looking for a sponsor for my packages bluecove and
 bluecove-gpl.
 
   Package name: bluecove
   Version : 2.1.0-1
   Upstream Author : Many
   URL : http://bluecove.org
   License : LGPL and GPL
   Section : java and libs
 
 Bluecove builds these binary packages:
 libbluecove-2.1.0-java - Java library for Bluetooth (JSR-82
 implementation)
 

I briefly reviewed the copyright information of libbluecove and was kind of
irritated by README and LICENSE saying it is LGPL while *all* (well, a few even
missing license/copyright information) the source files say it is Apache 2.0
licensed!? Could you please get some clarifification from upstream?

Please get this fixed first as BlueCove-GPL relies on this one and cannot be
built without it.

 BlueCove-GPL builds these binary packages:
 libbluecove-gpl-2.1.0 - additional module for BlueCove support on Linux
 (native library)
 libbluecove-gpl-2.1.0-java - additional module for BlueCove support on
 Linux (java library)
 
 BlueCove is lintian clean however BlueCove-GPL has two warnings:
 E: libbluecove-gpl-2.1.0:
 sharedobject-in-library-directory-missing-soname
 usr/lib/libbluecove-2.1.0.so
 W: libbluecove-gpl-2.1.0:
 library-not-linked-against-libc ./usr/lib/libbluecove-2.1.0.so
 
 I would appreciate help with these as I have run out of ideas. 
 

Run lintian with the additional flag -i to get a more detailed description,
which can also be found here:

http://lintian.debian.org/tags/sharedobject-in-library-directory-missing-soname.html
http://lintian.debian.org/tags/library-not-linked-against-libc.html

 The other small issue with the packages is the Maintainer, I created a
 Java package recently (ant-contrib-cpptasks), for which the Maintainer
 is the Debian Java Maintainers
 pkg-java-maintain...@lists.alioth.debian.org, should this package (as
 its a java package) have this Maintainer also?
 

[...]

I guess this is up to you, whether you prefer future team maintenance or would
like to stay the lone maintainer of these packages.

Hope this helps,
Michael



pgpYSVR1VlqxE.pgp
Description: PGP signature

Re: RFS: dalle

[Michael Tautschnig]

Hi Alberto,

 Hi,
 
 I've uploaded a new package for review. Summary:
 - Cleaned changelog. Added a thaks to Mònica.
 - All source files now have license header (I didn't know
 licensecheck ...)
 - Email sent to the Pkg-mono-devel mailing list for help, review and
 sponsor.
 - copyright file changed to DEP5
 

Thanks a lot for taking all this into account. From this point of view, the
package looks really fine now. I would, however, hope that someone from
pkg-mono-devel takes the time to review your package from a mono perspective and
sponsor afterwards.

 I've one question about licenses, as author of the software.
 
 I've taken some Apache-2 licensed code on dalle (GPL3). I've ported the
 java code to c# (trivial). How do I have to license that files?
 

[...]

Maybe someone else on this list knows (I don't), but probably asking on
debian-le...@lists.debian.org is a much safer bet. I'd hope you can fine someone
good knowledge on that list.

Hope this helps,
Michael



pgptv30SWOBVd.pgp
Description: PGP signature

Re: RFS: libgis - virtual globe library

[Andy Spencer]

On 2010-11-13 10:21, Benoît Knecht wrote:
 I didn't really look at your package yet, but I just wanted to point out
 that you're not closing any bugs with this release. You're supposed to
 file a bug against WNPP (Work-Needing and Prospective Packages) and note
 in the debian/changelog entry that this package would be closing that
 bug. See [1] for details about the procedure.

Thanks, I've filed bug #603393 [1], added it to debian/changelog, and
noted it in the comment field on mentors.debian.net.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603393


pgpEN3Cag7NuN.pgp
Description: PGP signature

Re: RFS: pycam

[Benoît Knecht]

Hi Lars,

Lars Kruse wrote:
 I am looking for a sponsor for my package pycam.
 
 * Package name: pycam
   Version : 0.4-1
   Upstream Author : Lode Leroy, Lars Kruse (that's me)
 * URL : http://pycam.sourceforge.net
 * License : GPL3
   Section : python
 
 It builds these binary packages:
 pycam  - CAM program  library written in Python

Here are the few issues I spotted in your package:

 - You have debian/{postinst,prerm} scripts, but they do not do
   anything. You should just delete them.

 - In debian/copyright, there is no email address for either of the
   maintainers (and Sebastian Kuzminsky's email is not formatted
   correctly). While you're at it, you should also add yourself to the
   packaging copyright.
   You may also want to use the DEP-5 format [1] for that file.

   [1] http://dep.debian.net/deps/dep5/

 - lintian -I gives the following warnings:
 I: pycam source: quilt-patch-missing-description 
00.remove_windows_install_script.patch
 I: pycam source: quilt-patch-missing-description 
01.remove-superfluous-files-from-doc.patch
 I: pycam source: debian-watch-file-is-missing
   and these three about the man page:
 I: pycam: spelling-error-in-manpage usr/share/man/man1/pycam.1.gz 
paramters parameters
 I: pycam: hyphen-used-as-minus-sign usr/share/man/man1/pycam.1.gz:248
 I: pycam: hyphen-used-as-minus-sign usr/share/man/man1/pycam.1.gz:261
   It would be nice if you could fix them.

Cheers,

-- 
Benoît Knecht


-- 
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/20101113175722.ga31...@debian.lan

Re: RFS: libgis - virtual globe library

[Andy Spencer]

On 2010-11-13 10:58, David Paleino wrote:
 IMHO, the name of your project is rather too generic (libgis). It should be
 changed to something more descriptive, but that's your choice as upstream at
 the end.

 Apart from this, you're very welcome to maintain it under the Debian GIS Team
 umbrella. To join us, please join the pkg-grass [0] project on
 alioth.debian.org.
 
 [0]: https://alioth.debian.org/projects/pkg-grass/

I've never been good with names :) I agree that it is a little generic,
but I would rather leave it the way it is. I can't find any conflicts in
Contents-i386 and googling for libgis seems to indicate that it's a
fairly unique name, apart from a subsection of GRASS.

Maintaining it under the Debian GIS Team would be nice. That website
looks pretty GRASS-specific though, would it be suitable for a non-GRASS
related package?


 - In debian/control, you misinterpreted the meaning of Vcs-* fields. Those
   should point to the location where the Debian packaging is kept, while you
   pointed at the upstream repository. You can choose to maintain the debian/
   dir there as well, or host it on Alioth within the Debian GIS Team (which
   would be better for team-maintainance).

Oops, I've removed the links for now and will add proper links once
version control is set up for the debian files. Alioth seems like a good
place, I'll look into how that works.


 - Why is libgis-doc an arch:any package? I didn't check its contents, but I
   suspect it should be arch:all. ;)

Fixed :)


 - You might want to use DEP-5 format for your debian/copyright. Read more at
   http://dep.debian.net/deps/dep5/ . It's entirely optional, and it won't be a
   stopper if you leave it like it is now.

That looks like a nice format, I've change debian/copyright accordingly.


 - In libgis-dev.install , please avoid installing *.a files. We (as Debian) 
 are
   deprecating them, and installing them in a brand new package is a bad thing.

Removed.


 - Your package doesn't seem to be lintian clean ;-) -- you pasted lintian's
   output in debian/lintian.txt, and there it clearly says to a) close an ITP
   bug and b) use a proper name for the binary (point 2 of my comments). Next
   time please read it ;)

The first lintian file I generated was actually much bigger ;)
  a) Fixed now (per Benoît's email) #603393 for reference
  b) I wanted to discuss this one a little further before trying to
 correct it. (See below)

Another point of interest is that mentors.debian.net says:
  intian warnings: none
  intian errors:   none
Even though there were some warnings. I copied the `lintian clean'
message from the template it generated, but I'm not sure if it generated
the `lintian clean' part or if that was hard coded.


 - Library packaging in Debian has to follow certain policies. The binary
   package you're producing should be named libgisSONAME (i.e. libgis0, or
   similar). This ensures that any dependant package depends on the correct
   version of the library.

 - Always in the lintian warning, it says you're missing a symbols file. Since
   it's a C project, I strongly suggest you to make one (I personally dislike
   C++ symbols files, but that's just me). Please read more at
   http://wiki.debian.org/UsingSymbolsFiles

(I wanted to address these comments together)

Personally, I'm not too concerned with the symbols file, or library
versioning at all for that matter. Now, I had better clarify before
someone bashes me with the libtool manual ;)

As I mentioned in my initial email, libgis was developed to support
another program called AWeather. Since AWeather is the only program that
currently uses libgis and it depends on the latest version anyway, I
don't expect there to be very many issues with library versioning. 

That being said, if/when I hear about other people wanting to use libgis
in their own programs (which I hope they will) I will start caring much
more about library versioning, a stable API, etc.

Anyway, I suspect some library versioning will be required, but I think
doing as little as possible would (for now) be the most efficient way to
go. Does this sound correct for package names, or can I do without the
0.4?

  - libgis-0.4-0
  - libgis-0.4-dev
  - libgis-0.4-bin
  - libgis-0.4-doc

  (using -version-info 0:0:0 -release 0.4.1)


Thanks for all the comments. I'll build and post another set of packages
this evening with these (and other) changes.


pgp4iRhkm18jD.pgp
Description: PGP signature

Re: RFS: libgis - virtual globe library

[David Paleino]

On Sat, 13 Nov 2010 19:20:23 +, Andy Spencer wrote:

 On 2010-11-13 10:58, David Paleino wrote:
  IMHO, the name of your project is rather too generic (libgis). It should
  be changed to something more descriptive, but that's your choice as
  upstream at the end.
 
  Apart from this, you're very welcome to maintain it under the Debian GIS
  Team umbrella. To join us, please join the pkg-grass [0] project on
  alioth.debian.org.
  
  [0]: https://alioth.debian.org/projects/pkg-grass/
 
 I've never been good with names :) I agree that it is a little generic,
 but I would rather leave it the way it is. I can't find any conflicts in
 Contents-i386 and googling for libgis seems to indicate that it's a
 fairly unique name, apart from a subsection of GRASS.
 
 Maintaining it under the Debian GIS Team would be nice. That website
 looks pretty GRASS-specific though, would it be suitable for a non-GRASS
 related package?

Yes. The team is named pkg-grass mainly for historical reasons, now it
maintains all sorts of GIS-related software -- from GRASS to OpenStreetMap
things.

  - In debian/control, you misinterpreted the meaning of Vcs-* fields. Those
should point to the location where the Debian packaging is kept, while you
pointed at the upstream repository. You can choose to maintain the debian/
dir there as well, or host it on Alioth within the Debian GIS Team (which
would be better for team-maintainance).
 
 Oops, I've removed the links for now and will add proper links once
 version control is set up for the debian files. Alioth seems like a good
 place, I'll look into how that works.

If you join pkg-grass, you could ssh into alioth and do:

$ cd /git/pkg-grass/
$ ./setup-repository libgis 'some description'

After that, you can use git.debian.org/git/pkg-grass/libgis.git as remote in
your packaging repository. Most (if not all) of the packages there use the
git-buildpackage layout -- you might want to read about git-import-origin,
git-import-dsc and git-buildpackage.

 [..]
  - Your package doesn't seem to be lintian clean ;-) -- you pasted lintian's
output in debian/lintian.txt, and there it clearly says to a) close an ITP
bug and b) use a proper name for the binary (point 2 of my comments). Next
time please read it ;)
 
 The first lintian file I generated was actually much bigger ;)
   a) Fixed now (per Benoît's email) #603393 for reference
   b) I wanted to discuss this one a little further before trying to
  correct it. (See below)

Ack.

 Another point of interest is that mentors.debian.net says:
   intian warnings: none
   intian errors:   none
 Even though there were some warnings. I copied the `lintian clean'
 message from the template it generated, but I'm not sure if it generated
 the `lintian clean' part or if that was hard coded.

Well, no. AFAICT, mentors.debian.net doesn't use sid's lintian -- while a
maintainer should always use that one.

  - Library packaging in Debian has to follow certain policies. The binary
package you're producing should be named libgisSONAME (i.e. libgis0,
  or similar). This ensures that any dependant package depends on the correct
version of the library.
 
  - Always in the lintian warning, it says you're missing a symbols file.
  Since it's a C project, I strongly suggest you to make one (I personally
  dislike C++ symbols files, but that's just me). Please read more at
http://wiki.debian.org/UsingSymbolsFiles
 
 (I wanted to address these comments together)
 
 Personally, I'm not too concerned with the symbols file, or library
 versioning at all for that matter. Now, I had better clarify before
 someone bashes me with the libtool manual ;)

Yeah. Such statements don't usually pass unpunished :-)

 As I mentioned in my initial email, libgis was developed to support
 another program called AWeather. Since AWeather is the only program that
 currently uses libgis and it depends on the latest version anyway, I
 don't expect there to be very many issues with library versioning. 
 
 That being said, if/when I hear about other people wanting to use libgis
 in their own programs (which I hope they will) I will start caring much
 more about library versioning, a stable API, etc.

Uploading a library in Debian, you're giving other users the chance to use it,
and link against it. Even for private (as in not-published) projects. And
breaking users' software for no reason isn't good ;)

 Anyway, I suspect some library versioning will be required, but I think
 doing as little as possible would (for now) be the most efficient way to
 go. Does this sound correct for package names, or can I do without the
 0.4?
 
   - libgis-0.4-0
   - libgis-0.4-dev
   - libgis-0.4-bin
   - libgis-0.4-doc

Nope.
What's required in the package name is the SONAME, which in your case is 0. So
the packages should look like:

- libgis0
- libgis-bin
- libgis-dev
- libgis-doc

Why the SONAME is only on the shared library package? Because it's 

Re: RFS: lightspeed (updated package)

[Ansgar Burchardt]

Hi,

sorry for the late reply.

Tony Palma xbyt...@gmail.com writes:
 I notified the author and upload the package to mentors with a very
 large patch(build-update.diff). Now I'm using 
 dh $@ --with autotools_dev
 and their respectives overrides, to manage the updates of
 config.{guess,sub}.

There are still changes to these files in the diff:

  lightspeed-1.2a/config/config.sub
  lightspeed-1.2a/config/config.guess

They should not be included in the diff.

You might also want to update ./configure (and Makefile.in) itself in
d/rules, for example by using dh-autoreconf, instead of including these
rather large changes in the diff.

Is the copy of libintl necessary? At least information about it is
missing in debian/copyright:

  lightspeed-1.2a/intl/* (included in the diff)

Some of the override_* targets in debian/rules are not necessary:
dh_installchangelogs will install the ChangeLog file even when you do
not pass the file name explicitly.  You might also want to use
debian/${package}.docs and debian/${package}.manpages instead of using
override_* targets for dh_installdocs (dh_installman).

Regards,
Ansgar


-- 
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/87sjz47th6@marvin.43-1.org

Re: RFS: kstars-data-extra-tycho2 (third try)

[Michael Tautschnig]

Hi again,

I think sounded pretty rude in my earlier mail; I'm sorry, I didn't mean to be
rude. I just had got the impression that you were waving away other people's
suggestions for no reason obvious to me.

[...]

  
  Would you mind to elaborate in what respect this is going to be more than
  your little pet package? Is kstars that often installed on true multi-user
  systems such that a quick hack is warranted?
 
 I do not want a quick hack but a truly good package that allows users to have 
 their systems fully installed through Debian packaging systems. I do not know 
 why one needs to download data from the network for a program that is 
 packaged: kstars data is not a non-distributable PDF reader to need an 
 installer outside the packaging system. Is it?
 

You're right; I just hadn't fully accepted that is was a simple data package
that will ensure the data doesn't get stored for each and every user, but just
once and for all on the system.

[...]

  
  I find it very unfortunate that you refuse to integrate with existing
  Debian work right from the start. Given that your package is unlikely to
  make it into Squeeze anyway, IMHO there is no need to hurry. Why not
  prepare a nicely integrated package right away, what would you expect to
  gain from this first shot if you'll later plan to transition to
  stardata-common anyway?
 
 I agree that there is no hurry, but I'm working on the set to have it in 
 shape 
 for wheezy. Would you prefer for me to wait?
 

Oh no, surely not, I was rather hoping that ...

 About the transition to stardata-common, the problem with that is that I'm 
 still not convinced that it is compatible with this package set. The source 
 for this version of the Tycho2 package is not the original data as-is but a 
 subset of it, but even the stardata-common concept may be not applicable to 
 other packages of the set like ephemerides, DST rules, images or icons, as 
 stardata-common is Common framework for handling stardata catalogues in 
 Debian and not anything similar to Common framework for handling 
 astronomical and related data in Debian.
 

[...] (more detailed explanation of your point)

... you could go for stardata-common right now. This might be a bit more work
(and you would hence possibly miss the Squeeze freeze), but I still believe in
it being beneficial. It would actually even more reduce the disk space and band
width usage if several packages shared such data. I understand that this is
non-trivial. So why was I panicking? Once the package has entered the archive,
it will stay. It does what you wanted it to do, and it will be hard to enforce
any changes. Here and now is my only chance to try to convince you to follow a
different route. Of course, bugs could be filed, but none of them would be of
release-critical severity.

  Please don't feel offended in any way, but I'm not going to sponsor such a
  package. Of course many others might have a very different attitude and
  will take it, so just don't count on me.
 
 I'm not offended: I try to learn from everybody's comments, either 
 constructive or not, but it seems to me (personal humble opinion) that you 
 missed the point of these packages. I think that a good enough solution is 
 better than an asimptotycally unreachable perfect one, moreover if it is 
 later 
 improvable, and even if the perfect solution is actually reachable but in a 
 long term.
 

[...]

I think I got the point of your packages and while I might still not be the one
sponsoring them, it would be for technical reasons only (my knowledge of KDE
stuff is really limited). Which may not make a difference for you, but at least
for me it was important to have my attitude adjusted. I still hope that there is
a convergence towards a common data set for packages interested in the same
data, but it shall not block an initial upload.

Best regards,
Michael



pgpA3ifkdtutZ.pgp
Description: PGP signature

kredit tanpa agunan scb solusi keuangan anda

[SOLUSI]

Personal loan  atau kredit tanpa agunan dari standard chartered bank
memberikan 
pinjaman hingga Rp.150.000.000 , bunga hingga 1,50 %  / bulan.Proses yang
mudah dan cepat  
7- 10  hari kerja dengan  kepastian approval yg tinggi


DATA YG DIBUTUHKAN UNTUK PENGAJUAN  1 BUNGA 1,50 %:
1.Foto copy KTP
2.Foto copy Credit Card 
3.Foto copy billing credit card 1 bulan terakhir
4.Foto copy NPWP untuk pinjaman diatas Rp.50 juta
5.Foto Copy nomor rek.tabungan
6.Materai Rp. 6.000 1 bh.



Untuk keterangan lebih lanjut hubungi :


HARTAWAN
0858-83824829
Or
harta...@yahoo.co.id


-- 
View this message in context: 
http://old.nabble.com/kredit-tanpa-agunan-scb-solusi-keuangan-anda-tp30210584p30210584.html
Sent from the debian-mentors mailing list archive at Nabble.com.


-- 
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/30210584.p...@talk.nabble.com

Re: RFS: icoutils (updated package)

[Paul Wise]

2010/11/11 Markus Schölzel m-schoel...@web.de:

 I am looking for a sponsor for the new version 0.29.1-0.1
 of my package icoutils.

I pinged the maintainer, Colin Watson, about your upload on IRC. I
would suggest that you get in touch with him via mail.

New upstream versions are not appropriate for unstable at this stage
in the release cycle.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
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/aanlktik_irasejr7v19tps8rysj+bx3elc94irhr+...@mail.gmail.com