RFS: qmagneto

[Jean-Luc Biord]

Dear mentors,

I am looking for a sponsor for my package "qmagneto".

* Package name : qmagneto
Version : 1.3-4
Upstream Author : Jean-Luc Biord <***@gmail.com>
* URL : http://biord-software.org/qmagneto/
* License : GPL
Section : graphics

It builds these binary packages:
qmagneto - QMagneto is an EPG (Electronic Program Guide) which
displays the TV programs. It also able to record programs by call an
external program as
VLC or mencoder. It is thus possible to record programs from a french
BOX (Neufbox or Freebox) or a DVB-T device.


The package appears to be lintian clean.

The upload would fix these bugs: 603806

My motivation for maintaining this package is: Provide a new EPG for
debian compatible with the XMLTV format.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/q/qmagneto
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/q/qmagneto/qmagneto_1.3-4.dsc

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

Kind regards
Jean-Luc Biord

[Paul Tagliamonte]

Post by Jean-Luc Biord
Dear mentors,
I am looking for a sponsor for my package "qmagneto".
* Package name : qmagneto
Version : 1.3-4
* URL : http://biord-software.org/qmagneto/
* License : GPL
Section : graphics
qmagneto - QMagneto is an EPG (Electronic Program Guide) which displays
the TV programs. It also able to record programs by call an external program
as
VLC or mencoder. It is thus possible to record programs from a french BOX
(Neufbox or Freebox) or a DVB-T device.
The package appears to be lintian clean.
The upload would fix these bugs: 603806
My motivation for maintaining this package is: Provide a new EPG for debian
compatible with the XMLTV format.
- URL: http://mentors.debian.net/debian/pool/main/q/qmagneto
- Source repository: deb-src http://mentors.debian.net/debian unstable main
contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/q/qmagneto/qmagneto_1.3-4.dsc
I would be glad if someone uploaded this package for me.
Kind regards
Jean-Luc Biord

One lintian warning with your dsc:

W: qmagneto source: out-of-date-standards-version 3.8.4 (current is 3.9.1)

postinst should be qmagneto.postinst
install should be qmagneto.install
menu should be qmagneto.menu

manpages is empty, you should delete that file.
docs is empty, you should delete that file

watch is empty, you should fix it.

As much as I love Ubuntu, you should not have Ubuntu versions in the
Changelog. This looks like a new package, so this must be left over
from your PPA. FYI, the versions should be appended with ~ppaN. That's
secondary to the fact that they should not be here :)

You should also be on revision qmagneto_1.3-1, not 4.

Remove all the old uploads from the file, and close an ITP on the
upload. If you don't have an ITP you should create one.

Your desktop file has an error:

qmagneto.desktop: warning: key "Encoding" in group "Desktop Entry" is deprecated

You should fix this as well.

I did not build the application, my netbook has a hard time. I'll
build it and look at the debs when I get back to my computer.

Cheers,
Paul
--
All programmers are playwrights, and all computers are lousy actors.

#define sizeof(x) rand()
:wq

[Paul Tagliamonte]

[snip]

Post by Paul Tagliamonte
W: qmagneto source: out-of-date-standards-version 3.8.4 (current is 3.9.1)
postinst should be qmagneto.postinst
install should be qmagneto.install
menu should be qmagneto.menu
manpages is empty, you should delete that file.
docs is empty, you should delete that file
watch is empty, you should fix it.
As much as I love Ubuntu, you should not have Ubuntu versions in the
Changelog. This looks like a new package, so this must be left over
from your PPA. FYI, the versions should be appended with ~ppaN. That's
secondary to the fact that they should not be here :)
You should also be on revision qmagneto_1.3-1, not 4.
Remove all the old uploads from the file, and close an ITP on the
upload. If you don't have an ITP you should create one.

Sorry, I see you have one, and you're closing it. Just move the
changelog entry to the bottom and get rid of all the other entries.

Also, the close should be the only thing on that line. It's good
you're noting changes, but you don't need to on the first upload. You
should also wrap lines earlier, 80 wide is normal.

Post by Paul Tagliamonte
qmagneto.desktop: warning: key "Encoding" in group "Desktop Entry" is deprecated
You should fix this as well.
I did not build the application, my netbook has a hard time. I'll
build it and look at the debs when I get back to my computer.

Sidenote before I get to the goodies: It looks like you ship the logos
of some channels in your source. Does this comply with their license?
Can you do that? I'm pretty sure there might be an issue with doing
that. Please double check, and email debian-legal if you are unsure.
That could be enough for the ftp-masters to deny the package.

( but it is impressive how much work you went through for that )

So, I built your package, it built fine. You do, however, have a
litany of issues with the deb:

E: qmagneto: description-starts-with-package-name
I: qmagneto: description-synopsis-might-not-be-phrased-properly
W: qmagneto: description-too-long
E: qmagneto: extended-description-is-empty
P: qmagneto: no-homepage-field
P: qmagneto: copyright-refers-to-symlink-license usr/share/common-licenses/GPL
I: qmagneto: desktop-entry-contains-encoding-key
/usr/share/applications/qmagneto.desktop:2 Encoding
E: qmagneto: menu-item-creates-new-root-section user /usr/share/menu/qmagneto:4
P: qmagneto: no-upstream-changelog
W: qmagneto: syntax-error-in-debian-changelog line 68 "badly formatted
trailer line"
W: qmagneto: syntax-error-in-debian-changelog line 77 "badly formatted
trailer line"
W: qmagneto: debian-changelog-line-too-long line 1
W: qmagneto: binary-without-manpage usr/bin/qmagneto
W: qmagneto: maintainer-script-ignores-errors postinst
E: qmagneto: missing-dependency-on-libc needed by ./usr/bin/qmagneto


I'd fix these up while you're in there working on the debdir. Good luck!


Hope to see the package fixed up!
-Paul
--
All programmers are playwrights, and all computers are lousy actors.

#define sizeof(x) rand()
:wq

[Julien Viard de Galbert]

I'm not DD either, but I have some comments...

Post by Paul Tagliamonte

Post by Jean-Luc Biord
Dear mentors,
I am looking for a sponsor for my package "qmagneto".
* Package name : qmagneto
Version : 1.3-4
* URL : http://biord-software.org/qmagneto/
* License : GPL
Section : graphics
qmagneto - QMagneto is an EPG (Electronic Program Guide) which displays
the TV programs. It also able to record programs by call an external program
as
VLC or mencoder. It is thus possible to record programs from a french BOX
(Neufbox or Freebox) or a DVB-T device.
The package appears to be lintian clean.
The upload would fix these bugs: 603806
My motivation for maintaining this package is: Provide a new EPG for debian
compatible with the XMLTV format.
- URL: http://mentors.debian.net/debian/pool/main/q/qmagneto
- Source repository: deb-src http://mentors.debian.net/debian unstable main
contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/q/qmagneto/qmagneto_1.3-4.dsc
I would be glad if someone uploaded this package for me.
Kind regards
Jean-Luc Biord

W: qmagneto source: out-of-date-standards-version 3.8.4 (current is 3.9.1)
postinst should be qmagneto.postinst
install should be qmagneto.install
menu should be qmagneto.menu
manpages is empty, you should delete that file.
docs is empty, you should delete that file
watch is empty, you should fix it.
As much as I love Ubuntu, you should not have Ubuntu versions in the
Changelog. This looks like a new package, so this must be left over
from your PPA. FYI, the versions should be appended with ~ppaN. That's
secondary to the fact that they should not be here :)
You should also be on revision qmagneto_1.3-1, not 4.

I'm not 100% sure the rule is that strict here, you probably want to
keep the upgrade path easy for the users, and the current ppa version
did not use the ~ (in debian version ordering ~ is before anything,
even before the empty string) so you might need to keep it -4.
I think I've already seen such an explanation before on mentors but I
couldn't find the reference just now...
(an other option would be to do a new upstream release, if you have
some fix for it, and then adjust the ppa version to 1.4-1~ppa1 and
the debian one to 1.4-1)

Also your qmagneto_1.3.orig.tar.gz file should normally be the result
of just renaming the upstream release tarball (the one the watch file
should be trying to find)

Post by Paul Tagliamonte
Remove all the old uploads from the file, and close an ITP on the
upload. If you don't have an ITP you should create one.

Well actually #603806 is the ITP, but it should be more obvious,
the debian new maintainers' guide propose the following wording:

* Initial release (Closes: #603806)

Post by Paul Tagliamonte
qmagneto.desktop: warning: key "Encoding" in group "Desktop Entry" is deprecated
You should fix this as well.
I did not build the application, my netbook has a hard time. I'll
build it and look at the debs when I get back to my computer.
Cheers,
Paul
--
All programmers are playwrights, and all computers are lousy actors.
#define sizeof(x) rand()
:wq

Hope this helps,

[Jean-Luc Biord]

Hi,

I fixed many issues:

W: qmagneto source: out-of-date-standards-version 3.8.4 (current is 3.9.1)
Now with 3.9.1 version

postinst should be qmagneto.postinst
install should be qmagneto.install
menu should be qmagneto.menu
The files are renamed

manpages is empty, you should delete that file.
I created one

docs is empty, you should delete that file
ok, deleted

watch is empty, you should fix it.
Fixed but partially

qmagneto.desktop: warning: key "Encoding" in group "Desktop Entry" is
deprecated
Fixed

If anyone wants to check again.

Regards,
Jean-Luc Biord

Post by Julien Viard de Galbert
I'm not DD either, but I have some comments...

Post by Paul Tagliamonte

Post by Jean-Luc Biord
Dear mentors,
I am looking for a sponsor for my package "qmagneto".
* Package name : qmagneto
Version : 1.3-4
* URL : http://biord-software.org/qmagneto/
* License : GPL
Section : graphics
qmagneto - QMagneto is an EPG (Electronic Program Guide) which

displays

Post by Paul Tagliamonte

Post by Jean-Luc Biord
the TV programs. It also able to record programs by call an external

program

Post by Paul Tagliamonte

Post by Jean-Luc Biord
as
VLC or mencoder. It is thus possible to record programs from a french

BOX

Post by Paul Tagliamonte

Post by Jean-Luc Biord
(Neufbox or Freebox) or a DVB-T device.
The package appears to be lintian clean.
The upload would fix these bugs: 603806
My motivation for maintaining this package is: Provide a new EPG for

debian

Post by Paul Tagliamonte

Post by Jean-Luc Biord
compatible with the XMLTV format.
- URL: http://mentors.debian.net/debian/pool/main/q/qmagneto
- Source repository: deb-src http://mentors.debian.net/debian unstable

main

Post by Paul Tagliamonte

Post by Jean-Luc Biord
contrib non-free
- dget

http://mentors.debian.net/debian/pool/main/q/qmagneto/qmagneto_1.3-4.dsc

Post by Paul Tagliamonte

Post by Jean-Luc Biord
I would be glad if someone uploaded this package for me.
Kind regards
Jean-Luc Biord

W: qmagneto source: out-of-date-standards-version 3.8.4 (current is

3.9.1)

Post by Paul Tagliamonte
postinst should be qmagneto.postinst
install should be qmagneto.install
menu should be qmagneto.menu
manpages is empty, you should delete that file.
docs is empty, you should delete that file
watch is empty, you should fix it.
As much as I love Ubuntu, you should not have Ubuntu versions in the
Changelog. This looks like a new package, so this must be left over
from your PPA. FYI, the versions should be appended with ~ppaN. That's
secondary to the fact that they should not be here :)
You should also be on revision qmagneto_1.3-1, not 4.

I'm not 100% sure the rule is that strict here, you probably want to
keep the upgrade path easy for the users, and the current ppa version
did not use the ~ (in debian version ordering ~ is before anything,
even before the empty string) so you might need to keep it -4.
I think I've already seen such an explanation before on mentors but I
couldn't find the reference just now...
(an other option would be to do a new upstream release, if you have
some fix for it, and then adjust the ppa version to 1.4-1~ppa1 and
the debian one to 1.4-1)
Also your qmagneto_1.3.orig.tar.gz file should normally be the result
of just renaming the upstream release tarball (the one the watch file
should be trying to find)

Post by Paul Tagliamonte
Remove all the old uploads from the file, and close an ITP on the
upload. If you don't have an ITP you should create one.

Well actually #603806 is the ITP, but it should be more obvious,
* Initial release (Closes: #603806)

Post by Paul Tagliamonte
qmagneto.desktop: warning: key "Encoding" in group "Desktop Entry" is

deprecated

Post by Paul Tagliamonte
You should fix this as well.
I did not build the application, my netbook has a hard time. I'll
build it and look at the debs when I get back to my computer.
Cheers,
Paul
--
All programmers are playwrights, and all computers are lousy actors.
#define sizeof(x) rand()
:wq

Hope this helps,
--
GPG Key ID: D00E52B6 Published on: hkp://keys.gnupg.net
Key Fingerprint: E312 A31D BEC3 74CC C49E 6D69 8B30 6538 D00E 52B6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iQIcBAEBCAAGBQJM9C/5AAoJEIswZTjQDlK2J9YQAI8yhE21lsN24hlBFCbHCn7W
Zcei/sC2ck5BB2oYMnAbhIJfhM/Y0CtyGmY/UAUzzOGyrxlJeklZ+ZtQ+9SUr5Pm
rkhj8wJkOUnzENEzZct4T8lmtvfpemOojBAwwQLJqCNUwGFYsK5qyqGrO8uxEt4D
0YkgULNRm3fWuyqsBRwc7RnrYNfcyiw6JGqnNsqKXskF4d0ArDniy75NToTqeL3M
j9UDW0MepjFS4ARtc//HpWHumnJkqWm5mZSDctbB8f6IOBB7dO+dXTADtYgtZy2x
aBUJmINfCAiivlIwPOkccmpFqvDxCz+Wkp1JPly1aNUxiqRJVNNwg+JTppA99cAj
LWnvrz5TOYTNbE9z3PifBb3zj+LYZugL5aKzJxpKwTpt3owwUhr+KJjaNcATpwP4
71LsoSxQgtiXJ4+T0lyzjsKSwJwjcNCaBLnkIVL+OyZi/dwz/WtngZ92CQrVV6eQ
i74FiUsNdD6i5v+JUvK+C624mzjIgTKQaECK7lGB5Dj7eBK+P/69ZKCIvDIACToy
TTo3xbpCfveJBfuT/ZSwXkOx6GkGJeuK1Rk8XROoOADdge+Vy9SlehczEeiFDvhx
b0XmX+i47KPPghVVWPs/gUjMAljpRTWX4cv7AGqgDVHPcOt4VXfkfXwGtQE5biao
bs15Z1ZXduNAQe6sIaR1
=MHNR
-----END PGP SIGNATURE-----

[Michael Tautschnig]

Hi Jean-Luc,

[...]

Post by Jean-Luc Biord

Post by Jean-Luc Biord
qmagneto - QMagneto is an EPG (Electronic Program Guide) which

displays

Post by Jean-Luc Biord
the TV programs. It also able to record programs by call an external

program

Post by Jean-Luc Biord
as
VLC or mencoder. It is thus possible to record programs from a french

BOX

Post by Jean-Luc Biord
(Neufbox or Freebox) or a DVB-T device.

[...]

(pabs, please excuse the verbatim quote of your text previously used for another
RFS.)

"Seems like this would be a good fit for the Debian multimedia team.
You might like to join them to help maintain other consumer/producer
multimedia software within Debian."

Best regards,
Michael

[Paul Wise]

Post by Michael Tautschnig
(pabs, please excuse the verbatim quote of your text previously used for another
RFS.)

Feel free to use it verbatim or modified as many times as you want :)
--
bye,
pabs

http://wiki.debian.org/PaulWise

[Jean-Luc Biord]

Hi,

Post by Michael Tautschnig
Hi Jean-Luc,
[...]

Post by Jean-Luc Biord

Post by Jean-Luc Biord
qmagneto - QMagneto is an EPG (Electronic Program Guide) which

displays

Post by Jean-Luc Biord
the TV programs. It also able to record programs by call an

external

Post by Jean-Luc Biord
program

Post by Jean-Luc Biord
as
VLC or mencoder. It is thus possible to record programs from a

french

Post by Jean-Luc Biord
BOX

Post by Jean-Luc Biord
(Neufbox or Freebox) or a DVB-T device.

[...]
(pabs, please excuse the verbatim quote of your text previously used for another
RFS.)
"Seems like this would be a good fit for the Debian multimedia team.
You might like to join them to help maintain other consumer/producer
multimedia software within Debian."
Best regards,
Michael
Ok but before helping another sofware in the multimedia team, I want to

works on my software !
My software is stable (2.5 years old) and except (perhaps) the debian
directory for the packaging, will not create a problem for the Debian
distribution. So would be nice if a DD wants to help me.

Best regards,
JL

[Michael Tautschnig]

Hi again,

[...]

Post by Jean-Luc Biord

Post by Michael Tautschnig
"Seems like this would be a good fit for the Debian multimedia team.
You might like to join them to help maintain other consumer/producer
multimedia software within Debian."
Best regards,
Michael
Ok but before helping another sofware in the multimedia team, I want to

works on my software !
My software is stable (2.5 years old) and except (perhaps) the debian
directory for the packaging, will not create a problem for the Debian
distribution. So would be nice if a DD wants to help me.

Oh, sorry, maybe that wasn't quite clear: The idea of joining the Debian
multimedia team would be to get those people have a look at your package as they
might be much more competent. And, if time permits, you could then also give
back by helping them.

Best regards,
Michael

[Jean-Luc Biord]

Hi,

I Changed the section to "misc" because "graphic" was not properly.

I would like anyway a DD who sponsors my software...

Best regards,
JL

Post by Michael Tautschnig
Hi again,
[...]

Post by Jean-Luc Biord

Post by Michael Tautschnig
"Seems like this would be a good fit for the Debian multimedia team.
You might like to join them to help maintain other consumer/producer
multimedia software within Debian."
Best regards,
Michael
Ok but before helping another sofware in the multimedia team, I want to

works on my software !
My software is stable (2.5 years old) and except (perhaps) the debian
directory for the packaging, will not create a problem for the Debian
distribution. So would be nice if a DD wants to help me.

Oh, sorry, maybe that wasn't quite clear: The idea of joining the Debian
multimedia team would be to get those people have a look at your package as they
might be much more competent. And, if time permits, you could then also give
back by helping them.
Best regards,
Michael

[Michael Tautschnig]

Hi,

[...]

I finally got around to take a look at your package. One basic problem must be
solved at first: several files lack license and copyright information:

src/changethumbimpl.h
src/application.cpp
src/changethumbimpl.cpp
src/channeliconitem.h
src/application.h
src/releaseversion.h
src/expandedpixmap.cpp
src/expandedpixmap.h
src/channeliconitem.cpp

Furthermore, the following issues should be addressed:

- debian/copyright: Nothing is said about the license of Debian packaging;
likely it takes the same license as upstream code, but that should be stated
explicitly. Furthermore please consider conversion to DEP5 format. Furthermore
it's not even said where this software can be downloaded from.
- debian/docs is empty (should probably be removed).
- debian/watch does nothing.
- Your build rules are semi-broken it seems: the entire build is performed
twice.
- Building the package yields a large number of warnings; as you are upstream,
please address these.
- Please make sure your package is lintian-clean.

Best regards,
Michael

[Michael Tautschnig]

Hi Alejandro,

[...]

Done, I have fixed and included all suggestions. The package is
up-to-date in my git repository and mentors. Thanks you.

As it seems there has been little response to your RFS after Raphael's initial
comments you might want to start working with the Python Apps Packaging team
instead. Most probably there are several people available who are well
acquainted with Python apps and can readily review your package. Please see

http://wiki.debian.org/Teams/PythonAppsPackagingTeam

for further information.

Best regards,
Michael

[Michael Tautschnig]

Hi again,

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

do you mean thanking guys in this thread helped me to fix the
package ? And put a line in debian/changelog ? But if so, I should
also open a bug ?

No, that's not necessary - basically you can put in the changelog whatever you
think is useful information, as long as you format it properly. There is
absolutely no need for each and every line to include a "closes:..." entry.

[...]

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

I think I have to dig into this. Could the package be acceptable
without this ?

Apart from the debian/docs thing: yes, sure, that's just nice-to-have ideas.

- A number of source files lack copyright- and license-information. As you are
upstream, this should be fairly easy to fix.

But this one is a stringent requirement.

Sorry for the delayed reply!

Best regards,
Michael

[Michael Tautschnig]

Hi Chris,

I have nearly completed these changes now. However I am having problems
with the three files listed below. All files are required to build, even
thought they are not part of the release jar. I guess that rules out
just removing them?
What is the best way to proceed now? The options I can think of are,
find out where these files come from and what licences and copyright
apply, then if possible upload the bluecove package to unstable and
bluecove-gpl to contrib, or, package the source of these files
seperately and if possible add to non-free, then upload both packages to
contrib.

[...]

./src/main/java/com/sun/cdc/io/ConnectionBaseInterface.java: *No copyright* UNKNOWN
./src/main/java/com/ibm/oti/connection/CreateConnection.java: UNKNOWN
./src/main/java/com/ibm/oti/vm/VM.java: UNKNOWN
All of them carry a marker "Not in distributed bluecove jar", but this doesn't
make the source of those files distributable. I guess you will have to repack
the tarball to produce a DFSG-free version.

[...]

If these files completely lack copyright information, it might not even be legal
to distribute them. The proper approach would definitely be to track down where
they come from and fix the copyright&license information. Maybe they are part of
some larger source package which has its license stated in a separate file!?

Best regards,
Michael

[Chris Baines]

Post by Michael Tautschnig
[...]

./src/main/java/com/sun/cdc/io/ConnectionBaseInterface.java: *No copyright* UNKNOWN
./src/main/java/com/ibm/oti/connection/CreateConnection.java: UNKNOWN
./src/main/java/com/ibm/oti/vm/VM.java: UNKNOWN
All of them carry a marker "Not in distributed bluecove jar", but this doesn't
make the source of those files distributable. I guess you will have to repack
the tarball to produce a DFSG-free version.

[...]
If these files completely lack copyright information, it might not even be legal
to distribute them. The proper approach would definitely be to track down where
they come from and fix the copyright&license information. Maybe they are part of
some larger source package which has its license stated in a separate file!?
Best regards,
Michael

I have contacted the developer but am quite confused with his response.
You can see the thread here
http://groups.google.com/group/bluecove-developers/browse_thread/thread/f28c13ae5a3e9d46 .

Thanks,

Chris

[Michael Tautschnig]

Hi Chris,

Sorry for the huge wait.

[...]

Post by Chris Baines

Post by Michael Tautschnig
If these files completely lack copyright information, it might not even be legal
to distribute them. The proper approach would definitely be to track down where
they come from and fix the copyright&license information. Maybe they are part of
some larger source package which has its license stated in a separate file!?
Best regards,
Michael

I have contacted the developer but am quite confused with his response.
You can see the thread here
http://groups.google.com/group/bluecove-developers/browse_thread/thread/f28c13ae5a3e9d46 .

If they created the files, they should also take their copyright. This would at
least clarify who created them. Licensing might be free of choice as well; and
with a copyright it would at least be clear with whom this is to be discussed,
if debate is necessary.

If you could get that fixed I'd offer to do another round of reviews.

Thanks a lot,
Michael

[Michael Tautschnig]

Hi Benoît,

[...]

Just one question regarding your most recent changes: Why did you remove the
AUTHORS sections from man pages?

"Use of an AUTHORS section is strongly discouraged. Generally, it is
better not to clutter every page with a list of (over time potentially
numerous) authors; if you write or significantly amend a page, add a
copyright notice as a comment in the source file."
It seemed sensible to me, so that's what I did.

Fair enough :-) I wasn't quite aware of this recommendation, I should probably
consider that myself...!

Thanks again for the reviews and the upload. You've been very helpful
and it's really motivating to take part in a project with great people
like you.

Oh, thank you :-) But please allow me to take this opportunity for thanking you
for all the reviews of other packages/RFS you've already done! It's great to see
such contributions, and I hope this motivates other not-yet-DDs to do the same!
BTW: Do you have any plans to apply for DM (and possibly DD afterwards)? I'd be
happy to advocate such an application.

Best regards,
Michael

[Michael Tautschnig]

Hi Andreas,

[...]

- it fixes the problems in my previous upload mentioned by Ansgar Burchardt.

[...]

debdiff reviewed, built and uploaded. Thanks a lot for the quick fix!

Best regards,
Michael

[Michael Tautschnig]

Hi Tobias,

[...]

I fixed these bugs - the package builds now separate binary packages for the
library and accompanying dev packages. Thanks to all for the answers. I am
still looking for someone to sponsor this package.

I just looked at your RFS and intended to sponsor your package. But before doing
so I did another round of reviewing and this resulted in a number of comments
which need to be addressed before the package can be uploaded:

- Upstream has released 3.2.2.
- debian/changelog: "Initial package" is generally worded as "Initial upload"
- debian/control: All binary packages share the same description. You should at
least append one sentence describing the peculiarities of each package. And
please use a consistent uppercase/lowercase version of "KLatexFormula".
- debian/copyright: It would be nice if it were formatted according to DEP-5
(http://dep.debian.net/deps/dep5/); especially as this is already almost the
case.
- No need for debian/README.source if your package is v3/quilt anyway.
- debian/rules: It says "rm debian/klatexformula.1", but you ship
klatexformula.1 in the *source* package!?
- debian/patches/debian-changes-3.2.1-1: This patch contains a number of
auto-generated files. Couldn't you just have the debian build process generate
those files? Even more so as your home-directory name occurs several times...

Well, and I tried to build your package:

...
-- [KDE4 SETTINGS (for kate plugin)]

*** NOTE ***
KDE4 is required to build KTextEditor plugin.
Since KDE4 could not be found, the KLatexFormula KTextEditor plugin will not be built (KLF_BUILD_KTEXTEDITORPLUGIN).
KLatexFormula itself does not need KDE4 and will be compiled normally.
Please re-run cmake to proceed.

CMake Error at src/klfkateplugin/CMakeLists.txt:30 (message):
KDE4 not found.
Call Stack (most recent call first):
src/klfkateplugin/CMakeLists.txt:36 (klf_nokde4)

It seems that your dependencies are incomplete.

Please fix these issues and ping the list once again, then your package should
get sponsored soon.

Hope this helps,
Michael

[Tobias Winchen]

Dear all,

I fixed the issues mentioned below and uploaded the latest packages to the
mentors server at http://mentors.debian.net/debian/pool/main/k/klatexformula

Hopefully these have been the last issues and the package is ready to be
sponsored.

Best regards,

Tobias

Post by Michael Tautschnig
I just looked at your RFS and intended to sponsor your package. But before
doing so I did another round of reviewing and this resulted in a number of
- Upstream has released 3.2.2.
- debian/changelog: "Initial package" is generally worded as "Initial
upload" - debian/control: All binary packages share the same description.
You should at least append one sentence describing the peculiarities of
each package. And please use a consistent uppercase/lowercase version of
"KLatexFormula". - debian/copyright: It would be nice if it were formatted
according to DEP-5 (http://dep.debian.net/deps/dep5/); especially as this
is already almost the case.
- No need for debian/README.source if your package is v3/quilt anyway.
- debian/rules: It says "rm debian/klatexformula.1", but you ship
klatexformula.1 in the *source* package!?
- debian/patches/debian-changes-3.2.1-1: This patch contains a number of
auto-generated files. Couldn't you just have the debian build process
generate those files? Even more so as your home-directory name occurs
several times...
...
-- [KDE4 SETTINGS (for kate plugin)]
*** NOTE ***
KDE4 is required to build KTextEditor plugin.
Since KDE4 could not be found, the KLatexFormula KTextEditor plugin
will not be built (KLF_BUILD_KTEXTEDITORPLUGIN). KLatexFormula itself does
not need KDE4 and will be compiled normally. Please re-run cmake to
proceed.
KDE4 not found.
src/klfkateplugin/CMakeLists.txt:36 (klf_nokde4)
It seems that your dependencies are incomplete.
Please fix these issues and ping the list once again, then your package
should get sponsored soon.
Hope this helps,
Michael

[Michael Tautschnig]

Hi Ruben,

[...]

Thanks for pointing this out.
It's fixed and re-uploaded now.

I just checked your package and would be willing to sponsor it. However, I
noticed that Benoît also submitted a bug report (and patch) to improve the man
pages. Could you please include that in the package and re-upload to mentors? If
you could just ping me afterwards I'd re-check and upload.

Thanks a lot,
Michael

[Ruben Molina]

Post by Michael Tautschnig
I just checked your package and would be willing to sponsor it. However, I
noticed that Benoît also submitted a bug report (and patch) to improve the man
pages. Could you please include that in the package and re-upload to mentors? If
you could just ping me afterwards I'd re-check and upload.

Hi Michael,
Thanks a lot for your help.

I included Benoît's patch, and reuploaded my package to mentors:
http://mentors.debian.net/debian/pool/main/g/gts/gts_0.7.6+darcs101112-1.dsc

Thanks again.

Best regards,
Ruben

[Benoît Knecht]

Hi Ruben,

Post by Ruben Molina
http://mentors.debian.net/debian/pool/main/g/gts/gts_0.7.6+darcs101112-1.dsc

You got the bug number wrong in debian/changelog :) It's actually
#605493.

Cheers,

[Benoît Knecht]

Post by Benoît Knecht

Post by Ruben Molina
http://mentors.debian.net/debian/pool/main/g/gts/gts_0.7.6+darcs101112-1.dsc

You got the bug number wrong in debian/changelog :) It's actually
#605493.

Thanks Benoît.
Reuploaded.

I'm sorry, I hope it doesn't sound like I'm relentlessly trying to find
flaws in your uploads, but now you have two '#' instead of one:
"Closes: ##605493"
instead of
"Closes: #605493".

Don't worry, third time's a charm :)

Cheers,

[Michael Tautschnig]

Hi,

So here comes the review from the guy claiming he wouldn't sponsor that package
:-)

Well, besides your suggestion on the default of kstarsrc-does-not-exist (since
the user is asked for all options), and the fact that I'm not parsing (yet)
the configuration file, this is a new iteration of the package.
I hope everything is all right now :) and I can search for a sponsor now :)

Well, I'd actually be willing to sponsor your package, but the following review
tells that it's not completely ready yet and will need another iteration. Let's
see:

- debian/config vs. debian/config.THIS: What is the point of those *two* files?
Is one of them (.THIS) just a backup version? What is the
"kstarsrc-previously-exists" debconf value actually good for? Are you sure you
need that?
- debian/control: It would be nice to synchronize your package description with
that of kstars-data. Well, and the short description (1) should not start with
a capital letter; (2) should definitely be *short* and not be any longer than
60 characters; (3) need not be a complete sentence; (4) should make clear that
this is related to kstars. Again, take a look at the kstars-data package.
- debian/copyright: It would be nice if it were formatted according to DEP-5,
see http://dep.debian.net/deps/dep5/. Furthermore I believe there was some
discussion about the license of this data file. I re-read the discussion in
#597202, but where do I find information that this dat-file is GPL-licensed?
BTW: Is there some source-file for this .dat-file? Most likely nobody put
together this binary file by hand. In this case it would be a lot nicer to
have the source file in the source package and only ship the .dat file as
built from the source package as binary package.
- debian/docs: README.source doesn't quite sound like a filename that should go
in the binary packages. Benoît suggested it as only candidate for debian/docs,
but I believe you should rather just delete debian/docs.
- debian/README.Debian: That file is supposed to contain information about
Debian-specific changes, hints for configuration, etc. Probably better just
delete this file.

Hope this helps,
Michael

[Noel David Torres Taño]

Post by Michael Tautschnig
Hi,
So here comes the review from the guy claiming he wouldn't sponsor that package
:-)

Well, besides your suggestion on the default of kstarsrc-does-not-exist
(since the user is asked for all options), and the fact that I'm not
parsing (yet) the configuration file, this is a new iteration of the
package.
I hope everything is all right now :) and I can search for a sponsor now :)

Well, I'd actually be willing to sponsor your package, but the following
review tells that it's not completely ready yet and will need another
- debian/config vs. debian/config.THIS: What is the point of those *two*
files? Is one of them (.THIS) just a backup version? What is the
"kstarsrc-previously-exists" debconf value actually good for? Are you
sure you need that?
- debian/control: It would be nice to synchronize your package description
with that of kstars-data. Well, and the short description (1) should not
start with a capital letter; (2) should definitely be *short* and not be
any longer than 60 characters; (3) need not be a complete sentence; (4)
should make clear that this is related to kstars. Again, take a look at
the kstars-data package. - debian/copyright: It would be nice if it were
formatted according to DEP-5, see http://dep.debian.net/deps/dep5/.
Furthermore I believe there was some discussion about the license of this
data file. I re-read the discussion in #597202, but where do I find
information that this dat-file is GPL-licensed? BTW: Is there some
source-file for this .dat-file? Most likely nobody put together this
binary file by hand. In this case it would be a lot nicer to have the
source file in the source package and only ship the .dat file as built
from the source package as binary package.
- debian/docs: README.source doesn't quite sound like a filename that
should go in the binary packages. Benoît suggested it as only candidate
for debian/docs, but I believe you should rather just delete debian/docs.
- debian/README.Debian: That file is supposed to contain information about
Debian-specific changes, hints for configuration, etc. Probably better
just delete this file.
Hope this helps,
Michael

It helps, thanks. Working on it.

Noel
er Envite

[Noel David Torres Taño]

Post by Michael Tautschnig
Hi,
So here comes the review from the guy claiming he wouldn't sponsor that package
:-)

Well, besides your suggestion on the default of kstarsrc-does-not-exist
(since the user is asked for all options), and the fact that I'm not
parsing (yet) the configuration file, this is a new iteration of the
package.
I hope everything is all right now :) and I can search for a sponsor now :)

Well, I'd actually be willing to sponsor your package, but the following
review tells that it's not completely ready yet and will need another
- debian/config vs. debian/config.THIS: What is the point of those *two*
files? Is one of them (.THIS) just a backup version? What is the
"kstarsrc-previously-exists" debconf value actually good for? Are you
sure you need that?

.THIS deleted (yes, it was a backup file)

In my flow diagram, kstarsrc-previously-exists is used to check if some
preconfigured /etc/kde4/kstarsrc exists, and if it exists, leave it as it is.
It is needed because at deconfiguring, in a future postrm script, it can be
checked if file is to be deleted (if created by any kstars-data-extra-*
package) or kept. Moreover, since there will be a bunch of kstars-data-extra-*
packages, this value will help avoid reconfigure over reconfigure ,if more
than one of them is installed.

Post by Michael Tautschnig
- debian/control: It would be nice to synchronize your package description
with that of kstars-data. Well, and the short description (1) should not
start with a capital letter; (2) should definitely be *short* and not be
any longer than 60 characters; (3) need not be a complete sentence; (4)
should make clear that this is related to kstars. Again, take a look at

short changed to:
Tycho2 star catalog for centralized install of KStars

long changed, too, to have it start more or less like the kstars-data package,
but ephasizing the differences.

Post by Michael Tautschnig
the kstars-data package. - debian/copyright: It would be nice if it were
formatted according to DEP-5, see http://dep.debian.net/deps/dep5/.

Done. I've included some X- fields for relevant info.

Post by Michael Tautschnig
Furthermore I believe there was some discussion about the license of this
data file. I re-read the discussion in #597202, but where do I find
information that this dat-file is GPL-licensed? BTW: Is there some

http://edu.kde.org/kstars/downloads/knewstuff.xml says it is GPL (no version).
That is the official page for automated downloads from the program.

Post by Michael Tautschnig
source-file for this .dat-file? Most likely nobody put together this
binary file by hand. In this case it would be a lot nicer to have the
source file in the source package and only ship the .dat file as built
from the source package as binary package.

I still do not know how this file has been compiled. I think it's some
internal method of the KStars team. It's immediate source is not published
AFAIK and its non-immediate source is the Tycho-2 catalog itself. You can find
it at http://cdsarc.u-strasbg.fr/cgi-bin/myqcat3?I/259/ but I do not know
(yet) how was it cooked and then compiled to get the deepstars.dat file. Once
I know, I will try to get this in shape with stardata-common system.

Post by Michael Tautschnig
- debian/docs: README.source doesn't quite sound like a filename that
should go in the binary packages. Benoît suggested it as only candidate
for debian/docs, but I believe you should rather just delete debian/docs.

Done

Post by Michael Tautschnig
- debian/README.Debian: That file is supposed to contain information about
Debian-specific changes, hints for configuration, etc. Probably better
just delete this file.

Done

Post by Michael Tautschnig
Hope this helps,
Michael

New version uploaded: http://mentors.debian.net/cgi-bin/sponsor-
pkglist?action=details;package=kstars-data-extra-tycho2

Many many thanks

Noel
er Envite

[Michael Tautschnig]

Hi Dmitry,

Sorry for the huge wait for a first reply to your post.

Post by Jean-Luc Biord
Dear mentors,
I am looking for a sponsor for my package "polygraph".
* Package name : polygraph
Version : 4.0.11-1
* URL : http://www.web-polygraph.org
* License : Apache-2.0
Section : net

[...]

I have now started to review this package and found at least two fundamental
problems:

- The Apache license also gives a fairly precise description how it is to be
applied to your work, as can be seen at the very end of

http://www.apache.org/licenses/LICENSE-2.0.html

The codebase of polygraph does not seem to follow this requirement, which (1)
makes checking for proper licensing extremely hard and (2) may even be in
violation with the license requirements.

- Your package fails to build:

Ssl.cc: In constructor ‘SslCtx::SslCtx(SslCtx::SslProtocol, const String&)’:
Ssl.cc:33:27: error: ‘::SSLv2_method’ has not been declared

Other than that the package looks fine to me, but given this FTBFS this review
remains very incomplete.

Best regards,
Michael

[Dmitry Kurochkin]

Hi Michael.

Post by Michael Tautschnig
Hi Dmitry,
Sorry for the huge wait for a first reply to your post.

Post by Jean-Luc Biord
Dear mentors,
I am looking for a sponsor for my package "polygraph".
* Package name : polygraph
Version : 4.0.11-1
* URL : http://www.web-polygraph.org
* License : Apache-2.0
Section : net

[...]
I have now started to review this package and found at least two fundamental

Thanks for review.

Note that the package has been already uploaded by Tollef Fog Heen.

Post by Michael Tautschnig
- The Apache license also gives a fairly precise description how it is to be
applied to your work, as can be seen at the very end of
http://www.apache.org/licenses/LICENSE-2.0.html
The codebase of polygraph does not seem to follow this requirement, which (1)
makes checking for proper licensing extremely hard and (2) may even be in
violation with the license requirements.

I see how the non-standard preamble can make licensing checking harder
(though, I do not consider it extremly hard). Do you use some tool for
license checking?

Can you please explain how non-standard preamble violates the license
terms? I do not see any requirements on the preamble format in the
Apache license text. Note that the appendix which describes it goes
after the "END OF TERMS AND CONDITIONS" line.

Do you argue that non-standard preamble renders the package not
apropriate for Debian?

Post by Michael Tautschnig
Ssl.cc:33:27: error: ‘::SSLv2_method’ has not been declared
Other than that the package looks fine to me, but given this FTBFS this review
remains very incomplete.

Yep, I am aware of the issue. It was broken by OpenSSL 1.0 upload to
unstable. SSLv2 is disabled now, hence the build failure. See Debian bug
#589706 [1]. The package was building fine in unstable just few days
ago. I will prepare a new package soon.

Regards,
Dmitry

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

Post by Michael Tautschnig
Best regards,
Michael

[Michael Tautschnig]

Hi Dmitry,

Thanks a lot for the very quick reply.

[...]

Post by Dmitry Kurochkin
Thanks for review.
Note that the package has been already uploaded by Tollef Fog Heen.

Oh, I must have missed that message, sorry.

[...]

Post by Dmitry Kurochkin
I see how the non-standard preamble can make licensing checking harder
(though, I do not consider it extremly hard). Do you use some tool for
license checking?

Indeed, it's the licensecheck tool. And indeed you'd be putting quite a lot less
work on reviewers if some auto-checkable header were used.

Post by Dmitry Kurochkin
Can you please explain how non-standard preamble violates the license
terms? I do not see any requirements on the preamble format in the
Apache license text. Note that the appendix which describes it goes
after the "END OF TERMS AND CONDITIONS" line.
Do you argue that non-standard preamble renders the package not
apropriate for Debian?

I'm not sure. ftp-master will tell you, but you are probably right that this
appendix is not part of the license and hence can safely be ignored. ftp-masters
will let you know :-)

Post by Dmitry Kurochkin

Post by Michael Tautschnig
Ssl.cc:33:27: error: ‘::SSLv2_method’ has not been declared
Other than that the package looks fine to me, but given this FTBFS this review
remains very incomplete.

Yep, I am aware of the issue. It was broken by OpenSSL 1.0 upload to
unstable. SSLv2 is disabled now, hence the build failure. See Debian bug
#589706 [1]. The package was building fine in unstable just few days
ago. I will prepare a new package soon.

[...]

Ok, as it has been uploaded already and you are aware of that problem that's ok
then.

Thanks a lot for your work,
Michael

[Alex Rousskov]

Post by Michael Tautschnig

Post by Jean-Luc Biord
* Package name : polygraph
Version : 4.0.11-1
* URL : http://www.web-polygraph.org
* License : Apache-2.0
Section : net

I have now started to review this package and found at least two fundamental

I wish all our "fundamental problems" were that easy :-)

Post by Michael Tautschnig
- The Apache license also gives a fairly precise description how it is to be
applied to your work, as can be seen at the very end of
http://www.apache.org/licenses/LICENSE-2.0.html
The codebase of polygraph does not seem to follow this requirement, which (1)
makes checking for proper licensing extremely hard and (2) may even be in
violation with the license requirements.

FWIW, Apache itself does not follow what you consider a license
application requirement.

For example, the very web page you linked to above, has no preamble and
just says "Copyright 2011 The Apache Software Foundation, Licensed under
the Apache License, Version 2.0" at the bottom. Moreover, Apache httpd
sources use a different preamble as well (e.g.,
httpd-2.2.17/srclib/apr/mmap/unix/mmap.c -- the first file I checked).

As for being "extremely hard" to check, it seems like an exaggeration.
Would the following preamble really leave a lot of question with regard
to the distribution license?

/* Web Polygraph http://www.web-polygraph.org/
* (C) 2003-2006 The Measurement Factory
* Licensed under the Apache License, Version 2.0 */

As you can see, Polygraph preamble uses the exact same text used by
Apache site. That text is a part of what is recommended by Apache
License; it just does not repeat what is already said in Apache License
itself.


IMO, we are not doing anything wrong here, but we should be pragmatic
about this issue: Humans should have no problems, but if the problem is
with automated tools used by Debian, we should try to accommodate them.
There is probably some flexibility here because they apparently work
fine with other packages using custom preambles, such as Apache httpd.
For example, perhaps including the URL of the Apache license would be
sufficient to pass those automated checks?


Thank you,

Alex.

[Michael Tautschnig]

Hi,

[...]

Post by Alex Rousskov
FWIW, Apache itself does not follow what you consider a license
application requirement.
For example, the very web page you linked to above, has no preamble and
just says "Copyright 2011 The Apache Software Foundation, Licensed under
the Apache License, Version 2.0" at the bottom. Moreover, Apache httpd
sources use a different preamble as well (e.g.,
httpd-2.2.17/srclib/apr/mmap/unix/mmap.c -- the first file I checked).

Indeed it does not use the suggested text, but it still uses a lot more text
than polygraph does.

Post by Alex Rousskov
As for being "extremely hard" to check, it seems like an exaggeration.
Would the following preamble really leave a lot of question with regard
to the distribution license?

/* Web Polygraph http://www.web-polygraph.org/
* (C) 2003-2006 The Measurement Factory
* Licensed under the Apache License, Version 2.0 */

The good thing is: polygraph seems to consistently use this text. Hence indeed
it can be pretty easily checked by testing for this particular pattern. Yes, my
statement might have been over-exaggerated, but at bit more of standardization
whenever such proposals exist would help us all a lot.

Post by Alex Rousskov
As you can see, Polygraph preamble uses the exact same text used by
Apache site. That text is a part of what is recommended by Apache
License; it just does not repeat what is already said in Apache License
itself.

I pretty much fail to see in what way it uses "exact the same text" - is it the
words "Licensed under ..." you are referring to? Then at least you missing the
first two lines of the Apache-proposed text, which is the copyright information.
Here you are in fact certainly lacking sufficient information, because (C) is
not generally equivalent to "Copyright" under all copyright laws.

Post by Alex Rousskov
IMO, we are not doing anything wrong here, but we should be pragmatic
about this issue: Humans should have no problems, but if the problem is
with automated tools used by Debian, we should try to accommodate them.
There is probably some flexibility here because they apparently work
fine with other packages using custom preambles, such as Apache httpd.
For example, perhaps including the URL of the Apache license would be
sufficient to pass those automated checks?

I'd suggest the following procedure: if this copyright/license statement gets
ack'ed by ftp-master, i.e., polygraph is accepted into the archive, then this
license header must be sufficient (not only for polygraph, but also for other
packages). It's then time to file a bug against the devscripts package to
acknowledge this fact.

Thanks a lot,
Michael

[Dmitry Kurochkin]

Post by Michael Tautschnig
Hi,
[...]

Post by Alex Rousskov
FWIW, Apache itself does not follow what you consider a license
application requirement.
For example, the very web page you linked to above, has no preamble and
just says "Copyright 2011 The Apache Software Foundation, Licensed under
the Apache License, Version 2.0" at the bottom. Moreover, Apache httpd
sources use a different preamble as well (e.g.,
httpd-2.2.17/srclib/apr/mmap/unix/mmap.c -- the first file I checked).

Indeed it does not use the suggested text, but it still uses a lot more text
than polygraph does.

Post by Alex Rousskov
As for being "extremely hard" to check, it seems like an exaggeration.
Would the following preamble really leave a lot of question with regard
to the distribution license?

/* Web Polygraph http://www.web-polygraph.org/
* (C) 2003-2006 The Measurement Factory
* Licensed under the Apache License, Version 2.0 */

The good thing is: polygraph seems to consistently use this text. Hence indeed
it can be pretty easily checked by testing for this particular pattern. Yes, my
statement might have been over-exaggerated, but at bit more of standardization
whenever such proposals exist would help us all a lot.

Post by Alex Rousskov
As you can see, Polygraph preamble uses the exact same text used by
Apache site. That text is a part of what is recommended by Apache
License; it just does not repeat what is already said in Apache License
itself.

I pretty much fail to see in what way it uses "exact the same text" - is it the
words "Licensed under ..." you are referring to? Then at least you missing the
first two lines of the Apache-proposed text, which is the copyright information.
Here you are in fact certainly lacking sufficient information, because (C) is
not generally equivalent to "Copyright" under all copyright laws.

Post by Alex Rousskov
IMO, we are not doing anything wrong here, but we should be pragmatic
about this issue: Humans should have no problems, but if the problem is
with automated tools used by Debian, we should try to accommodate them.
There is probably some flexibility here because they apparently work
fine with other packages using custom preambles, such as Apache httpd.
For example, perhaps including the URL of the Apache license would be
sufficient to pass those automated checks?

I'd suggest the following procedure: if this copyright/license statement gets
ack'ed by ftp-master, i.e., polygraph is accepted into the archive, then this
license header must be sufficient (not only for polygraph, but also for other
packages). It's then time to file a bug against the devscripts package to
acknowledge this fact.

I have looked at licensecheck. It matches the following regexp:

/under the Apache License, Version ([^ ]+) \(the License\)/

Changing "Licensed under the Apache License, Version 2.0" line to
"Licensed under the Apache License, Version 2.0 (the License)" makes
licensecheck detect both license and copyright correctly. IMO the
licensecheck regexp should be improved.

Regards,
Dmitry

Post by Michael Tautschnig
Thanks a lot,
Michael

Non-text part: application/pgp-signature

[Alex Rousskov]

Post by Michael Tautschnig

/* Web Polygraph http://www.web-polygraph.org/
* (C) 2003-2006 The Measurement Factory
* Licensed under the Apache License, Version 2.0 */

Here you are in fact certainly lacking sufficient information, because (C) is
not generally equivalent to "Copyright" under all copyright laws.

We will change "(C)" to "Copyright".

Post by Michael Tautschnig
/under the Apache License, Version ([^ ]+) \(the License\)/
Changing "Licensed under the Apache License, Version 2.0" line to
"Licensed under the Apache License, Version 2.0 (the License)" makes
licensecheck detect both license and copyright correctly. IMO the
licensecheck regexp should be improved.

I do not know whether licensecheck does some relevant preprocessing, but
the above regex would not even match the recommended raw preamble

Post by Michael Tautschnig
Licensed under the Apache License, Version 2.0 (the "License");

Since the stuff in parenthesis is meant for the following text which may
not be present in many customized preambles, it should not be matched
for, IMHO,

Cheers,

Alex.

[Dmitry Kurochkin]

Post by Alex Rousskov

Post by Michael Tautschnig

/* Web Polygraph http://www.web-polygraph.org/
* (C) 2003-2006 The Measurement Factory
* Licensed under the Apache License, Version 2.0 */

Here you are in fact certainly lacking sufficient information, because (C) is
not generally equivalent to "Copyright" under all copyright laws.

We will change "(C)" to "Copyright".

Post by Michael Tautschnig
/under the Apache License, Version ([^ ]+) \(the License\)/
Changing "Licensed under the Apache License, Version 2.0" line to
"Licensed under the Apache License, Version 2.0 (the License)" makes
licensecheck detect both license and copyright correctly. IMO the
licensecheck regexp should be improved.

I do not know whether licensecheck does some relevant preprocessing, but
the above regex would not even match the recommended raw preamble

Post by Michael Tautschnig
Licensed under the Apache License, Version 2.0 (the "License");

Apparently, it does. Because the recommended preamble is recognized.

Post by Alex Rousskov
Since the stuff in parenthesis is meant for the following text which may
not be present in many customized preambles, it should not be matched
for, IMHO,

Agreed. I openned a bug for devscripts #620902 [1].

Regards,
Dmitry

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

Post by Alex Rousskov
Cheers,
Alex.

[Michael Tautschnig]

Hi,

Post by Jean-Luc Biord
Dear mentors,
I am looking for a sponsor for my package "mpd-sima" (new version of
previously named sima package).
* Package name : mpd-sima
Version : 0.7.0-1
* URL : http://codingteam.net/project/sima
* License : GPVv3
Section : sound

[...]

Built & uploaded (but will have to wait in NEW, though).

As you renamed the package to mpd-sima, could you please manually remove the
sima package from mentors.debian.net?

I'd like to point you to [1] - if you'd have some time, it would be great if you
could also help others to get their packages reviewed and sponsored. Obviously
meanwhile there have been several new RFS sent to the list (looking at my list
it must be around 200) and it would be nice if you could take a look at some of
these.

Thanks a lot for your contribution,
Michael

[1] http://lists.debian.org/debian-mentors/2010/10/msg00478.html

[Michael Tautschnig]

Hi,

I am looking for a sponsor for my package "mediadownloader".
* Package name : mediadownloader
Version : 1.5.0-1
* URL : http://mediadownloader.cz.cc
* License : gpl3
Section : graphics
mediadownloader - Search, preview, download with Google Image and YouTube
The package appears to be lintian clean.

[...]

That may well be true, but it doesn't even build:

g++ -c -pipe -O2 -D_REENTRANT -Wall -W -DPHONON_LIB -DQT_OPENGL_SUPPORT -DQT_NO_DEBUG -DQT_WEBKIT_LIB -DQT_PHONON_LIB -DQT_XML_LIB -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtOpenGL -I/usr/include/qt4/QtXml -I/usr/include/phonon -I/usr/include/qt4/QtWebKit -I/usr/include/qt4 -Imain -I/usr/include/qt4/phonon_compat -I/usr/X11R6/include -I.build -I.build -o .build/browse.o main/browse.cpp
main/browse.cpp:20:20: fatal error: QWebView: No such file or directory

Apart from this major problem, please consider the following changes, some of
which I already suggested in an earlier review:

- You might want to acknowledge several previous reviewers in your changelog.
- debian/copyright: It would be nice if it were converted to DEP-5 format.
- debian/rules: A debian/install (and maybe debian/dirs) should help to simplify
your rules, and moving to the simplified debhelper-7 version would be even
better.

Best regards,
Michael

[Michael Tautschnig]

Hi,

Post by Jean-Luc Biord
Dear mentors,
I am looking for a sponsor for my package "leechcraft".
* Package name : leechcraft
Version : 0.4.55+88-1
* URL : http://leechcraft.org
* License : GPLv3
Section : net

[...]

I've finally gotten around to start reviewing this package; its size make it
pretty hard to review and I'd suggest that at least some of it is moved to a
separate leechcraft-plugins package (after all, that should be the idea of
plug-ins), not only for reviewing but primarily for re-uploads: if only some
plug-in changes, why rebuild the entire framework?

At least one major issue has to be fixed: src/plugins/eiskaltdcpp/eiskaltdcpp/
(and also a small number of files in other directories) has a lot of files
without license and copyright information.

Looking at the debian/ directory I see:

- debian/copyright is incomplete (no short version of license text) and should
be DEP-5 formatted.
- debian/changelog: It's a bit odd to close the ITP with "new upstream version"
(rather in this case this is the initial upload).

Best regards,
Michael

[Michael Tautschnig]

Hi,

Post by Jean-Luc Biord
Dear mentors,
I am looking for a sponsor for the new version 2.0-1
of my package "blankon".
gnome-icon-theme-blankon - BlankOn Ombilin icon theme for GTK+ 2.x

[...]

I'd generally be fine uploading this package, but I fail to understand why this
theme *package* is called "blankon" whereas all the files it contains plus the
theme name when installed are "monde" it seems!?

Best regards,
Michael

[Michael Tautschnig]

Hi Benoît,

I am looking for a sponsor for the new version 0.42-0.1
of my package "pms".
pms - Practical Music Search, an MPD client
The package appears to be lintian clean.
The upload would fix these bugs: 551619, 612192, 615003
This version was released in May 2010, and the current version in debian
(0.41) is more than 18 months old. I opened a bug (#612192) back in
February about the new upstream version, but the maintainer (cc'ed)
didn't react.

[...]

May I ask you to follow MIA procedures as described in Section 7.4 of the
Developer's Reference? I think you have already reached the point that you can
safely contact ***@qa.debian.org with the effect that the package should get
orphaned. You can then change this into an intend-to-adopt and upload a new
version that also closes this ITA bug report.

I'd then happily review your package (feel free to ping me in a separate mail)
and subsequently upload it; but I won't do a straight away hijack :-)

Best,
Michael

[Michael Tautschnig]

Hi,

I am looking for a sponsor for my package "ardentryst".
* Package name : ardentryst
Version : 1.7.1
* URL : http://jordan.trudgett.com/
* License : game itself: GPL-3 ; game data/music: CC 3.0
Programming Lang: Python
Section: games
Description : Action/RPG sidescoller, focused on story and character
development

[...]

To the best of my knowledge there hasn't been much response to your request on
this list. Have you considered contacting and working with the Debian Games
team? They might be of much more help in this particular case.

Best regards,
Michael

[Paul Wise]

Post by Michael Tautschnig
To the best of my knowledge there hasn't been much response to your request on
this list. Have you considered contacting and working with the Debian Games
team? They might be of much more help in this particular case.

ana already uploaded ardentryst (very nice game too, if short).

Vincent has already joined the games team, packaging naev, I imagine
he will move ardentryst to the team too.
--
bye,
pabs

http://wiki.debian.org/PaulWise

[Vincent Cheng]

Post by Michael Tautschnig

Post by Michael Tautschnig
To the best of my knowledge there hasn't been much response to your

request on

Post by Michael Tautschnig
this list. Have you considered contacting and working with the Debian

Games

Post by Michael Tautschnig
team? They might be of much more help in this particular case.

ana already uploaded ardentryst (very nice game too, if short).
Vincent has already joined the games team, packaging naev, I imagine
he will move ardentryst to the team too.

I didn't know about the games team when I first sent out this RFS back in
January. Anyways, yes, I intend to move ardentryst to the games team, and
I've already uploaded a copy of my packaging to the pkg-games svn
repository. Thanks for taking the time to inquire about my package (and many
others as well), Michael!

- Vincent

[Michael Tautschnig]

Hi Johey,

Post by Jean-Luc Biord
Dear mentors,
I am looking for a sponsor for my package "zdoom".
* Package name : zdoom
Version : 2.5.0-1
* URL : http://zdoom.org
* License : ZDoom may be used and distributed free of charge.
Section : contrib/games

[...]

To the best of my knowledge there hasn't been much response to your request on
this list. Have you considered contacting and working with the Debian Games
team? They might be of much more help in this particular case.

Best regards,
Michael

[Johey Shmit]

Hi Michael,



----- Ursprüngliche Mail ----

Gesendet: Sonntag, den 1. Mai 2011, 14:03:55 Uhr
Betreff: Re: RFS: zdoom
Hi Johey,

Post by Jean-Luc Biord
Dear mentors,
I am looking for a sponsor for my package "zdoom".
* Package name : zdoom
Version : 2.5.0-1
* URL : http://zdoom.org
* License : ZDoom may be used and distributed free of charge.
Section : contrib/games

[...]
To the best of my knowledge there hasn't been much response to your request

on

this list. Have you considered contacting and working with the Debian Games
team? They might be of much more help in this particular case.

Thanks for the hint. I'm going to do that as soon I've reworked the
package. There is still a problem with a non free library that zdoom
depends on and I'm afraid it will take me some time to sort that out.
I've removed the zdoom package from mentors.debian.net for the moment.

Thanks,

Johey

[Michael Tautschnig]

Hi,

I am looking for a sponsor for my package "marave".
* Package name : marave
Version : 0.7-1
* URL : http://code.google.com/p/marave/
* License : gplV2+
Section : editors
marave - Full screen editor written on Python

[...]

There seems to have been little response to this request on the debian-mentors
list. Quite possibly no python experts are listing in. Therefore you might want
to try to speak to the Python Apps Packaging Team:

http://wiki.debian.org/Teams/PythonAppsPackagingTeam

Hope this helps,
Michael

[Michael Tautschnig]

Hi Evgeny,

[...]

- URL: http://mentors.debian.net/debian/pool/main/g/gtkevemon

[...]

Whatever the reason might be, this URL is 404 and neither has the package been
uploaded to Debian proper nor is it awaiting in NEW it seems.

Best,
Michael

[Michael Tautschnig]

Hi,

Hello, dear Mentors,
I'm looking for a sponsor for my package "qca-cyrus-sasl".
* Package name : qca-cyrus-sasl
Version : 2.0.0-beta3-1

[...]

Sorry for the massive delay until anyone got around to review your package. I
finally did so, built, and uploaded it. The package looked pretty much ok, I'd
only have minor requests for you to fix in future uploads:

- debian/copyright should be converted to DEP-5 format
(http://dep.debian.net/deps/dep5/). The current file is already very tidy and
hence a conversion should be very painless.
- Although upstream doesn't seem to be releasing too many new versions recently,
a watch file would be desirable.
- There is no need to duplicate the Section field in the binary package in
debian/control.

Best regards,
Michael

PS.: Given that your package has been uploaded it would be very much appreciated
if you could help others by reviewing their packages. Thanks a lot!

[Vsevolod Velichko]

Hi,

Post by Michael Tautschnig

* Package name    : qca-cyrus-sasl
  Version         : 2.0.0-beta3-1
I'm looking for a sponsor for my package "qca-cyrus-sasl".

[...]
Sorry for the massive delay until anyone got around to review your package. I
finally did so, built, and uploaded it. The package looked pretty much ok, I'd

Michael, thanks for your sponsorship.
It seems that I fixed all the things you've mentioned, so I've created
a new upload with version 2.0.0-beta3-2.
It's available on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/q/qca-cyrus-sasl
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/q/qca-cyrus-sasl/qca-cyrus-sasl_2.0.0-beta3-2.dsc

It'll be nice, if you could find some time to look into it.

Thanks again and my kind regards.

Post by Michael Tautschnig
- debian/copyright should be converted to DEP-5 format
 (http://dep.debian.net/deps/dep5/). The current file is already very tidy and
 hence a conversion should be very painless.
- Although upstream doesn't seem to be releasing too many new versions recently,
 a watch file would be desirable.
- There is no need to duplicate the Section field in the binary package in
 debian/control.

----
Best wishes and have a nice day,
Vsevolod Velichko

[Michael Tautschnig]

Hi,

I am looking for a sponsor for the new version 2.3-1
of my package "morse".

[...]

I finally got around to review this package and I must request minor changes
before accepting to sponsor its upload:

- It is *not* lintian clean:
W: morse: description-synopsis-starts-with-article
- The debdiff over the previous version shows that the changelog has diverged:
apparently your local version has overly long lines, which have been fixed
before the upload of 2.2-1 to the archives. Please make sure this change is
also reflected in your version.

In case I happen to miss some reply to this email, feel free to ping me. Another
review should be a matter of minutes.

Thanks a lot,
Michael

[Nanakos Chrysostomos]

Hi,

Post by Michael Tautschnig
Hi,

I am looking for a sponsor for the new version 2.3-1
of my package "morse".

[...]
I finally got around to review this package and I must request minor changes
W: morse: description-synopsis-starts-with-article

Fixed.

Post by Michael Tautschnig
apparently your local version has overly long lines, which have been fixed
before the upload of 2.2-1 to the archives. Please make sure this change is
also reflected in your version.

Sorry for that. Fixed.

Post by Michael Tautschnig
In case I happen to miss some reply to this email, feel free to ping me. Another
review should be a matter of minutes.

Package re-uploaded to mentors.d.n.

Thanks in advance,
Chris.

[Michael Tautschnig]

Hi,

Thanks a lot for the immediate reply!

[...]

Post by Nanakos Chrysostomos

Post by Michael Tautschnig
W: morse: description-synopsis-starts-with-article

Fixed.

[...]

Unfortunately, this fix is not acceptable either. Your description should
probably be:

morse-code training program for aspiring radio hams

(i.e., remove the "morse is").

Furthermore, could you please check whether you can safely bump the
Standards-Version to 3.9.2?

Thanks a lot,
Michael

[Michael Tautschnig]

Hi again,

Post by Nanakos Chrysostomos
Fixed.

Post by Michael Tautschnig
Furthermore, could you please check whether you can safely bump the
Standards-Version to 3.9.2?

Bumped. No changes needed. Have checked it again and forgot to update it. Thanks
also for that. Changelog changed also with these two new records.

Thanks a lot for another quick round of fixes. Built & uploaded!

Thanks a lot for your contribution,
Michael

[Nanakos Chrysostomos]

Thanks!

Post by Michael Tautschnig
Hi again,

Post by Nanakos Chrysostomos
Fixed.

Post by Michael Tautschnig
Furthermore, could you please check whether you can safely bump the
Standards-Version to 3.9.2?

Bumped. No changes needed. Have checked it again and forgot to update it. Thanks
also for that. Changelog changed also with these two new records.

Thanks a lot for another quick round of fixes. Built & uploaded!
Thanks a lot for your contribution,
Michael

[Nanakos Chrysostomos]

Hi,

Post by Michael Tautschnig
Hi,
Thanks a lot for the immediate reply!
[...]

Post by Nanakos Chrysostomos

Post by Michael Tautschnig
W: morse: description-synopsis-starts-with-article

Fixed.

[...]
Unfortunately, this fix is not acceptable either. Your description should
morse-code training program for aspiring radio hams
(i.e., remove the "morse is").

Fixed.

Post by Michael Tautschnig
Furthermore, could you please check whether you can safely bump the
Standards-Version to 3.9.2?

Bumped. No changes needed. Have checked it again and forgot to update it. Thanks
also for that. Changelog changed also with these two new records.

Cheers,
Chris.

[Michael Tautschnig]

Hi,

I am looking for a sponsor for my package "lastfmlib".
* Package name : lastfmlib
Version : 0.4.0-1
Upstream Author : Dirk Vander Boer
* URL : http://code.google.com/p/lastfmlib/
* License : GPL-2
Section : libs

[...]

Btw, I read somewhere that library packages should be named lib*,
liblastfmlib sounds kind of funny to me though..

[...]

First of all: I have no idea where this "somewhere" is, and indeed I find that
naming *of the source package* very strange. This naming requirement is true for
the binary packages, however, and therefore I wonder whether you could just call
those "liblastfm{1,-dev}"?

And there is more to be fixed:

- lastfmlib/unittest/lastfmclientmock.h lacks both copyright and license
information. Upstream must get that sorted out first.
- I could not find any essential changes in debian-changes-0.4.0-1.
- It would be desirable to enable the unittests at build time.
- A selection of lintian messages to be addressed:
I: liblastfmlib source: binary-control-field-duplicates-source field "section" in package liblastfmlib1
I: liblastfmlib source: duplicate-short-description liblastfmlib-dev liblastfmlib1
I: liblastfmlib source: duplicate-long-description liblastfmlib-dev liblastfmlib1
W: liblastfmlib-dev: description-synopsis-starts-with-article
W: liblastfmlib1: description-synopsis-starts-with-article

Best regards,
Michael

[Andreas Noteng]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Post by Michael Tautschnig
First of all: I have no idea where this "somewhere" is, and indeed I find that
naming *of the source package* very strange. This naming requirement is true for
the binary packages, however, and therefore I wonder whether you could just call
those "liblastfm{1,-dev}"?

I thought about that myself, but didn't because the upstream package is
named lastfmlib (i believe there's another project named liblastfm..). I
renamed the source package, binaries unchanged for now...

Post by Michael Tautschnig
- lastfmlib/unittest/lastfmclientmock.h lacks both copyright and license
information. Upstream must get that sorted out first.

I'll check with him..

Post by Michael Tautschnig
- I could not find any essential changes in debian-changes-0.4.0-1.
- It would be desirable to enable the unittests at build time.
I: liblastfmlib source: binary-control-field-duplicates-source field "section" in package liblastfmlib1
I: liblastfmlib source: duplicate-short-description liblastfmlib-dev liblastfmlib1
I: liblastfmlib source: duplicate-long-description liblastfmlib-dev liblastfmlib1
W: liblastfmlib-dev: description-synopsis-starts-with-article
W: liblastfmlib1: description-synopsis-starts-with-article

Updated package available in the collab-maint git repo, let me know if
you want me to upload to mentors instead.

Thanks for reviewing :)

Regards
Andreas Noteng

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

iQIcBAEBCAAGBQJNxFTGAAoJELRG7qgympRaYRMP/1j+05hnf1HfAwfk18R5o/gN
FdlKGbdwRl6S4wCVudloOEk9liQR4sgnU3DIVpkZeZb8EToPfHn7B2+c1T9H4yYB
qhyG0ifDNWYqFfo+ZhUTx+Y2vNSzkTGrhFSSFMiHMdmcc6Ge1eNnAqtEZ4xVPz6+
ENZCc+J4WZyeASy/1Qkwb4xsPkqY0MW5KD+8v9HxiJJFwRs2oUDV0HNktrUKB5Yg
e2sb4lYVjfZatRj7IF3+jG8dKOqL7ihl/BuCCZQlzwOH6tFKG7bPXyvRWp7CTLU3
4UMxtDsKH8XlVCUFFGcMXEKC6vH1OerHMCnSBFZfJ7HX9auBOES1yZdZxB51C+gK
O2EIDVsuNhCLeoShqWtDxTSm+9oQuE2cWR0FADZcPxA9LHVHoqD8GHvMZC+36SXu
B67dVGEepJPXUOuYc5/GGQLZmSxfbAS8ohHfkpGq/sZ0VqvgWaZ4X1nYXvsybcDn
JMB78IhyNmOds8iLigoTjQ5Rh/Z94IFE0EJbebntpu5A6JPykqpH/q0BZFE/Fn6O
zaIF0mw4I1m2QisnzXwFvafD2nlVBty5eQUtJm8ErKRKSP08Lj8ESXFiLA4pJNo+
l0ddxRKW/T3cBdmuJ64gXuzVW9ptvj95vn+DyJ3W/huJUbr6uJ01k9+XC6TylybC
8v1iLKC2Ub1rcR6MK3NH
=YYy/
-----END PGP SIGNATURE-----

[Michael Tautschnig]

Hi,

Post by Jean-Luc Biord
Dear mentors,
I am looking for a sponsor for my package "ax-emergency-listen".
* Package name : ax-emergency-listen
Version : 1.3.2-1
* URL : http://iz6rdb.trentalancia.com/en/aprs_igate.html
* License : GPL-3.0+
Section : hamradio

[...]

I tried to review this package, but found to blockers that must be addressed
before even a full review can be done:

- Missing copyright and license information: config.h, listen.h lack both of
them and ax25dump.c, kissdump.c, utils.c don't have any license information.
As such, they are not distributable.
- Package fails to build from source:
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT ax_emergency_listen.o -MD -MP -MF .deps/ax_emergency_listen.Tpo -c -o ax_emergency_listen.o ax_emergency_listen.c
ax_emergency_listen.c:48:30: fatal error: netax25/axconfig.h: No such file or directory

Best regards,
Michael

[Fabrizio Regalli]

Hello Michael,

thanks for your review.

Post by Michael Tautschnig
I tried to review this package, but found to blockers that must be addressed
- Missing copyright and license information: config.h, listen.h lack both of
them and ax25dump.c, kissdump.c, utils.c don't have any license information.
As such, they are not distributable.

I need to talk with the author for try to solve this issue.

Post by Michael Tautschnig
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT ax_emergency_listen.o -MD -MP -MF .deps/ax_emergency_listen.Tpo -c -o ax_emergency_listen.o ax_emergency_listen.c
ax_emergency_listen.c:48:30: fatal error: netax25/axconfig.h: No such file or directory

Sorry, the 'Build-Depends' was broken.
Fixed in new uploaded version.

Cheers,
Fabrizio.

[Craig Small]

Post by Fabrizio Regalli

Post by Michael Tautschnig
- Missing copyright and license information: config.h, listen.h lack both of
them and ax25dump.c, kissdump.c, utils.c don't have any license information.
As such, they are not distributable.

I need to talk with the author for try to solve this issue.

They sound the like files out of the listen program in ax25-utils.

- Craig
--
Craig Small VK2XLZ http://www.enc.com.au/ csmall at : enc.com.au
Debian GNU/Linux http://www.debian.org/ csmall at : debian.org
GPG fingerprint: 1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5

[Fabrizio Regalli]

Hi Craig,

Post by Craig Small

Post by Fabrizio Regalli

Post by Michael Tautschnig
- Missing copyright and license information: config.h, listen.h lack both of
them and ax25dump.c, kissdump.c, utils.c don't have any license information.
As such, they are not distributable.

For kissdump.c and utils.c files, I've added the copyright information.
The only problem is finding which type of license they use.

Post by Craig Small

Post by Fabrizio Regalli
I need to talk with the author for try to solve this issue.

They sound the like files out of the listen program in ax25-utils.

I'm looking into ax25-utils package for finding some useful
information.

Cheers,
Fabrizio.

[Michael Tautschnig]

Hi,

I am looking for a sponsor for my package "spey".
* Package name : spey
Version : 1.0.pre1-1
* URL : http://spey.sf.net
* License : GPL v2
Section : mail

[...]

I finally got around to review your package. I have two main issues that at
least need further discussion:

- You do have a proper copyright statement and a hint at the license, but as you
are upstream: wouldn't it be nicer to use the standard license header
recommended by GPL? The debian/copyright file definitively needs fixing, it
still has some of the boilerplate text in it. Here I'd suggest using DEP-5
format: http://dep.debian.net/deps/dep5/
- The package fails to build from source, possibly due to libgcrypt updates:

/usr/bin/ld: .pm-cache/4-main_spey.o: undefined reference to symbol 'gcry_control@@GCRYPT_1.2'
/usr/bin/ld: note: 'gcry_control@@GCRYPT_1.2' is defined in DSO /lib64/libgcrypt.so.11 so try adding it to the linker command line
/lib64/libgcrypt.so.11: could not read symbols: Invalid operation

As I'm not into this pm build system you're pretty much on your own here.

Best regards,
Michael

[Michael Tautschnig]

Hi Miguel,

I am looking for a sponsor for the new version 3.0.0015-0.1
of my package "nvidia-cg-toolkit".

[...]

You seem to be putting lots of energy in this package. Yet your changes go far
beyond what an ordinary NMU should be like. As there has been a sequence of NMUs
already probably it would be best if you took over the package. Yet you will
have to follow proper procedures to do so. Have you gotten in touch with the
current official maintainer(s)? Looking at your changelog you seem to have
spoken to at least one of them. Please provide some information about this
process (here, not in the package) and please perform the proper procedure to
take over the package, if you intend to do so in long term. If all you want to
do is an NMU, then please make sure you keep the changes to a minimum.

Best regards,
Michael

[Russ Allbery]

Post by Michael Tautschnig
Hi Miguel,

I am looking for a sponsor for the new version 3.0.0015-0.1
of my package "nvidia-cg-toolkit".

[...]
You seem to be putting lots of energy in this package. Yet your changes
go far beyond what an ordinary NMU should be like. As there has been a
sequence of NMUs already probably it would be best if you took over the
package. Yet you will have to follow proper procedures to do so. Have
you gotten in touch with the current official maintainer(s)? Looking at
your changelog you seem to have spoken to at least one of them. Please
provide some information about this process (here, not in the package)
and please perform the proper procedure to take over the package, if you
intend to do so in long term. If all you want to do is an NMU, then
please make sure you keep the changes to a minimum.

Also, if you're interested in maintaining packages of this sort in
general, you may want to consider joining the NVIDIA packaging team by
subscribing to the pkg-nvidia-devel mailing list on
lists.alioth.debian.org. We're currently maintaining the CUDA packages as
well as the NVIDIA graphics drivers and libraries, and while I don't have
any time to work on NVIDIA packaging myself, I'm happy to do uploads for
others and some package review. Other people on the team may also be
willing to help.

[Andres Mejia]

Post by Russ Allbery

Post by Michael Tautschnig
Hi Miguel,

I am looking for a sponsor for the new version 3.0.0015-0.1
of my package "nvidia-cg-toolkit".

[...]
You seem to be putting lots of energy in this package. Yet your changes
go far beyond what an ordinary NMU should be like. As there has been a
sequence of NMUs already probably it would be best if you took over the
package. Yet you will have to follow proper procedures to do so. Have
you gotten in touch with the current official maintainer(s)? Looking at
your changelog you seem to have spoken to at least one of them. Please
provide some information about this process (here, not in the package)
and please perform the proper procedure to take over the package, if you
intend to do so in long term. If all you want to do is an NMU, then
please make sure you keep the changes to a minimum.

Also, if you're interested in maintaining packages of this sort in
general, you may want to consider joining the NVIDIA packaging team by
subscribing to the pkg-nvidia-devel mailing list on
lists.alioth.debian.org.  We're currently maintaining the CUDA packages as
well as the NVIDIA graphics drivers and libraries, and while I don't have
any time to work on NVIDIA packaging myself, I'm happy to do uploads for
others and some package review.  Other people on the team may also be
willing to help.
--
--

I'm no longer interested in maintaining nvidia-cg-toolkit. You could
ask Federico to see if he still wants to maintain this package.

Also, I believe the license could allow nvidia-cg-toolkit sources and
binaries to be included in non-free, thus there would be no need for
the downloader tool.

[Stefano Rivera]

Hi Andres (2011.05.03_05:51:51_+0200)

Post by Andres Mejia
Also, I believe the license could allow nvidia-cg-toolkit sources and
binaries to be included in non-free, thus there would be no need for
the downloader tool.

I made that change in Ubuntu, and would be glad to see it happen here
too. nvidia-cg-toolkit is a build-dep for a couple of other packages,
but they can't be built on buildds as long as this is downloading from
the Internet in postinst.

See #502457 (although that got dragged totally off-topic).

SR
--
Stefano Rivera
http://tumbleweed.org.za/
H: [phone] C: [phone] UCT: x3127

[Andreas Beckmann]

[Adding Cc: Federico Di Gregorio as he is the current maintainer]

Post by Russ Allbery

Post by Michael Tautschnig
Hi Miguel,

I am looking for a sponsor for the new version 3.0.0015-0.1
of my package "nvidia-cg-toolkit".

[...]
You seem to be putting lots of energy in this package. Yet your changes
go far beyond what an ordinary NMU should be like. As there has been a
sequence of NMUs already probably it would be best if you took over the
package. Yet you will have to follow proper procedures to do so. Have
you gotten in touch with the current official maintainer(s)? Looking at
your changelog you seem to have spoken to at least one of them. Please
provide some information about this process (here, not in the package)
and please perform the proper procedure to take over the package, if you
intend to do so in long term. If all you want to do is an NMU, then
please make sure you keep the changes to a minimum.

Also, if you're interested in maintaining packages of this sort in
general, you may want to consider joining the NVIDIA packaging team by
subscribing to the pkg-nvidia-devel mailing list on
lists.alioth.debian.org. We're currently maintaining the CUDA packages as
well as the NVIDIA graphics drivers and libraries, and while I don't have
any time to work on NVIDIA packaging myself, I'm happy to do uploads for
others and some package review. Other people on the team may also be
willing to help.

I'm fine with getting this package under the Debian NVIDIA Maintainers
umbrella. But of course we need to hear what Federico plans, first.
I can help with the packaging, but I doubt I'll ever use the package :)

I just had a brief look over the package.
What's curious is that you need a login at nvidia to download the
software, but the license explicitely allows redistribution.

* as Andres Mejia has resigned, you should also drop the
DM-Upload-Allowed: yes
from debian/control as there are no non-DD uploaders left
* the debian/watch file can be generated with a single sed call with
two -e '...' -e '...' parameters
* the watch file is not useful since it points to a page that requires
a login :-(
* why do we need override_dh_gencontrol: and override_dh_builddeb:? dh
should work fine without
* the doc package should only Recommends/Suggests: the toolkit (if you
add a dependency at all), otherwise you have an Arch: all package that's
uninstallable everywhere except on i386/amd64. But why shouldn't you
read the docs on a different arch or without installing the toolkit?
* use Suggests: nvidia-cg-toolkit-doc (= ${source:Version}) as this is
an arch:all package that does not get binNMUed. See deb-substvars(5)
* the runtime libraries should probably be split to a separate package,
I assume that binaries created with the cg toolkit will be linked
against them and this shouldn't pull in the toolkit. But that's not for
this new upstream NMU. A single package for both libs should be OK to
avoid mixing different versions as there seems to be no proper
SONAME/SOVERSION being used :-(
* why do we need post{inst,rm} scripts that manually call ldconfig?
* eventually override the Informational and eXperimental lintian tags,
too (spelling-error-in-binary, binary-has-unneeded-section,
shlib-calls-exit). Have a look at the nvidia-graphics-drivers package
how we did this there, e.g. copy the comments why we added these overrides
* since source code seems to be available, can you rebuild the cgfxcat
and cginfo binaries? These rebuilds could be stripped :-)
* debhelper 8, standards 3.9.2

Andreas

[Miguel Colon]

Hi all:

Since I received 3 email within the last 24 hours I will try to answer
all the question here.

I started this package over a year ago and made packages for 6-7
nvidia toolkit releases while merging the changelog so I might not
remember all the reasons I did things like that since I never made a
local git for it. I only uploaded the last 2 releases to Debian

Post by Michael Tautschnig
You seem to be putting lots of energy in this package. Yet your changes go far
beyond what an ordinary NMU should be like. As there has been a sequence of NMUs
already probably it would be best if you took over the package. Yet you will
have to follow proper procedures to do so. Have you gotten in touch with the
current official maintainer(s)? Looking at your changelog you seem to have
spoken to at least one of them. Please provide some information about this
process (here, not in the package) and please perform the proper procedure to
take over the package, if you intend to do so in long term. If all you want to
do is an NMU, then please make sure you keep the changes to a minimum.
Best regards,
Michael

Yeah I realize the changes are way over a standard NMU. My original
plan was to email the original maintainers the changes so they could
incorporate them. I sent a few email and finally opened a bug report
since I never got a reply. Since the package is not officially
orphaned and I'm not a DD/DM I was waiting to see if it got orphaned
and then was planning on contacting the nvidia devel list to see if
they wanted to include it under their team umbrella.

Post by Michael Tautschnig
Also, if you're interested in maintaining packages of this sort in
general, you may want to consider joining the NVIDIA packaging team by
subscribing to the pkg-nvidia-devel mailing list on
lists.alioth.debian.org.  We're currently maintaining the CUDA packages as
well as the NVIDIA graphics drivers and libraries, and while I don't have
any time to work on NVIDIA packaging myself, I'm happy to do uploads for
others and some package review.  Other people on the team may also be
willing to help.
--

As I mentioned above I was considering this but I was waiting to hear
from the maintainers since I did not want to hijack or do anything
that may have been perceived as rude by them.

Post by Michael Tautschnig
I just had a brief look over the package.
What's curious is that you need a login at nvidia to download the
software, but the license explicitely allows redistribution.

Yes this started within the last week or so since I try to check every
1-2 weeks for a new version and I first saw this 3-4 days ago.

Post by Michael Tautschnig
* as Andres Mejia has resigned, you should also drop the
   DM-Upload-Allowed: yes
 from debian/control as there are no non-DD uploaders left

Seems that I missed it when I removed Andres Mejia name.

Post by Michael Tautschnig
* the debian/watch file can be generated with a single sed call with
 two -e '...' -e '...' parameters
* the watch file is not useful since it points to a page that requires
 a login :-(

Yeah, when I noticed this 3-4 days ago I knew the watch file /
get-orig-source routine became obsolete.

Post by Michael Tautschnig
* why do we need override_dh_gencontrol: and override_dh_builddeb:? dh
should work fine without

This is for compatibility with ubuntu lucid or to be more
correct/precise with debhelper 7 or at least some versions of it. I
compile these on my ppa and from what I remember the i386 version
tried to run those 2 commands for the ia32 package which is amd64
only. I never saw this error on my local machine on Debian since it
had debhelper 8 and compiling in maverick also worked fine without
those overrides. I used to bump the debhelper dependency to > 8 but
decided to use this method since it worked in debhelper 7/8.

Post by Michael Tautschnig
* the doc package should only Recommends/Suggests: the toolkit (if you
add a dependency at all), otherwise you have an Arch: all package that's
uninstallable everywhere except on i386/amd64. But why shouldn't you
read the docs on a different arch or without installing the toolkit?

The -doc package contains several example programs that would require
the toolkit to compile. To ensure that those program compiled I made
it depend on the same source version to avoid compatibility issues. To
be honest I thought I had it as a Recommends but thanks for pointing
it out. Also I was thinking of splitting the package since the
documentation is truly an arch:all package but the examples are really
an arch: i386 amd64 package but never got around to it.

Post by Michael Tautschnig
* use Suggests: nvidia-cg-toolkit-doc (= ${source:Version}) as this is
an arch:all package that does not get binNMUed. See deb-substvars(5)

True.

Post by Michael Tautschnig
* the runtime libraries should probably be split to a separate package,
I assume that binaries created with the cg toolkit will be linked
against them and this shouldn't pull in the toolkit. But that's not for
this new upstream NMU. A single package for both libs should be OK to
avoid mixing different versions as there seems to be no proper
SONAME/SOVERSION being used :-(

When I thought about this, I reached a similar conclusion :-(.

Post by Michael Tautschnig
* why do we need post{inst,rm} scripts that manually call ldconfig?

That was my interpretation of:
http://www.debian.org/doc/debian-policy/ch-sharedlibs.html
Section 8.1.1

Post by Michael Tautschnig
* eventually override the Informational and eXperimental lintian tags,
too (spelling-error-in-binary, binary-has-unneeded-section,
shlib-calls-exit). Have a look at the nvidia-graphics-drivers package
how we did this there, e.g. copy the comments why we added these overrides

Oh I had these override before but I took them out since I did not
want to go too override happy. I can add them back and check the
graphic package for the comment.

Post by Michael Tautschnig
* since source code seems to be available, can you rebuild the cgfxcat
and cginfo binaries? These rebuilds could be stripped :-)

I did not know the source code was available. I will try searching for
it and see.

Post by Michael Tautschnig
* debhelper 8, standards 3.9.2

Yeah I was waiting for the next version to update the package and this
was in the TODO list.


I will incorporate some of these changes in the local version I have
and wait till confirmation for the others. If there is any interest I
can re-upload it to debian.mentors or wait and see if it gets
incorporated under the nvidia umbrella and then do them.


Thanks for the interest,
Miguel

[Michael Tautschnig]

Hi again,

Post by Jean-Luc Biord
Dear mentors,
I am looking for a sponsor for the new version 2.0.5-2
of my package "xlog".

[...]

Why do you ship src/dxcc.patch? I guess that is just a left over from applying
that patch. Could you please clean that up and re-upload to mentors?

Thanks a lot,
Michael

[Nanakos Chrysostomos]

Post by Michael Tautschnig
Hi again,

Post by Jean-Luc Biord
Dear mentors,
I am looking for a sponsor for the new version 2.0.5-2
of my package "xlog".

[...]
Why do you ship src/dxcc.patch? I guess that is just a left over from applying
that patch. Could you please clean that up and re-upload to mentors?

Fixed and re-uploaded to mentors. Bumped also to S-V 3.9.2. Thanks again.

Post by Michael Tautschnig
Thanks a lot,
Michael

[Michael Tautschnig]

Hi again,

[...]

Post by Nanakos Chrysostomos
Fixed and re-uploaded to mentors. Bumped also to S-V 3.9.2. Thanks again.

Thanks again for another quick turnaround. Built and just uploading.

Best regards,
Michael

[Michael Tautschnig]

Hi,

I am looking for a sponsor for my package "haserl".
* Package name : haserl
Version : 0.9.27-1
* URL : http://haserl.sourceforge.net
* License : GPL-2
Section : interpreters

[...]

IMHO this is not distributable as-is because all the header files in src/ lack
both copyright and license information. Please persuade upstream to fix this.

Best regards,
Michael

[Chow Loong Jin]

Post by Michael Tautschnig
Hi,

I am looking for a sponsor for my package "haserl".
* Package name : haserl
Version : 0.9.27-1
* URL : http://haserl.sourceforge.net
* License : GPL-2
Section : interpreters

[...]
IMHO this is not distributable as-is because all the header files in src/ lack
both copyright and license information. Please persuade upstream to fix this.

I'll talk to them about it, but as far as I know, there is nothing in GPL that
states that all source files *must* contain the GPL copyright/license header.

In fact, I was under the impression that while it is strongly recommended for
the license/copyright information for each source file to be documented, if
there is no reason to believe that the source file does not come from somewhere
else, it is then safe to assume that source files which do not contain explicit
license/copyright information are released under the same license/copyright as
the global project license/copyright, as mentioned in COPYING.

Am I wrong about this?

[Michael Tautschnig]

Hi again,

[...]

Post by Chow Loong Jin

Post by Michael Tautschnig
IMHO this is not distributable as-is because all the header files in src/ lack
both copyright and license information. Please persuade upstream to fix this.

I'll talk to them about it, but as far as I know, there is nothing in GPL that
states that all source files *must* contain the GPL copyright/license header.

IANAL, but "How to Apply These Terms to Your New Programs" states pretty clearly
that "... each file should have at least the “copyright” line and a pointer to
where the full notice is found."

I'm not sure whether this is legally binding, but

http://www.gnu.org/licenses/gpl-howto.html

explicitly states in the fourth paragraph that adding such a header is required.

Post by Chow Loong Jin
In fact, I was under the impression that while it is strongly recommended for
the license/copyright information for each source file to be documented, if
there is no reason to believe that the source file does not come from somewhere
else, it is then safe to assume that source files which do not contain explicit
license/copyright information are released under the same license/copyright as
the global project license/copyright, as mentioned in COPYING.
Am I wrong about this?

I have no information stating that there is a difference between multiple
license/copyright holders and a single one. Yet neither do I have conclusive
information beyond the one cited above.

If you need a conclusive statement, please consult debian-legal. As far as I am
concerned I'm just not going to mess around with such an unclear state of
affairs and will refrain from sponsoring. Yet others might be fine with it :-)

Best,
Michael

[Chow Loong Jin]

[...]

Hi Michael,

I've just uploaded a new version of haserl (0.9.29-1), which has the copyright
issues fixed. Could you look through it please?

Thanks for your time!

[Michael Tautschnig]

[...]

Well, it seems to me that this information is better suited for the
patch header and the changelog (I want to know about that when I'm
looking at the patch, but as an end-user reading the installed
README.Debian, I don't really care; it won't change how I use the
package).

I have changed them to the changelog file. However, I don't know how
to get the information in the debian patches folder, as those files
are automatically created by dpkg. Can you help me? I'm using
git-buildpackge for creating the package.

[...]

They are created by dpkg *once*, but after that you can freely modify them.

Hope this helps,
Michael

[Daniel Lombraña González]

Dear Michael,

Thanks for your advice. I will try to fix this problem, and upload a new
version.

Regards,

Daniel

Post by Michael Tautschnig
[...]

Well, it seems to me that this information is better suited for the
patch header and the changelog (I want to know about that when I'm
looking at the patch, but as an end-user reading the installed
README.Debian, I don't really care; it won't change how I use the
package).

I have changed them to the changelog file. However, I don't know how
to get the information in the debian patches folder, as those files
are automatically created by dpkg. Can you help me? I'm using
git-buildpackge for creating the package.

[...]
They are created by dpkg *once*, but after that you can freely modify them.
Hope this helps,
Michael

--
··························································································································································
http://github.com/teleyinex
http://www.flickr.com/photos/teleyinex
··························································································································································
Por favor, NO utilice formatos de archivo propietarios para el
intercambio de documentos, como DOC y XLS, sino HTML, RTF, TXT, CSV
o cualquier otro que no obligue a utilizar un programa de un
fabricante concreto para tratar la información contenida en él.
··························································································································································

[Michael Tautschnig]

Hi,

I am looking for a sponsor for the new version 0.3-4
of my package "googlizer".
googlizer - utility to search Google via your GNOME menu/panel
The package appears to be lintian clean.

[...]

That might well be, but it fails to build:

gcc -lgtk-x11-2.0 -lglib-2.0 -lgnome-2 -lgnomeui-2 -Wl,--no-add-needed -Wl,--as-needed `pkg-config --libs libgnomeui-2.0 libgnome-2.0 gtk+-2.0 glib-2.0` googlizer.o -o googlizer
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libgtk-x11-2.0.so: undefined reference to symbol 'gdk_atom_intern'
/usr/bin/ld: note: 'gdk_atom_intern' is defined in DSO /usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libgdk-x11-2.0.so so try adding it to the linker command line
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libgdk-x11-2.0.so: could not read symbols: Invalid operation

Besides this fundamental problem, please also consider the using the simplified
debian/rules file as you upgrade to debhelper >= 7. Another plus would be moving
debian/copyright to DEP-5 format.

Thanks a lot,
Michael

[Gildardo Adrian Maravilla Jacome]

Post by Michael Tautschnig
Hi,

I am looking for a sponsor for the new version 0.3-4
of my package "googlizer".
googlizer - utility to search Google via your GNOME menu/panel
The package appears to be lintian clean.

[...]
gcc -lgtk-x11-2.0 -lglib-2.0 -lgnome-2 -lgnomeui-2 -Wl,--no-add-needed -Wl,--as-needed `pkg-config --libs libgnomeui-2.0 libgnome-2.0 gtk+-2.0 glib-2.0` googlizer.o -o googlizer
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libgtk-x11-2.0.so: undefined reference to symbol 'gdk_atom_intern'
/usr/bin/ld: note: 'gdk_atom_intern' is defined in DSO /usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libgdk-x11-2.0.so so try adding it to the linker command line
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libgdk-x11-2.0.so: could not read symbols: Invalid operation
Besides this fundamental problem, please also consider the using the simplified
debian/rules file as you upgrade to debhelper >= 7. Another plus would be moving
debian/copyright to DEP-5 format.
Thanks a lot,
Michael

Thanks for the observation, i'll work on that right now

[Michael Tautschnig]

Hi,

Post by Jean-Luc Biord
Dear mentors,
I am looking for a sponsor for my package "mosquitto".
* Package name : mosquitto
Version : 0.9.2-1
* URL : http://mosquitto.org/
* License : BSD
Section : net

[...]

I've reviewed your package and a few issues need fixing. As you are upstream,
all of them should be easy to address:

- src/conf.c lacks copyright and license information
- debian/mosquitto.prerm: Where does the "service" command come from in "service mosquitto stop"?
- 0.10 has been released :-) (according to debian/watch)

Best regards,
Michael

[Roger Light]

Hi Michael,

Thanks for responding - you've worked up quite a list of reviews there!

Post by Michael Tautschnig
Hi,

Post by Jean-Luc Biord
Dear mentors,
I am looking for a sponsor for my package "mosquitto".
* Package name    : mosquitto
 Version         : 0.9.2-1
* URL             : http://mosquitto.org/
* License         : BSD
 Section         : net

[...]
I've reviewed your package and a few issues need fixing. As you are upstream,
- src/conf.c lacks copyright and license information

This was fixed in 0.10.

Post by Michael Tautschnig
- debian/mosquitto.prerm: Where does the "service" command come from in "service mosquitto stop"?

It comes from sysvinit-utils. I'd like some advice on this topic
though - I've seen both "service" and invoke-rc.d used for
starting/stopping services in prerm. Is there a recommended way of
doing it?

Post by Michael Tautschnig
- 0.10 has been released :-) (according to debian/watch)

Yup - proves that debian/watch works :)

Thanks,

Roger

[Roger Light]

Post by Michael Tautschnig
Hi,

Post by Jean-Luc Biord
Dear mentors,
I am looking for a sponsor for my package "mosquitto".
* Package name    : mosquitto
 Version         : 0.9.2-1
* URL             : http://mosquitto.org/
* License         : BSD
 Section         : net

[...]
I've reviewed your package and a few issues need fixing. As you are upstream,
- src/conf.c lacks copyright and license information
- debian/mosquitto.prerm: Where does the "service" command come from in "service mosquitto stop"?
- 0.10 has been released :-) (according to debian/watch)

I've fixed these issues and uploaded a new version.

* src/conf.c has copyright information included in mosquitto-0.10 anyway.
* debian/mosquitto.prerm uses invoke-rc.d instead of "service",
assuming that it is available. This matches behaviour I've seen in
other prerm scripts.
* The package has been updated for 0.10.

Thanks,

Roger

[Michael Tautschnig]

Hi,

I am looking for a sponsor for my package "oggfix".
* Package name : oggfix
Version : 0.9.0
Upstream Author : Gunter Königsmann
* URL : http://launchpad.net/oggfix
* License : GPL V3+
Section : sound
oggfix - Command-line-utility that fixes broken ogg vorbis files
The package appears to be lintian clean.

^^^^^^^^^^^^^

No, that can't be true.

- Depends lacks ${shlibs:Depends}
- No copyright and license information in source files.
- debian/copyright should be DEP-5 formatted (see
http://dep.debian.net/deps/dep5/)
- Build-Depends should not include build-essential packages.
- It sounds weird that gnome-common is needed to build a command-line utility
for ogg files!?

Please address these issues and re-upload.

Thanks a lot,
Michael

[Gunter Königsmann]

Post by Michael Tautschnig
Hi,

I am looking for a sponsor for my package "oggfix".
* Package name : oggfix
Version : 0.9.0
Upstream Author : Gunter Königsmann
* URL : http://launchpad.net/oggfix
* License : GPL V3+
Section : sound
oggfix - Command-line-utility that fixes broken ogg vorbis files
The package appears to be lintian clean.

^^^^^^^^^^^^^
No, that can't be true.
- Depends lacks ${shlibs:Depends}

Fixed that on my computer.

Post by Michael Tautschnig
- No copyright and license information in source files.

Is there any fixed or recommended format for doing this?

Post by Michael Tautschnig
- debian/copyright should be DEP-5 formatted (see
http://dep.debian.net/deps/dep5/)

Fixed that on my computer.

Post by Michael Tautschnig
- Build-Depends should not include build-essential packages.

Fixed that on my computer.

Post by Michael Tautschnig
- It sounds weird that gnome-common is needed to build a command-line utility
for ogg files!?

Will fix that before re-uploading the file: The only thing I did use
from this package was the autogen.sh from gnome.

Post by Michael Tautschnig
Please address these issues and re-upload.

Will upload the package as soon as you tell me which format the
copyright information in the source files has to be in.

Kind regards,

Gunter.

[Dominique Dumont]

Post by Gunter Königsmann

Post by Michael Tautschnig
- No copyright and license information in source files.

Is there any fixed or recommended format for doing this?

You should contact upstream and ask them to clarify copyright and license.
Ideally, this info should be somewhere in upstream source. But a mail from the
author can be enough to clarify.

Once you have this updated info, you can update debian/copyright file.

Hope this helps

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/

[Michael Tautschnig]

Hi again,

[...]

Post by Gunter Königsmann

Post by Michael Tautschnig
- No copyright and license information in source files.

Is there any fixed or recommended format for doing this?

[...]

Post by Gunter Königsmann

Post by Michael Tautschnig
- It sounds weird that gnome-common is needed to build a command-line utility
for ogg files!?

Will fix that before re-uploading the file: The only thing I did use
from this package was the autogen.sh from gnome.

Post by Michael Tautschnig
Please address these issues and re-upload.

Will upload the package as soon as you tell me which format the
copyright information in the source files has to be in.

As you claim it is GPL, you should familiarize yourself with its use:

http://www.gnu.org/licenses/gpl-howto.html

Well, at least you should have fully read the license text. The last section is
titled "How to Apply These Terms to Your New Programs." Please re-read that
part.

Best regards,
Michael

[Gunter Königsmann]

Post by Michael Tautschnig
http://www.gnu.org/licenses/gpl-howto.html
Well, at least you should have fully read the license text. The last section is
titled "How to Apply These Terms to Your New Programs." Please re-read that
part.

Cool! Did actually never do that.

---

Uploaded the new version of the file to mentors.debian.net.

Thanks a lot,

and kind regards,

Gunter Königsmann.

[Michael Tautschnig]

Hi,

I am looking for a sponsor for my package "xkbind".
* Package name : xkbind
Version : 2010.05.20-1
* URL : http://xkbind.sourceforge.net/
* License : GPL-2
Section : x11

[...]

Nice one, package looks good. Built and uploaded.

Best regards,
Michael

[Michael Tautschnig]

Hi Michael,

I am looking for a sponsor for my package "gordon".
* Package name : gordon
Version : 0~git20101011-1
Section : utils

[...]

I had previously reviewed that package; sorry for taking so long for yet another
round of reviews.

I have now built&uploaded your package, although I'm not 100% convinced whether
patching in the copyright headers is acceptable practice. We'll see what
ftp-master says about that. Other than that the package seems mostly fine, just
one issue that you should fix in the next upload (which you can do yourself...):

W: libjs-gordon: description-synopsis-starts-with-article

Best regards,
Michael

[Michael Gilbert]

Post by Ruben Molina
Hi Michael,

I am looking for a sponsor for my package "gordon".
* Package name : gordon
Version : 0~git20101011-1
Section : utils

[...]
I had previously reviewed that package; sorry for taking so long for yet another
round of reviews.
I have now built&uploaded your package, although I'm not 100% convinced whether
patching in the copyright headers is acceptable practice. We'll see what
ftp-master says about that. Other than that the package seems mostly fine, just
W: libjs-gordon: description-synopsis-starts-with-article

Thanks Michael! I'll fix that up.

Best wishes,
Mike

[Michael Tautschnig]

Hi,

I am looking for a sponsor for my package "hiredis".
* Package name : hiredis
Version : 0.9.2-1
* URL : https://github.com/antirez/hiredis
* License : BSD-3-Clause
Section : libs

[...]

The package looks mostly fine, just one major problem: all files in adapter/ and
the example* and test.c files lack both copyright and license information.
Please persuade upstream to get this fixed.

Best regards,
Michael

[Alessandro Ghedini]

Post by Michael Tautschnig
Hi,

I am looking for a sponsor for my package "hiredis".
* Package name : hiredis
Version : 0.9.2-1
* URL : https://github.com/antirez/hiredis
* License : BSD-3-Clause
Section : libs

[...]
The package looks mostly fine,

Thanks for reviewing. I've uploaded to mentors.d.n a new version of the
package based on the new upstream release (0.10.0).

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/h/hiredis
- Source repository: deb-src http://mentors.debian.net/debian unstable main
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/h/hiredis/hiredis_0.10.0-1.dsc

Some other "major" changes have been the bump to Standards-Verion 3.9.2,
the inclusion of the pkg-config file made by Andriy Senkovych, some patches
have been reworked (mainly to reflect upstream sources), and the rename of
the -dev package from libhiredis0-dev to libhiredis-dev.

Could you please review the new version as well?

Post by Michael Tautschnig
just one major problem: all files in adapter/ and
the example* and test.c files lack both copyright and license information.
Please persuade upstream to get this fixed.

I'm going to contact upstream as soon as possible. Thanks for the pointer.
What would be a viable solution? I mean, is a new upstream release needed,
or just a statement from the upstream author (e.g. on the project's
bugtracker, to which d/copyright will point) is enough? The second solution
does not exlude the first of course (the files will be fixed in a
subsequent release) but would permit the package to enter Debian without
waiting and to not block other packages that depend on this (e.g. webdis
which is an ITP).

Cheers

[Michael Tautschnig]

Hi Michael,

Four months later ...

Post by Jean-Luc Biord
Dear mentors,
I am looking for a sponsor for my package "unix-privesc-check".
* Package name : unix-privesc-check
Version : 1.4-1
* URL : http://pentestmonkey.net/tools/unix-privesc-check
* License : GPL-2
Section : utils

[...]

Post by Jean-Luc Biord
I would be glad if someone uploaded this package for me.

I'd be willing to upload, but there are a few things I'd like to see
clarified/resolved first:

- Versioning: above, you claim it's version 1.4-1, then your package on
mentors.d.n has 0~r25 and the script itself says "1.6". I'm confused...
- What about the license? Has upstream meanwhile removed the legal-use-only
restriction?
- The package ships unix-privesc-check.1 via a patch. This seems unintentional.
- A watch file would be desirable. But that requires cleaning up the version
mess :-)

Best regards,
Michael

[Michael Tautschnig]

Hi,

It seems to me that no one has replied (in public?) so far to this nice request.
Sorry about that.

[...]

i'm not sure how to proceed from here, so i'm hereby asking you to
assist me. i'm listed as uploader, yet i'm not sure if i can upload
anywhere else than on my own repository, please let me know how we can
close this bug. it is my intention in some close future to try become
a debian maintainer so please don't save your suggestions on how
things should be done, but also keep in mind this bug should be closed
ASAP and i have no more time to dedicate to this task in the coming
week.

Even though it may seem as yet another burden despite the long wait: have you
had any chance to speak to your co-maintainers? Or heard back from them (some of
them seem to be CC'ed)?

If they're unwilling to continue to work on this package that's quite a shame;
but then I'd be happy to review your new code and changes and possibly sponsor
an upload. But I'd seriously refrain from stepping on your co-maintainers' toes,
so please first try to go this route.

Best regards,
Michael

[Adam D. Barratt]

[Reply-To overridden, as I have no idea if the other recipients are
reading -mentors, but reset to there having noted that. Please Cc: me
on replies if relevant as I am not subscribed]

Post by Michael Tautschnig
It seems to me that no one has replied (in public?) so far to this nice request.

The bug log of #614458 disagrees with you, fwiw, at least to some extent
(for one thing, it explicitly mentions that Filippo reviewed the updated
packaging).

Regards,

Adam

[Michael Tautschnig]

Hi Marco,

[...]

This is a demonstrative GUI for the IWTAN library (see my previous mail
in this list). It is built upon the QT library. It contains a binary
iwtan-gui and its manpage.

[...]

Before even starting to possible review this package I'm seriously wondering why
these are separate source packages. Why aren't both the GUI and the library
built from the same source package? As is, I would expect a number of dependency
problems to appear!?

Best regards,
Michael

[Marco Cornolti]

Post by Michael Tautschnig
Hi Marco,
[...]

This is a demonstrative GUI for the IWTAN library (see my previous mail
in this list). It is built upon the QT library. It contains a binary
iwtan-gui and its manpage.

[...]
Before even starting to possible review this package I'm seriously wondering why
these are separate source packages. Why aren't both the GUI and the library
built from the same source package? As is, I would expect a number of dependency
problems to appear!?
Best regards,
Michael

Hello,
thank you for considering reviewing this package. I have separated the
GUI and the library because they are actually separated projects. The
idea is that, despite they were both coded by me, the gui could be
written (and, in the future, mantained) by someone else just using the API.
I'm not sure that's a good reason, and i can merge the two source
packages if it's considered cleaner.
The point is that I've written the GUI just to give an example of how to
exploit some of the library features (even though the gui is thought to
be nice and useful), and I wanted to keep the example and library codes
separate.

Bests,
Marco

[Michael Tautschnig]

Hi Francesco,

Post by Jean-Luc Biord
Dear mentors,
I am looking for a sponsor for the new version 2.05-6
of my package "libhtml-fromtext-perl".
libhtml-fromtext-perl - Mark up text as HTML

[...]

Concerning this package and also your other RFS, libemail-find-perl: could you
please try to speak to the Debian perl group [1]? They should be able offer much
more informed input on your packages.

Hope this helps,
Michael

[1] http://pkg-perl.alioth.debian.org/

[Michael Tautschnig]

Hi Patrick,

Post by Jean-Luc Biord
Dear mentors,
I am looking for a sponsor for my package "basenji".
* Package name : basenji
Version : 0.7.2-1
Upstream Author : Patrick Ulbrich
* URL : www.launchpad.net/basenji
* License : GPL
Section : gnome
basenji - A portable volume indexing tool

[...]

Post by Jean-Luc Biord
I would be glad if someone uploaded this package for me.

Have you spoken to debian-med people for reviewing this package? After all, the
Maintainer is set as such, hence I'd expect you can easily receive much more
informed input from this end!?

Best,
Michael

[Michael Tautschnig]

Hi,

Post by Jean-Luc Biord
Dear mentors,
I am looking for a sponsor for the new version 0.1.6.2-2
of my package "halevt".
halevt - generic handler for HAL events

[...]

I've reviewed, built, and uploaded the package. Yet it would be nice if a number
of spelling errors could be fixed in upcoming versions, as lintian will tell you
when run as

lintian -iI --pedantic *.changes

Thanks a lot for your work,
Michael