Re: RFS: l2tp-ipsec-vpn (updated package)

[Kilian Krause]

Hi Werner,

On Wed, Nov 07, 2012 at 07:58:16PM +0100, Werner Jaeger wrote:
> I've added the missing entry for 1.0.7-1 in changelog and just uploaded
> it successfully.

Thanks.

Reviewed, built, signed, uploaded.

For the next upload you may want to look at:
W: l2tp-ipsec-vpn: hardening-no-relro usr/bin/L2tpIPsecVpn
W: l2tp-ipsec-vpn: hardening-no-fortify-functions usr/bin/L2tpIPsecVpn

Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: l2tp-ipsec-vpn (updated package)

[Kilian Krause]

Hi Werner,

On Sat, Mar 10, 2012 at 03:28:28PM +0100, Werner Jaeger wrote:
> My sponsor is kil...@debian.org.
> 
> I just uploaded the new version 1.0.4-1 of my package "l2tp-ipsec-vpn".
[...]
> http://mentors.debian.net/debian/pool/main/l/l2tp-ipsec-vpn/l2tp-ipsec-vpn_1.0.4-1.dsc

following the lintian warning
W: l2tp-ipsec-vpn: possibly-insecure-handling-of-tmp-files-in-maintainer-script 
prerm:23

I'd like to ask you to explain a bit more about your motivation to move from
/var/run to /var/tmp. Of course /tmp can be used for sockets, but according
to [1] I'd say /var/tmp/ is not the right choice.

To me the old path looked much better: (see resources/getIPSecInfo.lib.tpl)
-exec 3http://www.pathname.com/fhs/2.2/fhs-5.15.html

-- 
Best regads,
Kilian


signature.asc
Description: Digital signature

Re: RFS: lebiniou (already in Debian, new upstream version 3.15)

[Kilian Krause]

Hi Olivier,

On Tue, Feb 21, 2012 at 12:40:32AM +0100, Olivier Girondel wrote:
> http://mentors.debian.net/debian/pool/main/l/lebiniou/lebiniou_3.15-1.dsc

reviewed, built, signed, uploaded.

Thanks for your work!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: lebiniou (new upstream version 3.14)

[Kilian Krause]

Hi Nicolas,

On Fri, 2012-01-20 at 07:54 +0100, Nicolas Bourdaud wrote:
> On 20/01/2012 01:11, Olivier Girondel wrote:
> > 
> > Dear mentors,
> > 
> > I am looking for a sponsor for my package "lebiniou".
> > 
> >Package name: lebiniou
> >Version : 3.14-1
> >Upstream Author : Olivier Girondel 
> >URL : http://biniou.net/
> >License : GPL2+
> >Section : graphics
> 
> I have not done a full review, but I think your debian/control file miss
> some Build-Depends like libpulse-dev or zlibg1-dev...

I wouldn't see why they should lack - it builds perfectly fine without.

Reviewed, built, signed, uploaded.

Thanks to Olivier for the work!

-- 
Cheers,
Kilian


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

Re: New version of autoconf-archive

[Kilian Krause]

Hi Bastien,

On Mon, Jan 09, 2012 at 03:10:05PM +0100, bastien ROUCARIES wrote:
> Le Monday 9 January 2012 00:28:04, Paul Wise a écrit :
> > On Mon, Jan 9, 2012 at 4:17 AM, bastien ROUCARIES wrote:
> > > A new version of autoconf-archive.
> > 
> > At the very least you should be linking to the dsc file.
> Sorry available here:
> http://mentors.debian.net/package/autoconf-archive
> and 
> http://mentors.debian.net/debian/pool/main/a/autoconf-archive/autoconf-archive_20111221-1.dsc

that version obviously FTBFS due to the quilt removal being incomplete and
having "include /usr/share/cdbs/1/rules/patchsys-quilt.mk" still in
debian/rules. With that line removed, I've built, signed and uploaded your
package, so please make sure you sync that change back into your Git
including all tags.

Thanks for your work!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: l2tp-ipsec-vpn-daemon (updated package)

[Kilian Krause]

Hi Werner,

On Tue, 2011-12-27 at 19:54 +0800, Werner Jaeger wrote:
> I just uploaded the new version 0.9.6-2 of my package
> "l2tp-ipsec-vpn-daemon".
> 
> This upload fixes the lintian warning "empty lines must be escaped by
> representing them by a space followed by a dot" in the
> debian/copyright file.

This is a rather cosmetic change that IMHO doesn't need a new upload. If
there is no fix other than this that needs to be put into Debian right
now I'd prefer to wait for a couple of days/weeks and see if there
aren't any substantial changes for the next upload to be included too.
If then again nothing else pops up we can do a new sourceful upload with
just this change.

-- 
Best regards,
Kilian


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

Re: RFS: l2tp-ipsec-vpn (updated package)

[Kilian Krause]

Hi Werner,

On Tue, 2011-12-27 at 19:54 +0800, Werner Jaeger wrote:
> My sponsor is kil...@debian.org.
> 
> I just uploaded the new version 1.0.3-1 of my package "l2tp-ipsec-vpn".
> 
> This upload would fix several bugs.
> 
>  * Package name: l2tp-ipsec-vpn
>Version : 1.0.3-1
>Upstream Author : Werner Jaeger 
>  * URL : https://launchpad.net/l2tp-ipsec-vpn
>  * License : GPL 3
>Section : net
> 
> It builds those binary packages:
> 
> l2tp-ipsec-vpn - control your L2TP IPsec VPN connections
> 
> To access further information about this package, please visit the
> following URL:
> 
>   http://mentors.debian.net/package/l2tp-ipsec-vpn
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x
> http://mentors.debian.net/debian/pool/main/l/l2tp-ipsec-vpn/l2tp-ipsec-vpn_1.0.3-1.dsc
> 
> I would be glad if someone uploaded this package for me.

Reviewed, built, signed, uploaded.

Thanks for your work!

-- 
Best regards,
Kilian


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

Re: New autoconf-archive package

[Kilian Krause]

Salut Bastien,

On Sat, Nov 05, 2011 at 01:04:56PM +, Bastien ROUCARIES wrote:
> On Fri, Nov 4, 2011 at 1:40 PM, Kilian Krause  wrote:
> > On Thu, Nov 03, 2011 at 05:03:50PM +0100, Bastien ROUCARIES wrote:
> >> Any news ?
> >
> > I guess you're talking about the debian/2011.04.12-1 tag in Git? Or where
> > can I grab the latest version you want uploaded?
> 
> I have not yet pushed on git. Will do tomorow. I  have downloaded
> under mentors, you will find the link at
> http://mentors.debian.net/package/autoconf-archive.

that version is fine for me. During building I'm seeing though:
-(snip)-
make[1]: Leaving directory `/tmp/buildd/autoconf-archive-20110917'
rm -f debian/stamp-autotools
rmdir --ignore-fail-on-non-empty .
rmdir: failed to remove `.': Invalid argument
make: [makefile-clean] Error 1 (ignored)
dh_clean 
rm -f debian/stamp-autotools-files
/usr/bin/make -f debian/rules reverse-config
make[1]: Entering directory `/tmp/buildd/autoconf-archive-20110917'
-(snip)-

...which may or may not be intended.

Further, thinking once more about
P: autoconf-archive source: unneeded-build-dep-on-quilt
I think that the quilt is really not used during package build and thus can be
safely removed as you only use it in your scripts, right?

And regarding the move in debian/rules for the docs, I would consider asking
upstream to implement a DOCDIR variable or so.

As none of the above is actually serious enough, I've just built, signed and
uploaded your package as is. ;-)

Thanks!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: lebiniou (already in Debian, new upstream version 3.13)

[Kilian Krause]

Hi Olivier,

On Sat, Nov 05, 2011 at 09:19:53PM +0100, Olivier Girondel wrote:
> I am looking for a sponsor for my package "lebiniou".
[...]
> http://mentors.debian.net/debian/pool/main/l/lebiniou/lebiniou_3.13-1.dsc
> 
> I would be glad if someone uploaded this package for me.

Reviewed, built, signed, uploaded.

Just for the record: There's no need to update old entries in the changelog.
Actually that should not be done at all. Even if it makes the read more
uniform.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: New autoconf-archive package

[Kilian Krause]

Hi Bastien,

On Thu, Nov 03, 2011 at 05:03:50PM +0100, Bastien ROUCARIES wrote:
> Any news ?

I guess you're talking about the debian/2011.04.12-1 tag in Git? Or where
can I grab the latest version you want uploaded?

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: l2tp-ipsec-vpn (updated package)

[Kilian Krause]

Hi Werner,

On Sat, 2011-10-22 at 22:02 +0200, Werner Jaeger wrote:
> I am looking for a sponsor for the new version 1.0.1-2 of my package
> "l2tp-ipsec-vpn".
> [...]
> http://mentors.debian.net/debian/pool/main/l/l2tp-ipsec-vpn/l2tp-ipsec-vpn_1.0.2-1.dsc

Reviewed, built, signed, uploaded.

Thanks!

-- 
Best regards,
Kilian


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

Re: RFS: lebiniou (already in Debian, new upstream version 3.12)

[Kilian Krause]

Hi Olivier,

On Sun, Oct 16, 2011 at 08:46:11PM +0200, Olivier Girondel wrote:
> I am looking for a sponsor for my package "lebiniou".
> http://mentors.debian.net/debian/pool/main/l/lebiniou/lebiniou_3.12-1.dsc

Reviewed, built, signed, uploaded.

Thanks for your work!

-- 
Cheers,
Kilian


signature.asc
Description: Digital signature

Re: RFS: qasconfig 0.2.0

[Kilian Krause]

Hi Sebastian,

On Thu, Oct 13, 2011 at 02:16:24PM +0200, Sebastian H. wrote:
> I am looking for a sponsor for my package "qasconfig".
> 
>  * Package name: qasconfig
>Version : 0.2.0-1
>Upstream Author : Sebastian Holtermann 
>  * URL : http://xwmw.org/qasconfig
>  * License : GPL-3
>Section : sound
> 
> http://mentors.debian.net/debian/pool/main/q/qasconfig/qasconfig_0.2.0-1.dsc

Reviewed, built, signed, uploaded.

Thanks for your work.

Just for the record:
I: qasconfig: capitalization-error-in-description linux Linux

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: qasmixer 0.14.0 - squeeze backport

[Kilian Krause]

Hi Sebastian,

On Tue, Oct 04, 2011 at 03:36:28PM +0200, Sebastian H. wrote:
> I am looking for a sponsor for my package "qasmixer".
[...]
> http://mentors.debian.net/debian/pool/main/q/qasmixer/qasmixer_0.14.0-1~bpo60+1.dsc
> 
> I would be glad if someone uploaded this package for me.

Reviewed (and yes, I did see the missing QT change! ;-)), built, signed and
uploaded.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: lebiniou (already in Debian, new upstream version: 3.11)

[Kilian Krause]

Salut Olivier,

On Wed, 2011-09-28 at 11:21 +0200, Olivier Girondel wrote:
> I am looking for a sponsor for my package "lebiniou".
> http://mentors.debian.net/debian/pool/main/l/lebiniou/lebiniou_3.11-1.dsc
> 
> I would be glad if someone uploaded this package for me.


Rebuilt using the official tarball from your website, reviewed, signed,
uploaded.

Thanks!

-- 
Best regards,
Kilian


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

Re: RFS: lebiniou

[Kilian Krause]

Hi Olivier,

On Sun, Sep 11, 2011 at 10:31:20PM +0200, Olivier Girondel wrote:
> I am looking for a sponsor for my package "lebiniou".
[...]
> http://mentors.debian.net/debian/pool/main/l/lebiniou/lebiniou_3.10-1.dsc

Thanks for your work.

Built, signed, uploaded.

-- 
Cheers,
Kilian


signature.asc
Description: Digital signature

Re: RFS: lebiniou-data

[Kilian Krause]

Hi Olivier,

On Sun, Sep 11, 2011 at 10:34:40PM +0200, Olivier Girondel wrote:
> I am looking for a sponsor for my package "lebiniou-data".
[...]
> http://mentors.debian.net/debian/pool/main/l/lebiniou-data/lebiniou-data_3.10-1.dsc

Thanks for your work. 

Built, signed, uploaded.

-- 
Cheers,
Kilian


signature.asc
Description: Digital signature

Re: RFS: l2tp-ipsec-vpn (updated package)

[Kilian Krause]

Hi Werner,

On Wed, 2011-08-31 at 08:05 +0200, Werner Jaeger wrote:
> I am looking for a sponsor for the new version 1.0.1-1 of my package 
> "l2tp-ipsec-vpn".
> This upload would fix the problem that the package is not installable on 
> kfreebsd-* and hurd-*.
> 
>  * Package name: l2tp-ipsec-vpn
>Version : 1.0.1-1
>Upstream Author : Werner Jaeger 
>  * URL : https://launchpad.net/l2tp-ipsec-vpn
>  * License : GPL 3
>Section : net
> 
> It builds those binary packages:
> 
> l2tp-ipsec-vpn - control your L2TP IPsec VPN connections
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   http://mentors.debian.net/package/l2tp-ipsec-vpn
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x 
> http://mentors.debian.net/debian/pool/main/l/l2tp-ipsec-vpn/l2tp-ipsec-vpn_1.0.1-1.dsc
> 
> My main sponsor is kil...@debian.org, but he doesn't reply, so I post it here.

sorry for the delay.

Built, signed, uploaded.

Thanks for the work!

-- 
Best regards,
Kilian


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

Re: RFS: l2tp-ipsec-vpn-daemon (updated package)

[Kilian Krause]

Hi Werner,

On Wed, 2011-08-31 at 07:58 +0200, Werner Jaeger wrote:
> I am looking for a sponsor for the new version 0.9.6-1 of my package 
> "l2tp-ipsec-vpn-daemon".
> The upload would fix Bug #639434: "l2tp-ipsec-vpn-daemon: not installable on 
> kfreebsd-*" in package l2tp-ipsec-vpn-daemon
> 
>  * Package name: l2tp-ipsec-vpn-daemon
>Version : 0.9.6-1
>Upstream Author : Werner Jaeger 
>  * URL : https://launchpad.net/l2tp-ipsec-vpn
>  * License : GPL v3
>Section : net
> 
> It builds those binary packages:
> 
> l2tp-ipsec-vpn-daemon - daemon for L2tpIPsecVpn GUI
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   http://mentors.debian.net/package/l2tp-ipsec-vpn-daemon
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x 
> http://mentors.debian.net/debian/pool/main/l/l2tp-ipsec-vpn-daemon/l2tp-ipsec-vpn-daemon_0.9.6-1.dsc
> 
> My main sponsor is kil...@debian.org, but he doesn't reply, so I post it here.

sorry for the delay.

Built, signed, uploaded.

Thanks for the work!

-- 
Best regards,
Kilian


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

Re: RFS: xxxterm

[Kilian Krause]

Hi Luis,

On Tue, Aug 23, 2011 at 10:18:35PM +0100, Luis Henriques wrote:
> On Sun, Aug 21, 2011 at 10:11:42PM +0100, Luis Henriques wrote:
> [...]
> 
> Just to inform I re-uploaded the package.  Basically, I corrected an issue
> with the copyright file (finally I have all the licenses issues sorted
> out!)

Excellent!

Want me to upload this one or the new 1.500 version? ;-)

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: gnome-split

[Kilian Krause]

Hi Guillaume,

On Sat, Aug 13, 2011 at 09:08:31PM +0200, Guillaume Mazoyer wrote:
> I am looking for a sponsor for my package "gnome-split".
>   dget -x 
> http://mentors.debian.net/debian/pool/main/g/gnome-split/gnome-split_1.1-1.dsc

Thanks for your work.

Built, signed, uploaded.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: Sponsor for accessibility packages

[Kilian Krause]

Hi Jean-Philippe,

On Tue, Aug 09, 2011 at 02:22:48AM +0200, Jean-Philippe MENGUAL wrote:
> Actually I uploaded on http://demo.accelibreinfo.eu a edbrowse.tar.bz2
> which contains the whole package: .dsc, .orig, .debian.tar.gz, etc.
> You'll have the same things (a .dsc, a .orig.tar.gz, a .debian.tar.gz)
> in speechd-up2.tar.gz and speakup-tools.tar.gz for these packages.
> Sorry, I didn't put .dsc directly because I have bad conditions now to
> connect to the Internet. Besides it would create some mess on the
> repository I think.

Thanks for working on the package. I've just had a look at your edbrowse
package. This looks very intrusive for an NMU. IMHO too much intrusive. Is
there any public discussion with the current maintainer? What does he think
about this?

For future posts to this list I'd recommend putting the source upload
directly available either on mentors.debian.net or on your own web server.
The wrapped up tar.bz2 including source and binary is not very handy to
review.

Anyway, if an NMU would be required, please post the statement of the
current maintainer to go ahead and keep changes minimal. Or become new
uploader of the package and comment more verbose all the different changes
you introduce.

N.b. if you're NMUing you should not use the regular -1 version suffix.

Thanks!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: Sitplus -- Free software framework for ludic-therapeutic activities

[Kilian Krause]

Hi Luis,

On Tue, Aug 09, 2011 at 03:09:34AM +0200, Luis Rivas wrote:
[...]
> I've re-uploaded the latest sitplus source package to
> http://mentors.debian.net/debian/pool/main/s/sitplus/
> 
> It is lintian --pedantic clean except for a "binary-without-manpage"
> warning. Please let me know if you need something else.

Sorry to ask you to put another version up onto the now new mentors.d.n but
obviously the migration has eaten your package.

Thanks!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: libchart-php

[Kilian Krause]

Hi Daniel,

On Fri, Aug 12, 2011 at 11:05:52PM +0200, Daniel Lombraña González wrote:
> Would you mind to check again the package ;) I hope this time is almost done
> :)

Sorry for taking so long to have another look. Your debian/watch file still
has some issue in finding the latest version. It grabs a file "detail" for
me instead of the correct upstream source.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: vnstat -- console-based network traffic monitor

[Kilian Krause]

Hi Armin,

On Sat, Aug 13, 2011 at 06:52:53PM +0430, Armin Ranjbar wrote:
> indeed, this is my ITA:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637639

but in that case you cannot adopt the package with the same version that's
already in the archive.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: parcellite 1.0.2~rc2-1 (updated package)

[Kilian Krause]

Hi Andrew,

On Wed, 2011-08-10 at 15:16 -0400, Andrew Starr-Bochicchio wrote:
> On Fri, Aug 5, 2011 at 10:07 AM, Kilian Krause  wrote:
> > Anyway, regarding your packaging:
> >
> > 1.) adding autotools-dev would be still a plus for your package.
> >
> > 2.) debian/copyright is not (yet) in DEP-5 format but in some older format.
> >I don't know about Ubuntu but for Debian converting to DEP-5 would be
> >preferred (at least in d-mentors)
> >
> > 3.) debian/patches/dsofix.patch is having a good DEP-3 header already yet
> >hasn't been marked as pushed upstream. Don't you think upstream will be
> >interested in importing this back into their files?
> >
> > 4.) The LGPL2 files obviously still have the wrong FSF address:
> > ./src/eggaccelerators.h: LGPL (v2 or later) (with incorrect FSF address)
> > ./src/eggaccelerators.c: LGPL (v2 or later) (with incorrect FSF address)
> >You may want to inform upstream about this and have them fix this with
> >the next release.
> >
> > Other than that looks good to go, thus built, signed, uploaded.
> 
> Thanks for the detailed review and upload! Good news and bad news.
> 
> Bad news first: This upload introduced bug #637272
> 
> Good news: Upstream has already released a fix, and I have an upload
> prepared with this new release that also addresses all of your above
> points!
> 
> I've uploaded it to debexpo:
> 
> dget -x 
> http://expo.debian.net/debian/pool/main/p/parcellite/parcellite_1.0.2~rc3-1.dsc
> 
> If for some reason it has gotten lost in the transition, you can grab
> it from collab-maint with:
> 
> bzr branch http://bzr.debian.org/bzr/collab-maint/parcellite/unstable/
> bzr builddeb -S -- -sa
> 
> Here's the changelog for this release:
> 
> parcellite (1.0.2~rc3-1) unstable; urgency=low
> 
>   * debian/copyright: Update to current revision of Dep 5.
>   * Update config.sub and config.guess with dh_autotools_dev.
>   * debian/patches/dsofix.patch: Add upstream bug to header.
>   * New upstream release.
>- Fixed Status Icon missing on execute Action (Closes: #637272).
> 
> Thanks so much!


Even though the upstream tarball is a bit kind of messed up (including
autom4te.cache and ~ backup files) I've just built, signed and uploaded
your package.

Thanks!

-- 
Best regards,
Kilian


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

Re: RFS: wmmixer

[Kilian Krause]

Hi kix,

On Wed, Aug 10, 2011 at 11:25:21AM +0200, Rodolfo kix Garcia wrote:
[...]
> 1. create a new package (pe. wmaker-crm)
> 2. convert wmaker in a metapackage with dependency wmaker-crm
> 3. work normally
> 4. in the future, move wmaker-crm to wmaker
> 
> Is possible to do it? Any idea?

What would be the benefit of having this new package instead of just making
the old one be updated really well with some larger update rounds? The
transition to testing happens only 10 days after upload if no RC bugs are
found in the meantime and if it largely makes sense we can add a "virtual RC
bug" just to hinder transition for some time.

Anyway, I'd suggest you prepare your version and we'll have a look at it and
then decide on how to make the transition.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: taxbird (updated package)

[Kilian Krause]

Hi Olaf,

On Mon, Aug 08, 2011 at 10:49:36PM +0200, Olaf Dietsche wrote:
> Kilian Krause  writes:
> 
> > On Mon, Aug 08, 2011 at 12:26:32PM +0200, Olaf Dietsche wrote:
> >> 
> >> I've seen build problems on
> >> <https://buildd.debian.org/status/package.php?p=taxbird&suite=sid>
> >> 
> >> The build problem could be fixed by adding autotools-dev to the build
> >> dependencies.
> >> 
> >> What should I do next? Just wait for a bug report?
> >> Upload taxbird 0.16-0.2 with a fixed Build-Depends?
> >> Something else ...?
> >
> > If you know the solution, we should pump the fixed version into SID with the
> > same procedure as before, just use a DELAYED/1 or so.
> >
> > Can you prepare that please?
> 
> I uploaded taxbird 0.16-0.2 to debian-mentors. I also emailed the
> NMU-diff to <619...@bugs.debian.org>.

Thanks! 

Looks like the package has some problems rebuilding cleanly (which is what I
usually do just to make sure such errors are caught). I'd welcome if you
could coordinate with the current maintainer to get the package into better
shape yet I have some doubts that this should be done in NMUs.

I've now built the package (only once) so that it actually contains only the
debdiff you've already sent to the bug and uploaded to DELAYED/1.

> If there are additional steps I missed, please tell me so.

Not regarding the NMU. Thanks!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: obexpushd (adopted two uploads ago) (was: Re: RFS: obexpushd (adopted one upload ago))

[Kilian Krause]

Hi Gabriele,

On Mon, Aug 08, 2011 at 03:17:03AM +0200, Gabriele Giacone wrote:
> I am looking for a sponsor for my package "obexpushd".
> http://mentors.debian.net/debian/pool/main/o/obexpushd/obexpushd_0.11.2-1.dsc
> 
> I would be glad if someone uploaded this package for me.
> DMUA flag would be really appreciated too.

1.) I see you now want the upload in unstable. I hope this was intended as
0.11.2-1 was only uploaded to experimental.

2.) Your patch debian/patches/01errno doesn't have any header explaining
where it came from (backported from upstream, self invented) and no notion
whether or not it was reported back upstream which it should have. I'm
sure upstream will like to have it unless they haven't already come up
with that solution in SVN/CVS/Git (in which case you can just refer to
that specific commit)

3.) You edit debian/changelog for past entries. This should not be done. As
the edit is minor I'll leave it as is.

Built, Signed, Uploaded.

Thanks!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: mpd-sima (updated package)

[Kilian Krause]

Hi Geoffroy,

On Mon, Aug 08, 2011 at 01:14:33PM +0200, Geoffroy Youri Berret wrote:
> I am looking for a sponsor for the new version 0.8.0-2
> of my package "mpd-sima".
[...]
> - dget 
> http://mentors.debian.net/debian/pool/main/m/mpd-sima/mpd-sima_0.8.0-2.dsc
> 
> I would be glad if someone uploaded this package for me.

Thanks for the update. 

Just as a personal style preference I'd have used 
"install -d -m 0755 -u $USER -g $USER $PIDDIR" in that case but your
solution is perfectly valid. I just fine the install -d version more elegant
as it's even less lines of code. =)

Anyway, Built, Signed, Uploaded.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: wmmoonclock (updated package)

[Kilian Krause]

Hi kix,

On Mon, Aug 08, 2011 at 01:16:32PM +0200, Rodolfo kix Garcia wrote:
[...]
> >Not sure what you mean with Git files.
> 
> Yes, what should I do with the files at
> http://repo.or.cz/w/dockapps.git

Uhm, I guess that they should become the next 34 new package unless they're
already packaged. Potentially you can try to group them together and omit
those which aren't actively developed and only test code / proof of concept
etc..

Depending on what upstream thinks about this you can also make them one big
source package and build a number of binary packages from there.

Have you got any idea in what source tarball form they'll end up on the web
once this webserver to host them you mentioned will be available?


> Thanks a lot.

Thanks for your work!

> The file is in mentors again.

Built, Signed, Uploaded.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: autotrace (updated package)

[Kilian Krause]

Hi Tony,

On Mon, Aug 08, 2011 at 06:23:39AM -0500, Edgar Antonio Palma de la Cruz wrote:
> El Mon, 08 Aug 2011 10:25:14 +0200
> Kilian Krause  escribió:
> > To me it looks like there's a number of patches that aren't useful
> > anymore:
> > - If you're using autoreconf, are you sure
> > debian/patches/aclocal.m4.patch is needed? 
> This is no applied, is just for history. 

I guess this is what a VCS would do better than some loose files in the
Debian package. They confuse especially a sponsor more than they seem to
help IMHO. If you think they should be left there, you may want to mark them
as UNUSED in both filename and header or just move them to some ATTIC
directory under debian/patches.

And just for the record, when rebuilding your package the following files
are replaced due to the autoreconf anyway:
Makefile.in
aclocal.m4
autotrace.spec
config.h.in
configure
install-sh
ltmain.sh
missing
mkinstalldirs

Thus there's no point in having a patch for them I'd say.


[...]
> Well the upstream was a little quiet the last few years(7) and there's
> no release since 9 years. Anyway I already sent a *ping*. 

*shrug* This makes me wonder how useful this package is in Debian regarding
having to support this for years to come in Debian stable. I'll make this
your call to make, but if upstream is dead this effectively means you're now
in charge to look after your package as if it were your own code I guess.
This may sounds more drastical than it actually is (there's a whole Debian
community to give you helping hands if you ask for it) but after all you
should consider how large the user community still is and if it's not really
better to move them over to a similar and still actively developed
alternative (if possible).

[...]

After a long walk I'd say that except for the unused patches the package is
now in a quite good shape and I hope you keep up the good work!

Thus, built, signed, uploaded.

Thanks for your help!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: taxbird (updated package)

[Kilian Krause]

Hi Olaf,

On Mon, Aug 08, 2011 at 12:26:32PM +0200, Olaf Dietsche wrote:
> Michael Tautschnig  writes:
> 
> > [...]
> >> 
> >> I added NMU-diffs for the debian changes only, because I think adding
> >> the upstream diffs from libgeier 0.11 to 0.12 and taxbird from 0.15 to
> >> 0.16 don't add any value.
> >> 
> > [...]
> >
> > I suppose that's fine. I've now done the following:
> >
> > - Built libgeier and uploaded to DELAYED/5.
> > - Fixed the build-dep of taxbird to use glade instead of glade-gnome as 
> > there is
> >   some semi-broken transition going on. Noted the change in the changelog.
> > - Built and uploaded taxbird to DELAYED/7.
> 
> I've seen build problems on
> 
> 
> The build problem could be fixed by adding autotools-dev to the build
> dependencies.
> 
> What should I do next? Just wait for a bug report?
> Upload taxbird 0.16-0.2 with a fixed Build-Depends?
> Something else ...?

If you know the solution, we should pump the fixed version into SID with the
same procedure as before, just use a DELAYED/1 or so.

Can you prepare that please?

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: lebiniou (new upstream version)

[Kilian Krause]

Hi Olivier,

On Mon, Aug 08, 2011 at 05:56:26PM +0200, Olivier Girondel wrote:
> I am looking for a sponsor for the new version of my package "lebiniou".
[...]
> http://mentors.debian.net/debian/pool/main/l/lebiniou/lebiniou_3.9.1-1.dsc
> 
> I would be glad if someone uploaded this package for me.

-rw-r--r-- 1 kk kk 526624 Aug  8 19:26 lebiniou_3.9.1.orig.tar.gz
-rw-r--r-- 1 kk kk 526640 Aug  8 17:21 lebiniou-3.9.1.tar.gz

...obviously your orig.tar.gz doesn't match your upstream URL. The contents
seems to be the same though. And it also seems that the 3.9 orig tarball no
longer has the ttf file too - so you've modified that as well, eh?

Anyway, using your official tarball, I've built, signed and uploaded your
package.

Thanks!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: wmmoonclock (updated package)

[Kilian Krause]

Hi Rodolfo,

On Mon, 2011-08-08 at 00:36 +0200, Rodolfo kix Garcia wrote:
> On Sat, 6 Aug 2011 20:24:26 +0200, Kilian Krause wrote:
[...]
> >> >4.) The patches altogether lack a DEP-3 header. Please consider
> >> >adding
> >> >one and especially feeding them back upstream to have them
> >> >included and
> >> >vanish from Debian packaging.
> >>
> >> perfect, I will do it.
> 
> I think is done. Some days before send the package to mentors I created 
> two packages, one without patches (patches applied) and other with 
> patches (unapplied). I wrote to the Author asking about add the patches 
> to the source in the upstream version, but I didn't get reply. For this 
> reason I sent the package with patches not applied. The author don't 
> reply me yet, probably is on vacation

There is still no notion which of the patches have been posted back
upstream.

[...]
> >>
> >> >6.) Updating debian/copyright to DEP-5 would be a bonus.
> >>
> >> ok++
> 
> bonus and extra live ;-)

actually no. The top line should have an URL like
http://anonscm.debian.org/viewvc/dep/web/deps/dep5.mdwn?view=co&pathrev=174 and 
no need to paste the verbatim copy of GPL twice. 

> >>
> >> >7.) debian/watch is empty. This makes comparing new upstream
> >> >tarballs to
> >> >your provided one quite tedious. Please update it to the correct
> >> >upstream locations.
> >>
> >> There is not webserver yet. The info at http://windowmaker.org or
> >> http://windowmaker.info is not updated. The pages will move to a CMS
> >> soon, but there is no tarballs yet. I will update the package if the
> >> tarballs are available. Now the files are only in the GIT.
> >
> > That's quite sad but in that case the debian/copyright needs to be 
> > updated
> > too (http://nis-www.lanl.gov/~mgh/WindowMaker/DockApps.shtml is no 
> > longer
> > valid then). And as a personal preference I'd recommend adding a
> > get-orig-source target in the meantime which would preferably 
> > reconstruct
> > some tarball with the contents of the 1.27.orig.tar.gz as is now in 
> > the
> > Debian archive (if possible).
> >
> >> Ok, what should I do? Update the problems 3-7?
> >
> > Yes, and reuse the original tarball to provide the next upload to
> > mentors.d.n (which would make the list 1-7 I guess). ;-)
> 
> I didn't do nothing with this part. I took the original tar.gz file 
> from debian and I made the new package. But what should I do with the 
> git files? How I should to update the package? why I need to update many 
> things (DEP-5, DEP-3, ...) in the package if is "lintian clean"? why not 
> is included in lintian these things?

The DEP-5/DEP-3 is only some minimal housekeeping to keep the package
up-to-date and follow latest developments in terms of Debian packaging.
They make reviewing a lot easier because the sponsor has to only look
for one type of syntax which he is used to. In that they are more a
convenience for the sponsor (and thus the sponsoree) than a technical
requirement.


> Anyway, probably I will need to create a new package, because the 
> problem with the changelog.upstream file, but please, tell me what to do 
> with the git files and how to update the package.

There is no need for a "new package" unless there's a new upstream
version. 

Overall the package looks very good now except for two things:

1.) You should add dh_installchangelogs debian/changelog.upstream as
override to debian/rules until the new upstream release which would
include it in their upstream tarball.

2.) Re-add the symlink /usr/bin/wmmoonclock -> wmMoonClock

You can check the diff using "debdiff wmmoonclock_1.27-29_amd64.changes
wmmoonclock_1.27-30_amd64.changes" (or whatever arch you're on) once
you've rebuilt the old package to see the binary package changes and
"debdiff wmmoonclock_1.27-29.dsc  wmmoonclock_1.27-30.dsc" if you're
interested in the source changes.

Apart from these two changes (and the mini-fix to debian/copyright) I'd
say it's fine to be uploaded.

Updates to the Debian package should be reusing the orig.tar.gz unless
there's a new upstream release (as we are doing with the -30 right now).
Not sure what you mean with Git files.

-- 
Best regards,
Kilian


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

Re: RFS: autotrace (updated package)

[Kilian Krause]

Hi Tony,

On Sun, 2011-08-07 at 20:25 -0500, Edgar Antonio Palma de la Cruz wrote:
> El Wed, 3 Aug 2011 23:49:53 +0200
> Kilian Krause  escribió:
> > Cleaning up is a good thing yet the oldpatches.patch looks like it
> > catches more than it should:
> > 
> > AUTHORS   |2 
> > Makefile.am   |4 
> > Makefile.in   |  914 -
> > README|2
> > aclocal.m4| 8966 +--
> > autotrace.1   |4
> > autotrace.h   |4
> > autotrace.pc.in   |4 
> > config.h.in   |3 
> > configure |25257
> > +-
> > configure.in  |   91 curve.c   |4 
> > fit.c |3
> > ltmain.sh | 3665 +--
> > main.c|   10 
> > output-pdf.c  |   16 
> > output-pstoedit.c |2 
> > output-pstoedit.h |2 
> > 18 files changed, 28530 insertions(+), 10423 deletions(-)
> I split the oldpatches.patch(and then was removed) to make a
> patch-per-file and then I removed the changes in:
> ltmain.sh
> configure
> config.h.in
> Makefile.in
>
> The patch for this files was removed because when I use autoreconf
> it remove this files and use another files(the same but *new*) to
> build.

Thanks! Still it looks like all of the patches you elaborately pieced
apart do neither have a meaningful description what they do and why they
are needed nor have any source (where they were taken from and who
originally made them up) and comment whether they have already been
pushed back upstream.

To me it looks like there's a number of patches that aren't useful
anymore:
- If you're using autoreconf, are you sure
debian/patches/aclocal.m4.patch is needed? 

- debian/patches/AUTHORS.patch is effectively a null edit. Moreover this
is nothing Debian should decide on its own.

- debian/patches/autotrace.h.patch looks pretty much like a null edit
too. Why is this needed?

- At least your patches:
  + debian/patches/autotrace.pc.in.patch
  + debian/patches/config.h.in.patch
  + debian/patches/configure.in.patch
  + debian/patches/curve.c.patch
  + debian/patches/fit.c.patch
  + debian/patches/main.c.patch
  + debian/patches/output-pdf.c.patch
  + debian/patches/output-pstoedit.c.patch
  + debian/patches/output-pstoedit.h.patch
  + debian/patches/README.patch
 sound like a pretty good idea to talk to upstream about. If that is not
taken from upstream they should be informed. Please put verbose comments
why they are needed and where taken from including the information
whether they are forwarded back upstream.

- debian/patches/configure.patch, debian/patches/ltmain.sh.patch,
debian/patches/Makefile.in.patch can be omited with autoreconf I guess.

- debian/patches/Makefile.am.patch would probably be a good candidate to
revisit. Debian does not want to ship *.la files anymore.

Having a look at the rest of the package:

What exactly is debian/pstoedit.m4 supposed to do?

In debian/rules you use autoreconf but not autotools-dev. Why? Moreover
your clean target removed *dh-orig which is supposed to be done by
autotools/autoreconf debhelpers. I guess you want to put sample.c into
debian/clean and remove the override to let the automatic work
correctly.

More of a style hint than a requirement: --prefix=/usr
--mandir=/usr/share/man are default for dh_auto_configure. No need to
add them.

> There's a warn from lintian:
> W: autotrace source: ancient-libtool ltmain.sh 1.4.2
> Should I override it?

Well, you have a patch in debian/patches for that anyway. So you can
both override this warning or just ignore it. The preferred would be if
upstream could produce a fixed release with all the patches applied to
move them out of Debian altogether.

Thanks!

-- 
Best regards,
Kilian


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

Re: RFS: ndpmon

[Kilian Krause]

Hi John,

On Sat, 2011-08-06 at 18:23 -0400, John R. Baskwill wrote:
> Now that I have the correct version of lintian, things look better.  I
> have upload a new version of the ndpmon package.  I changed the
> version back to 1.4.0-1 because I was told I shouldn't change the
> version number if this was the initial release of the package.  Thanks
> for all of the help.

thanks for the update.

While reading into your package I'm wondering about:

1.) ndpmon.init:
- DAEMON and INIT must be defined in /etc/default/ndpmon. I doubt
that's a good default. You should define fall-back defaults in the init
script too

- you background start-stop-daemon during starting yet try to evaluate
its return value. I doubt that's a good combination. Moreover you have a
added sleep without any useful value IMHO as the return code is pulled
before the sleep anyway.

- during stop you unconditionally cat a PIDFILE without checking it
exists and run kill on the outcome. A better solution would be something
like PID=$(ps -C $DAEMON -o pid=) and check if that's not empty and kill
that (or check if that's equal to the PIDFILE and kill it then).

- status should check PIDFILE and/or something like the ps -C $DAEMON
and report based on that.

  I'd recommend you check the manpage of ps for further options you may
see fit.

- exit $? at the end is very likely to not match what you intended to
use as exit status. Maybe you should 

2.) Patches:
- there is no need to modify Makefile to delete config.log and
config.status unless you want to report this back to upstream (which is
not indicated in the header). From a Debian POV debian/clean and/or
debian/rules will do (and should be used preferred)

- I'm not sure install.patch is needed. You can as well use debian/tmp
as DESTDIR and move files from there using dh_install I guess. Reporting
the fixes back upstream seem to make sense yet there again is no
indication this was done.

- spelling errors - again look useful, but please make sure they don't
remain in Debian's archive alone but are included upstream.

3.) debian/rules template header can be omited.

as autotools-dev are already in Build-Depends (which is good) they
should also be activated in debian/rules (using --with autotools_dev)

4.) Fetching http://standards.ieee.org/regauth/oui/oui_public.txt.

OUCH! There is no internet access guaranteed during building a
package. That means this is quite likely to fail.

Moreover:
Fetching http://www.cavebear.com/CaveBear/Ethernet.txt 
Error fetching http://www.cavebear.com/CaveBear/Ethernet/Ethernet.txt:
404 Not Found

N.b. there is an attempt to make a shared package for that. See e.g.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481299 for details and
more bugs numbers. Please try to use that package (once avail) or an
offline copy in the meantime.

5.) Rebuilding your package twice in a row produces a Debian patch:
dpkg-source: info: local changes stored in
ndpmon-1.4.0/debian/patches/debian-changes-1.4.0-1, the modified files
are:
 ndpmon-1.4.0/Makefile
 ndpmon-1.4.0/config_ndpmon.xml
 ndpmon-1.4.0/ndpmon.sh
 ndpmon-1.4.0/ndpmon_defs.h
 ndpmon-1.4.0/neighbor_list.xml
 ndpmon-1.4.0/plugins/countermeasures/Makefile
 ndpmon-1.4.0/plugins/mac_resolv/Makefile
dpkg-source: info: building ndpmon in ndpmon_1.4.0-1.debian.tar.gz

6.) You still ship source files in your binary package like:
./usr/lib/ndpmon/plugins/mac_resolv/mac_resolv.c
./usr/lib/ndpmon/plugins/mac_resolv/mac_resolv.h
./usr/lib/ndpmon/plugins/mac_resolv/Makefile.in
./usr/lib/ndpmon/plugins/countermeasures/icmp_lib_nd.c
./usr/lib/ndpmon/plugins/countermeasures/countermeasures.c
./usr/lib/ndpmon/plugins/countermeasures/countermeasures.h
./usr/lib/ndpmon/plugins/countermeasures/icmp_lib_nd.h
./usr/lib/ndpmon/plugins/countermeasures/icmp_lib.c
./usr/lib/ndpmon/plugins/countermeasures/Makefile.in
./usr/lib/ndpmon/plugins/countermeasures/icmp_lib.h
./usr/lib/ndpmon/plugins/countermeasures/countermeasures_on_link.h
./usr/lib/ndpmon/plugins/countermeasures/countermeasures_guard.h

Sorry!

-- 
Best regards,
Kilian


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

Re: RFS: ndpmon

[Kilian Krause]

Hi John,

On Sat, Aug 06, 2011 at 05:26:26PM -0400, John R. Baskwill wrote:
> 2011/8/4 Benoît Knecht 
[...]
> > > >  - 'lintian -I --pedantic ndpmon_1.4.0-2_*.changes' had this to say:
> > > >
> > > >  W: ndpmon source: configure-generated-file-in-source config.status
> > > >  W: ndpmon source: configure-generated-file-in-source config.cache
> > > >  W: ndpmon source: configure-generated-file-in-source config.log
> >
> 
> These files are included in the original tarball.  I modified the clean
> target to remove these files, and also included lintian overrides for the
> files.  I will suggest to upstream to not include these files in the future.
>  I do have one question about the tarball, though.  The file I downloaded
> was named ndpmon-1.4.0.tgz.  Everything I read about packaging seemed to
> assume the tarball would be named ndpmon-1.4.0.tar.gz, so I renamed the
> file.  Is that permissible, or should I have left the name as it was?

Renaming is fine. uscan will do that for you even if you ask it to --rename.

As you have a configure-based upstream source I hope you've put
autotools-dev in charge of keeping your config.* files up to date. ;-)


> > > >  W: ndpmon source: out-of-date-standards-version 3.9.1 (current is
> > > > 3.9.2)
> >
> 
> My lintian says the current standard is 3.9.1, but OK.

Then use the latest unstable or backports version. ;-)


[...]
> > > >  I: ndpmon: spelling-error-in-binary usr/sbin/ndpmon Recieved
> > Received
> > > >  I: ndpmon: spelling-error-in-binary usr/sbin/ndpmon adress address
> > > >  I: ndpmon: spelling-error-in-binary usr/sbin/ndpmon unkown unknown
> > > >  I: ndpmon: spelling-error-in-binary usr/sbin/ndpmon unkown unknown
> > > >  I: ndpmon: spelling-error-in-binary usr/src/ndpmon/ndpmon.o
> > Recieved
> > > > Received
> > > >  I: ndpmon: spelling-error-in-binary usr/src/ndpmon/ndpmon.o adress
> > > > address
> > > >  I: ndpmon: spelling-error-in-binary usr/src/ndpmon/neighbors.o
> > unkown
> > > > unknown
> > > >  I: ndpmon: spelling-error-in-binary usr/src/ndpmon/neighbors.o
> > unkown
> > > > unknown
> > > >  E: ndpmon: helper-templates-in-copyright
> > > >  I: ndpmon: spelling-error-in-manpage
> > usr/share/man/man8/ndpmon.8.gz
> > > > allows to allows one to
> > > >
> >
> 
> I included patches to correct the spelling errors.  The patches have not
> been sent upstream yet, but I will do that.  The copyright file is in DEP5
> format.

Patches should have their headers in DEP-3 format. DEP-5 is for
debian/changelog only.

[...]

Thanks for keeping us posted!

Please also tell us when the next version is up on mentors.d.n for review.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: presage

[Kilian Krause]

Hi Matteo,

On Sat, Aug 06, 2011 at 05:46:56PM +0100, Matteo Vescovi wrote:
[...]
> - dget 
> http://mentors.debian.net/debian/pool/main/p/presage/presage_0.8.6-1.dsc
> 
> I would be glad if you uploaded this package for me.

Good work!

Built, Signed, Uploaded.

And just while I'm watching the uplaod run I was just thinking that for the
next upload you may also want to introduce a -dbg package. Have you thought
about adding one? Usually complements a library quite well.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: mobile-broadband-provider-info (updated package)

[Kilian Krause]

Hi Bhavani,

On Sat, Aug 06, 2011 at 10:57:18PM +0530, Bhavani Shankar R wrote:
> I am looking for a sponsor for the new version 20110806-1
> of my package "mobile-broadband-provider-info".
> - dget 
> http://mentors.debian.net/debian/pool/main/m/mobile-broadband-provider-info/mobile-broadband-provider-info_20110806-1.dsc
> 
> I would be glad if someone uploaded this package for me.

Thanks for your work!

Built, Signed, Uploaded.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: wmmoonclock (updated package)

[Kilian Krause]

Hi kix,

On Sat, Aug 06, 2011 at 07:12:07PM +0200, Rodolfo kix Garcia wrote:
> On Fri, 05 Aug 2011 13:43:07 +0200, Kilian Krause wrote:
> >On Sat, 2011-07-30 at 12:48 +0200, Rodolfo kix Garcia wrote:
> >>I am looking for a sponsor for the new version 1.27-30
> >>of my package "wmmoonclock".
> >>
> >>http://mentors.debian.net/debian/pool/main/w/wmmoonclock/wmmoonclock_1.27-30.dsc
> >>
> >>I would be glad if someone uploaded this package for me.
> >
> >Sorry, but no.
> 
> :'( ;-)
> 
> >1.) If you update a package without new upstream release you must use
> >the orig.tar.gz file that is in the Debian archive. Any upload using
> >another tarball will fail to be accepted by the Debian archive.
> >
> >2.) You moved upstream's changelog out of debian/ with the new
> >upstream
> >tarball. As said above the tarball in inalienable without a new
> >upstream
> >release version and thus this change cannot be accepted.
> 
> Ok. Please, take a look here: http://repo.or.cz/w/dockapps.git
> 
> Is the git for dockapps. The WindowMaker project is making a new git
> with the dockapps. Here, in this tree, the changelog file is in the
> root folder, not in the debian folder. This is the reason for a new
> version with this file in the root and new version number.

Sorry if I've made myself not clear enough as you do not seem to have gotten
my point. To make an upload of 1.27-30 you have to use the orig.tar.gz like
http://ftp.debian.org/debian/pool/main/w/wmmoonclock/wmmoonclock_1.27.orig.tar.gz
which is already in the Debian archive for the last versions.

No other file will be accepted by the Debian archive for an upload using
upstream version 1.27. And this file does not contain a changelog. 

If you now provide a new upload with version 1.27-30 that has a changelog
file in there instead of under debian/ that means you're not using the same
upstream tarball and thus your upload cannot be accepted by the Debian
archive scripts.

In case you can have upstream declare this as 1.28 release that'll be fine
but until then there is no way around using exactly this tarball.


> >3.) shipping changelog as docs is not an required.
> >dh_installchangelogs
> >should catch it in default locations - unusual locations can be
> >provided
> >in debian/rules as argument. No need to add changelog as docs too.
> 
> ok
> 
> >4.) The patches altogether lack a DEP-3 header. Please consider
> >adding
> >one and especially feeding them back upstream to have them
> >included and
> >vanish from Debian packaging.
> 
> perfect, I will do it.
> 
> >5.) Regarding taking over the maintainer ship. You should update the
> >title of #588837 to read ITA.
> 
> ok
> 
> >6.) Updating debian/copyright to DEP-5 would be a bonus.
> 
> ok++
> 
> >7.) debian/watch is empty. This makes comparing new upstream
> >tarballs to
> >your provided one quite tedious. Please update it to the correct
> >upstream locations.
> 
> There is not webserver yet. The info at http://windowmaker.org or
> http://windowmaker.info is not updated. The pages will move to a CMS
> soon, but there is no tarballs yet. I will update the package if the
> tarballs are available. Now the files are only in the GIT.

That's quite sad but in that case the debian/copyright needs to be updated
too (http://nis-www.lanl.gov/~mgh/WindowMaker/DockApps.shtml is no longer
valid then). And as a personal preference I'd recommend adding a
get-orig-source target in the meantime which would preferably reconstruct
some tarball with the contents of the 1.27.orig.tar.gz as is now in the
Debian archive (if possible).

> Ok, what should I do? Update the problems 3-7?

Yes, and reuse the original tarball to provide the next upload to
mentors.d.n (which would make the list 1-7 I guess). ;-)

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: presage

[Kilian Krause]

Hi Matteo,

On Sat, Aug 06, 2011 at 03:53:27PM +0100, Matteo Vescovi wrote:
> >Anyway, an initial upload is 0.8.6-1 not 0.8.6-3.
> >And for a real first uploaded we don't need the entire d-mentors history.
> >That's on lists.d.o for everyone who wants to have a look.
> 
> Should I revert the package version to 0.8.6-1 before re-uploading
> to debian-mentors then? I assumed every upload to debian-mentors
> would require incrementing the package version.

Yes. mentors.d.n allows to override any version and also allows you to
upload any version disregarding whether there'd be a newer version already
uploaded or not. The Debian archive itself is of course not so generous. =)


> >I'd say it's fine to go in. Do you want to fix the last bits before the
> >first real upload to Debian or shall we just go as is?
> 
> I'll take a stab at fixing the last bits first, if you don't mind.

Sure.

> Many thanks for reviewing my package and all your help so far.

No problem. Happy to help!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: presage

[Kilian Krause]

Hi Matteo,

On Sat, Aug 06, 2011 at 03:12:51PM +0100, Matteo Vescovi wrote:
> Hi Kilian,
> 
> Many thanks for taking the time to review my package.
> 
> >Your changelog looks like this has been in Debian for a looong time yet I
> >cannot find any traces of it. If you reckon this is an initial upload there
> >should be only one entry in debian/changelog.
> 
> Yes, this would be an initial upload to Debian, if accepted. I
> previously uploaded the package for review to debian-mentors, and
> added a changelog entry for each round of reviews.

OMG. ;-)

Anyway, an initial upload is 0.8.6-1 not 0.8.6-3. 
And for a real first uploaded we don't need the entire d-mentors history.
That's on lists.d.o for everyone who wants to have a look.


> >>I would be glad if someone reviewed/uploaded this package for me.
> >Ok, you asked for it, so here goes:
> >
> >1.) debian/control has broken RFC822 multiline fields. The first char of all
> > subsequent lines needs to be a white space.
> 
> Subsequent lines in multiline fields begin with a single space
> character. I think this complies with RFC822, or am I missing
> something?

My vim highlighting tells me that whitespace is ok but tabstop isn't.
Practicallly dpkg seems to agree with you that tabs are accepted as well.
;-)

For the Description fiels you've used leading white space btw. just not for
Build-Depends and Depends of libpresage1 and pyprompter.

[...]
> >5.) debian/copyright is still at rev 135. Latest candidate of DEP-5 is 174
> >
> > Moreover there's a typo: License: GLP-2+
> > And these seem to be not included:
> > ./apps/gtk/gprompter/scintilla/src/RESearch.h: *No copyright* Public 
> > domain
> > ./apps/gtk/gprompter/scintilla/lexlib/StyleContext.cxx: Public domain
> > ./apps/gtk/gprompter/scintilla/lexlib/StyleContext.h: Public domain
> 
> Fixed typo and added missing files.

Good.

> BTW, is there a tool I can use to check that debian/copyright is in
> good shape?

None that I know of. Sorry.


> >6.) debian/libpresage1.symbols looks pretty empty
> 
> The symbols exported by the libpresage1 shared library are
> controlled and versioned by a linker version script
> (src/lib/libpresage.map). debian/libpresage1.symbols leverages
> upstream symbol versioning.

Maybe they're controlled, but the libpresage1.symbols has got nothing but
headers! :-?


> >7.) usr/share/doc/libpresage-dev doesn't need to be created in
> > debian/libpresage-dev.dirs - it'll be auto-created by
> > debian/libpresage-dev.docs if required.
> 
> Fixed, removed debian/libpresage-dev.dirs

Good.
libpresage-dev.install still has
usr/share/presage/getting_started.txt usr/share/doc/libpresage-dev
which effectively is a *.docs entry. Not sure why you'd want to hide that in
*.install.

[...]
> >10.) pyprompter and libpresage-dev are arch any but none of which has any
> >  arch dependent files. Do you plan to add a static lib or something?
> 
> I changed pyprompter package to arch: all and changed its dependency
> to python-presage (>= ${binary:Version}) to clear the lintian
> not-binnmuable-all-depends-any error. Is this appropriate?

Sure. Looks good to me. Even though as the arch=all only is built for the
first time, you could as well use >= ${source:Version} here.

 
> I'm not sure what to do with the libpresage-dev package.
> I tried changing this to arch: all, but this also caused lintian to
> give a not-binnmuable-all-depends-any error.
> Should -dev packages not be arch: any ?
> Can I change its "libpresage1 (= ${binary:Version})" to "libpresage1
> (>= ${binary:Version})" ?

Mmmmh, this one is a bit more tricky. I think it's best to leave it as is
because otherwise you'd loosen the Depends too much. 

And eventually there'll be a static lib or some other arch dependent code
that you'll want to ship in the -dev package anyway. 

> - dget 
> http://mentors.debian.net/debian/pool/main/p/presage/presage_0.8.6-3.dsc

Your patch
debian/patches/fix-hyphen-used-as-minus-sign-in-text2ngram-man-page.patch
doesn't have a debian/patches/series and therefore isn't applied. Is this
intended?

I'd say it's fine to go in. Do you want to fix the last bits before the
first real upload to Debian or shall we just go as is?

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: Default options for Lintian (Was: Re: RFS: fgo)

[Kilian Krause]

Hi Niels,

On Sat, Aug 06, 2011 at 03:52:06PM +0200, Niels Thykier wrote:
> On 2011-08-06 15:31, Christopher Baines wrote:
> > [...]
> > Thanks, I have now fixed these, issues and uploaded the fixed package.
> > 
> > After finally guessing the correct syntax for the lintian config file
> > (~/.lintianrc), I was able to make the -I and --pedantic options
> > permanent: 
> > pedantic = 1
> > display-info = 1
> > This might be useful for others.
> >  
> >> [...]
> 
> Hey,
> 
> You were not the only one with that problem (#636681). :)
> 
> I committed a fix for that earlier today, but a review of the actual
> text is more than welcome[1].

or use DEBUILD_LINTIAN_OPTS="-IE --pedantic" in .devscripts together with
debuild. ;-)

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: fgo

[Kilian Krause]

Hi Christopher,

On Sat, Aug 06, 2011 at 02:31:10PM +0100, Christopher Baines wrote:
> On Sat, 2011-08-06 at 13:47 +0200, Kilian Krause wrote:
[...]
> > The upstream ChangeLog is obviously under docs/CHANGE_LOG.
> 
> Thanks, I have now fixed these, issues and uploaded the fixed package.

I've just added another line in debian/rules to make sure CHANGE_LOG isn't
installed twice, built, signed and uploaded your package.

-- 
Cheers,
Kilian


signature.asc
Description: Digital signature

Re: RFS: evolution-tray

[Kilian Krause]

Hi Max,

On Fri, Jul 15, 2011 at 09:56:37AM +0600, Max Tsepkov wrote:
> Thanks to people from debian-devel the package is now ready and lintian
> clean.
> Therefore, I'm reposting the RFS.
> * Package name: evolution-tray
> http://mentors.debian.net/debian/pool/main/e/evolution-tray/evolution-tray_0.0.7-1.dsc
> 
> I would be glad if someone uploaded this package for me.

Thanks for your work. Reviewing your package I find:

1.) You're using dh 7 style for debian/rules but scripting the binary target
yourself. Why? You don't seem to put any options and even if so, you
could still add the override_.. targets.

2.) You include autotools-dev in Build-Depends, but don't add the call to dh
in debian/rules.

3.) You put depends for your binary package even though using
shlibs:Depends. Why aren't they properly detected by the automatic of
dh_shlibdeps?

4.) src/tray.c still has the old FSF-address. Upstream should correct this.

5.) You build-depends on debhelper (>= 8.0.0) which will block backporting.
Depending on >= 8 or >= 8.0 would be preferred.

6.) The template header in debian/rules can be removed

7.) debian/watch is missing.

8.) lintian moans about:
E: evolution-tray: non-empty-dependency_libs-in-la-file
usr/lib/evolution/2.32/plugins/liborg-gnome-evolution-tray.la

I don't see why the *.la file is needed at all. Can you explain?

Apart from that good to go even though I'm wondering if it'd not be easier
to try and find a way to make this code be included upstream in evolution
itself.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: fgo

[Kilian Krause]

Hi Christopher,

On Sat, Aug 06, 2011 at 12:30:33PM +0100, Christopher Baines wrote:
> On Fri, 2011-08-05 at 14:53 +0200, Kilian Krause wrote:
> > On Mon, Aug 01, 2011 at 10:29:34AM +0100, Christopher Baines wrote:
> > > I am looking for a sponsor for my package "fgo".
> > > - dget http://mentors.debian.net/debian/pool/main/f/fgo/fgo_1.3.1-1.dsc
> > > 
> > > I would be glad if someone uploaded this package for me.
> > 
> > Reviewing your package I find:
[...]
> > 2.) Your Depends has ${python:Depends} but you still spell out python-tk,
> > python-imaging, python-imaging-tk - why aren't they caught by the
> > automagic of dh_python/dh_python2 and need to manually added?
> 
> Looking at the manpage for dh_python2, it uses the requires.txt file.
> FGo does not have this file, and therefore its dependencies are not tested.  

as was already discussed on d-mentors I had been under the false impression
that dh_phython2 would lookup includes and build the Depends from the
actual *.py files. As this is obviously not the case, I had already
commented that this requirement is no longer valid and your package is good
as is.


[...]
> > 5.) debian/watch file is missing
> 
> I have tried building one:
> version=3
> http://sites.google.com/site/erobosprojects/flightgear/add-ons/fgo/download 
> /site/erobosprojects/flightgear/add-ons/fgo/download/fgo-(.+).tar.gz?attredirects=0&d=1
> 
> However I get the following error when running it.
> uscan warning: In debian/watch,
>   no matching hrefs for watch line
>   http://sites.google.com/site/erobosprojects/flightgear/add-ons/fgo/download 
> /site/erobosprojects/flightgear/add-ons/fgo/download/fgo-(.+).tar.gz?attredirects=0&d=1

The correct way of writing this looks like:
version=3
opts="uversionmangle=s/-/\./g" \
http://sites.google.com/site/erobosprojects/flightgear/add-ons/fgo/download
/site/erobosprojects/flightgear/add-ons/fgo/download/fgo-(.+).tar.gz\?attredirects=0\&\;d=1

[...]

For your next upload you might want to also fix:
I: fgo: desktop-entry-contains-encoding-key 
usr/share/applications/fgo.desktop:3 Encoding
and
P: fgo: no-upstream-changelog

The upstream ChangeLog is obviously under docs/CHANGE_LOG.

Anyway,
Built, Signed, Uploaded (including the debian/watch fix - I'll leave the
last one up to you).

Thanks!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: gtimer (updated package)

[Kilian Krause]

Hi Taylor,

On Sat, Aug 06, 2011 at 03:47:28AM -0500, Taylor LeMasurier-Wren wrote:
> I am looking for a sponsor for the new version 2.0.0-1
> of my package "gtimer".
> http://mentors.debian.net/debian/pool/main/g/gtimer/gtimer_2.0.0-1.dsc
> 
> I would be glad if someone uploaded this package for me.

Wow. An update to an oldstable package. ;-)

Having a closer look I find:

1.) Standards-Version is still at 3.9.1. Should be bumped to 3.9.2

2.) README.Debian doesn't need to be added to docs. Moreover the file should
be named "docs" not "doc"

3.) I wonder why there's a configure, but no config.guess and config.sub. In
case they should be there, adding autotools-dev to build-depends and dh call
in debian/rules would be preferred.

4.) Converting debian/copyright to DEP-5 would be a bonus.

The link to /usr/share/common-licenses/GPL needs to have a GPL version
number.

Moreover the GPLv2 statements upstream all have the old FSF address and
should be updated.

5.) Your debian/watch fails to fetch the latest version.
The correct line would be:
http://sf.net/gtimer/gtimer-([\d\.]+)\.tar.*

I've fixed 2.) and 5.) and built, signed, uploaded your package.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: retext (updated package)

[Kilian Krause]

Hi Jakub,

On Sat, Aug 06, 2011 at 12:15:41AM +0200, Jakub Wilk wrote:
> * Kilian Krause , 2011-08-05, 23:58:
> >>>1.) You add python, python-qt4, python-markdown on top of
> >>>${python:Depends} into the Depends line. This should not be
> >>>required.  Please check to make sure the automatic detection
> >>>works ok for you but try to use it to not add too many
> >>>dependencies that aren't actually required.
> >>What kind of automatic detection you are talking about?
> >dh_python2?
> 
> Do you mean "dh_python2 tries to translate Python dependencies from
> requires.txt file to Debian dependencies" (from dh_python2(1)
> manpage)?  retext doesn't even use setuptools, so that couldn't
> possibly work.

looking at /usr/share/python/debpython/depends.py I have to admit it does
lack the automatic detection I'd have hoped for (like makeshlibs).

So we can conclude that there is no problem with leaving this as is! ;-)

Thanks for nagging me to look into this!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: retext (updated package)

[Kilian Krause]

On Fri, Aug 05, 2011 at 10:51:15PM +0200, Jakub Wilk wrote:
> * Kilian Krause , 2011-08-05, 15:22:
> >1.) You add python, python-qt4, python-markdown on top of
> >${python:Depends} into the Depends line. This should not be
> >required.  Please check to make sure the automatic detection works
> >ok for you but try to use it to not add too many dependencies that
> >aren't actually required.
> 
> What kind of automatic detection you are talking about?

dh_python2?

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: Plan for managing the SWISS EPHEMERIS data, virtual packages.

[Kilian Krause]

Hi Paul,

On Fri, Aug 05, 2011 at 04:28:37PM -0500, Paul Elliott wrote:
> On Friday, August 05, 2011 10:35:11 AM you wrote:
> > Hi Paul,
> 
> > 
> > What you want is not a virtual package but rather a meta-package. See
> > xserver-xorg for example (or texlive or libreoffice) which pull in
> > submodules from a central package that holds only central information or
> > even only puts the Depends (like the gnome and gnome-desktop-environment
> > package too).
> > 
> > That way you can break apart sensible chunks into separate packages (up to
> > 54) and join them back with the central "give me everything" package
> > (which would be no. 55 at worst).
> > 
> > I doubt however that it'll make sense to break apart more than ~10 packages
> > but I'll leave the decision up to you or someone more experienced with the
> > daily usage.
> 
> A metapackage is basicly a package that does nothing but depends on other
> packages, so that installing a metapackage forces a combination of other 
> packages to be installed.

Right.

> So if I created one package for every SE file, then I could define a 
> metapackage
> SE-data-all that would depend on all of them. Some one else could define a 
> packages that only depends on the modern data, SE-data-modern.

Correct.

> The problem with this is that it requires me to package each file 
> individually.
> I hoped to avoid doing this.

They all still come from the same source. Not sure we're talking about the
same thing here. I was referring to one source and spitting out a number of
(binary) packages plus one/many meta-packages. That way all you need to do
is put together goups or individual files as one binary package each. If you
want to, you can script this to generate debian/control from a
debian/control.in template and run it from the clean target. The pkg-gnome
team uses something alike for setting Maintainer etc..

> If I define one virtual package for each file, I don't have to individually 
> package each file. I can create one package that provides and conflicts
> with each individual virtual package=file and  has a copy of all the data and 
> call this SE-data-all.

From what I'd expect this is not as scalable. Can you sketch up a
mini-example debian/control for what you have in mind?

> Someone else later could create a package that contained only the modern 
> data, 
> that would provide and conflict with each virtual package for which the 
> coresponding file contained modern data and in would include only those 
> files. 
> They would call this SE-data-modern.

Not sure what you mean here why this is someone else. Anyway, package names
in Debian are always lowercase.


> Application programs could decide which virtual packages they wanted to 
> depend 
> on and recommend.
>
> Thus the maitreya astrology program could depend on the modern data and
> recommend all the other.

They can just do the same with meta packages.


> At first my SE-data-all would be the only data package in existance, so 
> maitreya would be forced to bring in all the data. But if someone later 
> created SE-data-modern, the installer of maitreya could force only the modern 
> data to be installed for a low diskspace application even though all the data 
> would still be recommended.

That sounds exactly like what meta packages would achieve. Just keep in mind
that the default in Debian with both apt-get and aptitude is that Recommends
is installed just like Depends. Only Suggests isn't.


> My original question is, is this a legitimate use of the virtual package 
> concept?

IMHO no. Virtual pakges are for "httpd" and "mail-server" and such where
different functions are delivered to a system by totally different
architectural and programmatic concepts yet their interface is the same
among a number of packages. I'd still say what you want is a meta package.

[...]

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: presage

[Kilian Krause]

Hi Matteo,

On Fri, Aug 05, 2011 at 09:13:06PM +0100, Matteo Vescovi wrote:
> I am looking for a sponsor/reviewer for my package "presage".
> 
> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/p/presage
> - Source repository: deb-src http://mentors.debian.net/debian
> unstable main contrib non-free
> - dget 
> http://mentors.debian.net/debian/pool/main/p/presage/presage_0.8.6-1.dsc
> 
> 
> Since the last review, I switched the packaging from CDBS to debhelper 7 dh.

Good! ;-)

Your changelog looks like this has been in Debian for a looong time yet I
cannot find any traces of it. If you reckon this is an initial upload there
should be only one entry in debian/changelog.


> The package appears to be lintian clean (running sid's `lintian -iIE
> --pedantic' on the .changes file), except for a bunch of
> experimental duplicate-files warnings such as:
> 
> X: libpresage-doc: duplicate-files 
> usr/share/doc/libpresage-doc/html/classVariable_a178047db72953639e28c5931afca5f71_cgraph.md5
>  
> usr/share/doc/libpresage-doc/html/classVariable_a90a6a790b6f307e872919d8f4e9c809b_cgraph.md5
[...]
> 
> These warnings apply to files generated by Doxygen during the build.
> Should I add lintian overrides for these?

No, X is an experimental tag. No need to override. Just take it as a comment
lintian gives you.


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

Ok, you asked for it, so here goes:

1.) debian/control has broken RFC822 multiline fields. The first char of all
subsequent lines needs to be a white space.

Just for the record: LaTeX is spelled LaTeX not LaTex.

2.) debian/changelog should only be the initial entry for a first time
upload.

3.) Vcs-Svn and Vcs-Browser look like you haven't splitted out Debian
packaging from upstream. This should be separated as a best practice.

4.) Using dh_python2 would allow you to use ${python:Depends}

5.) debian/copyright is still at rev 135. Latest candidate of DEP-5 is 174

Moreover there's a typo: License: GLP-2+
And these seem to be not included:
./apps/gtk/gprompter/scintilla/src/RESearch.h: *No copyright* Public domain
./apps/gtk/gprompter/scintilla/lexlib/StyleContext.cxx: Public domain
./apps/gtk/gprompter/scintilla/lexlib/StyleContext.h: Public domain

6.) debian/libpresage1.symbols looks pretty empty

7.) usr/share/doc/libpresage-dev doesn't need to be created in
debian/libpresage-dev.dirs - it'll be auto-created by
debian/libpresage-dev.docs if required.

8.) autotools-dev is pulled in as Build-Depends but not activated in
debian/rules' dh call.

9.) #468814 should be retitled to ITP

10.) pyprompter and libpresage-dev are arch any but none of which has any
 arch dependent files. Do you plan to add a static lib or something?

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: mgen

[Kilian Krause]

Hi Raoul,

On Fri, Aug 05, 2011 at 09:02:47PM +0200, Raoul Borenius wrote:
> On Sun, Jul 10, 2011 at 10:01:19PM +0100, Michael Tautschnig wrote:
[...]
> > Two further nice-to-have changes: Use dh 7 simplified debian/rules; this 
> > would
> > immediately address the first two lintian warnings. Moving debian/copyright 
> > to
> > DEP-5 could go along with the fix of the error reported by lintian.
> 
> I ran into bug 631674 ;-)
> 
> I'll move it to DEP-5 when upstream provides a license file. For the moment
> I've included my email-exchange with upstream regarding the missing license in
> debian/copyright. I hope that is ok...

Regarding #631674 I don't see where this would stop you from converting
debian/copyright to DEP-5. Yet the more important part is that you do not
provide a verbatim copy of the GPL-3 in debian/copyright for the Debian
packaging. Please make sure it's added.

Moreover you seem to have skipped at least:
./mgen/protolib/src/sim/ns/ns233/cmu-trace.cc: BSD (4 clause) 
./mgen/protolib/src/sim/ns/ns233/cmu-trace.h: BSD (4 clause) 
./mgen/protolib/src/sim/ns/ns233/priqueue.cc: BSD (4 clause) 
./mgen/protolib/src/sim/ns/ns233/packet.h: BSD (4 clause) 
./mgen/protolib/src/sim/ns/ns233/packet.cc: BSD (4 clause) 

Please review again all files (especially regarding binary files) that they
are covered correct in terms of copyright and licensing. If possible, binary
files should not be in the source tarball at all as they are very difficult
to track licensewise and especially seeing the binary of library and
application I'm even more worried that this will end up in the package
without recompiling one day. Please make sure the clean target *always*
purges these unconditionally whenever they are rebuilt from source (of
course database files, images and other binary data like music files are not
to be deleted as they usually are not rebuilt from source).

Regarding this upstream license you received by email I wonder whether the
third paragraph is entirely DFSG-free. Have you asked for recommendations at
debian-legal? Or is this license already used by any other package in
Debian?

In mgen.docs you further use debian/tmp/usr/share/doc/mgen/changelog which
shouldn't be a doc, but which should rather passed to dh_installchangelogs
if even passing that as argument is required. Most default locations will be
caught without problems even if not given as arg to dh_installchangelogs. 

What puzzles me though is:
kk@debian:~/src/debian/build-area/mgen-5.02$ find -iname changelog
./debian/changelog
kk@debian:~/src/debian/build-area/mgen-5.02$ 

There is no upstream changelog in the original tarball?! Are you trying to
install the debian/changelog twice?

The debian/rules still has the dh-make template header. That can be removed.
Just like unused targets (like configure, configure-stamp). I'll refrain
Michael's comment that dh 7 style would make this shorter and thus more
straightforward (also IMHO).

And since you are scripting the install target yourself in debian/rules, why
still use debian/tmp as intermediate instead of directly installing into the
package directories?

Your upstream tarball doesn't match
http://downloads.pf.itd.nrl.navy.mil/mgen/src-mgen-5.02.tar.gz which is
where your debian/watch would fetch it. Rebuilding your package with that
tarball works ok but produces:
P: mgen source: source-contains-prebuilt-binary mgen/makefiles/mpmgr
P: mgen source: source-contains-prebuilt-binary mgen/makefiles/mgen

To fix this you'll either need a new release without prebuilt binaries or
you'll have to repack as ~dfsg.

Sorry!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: audacious-plugins (backported package)

[Kilian Krause]

Hi Cyril,

On Tue, Jul 12, 2011 at 04:47:35PM +0200, Cyril LAVIER wrote:
> I am looking for a sponsor for the new version 2.4.4-1~bpo60+1
> of my package "audacious-plugins".
> - dget 
> http://mentors.debian.net/debian/pool/main/a/audacious-plugins/audacious-plugins_2.4.4-1~bpo60+1.dsc
> 
> I would be glad if someone uploaded this package for me.

Built, Signed, Uploaded.

Thanks!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: audacious (backported package)

[Kilian Krause]

Hi Cyril,

On Tue, Jul 12, 2011 at 04:46:46PM +0200, Cyril LAVIER wrote:
> I am looking for a sponsor for the new version 2.4.4-1~bpo60+1
> of my package "audacious".
> - dget 
> http://mentors.debian.net/debian/pool/main/a/audacious/audacious_2.4.4-1~bpo60+1.dsc
> 
> I would be glad if someone uploaded this package for me.

Built, Signed, Uploaded.

Thanks!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: Plan for managing the SWISS EPHEMERIS data, virtual packages.

[Kilian Krause]

Hi Paul,

On Sat, Jul 30, 2011 at 07:36:27PM -0500, Paul Elliott wrote:
> I am planing to package the SWISS EPHEMERIS library and its data.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635672
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636089
> 
> The SWISS EPHEMERIS data is 36 Meg in 54 files. The Swiss Ephemeris library
> can be used with out installed data if the user has a private copy of the 
> data. I would like to encourage data sharing which is the reason for 
> packaging 
> the Swiss Ephemeris data. Any of the 54 data files could be needed or not 
> needed depending on what the user is doing.

as a start, I'd say 36MB is not big. texlive and xorg are surely more and
libreoffice even more so. =)


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

Yes, installing all by default sounds like a good default to me.


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

What you want is not a virtual package but rather a meta-package. See
xserver-xorg for example (or texlive or libreoffice) which pull in
submodules from a central package that holds only central information or
even only puts the Depends (like the gnome and gnome-desktop-environment
package too).

That way you can break apart sensible chunks into separate packages (up to 54) 
and join them back with the central "give me everything" package (which
would be no. 55 at worst).

I doubt however that it'll make sense to break apart more than ~10 packages
but I'll leave the decision up to you or someone more experienced with the
daily usage.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: yafc (NMU, fixes FTBFS bug)

[Kilian Krause]

Hi Sebastian,

On Fri, Aug 05, 2011 at 03:41:45PM +0200, Sebastian Ramacher wrote:
> I've prepared a NMU for yafc (version as 1.1.1.dfsg.1-4.1). I've expressed my
> intend to NMU in #636703.
> 
> - dget 
> http://mentors.debian.net/debian/pool/main/y/yafc/yafc_1.1.1.dfsg.1-4.1.dsc
> 
> I would be glad if someone uploaded this package to DELAYED/10 for me.

done.

Thanks!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: qasmixer (backport package)

[Kilian Krause]

Hi Sebastian,

On Fri, Aug 05, 2011 at 05:11:14PM +0200, Sebastian H. wrote:
> > On Tue, Aug 02, 2011 at 12:47:35PM +0200, Sebastian H. wrote:
> >> I am looking for a sponsor for the backport version 0.12.2-1~bpo60+1
> >> of my package "qasmixer".
> >> http://mentors.debian.net/debian/pool/main/q/qasmixer/qasmixer_0.12.2-1~bpo60+1.dsc
> > 
> > Built, Signed, Uploaded with the only change: I've used the orig.tar.gz
> > instead of your tar.bz2 to keep in sync with unstable. That'll keep the
> > Debian mirror size down and makes the backport even more similar to the
> > version in testing.
> 
> Thank you!
> Now I can offer links to backport instead of building own packages.

Happy to help. ;-)


> I've another question.
> Is there a recommendation in Debian for using bzip2, gzip or xz for
> packing source tarballs?

No. 

Only that xz is not available in older versions of apt/dpkg/etc..

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: libmowgli (backported package)

[Kilian Krause]

Hi Cyril,

On Tue, Jul 12, 2011 at 04:48:36PM +0200, Cyril LAVIER wrote:
> I am looking for a sponsor for the new version 0.7.1-1~bpo60+1
> of my package "libmowgli".
> - dget 
> http://mentors.debian.net/debian/pool/main/l/libmowgli/libmowgli_0.7.1-1~bpo60+1.dsc
> 
> I would be glad if someone uploaded this package for me.

Built, Signed, Uploaded.

Once that's in bpo I'll see to audacious.

Thanks for your work.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: qasmixer (backport package)

[Kilian Krause]

Hi Sebastian,

On Tue, Aug 02, 2011 at 12:47:35PM +0200, Sebastian H. wrote:
> I am looking for a sponsor for the backport version 0.12.2-1~bpo60+1
> of my package "qasmixer".
> http://mentors.debian.net/debian/pool/main/q/qasmixer/qasmixer_0.12.2-1~bpo60+1.dsc

Built, Signed, Uploaded with the only change: I've used the orig.tar.gz
instead of your tar.bz2 to keep in sync with unstable. That'll keep the
Debian mirror size down and makes the backport even more similar to the
version in testing.

Thanks!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: dpkg-awk (adopted package)

[Kilian Krause]

Hi Jeroen,

On Thu, Aug 04, 2011 at 03:20:53PM +0200, Jeroen Schot wrote:
> I am looking for a sponsor for the new version 1.1 of my package
> "dpkg-awk".
> - dget http://mentors.debian.net/debian/pool/main/d/dpkg-awk/dpkg-awk_1.1.dsc
> 
> I would be glad if someone uploaded this package for me.

Thanks for stepping up as new maintainer!

Just as a comment: Looking at the updates you introduce into debian/rules
I'm wondering if it wouldn't be easier to use debhelper dh style.

Anyway, Built, Signed, Uploaded!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: parcellite 1.0.2~rc2-1 (updated package)

[Kilian Krause]

Hi Andrew,

On Tue, Aug 02, 2011 at 02:54:32PM -0400, Andrew Starr-Bochicchio wrote:
> My sponsor is a swamped with other matters, so I turn to you to
> hopefully review/ sponsor my package.
> 
> I've uploaded it to mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/p/parcellite
> - Source repository: deb-src http://mentors.debian.net/debian unstable
> main contrib non-free
> - dget 
> http://mentors.debian.net/debian/pool/main/p/parcellite/parcellite_1.0.2~rc2-1.dsc

Thanks for the update. I see your upstream isn't too keen on clean release
tarballs (as the many *~ files document obviously - now that they have
remove config.status at least), heh? ;-)

Anyway, regarding your packaging: 

1.) adding autotools-dev would be still a plus for your package.

2.) debian/copyright is not (yet) in DEP-5 format but in some older format.
I don't know about Ubuntu but for Debian converting to DEP-5 would be
preferred (at least in d-mentors)

3.) debian/patches/dsofix.patch is having a good DEP-3 header already yet
hasn't been marked as pushed upstream. Don't you think upstream will be
interested in importing this back into their files?

4.) The LGPL2 files obviously still have the wrong FSF address:
./src/eggaccelerators.h: LGPL (v2 or later) (with incorrect FSF address) 
./src/eggaccelerators.c: LGPL (v2 or later) (with incorrect FSF address) 
You may want to inform upstream about this and have them fix this with
the next release.

Other than that looks good to go, thus built, signed, uploaded.

Thanks!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: l2tp-ipsec-vpn

[Kilian Krause]

Hi Werner,

On Fri, Aug 05, 2011 at 03:24:09PM +0200, Werner Jaeger wrote:
> unfortunately I could not reproduce the failure, however on suspicion
> I changed the clean target in the Makefile.

that seems to have done the trick. ;-)

Anyway now I get with a rebuild:
W: l2tp-ipsec-vpn source: format-3.0-but-debian-changes-patch
due to:
dpkg-source: info: local changes stored in
l2tp-ipsec-vpn-1.0.0/debian/patches/debian-changes-1.0.0-1, the modified
files are:
 l2tp-ipsec-vpn-1.0.0/qttmp-Release.mk

Should be fixed with the next uploaded I guess.

To get going with NEW however I've
Built, Signed, Uploaded
your package as is.

Please keep in mind that from now on all versions must use the same
orig.tar.gz tarball as long as they have the same upstream version.

Thanks!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: haproxy (updated package)

[Kilian Krause]

Hi Christo,

On Tue, Aug 02, 2011 at 08:38:10PM +0200, Christo Buschek wrote:
> I am looking for a sponsor for the new version 1.4.15-1
> of my package "haproxy".
> - dget 
> http://mentors.debian.net/debian/pool/main/h/haproxy/haproxy_1.4.15-1.dsc
> 
> I would be glad if someone uploaded this package for me.

Thanks for your work!

Regarding the crash bugfix that is also required for stable you may want to
talk to debian-release and propose a stable update with just that specific
fix against the 1.4.8-1 version.

Your debian/watch file doesn't work flawlessly btw.: 
dpkg: version '1.4/src.1.4.15' has bad syntax: invalid character in version 
number

Moreover there's some lintian proposed fixes that may be worth looking into:
P: haproxy source: unneeded-build-dep-on-quilt
I: haproxy source: quilt-patch-missing-description bashism
W: haproxy source: out-of-date-standards-version 3.9.1 (current is 3.9.2)
P: haproxy: example-shell-script-fails-syntax-check 
usr/share/doc/haproxy/examples/build.cfg
P: haproxy: example-shell-script-fails-syntax-check 
usr/share/doc/haproxy/examples/haproxy-1.1.21-flx.1.pkg
P: haproxy: example-shell-script-fails-syntax-check 
usr/share/doc/haproxy/examples/init.haproxy
I: haproxy: unused-override example-shell-script-fails-syntax-check 
./usr/share/doc/haproxy/examples/build.cfg
I: haproxy: unused-override example-shell-script-fails-syntax-check 
./usr/share/doc/haproxy/examples/haproxy-1.1.21-flx.1.pkg
I: haproxy: unused-override example-shell-script-fails-syntax-check 
./usr/share/doc/haproxy/examples/init.haproxy

As none of this is a new problem I'll just waive your upload as is.

Thanks!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: retext (updated package)

[Kilian Krause]

Hi Dmitry,

On Tue, Aug 02, 2011 at 02:35:04PM +0400, Dmitry Shachnev wrote:
> I am looking for a sponsor for the new version 1.1.5-1 of my package "retext".
> It's a bugfix release, but it fixes some important bugs (like "View
> HTML code" action not working)
> - dget http://mentors.debian.net/debian/pool/main/r/retext/retext_1.1.5-1.dsc
> 
> My main sponsor is am...@debian.org, but he doesn't reply, so I post it here.
> I would be glad if someone uploaded this package for me.

amaya is a she but no problem. Review is as follows:

1.) You add python, python-qt4, python-markdown on top of ${python:Depends}
into the Depends line. This should not be required. Please check to make
sure the automatic detection works ok for you but try to use it to not
add too many dependencies that aren't actually required.

Looking at the build log I see you're lacking the dh_python calls and
thus seeing:
dpkg-gencontrol: warning: Depends field of package retext: unknown 
substitution variable ${python:Depends}
dpkg-gencontrol: warning: Depends field of package retext-wpgen: unknown 
substitution variable ${python:Depends}

Once you'll have this added the Depends should come up as intended
without spelling it out in debian/control verbatim.

2.) changelog is not supposed to be a docs entry. It's caught automatically
by dh_installchangelogs.

3.) You may want to use dh_python2 in debian/rules I guess. Moreover as a
personal preferency of style, I'd make the auto_build override target run a
loop for each of the sizes. But that's not a requirement and perfectly ok as
you've put it.

4.) Last but not least, the icons/* is still needed in debian/copyright as
that directory is still shipped in the orig.tar.gz. It may not be used but
it's still there and mentioning it therefore must not be dropped.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: php-benchmark

[Kilian Krause]

Hi Jose,

On Tue, Aug 02, 2011 at 02:49:41AM +0200, Jose Antonio Quevedo Muñoz wrote:
> I am looking for a sponsor for my package "php-benchmark".
> http://mentors.debian.net/debian/pool/main/p/php-benchmark/php-benchmark_1.2.8-1.dsc
> 
> I would be glad if someone uploaded this package for me.

Thanks for the update!

Reviewing your changes I find:

1.) "Merry christmas release"?! Sorry for taking so long to review your
package, but still it wasn't *THAT* long. ;-)
Moreover you don't need to mention a "maintainer upload" - that's the
default. Just like adding the series file if you add a patch. It just
won't work without. =)

2.) Your debhelper is quite ancient. Bumping that to newer versions surely
doens't hurt.

3.) debian/patches/00-fixpath.diff contains a DEP-3 header but with a lot of
template data. Please fill in all fields that make sense and delete the
rest next time.

4.) Building your package I see:
rm debian/php-benchmark/usr/share/doc/php-benchmark/doc/timer_example.php
rm: cannot remove
`debian/php-benchmark/usr/share/doc/php-benchmark/doc/timer_example.php': No
such file or directory
make: [install/php-benchmark] Error 1 (ignored)
rmdir debian/php-benchmark/usr/share/doc/php-benchmark/doc
rmdir: failed to remove
`debian/php-benchmark/usr/share/doc/php-benchmark/doc': No such file or
directory
make: [install/php-benchmark] Error 1 (ignored)

which don't seem to hurt though.

5.) Asking the chatty lintian I see:
I: php-benchmark: package-contains-empty-directory 
usr/share/php/.registry/.channel.doc.php.net/
which may also make sense fixing.

6.) Your Standards-Version is still at 3.9.1. Updating to 3.9.2 would be
preferred.

7.) Last but not least I can't upload your package as it no longer has the
required files:
-rw-r--r--  root/root   /usr/share/php/.registry/benchmark.reg
-rw-r--r--  root/root   /usr/share/php/Benchmark/Iterate.php
-rw-r--r--  root/root   /usr/share/php/Benchmark/Profiler.php
-rw-r--r--  root/root   /usr/share/php/Benchmark/Timer.php
lrwxrwxrwx  root/root   /usr/share/php/docs/Benchmark -> 
../../doc/php-benchmark

have all vanished.

Sorry!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: fgo

[Kilian Krause]

Hi Christopher,

On Mon, Aug 01, 2011 at 10:29:34AM +0100, Christopher Baines wrote:
> I am looking for a sponsor for my package "fgo".
> - dget http://mentors.debian.net/debian/pool/main/f/fgo/fgo_1.3.1-1.dsc
> 
> I would be glad if someone uploaded this package for me.

Reviewing your package I find:

1.) You Build-Depends on debhelper 8.9.3 but only use debian/compat 7 - why?

2.) Your Depends has ${python:Depends} but you still spell out python-tk,
python-imaging, python-imaging-tk - why aren't they caught by the
automagic of dh_python/dh_python2 and need to manually added?

3.) debian/copyright is still at rev. 135 of DEP-5. Please bump to 174 which
is final.

4.) The "fix" in debian/rules (mv
debian/fgo/usr/share/games/fgo/src/pics/icon.png
debian/fgo/usr/share/pixmaps/fgo.png) should be reported upstream and fixed
there.

5.) debian/watch file is missing

6.) Your package fails to build in a clean pbuilder with:
 fakeroot debian/rules clean
 dh clean --with python2
 dh: unable to load addon python2: Can't locate
 Debian/Debhelper/Sequence/python2.pm in @INC (@INC contains: /etc/perl
 /usr/local/lib/perl/5.12.4 /usr/local/share/perl/5.12.4 /usr/lib/perl5
 /usr/share/perl5 /usr/lib/perl/5.12 /usr/share/perl/5.12
 /usr/local/lib/site_perl .) at (eval 22) line 2.
 BEGIN failed--compilation aborted at (eval 22) line 2.

 make: *** [clean] Error 2


Sorry!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: wizznic

[Kilian Krause]

Hi Peter,

On Fri, Aug 05, 2011 at 03:37:35PM +0300, Peter Pentchev wrote:
> On Fri, Aug 05, 2011 at 01:06:18PM +0200, Kilian Krause wrote:
[...]
> And I also just thought of something else :)  If a package needs a DFSG
> or DS cleanup in its very first upload, then +dfsg and ~dfsg are
> functionally equivalent and you're free to prefer ~dfsg, just as I think
> I'm free to prefer +dfsg :)  

Yes. Absolutely right. Even though the +svn and +git you've listed above are
very real updates that may be wanted. Except for +cvs that'll work as
d << g << s but c >> d. ;-)

So bumping a +dfsg to UPVER+cvs+dfsg won't work. Also +bzr won't be
possible that way. Which limits you in terms of the possible notations of
the new upstream version and may go unnoticed until the dak will throw it
back to you - which is plain not nice. 


> However, if a package has already been
> uploaded and somebody finds a DFSG violation, the maintainer has to
> upload a new version with a *higher* version number - and that's when
> ~dfsg will simply not work.  So... to not have to worry about such
> problems, I personally always use +dfsg instead of any other notation :P

In my experience it's a first-time upload that will need +dfsg but after
that you'll want to convert to ~dfsg for all subsequent upstream versions.
That way it'll scale much better from what I've seen already.

> Thanks for the time spent reading this, and keep up the great work!

Thanks for your comments!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: looking for sponsor for my package "jscribble"

[Kilian Krause]

Hi Martin,

On Wed, Aug 03, 2011 at 02:36:15PM +0200, Martin Ueding wrote:
[...]
> It should be uploaded to mentors again.

having a look at the latest version, I find:

1.) Standards-Version is at 3.9.1 - should be bumped to 3.9.2

2.) debian/copyright still has Source: without contents

3.) debian/docs is empty. That file can be removed.

4.) debian/rules still has a template header. That can be removed.

5.) debian/watch file is missing

Other than that it looks good enough to upload IMHO.

To clear the only real problem I've put https://launchpad.net/jscribble as
fix for 2.) and removed debian/docs.

Built, signed, uploaded that way.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: libstring-tokenizer-perl

[Kilian Krause]

Hi Ben,

On Fri, Aug 05, 2011 at 01:10:25PM +0100, Ben Webb wrote:
> On 5 August 2011 12:45, Kilian Krause  wrote:
> > Hi Ben,
> >
> > On Sat, 2011-07-30 at 20:47 +0100, Ben Webb wrote:
> >> I am looking for a sponsor for my package "libstring-tokenizer-perl".
> >> - dget 
> >> http://mentors.debian.net/debian/pool/main/l/libstring-tokenizer-perl/libstring-tokenizer-perl_0.05-2.dsc
> >>
> >> I would be glad if someone uploaded this package for me.
> >
> > This doesn't seem to work any more. Is this request still current?
> 
> Sorry, no the request is no longer current. As Niels suggested I've
> been in contact with the debian-perl team, and the package has been
> uploaded by them. To close this RFS do I need to do anything besides
> say so here?

Nope. Thanks for clarifying!

-- 
Best regrads,
Kilian


signature.asc
Description: Digital signature

Re: RFS: libstring-tokenizer-perl

[Kilian Krause]

Hi Ben,

On Sat, 2011-07-30 at 20:47 +0100, Ben Webb wrote:
> I am looking for a sponsor for my package "libstring-tokenizer-perl".
> - dget 
> http://mentors.debian.net/debian/pool/main/l/libstring-tokenizer-perl/libstring-tokenizer-perl_0.05-2.dsc
> 
> I would be glad if someone uploaded this package for me.

This doesn't seem to work any more. Is this request still current?

-- 
Best regards,
Kilian


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

Re: RFS: wmmoonclock (updated package)

[Kilian Krause]

Hi Rodolfo,

On Sat, 2011-07-30 at 12:48 +0200, Rodolfo kix Garcia wrote:
> I am looking for a sponsor for the new version 1.27-30
> of my package "wmmoonclock".
> http://mentors.debian.net/debian/pool/main/w/wmmoonclock/wmmoonclock_1.27-30.dsc
> 
> I would be glad if someone uploaded this package for me.

Sorry, but no.

1.) If you update a package without new upstream release you must use
the orig.tar.gz file that is in the Debian archive. Any upload using
another tarball will fail to be accepted by the Debian archive.

2.) You moved upstream's changelog out of debian/ with the new upstream
tarball. As said above the tarball in inalienable without a new upstream
release version and thus this change cannot be accepted.

3.) shipping changelog as docs is not an required. dh_installchangelogs
should catch it in default locations - unusual locations can be provided
in debian/rules as argument. No need to add changelog as docs too.

4.) The patches altogether lack a DEP-3 header. Please consider adding
one and especially feeding them back upstream to have them included and
vanish from Debian packaging. 

5.) Regarding taking over the maintainer ship. You should update the
title of #588837 to read ITA.

6.) Updating debian/copyright to DEP-5 would be a bonus.

7.) debian/watch is empty. This makes comparing new upstream tarballs to
your provided one quite tedious. Please update it to the correct
upstream locations.

-- 
Best regards,
Kilian


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

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

[Kilian Krause]

Hi Olivier,

On Fri, 2011-07-29 at 17:09 +0200, Olivier Girondel wrote:
> I am looking for a sponsor for my packages "lebiniou" and
> "lebiniou-data".
> http://mentors.debian.net/debian/pool/main/l/lebiniou/lebiniou_3.9-1.dsc
> http://mentors.debian.net/debian/pool/main/l/lebiniou-data/lebiniou-data_3.9-1.dsc
> 
> I would be glad if someone uploaded these packages for me.

Sorry for taking so long to review.

Built, signed, uploaded now.

Thanks!

-- 
Best regards,
Kilian


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

Re: RFS: Sitplus -- Free software framework for ludic-therapeutic activities

[Kilian Krause]

Hi Luis,

On Wed, 2011-07-27 at 16:46 +0200, Luis Rivas wrote:
> I'm looking for a sponsor for a brand new package: it would be great
> if someone could take a look at it and even upload it for me. Here is
> the info:
> 
> Name: sitplus

Sorry for taking so long to find the time to have a look at your
package.
Is this one still current? The download link seems to no longer work.

-- 
Best regards,
Kilian


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

Re: RFS: l2tp-ipsec-vpn

[Kilian Krause]

Hi Werner,

On Fri, 2011-08-05 at 10:52 +0200, Werner Jaeger wrote:
> yes my fault, I missed to clean the test files in the clean target.
> 
> I also moved the dependencies to openswan and xl2tpd from package
> l2tp-ipsec-vpn to package  l2tp-ipsec-vpn-daemon.
> 
> I've just uploaded the changes, so please have another look at it.

Now the build fails at:

qmake-qt4 -o qttmp-Pkcs12Tests.mk "BUILDDIR=build/Release"
"OBJECTS_DIR=build/TestFiles" "DESTDIR=build/TestFiles"
tests/Pkcs12Tests.pro
WARNING: Failure to find: build/Release/Pkcs12.o
WARNING: Failure to find: build/Release/CertificateInfo.o
mv -f qttmp-Pkcs12Tests.mk nbproject/qt-Pkcs12Tests.mk
make -f nbproject/qt-EncSecretsTests.mk build/TestFiles/f1
make[2]: Entering directory `/tmp/buildd/l2tp-ipsec-vpn-1.0.0'
make[2]: *** No rule to make target `build/Release/EncSecrets.o', needed
by `build/TestFiles/f1'.  Stop.
make[2]: Leaving directory `/tmp/buildd/l2tp-ipsec-vpn-1.0.0'
make[1]: *** [build-tests] Error 2
make[1]: Leaving directory `/tmp/buildd/l2tp-ipsec-vpn-1.0.0'
dh_auto_test: make -j1 test returned exit code 2
make: *** [binary] Error 29


-- 
Best regards,
Kilian


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

Re: RFS: wizznic

[Kilian Krause]

Hi Peter,

On Fri, 2011-08-05 at 13:18 +0300, Peter Pentchev wrote:
> On Fri, Aug 05, 2011 at 08:52:37AM +0200, Kilian Krause wrote:
> > Hi Tony,
> > 
> > On Thu, 2011-08-04 at 15:58 -0500, Edgar Antonio Palma de la Cruz wrote:
> > > > Done.
> > > > - URL: http://mentors.debian.net/debian/pool/main/w/wizznic
> > > > - dget
> > > >   
> > > > http://mentors.debian.net/debian/pool/main/w/wizznic/wizznic_0.9.2-preview2+dfsg-1.dsc
> [snip]
> > 
> > 4.) Having +dfsg as delimiter can be quite harmful. Usually ~dfsg is the
> > preferred method as this will always be lower than the upstream version.
> > Thus no matter what the next upstream version will look like, you can
> > bump your package up to that version.
> 
> Errr...  Maybe I'm missing something here, but why is that?  How exactly
> can having "+dfsg" be harmful?
> 
> My understanding is that both "+dfsg" and "~dfsg" are acceptable and it
> is only ".dfsg" that may indeed be harmful if upstream decides to
> release a next version with a new component that sorts lower than, well,
> "dfsg" :)  However, I really don't see what upstream's next version
> number has to be so that it will cause problems with "+dfsg"; could you
> please provide an example?

If upstream bumps 0.9.2-preview2 to 0.9.2-preview2+ABBA (considering
they have new ABBA tracks that are now available as musical score - just
for making a point here) what then? This is what will happen:

Checking for 0.9.2-preview2+dfsg-1 <= 0.9.2-preview2+ABBA+dfsg-1 will
fail.

Not that it's highly likely that this will happen a lot, but to not have
to worry about such problems, I'd recommend always using ~dfsg instead
of any other notation.

-- 
Best regards,
Kilian


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

Re: acsccid (Updated)

[Kilian Krause]

Hi Godfrey,

On Thu, 2011-08-04 at 17:47 +0800, Godfrey Chung wrote:
> Dear Kilian
>  
> Thank you for your review of my package.
>  
> 1. Done.
>  
> 2. Done.
>  
> 3.  override_dh_auto_install section is removed, please see No. 4 and
> comments had been added to override_dh_makeshlibs section.
>  
> 4. Initially, I used libccid for my reference. I think putting
> Info.plist to /etc is for user convenience of file modification. mv
> and ln is removed to avoid to break FHS.
>  
> 5. Done.
>  
> 6. The package name is changed to libacsccid1.
>  
> 7. The output is triggered by adding --enable-udev option to configure
> and it will modify a option in Info.plist file. This option is not
> used in the latest version of pcsc-lite.
>  
> 8. The upstream contains empty change log.
>  
> Please have a look of my updated package. Thanks!

Thanks!

Built, Signed, Uploaded.

-- 
Best regards,
Kilian



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

Re: RFS: wizznic

[Kilian Krause]

Hi Tony,

On Thu, 2011-08-04 at 15:58 -0500, Edgar Antonio Palma de la Cruz wrote:
> > Done.
> > - URL: http://mentors.debian.net/debian/pool/main/w/wizznic
> > - dget
> >   
> > http://mentors.debian.net/debian/pool/main/w/wizznic/wizznic_0.9.2-preview2+dfsg-1.dsc

1.) Your get-orig-source target doesn't work with this version due to a
bug in debian/watch. Adding + to the allowed dfsg prefix chars fixes
this.

2.) The orig.tar.gz on mentors.d.n doesn't match the one generated with
get-orig-source. You had also removed:
Only in wizznic-0.9.2-preview2.orig//tools/releaser/data/win:
prgicon.png
Only in wizznic-0.9.2-preview2.orig//tools/releaser/data/win:
WizznicWin.bat
Only in wizznic-0.9.2-preview2.orig//tools/releaser/data/win:
WizznicWin-Fullscreen.bat
Only in wizznic-0.9.2-preview2.orig//tools/releaser/data/win:
WizznicWin-Zoom.bat

If that was done on purpose it should be added to the get-orig-source
target. IMHO they can be left as is.

3.) Your get-orig-source passes GZIP=--best but uses bzip2
compression. ;-)

4.) Having +dfsg as delimiter can be quite harmful. Usually ~dfsg is the
preferred method as this will always be lower than the upstream version.
Thus no matter what the next upstream version will look like, you can
bump your package up to that version.

5.) The multiline fields in debian/control need to have a whitespace as
first char not a tab stop to make them fully RFC822 compliant.

6.) Having libsdl-mixer1.2 additionally in Depends looks a bit strange.
Are you sure it does not come through shlibs?

7.) debian/README.debian-source doesn't need to be shipped with the
binary package. It's a comment on the source.

8.) debian/patches/makefile_media.patch wasn't pushed upstream AFAICT. I
guess upstream might be interested though.

9.) http://sf.net/wizznic/ is invalid. You probably mean
http://sf.net/projects/wizznic/

I've built using a freshly generated get-orig-source tarball, fixed 1.),
5.), 7.) and 9.) built, signed and uploaded your package.

You can find my upload at http://people.debian.org/~kilian/wizznic/

-- 
Best regards,
Kilian


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

Re: RFS: xxxterm

[Kilian Krause]

Hi Luis,

On Fri, 2011-08-05 at 00:38 +0100, Luis Henriques wrote:
> Dear mentors,
> 
> I am looking for a sponsor for my package "xxxterm".
> 
>  * Package name: xxxterm
>Version : 1.471-1
>Upstream Author : Several (Marco Peereboom )
>  * URL : http://opensource.conformal.com/wiki/XXXTerm
>  * License : ISC, MIT, BSD-4-clause, BSD-3-clause, BSD-2-clause, 
> CC-BY-SA
>Section : web
> 
> To access further information about this package, please visit the
> following URL:
> 
>   http://expo.debian.net/package/xxxterm
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x 
> http://expo.debian.net/debian/pool/main/x/xxxterm/xxxterm_1.471-1.dsc
> 
> I would be glad if someone uploaded this package for me.

Thanks! Excellent work!

I've just built, signed and uploaded your package. The patches have
neither been marked as pulled from upstream nor pushed back there. Have
you considered that? Especially the manpage and Makefile updates should
be interesting to them.

-- 
Best regards,
Kilian




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

Re: RFS: herculesstudio (updated package)

[Kilian Krause]

Hi Guo,

On Sat, Jul 30, 2011 at 12:04:00PM +0800, Liang Guo wrote:
> I am looking for a sponsor for the new version 1.3.0-1
> of my package "herculesstudio".
> - dget 
> http://mentors.debian.net/debian/pool/main/h/herculesstudio/herculesstudio_1.3.0-1.dsc

Thanks!

Btw. you've got still an unneeded-build-dep-on-quilt as the package is
dpkg-source v3.0.

Anyway, built, signed, uploaded.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: eviacam

[Kilian Krause]

Hi César,

On Wed, Aug 03, 2011 at 10:26:46PM +0200, Cesar Mauri wrote:
> Hi Kilian,
> 
> >>>[...]
> >>>- Have your binary chmod 4750
> >>>- with uid 0 (thus the setUID) and
> >>>- group "whateveryournewgroupname"
> >>>
> >>>In debian/postinst that would look like:
> >>>chmod 4750 $BINARY
> >>>chown 0:$GID $BINARY
> >>>
> >>>where $GID is the group id of the group you create in postinst.
> >>>
> >>>That will make sure it gets the UID 0 correctly so that nice(2) will work 
> >>>ok
> >>>and also will make sure that only users of the group are allowed to execute
> >>>it.
> >>>[...]
> 
> >>I think that if we need to create a new group may be some non-expert
> >>users won't be able to run eviacam properly (i.e. they might fail to add
> >>their username to such group). Other options include:
> >>
> >>i) ask the user whether to make eviacamloader SUID and explain that a
> >>new group is needed and such and such.
> >
> >Can be done with debconf quite easily as:
> >a) Ask whether SUID should be activated
> 
> Done. Package uploaded.

Good!

The file debian/po/templates.pot has a lot of template headers still though.
Please fill in all fields that are still holding bogus data.

Regarding the activation I'd still vote for a group to be created and the
chmod to be 4750 if SUID and 0755 if not SUID. You may want to use
dpkg-statoverride for this to set both user:group and chmod permissions in
one line.

If you need a good template I'd need to dig among the last packages I have
reviewed. There was a really good postinst doing exactly this.

Your text then should also include the name of the group (probably eviacam)
and that the sysadmin should add users if they're supposed to use the
program.

> >b) which users should be added to the group interactively
> 
> I would need some help here. Can you point a good document (or
> better, an example) on how to interactively add users to a group
> using debconf?

I was thinking of the libc version asking for which processes need to be
restarted. Not sure though if that's useful considering that e.g. sudo
leaves this to the sysadmin too. I guess we can live with just the SUID-yes
and SUID-no question in debconf.


> >Please set sensible defaults so that you can also work with
> >DEBCONF_FRONTEND=noninteractive
> 
> The default option is to *NOT* use SUID.

Very good. ;-)

> >>ii) completely get rid of the SUID thing at the expense of less
> >>responsiveness.
> >
> >If that's possible and doesn't limit core functionality it sounds like a
> >valid option. What downsides would that bring?
> 
> The core functionality is exactly the same. The only downside is
> that eviacam won't work as smooth as if it were running in high
> priority (i.e. the user might notice that the mouse pointer is less
> responsive when CPU load is high).
> 
> >I think debconf as explained above together with properly adding a new
> >group and importing users through debconf would be a good thing.
> 
> Agreed. But some help needed :-). Thanks.

Hth. ;-)

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: l2tp-ipsec-vpn

[Kilian Krause]

Hi Werner,

On Thu, Aug 04, 2011 at 08:13:39PM +0200, Werner Jaeger wrote:
> I just uploaded following changes for packages l2tp-ipsec-vpn and
> l2tp-ipsec-vpn-daemon
> 
> - deleted postinst, postrm, prerm (l2tp-ipsec-vpn-daemon)
> - removed hard coded arch (l2tp-ipsec-vpn, l2tp-ipsec-vpn-daemon)
> - simplified rules by putting all dependencies into make file
> (l2tp-ipsec-vpn, l2tp-ipsec-vpn-daemon)
> - added tests (l2tp-ipsec-vpn)
> 
> I did not change the daemon path
> "/usr/lib/l2tp-ipsec-vpn-daemon/L2tpIPsecVpnControlDaemon" to /usr/sbin,
> because the daemon is supposed to be called only from the GUI. According to
> 
> http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA
> 
> I think this is the right place.
> 
> Hoping to receive either further reviews or that someone will put the
> packages into NEW.

Good work! ;-)

Just wondering whether the Depends on openswan and xl2tpd shouldn't rather
be put into the l2tp-ipsec-vpn-daemon package instead of just into the gui 
package.

Regarding the dh_installchangelogs override - that one shouldn't be
necessary with debhelper compat at 7 and greater. It's not wrong to put it
though. ;-)

The l2tp-ipsec-vpn-daemon builds ok, but with your latest changes rebuilding
the l2tp-ipsec-vpn fails for me with:

dpkg-source: info: building l2tp-ipsec-vpn using existing 
./l2tp-ipsec-vpn_1.0.0.orig.tar.gz
dpkg-source: error: cannot represent change to 
l2tp-ipsec-vpn-1.0.0/build/TestFiles/EncSecretsTests.o: binary file contents 
changed
dpkg-source: error: add build/TestFiles/EncSecretsTests.o in 
debian/source/include-binaries if you want to store the modified binary in the 
debian tarball
dpkg-source: error: cannot represent change to 
l2tp-ipsec-vpn-1.0.0/build/TestFiles/f2: binary file contents changed
dpkg-source: error: add build/TestFiles/f2 in debian/source/include-binaries if 
you want to store the modified binary in the debian tarball
dpkg-source: error: cannot represent change to 
l2tp-ipsec-vpn-1.0.0/build/TestFiles/LibtoolTests.o: binary file contents 
changed
dpkg-source: error: add build/TestFiles/LibtoolTests.o in 
debian/source/include-binaries if you want to store the modified binary in the 
debian tarball
dpkg-source: error: cannot represent change to 
l2tp-ipsec-vpn-1.0.0/build/TestFiles/f1: binary file contents changed
dpkg-source: error: add build/TestFiles/f1 in debian/source/include-binaries if 
you want to store the modified binary in the debian tarball
dpkg-source: error: cannot represent change to 
l2tp-ipsec-vpn-1.0.0/build/TestFiles/Pkcs12Tests.o: binary file contents changed
dpkg-source: error: add build/TestFiles/Pkcs12Tests.o in 
debian/source/include-binaries if you want to store the modified binary in the 
debian tarball
dpkg-source: error: cannot represent change to 
l2tp-ipsec-vpn-1.0.0/build/TestFiles/TestRunner.o: binary file contents changed
dpkg-source: error: add build/TestFiles/TestRunner.o in 
debian/source/include-binaries if you want to store the modified binary in the 
debian tarball
dpkg-source: error: cannot represent change to 
l2tp-ipsec-vpn-1.0.0/build/TestFiles/f3: binary file contents changed
dpkg-source: error: add build/TestFiles/f3 in debian/source/include-binaries if 
you want to store the modified binary in the debian tarball
dpkg-source: error: unrepresentable changes to source
dpkg-buildpackage: error: dpkg-source -b l2tp-ipsec-vpn-1.0.0 gave error exit 
status 2

Looks like your clean target isn't working properly. If you want to try for 
yourself, use 
"pdebuild -- --twice".

Sorry.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: how to write watch file for multi-tarball source package?

[Kilian Krause]

Hi Paul,

On Thu, Aug 04, 2011 at 11:58:01AM -0500, Paul Elliott wrote:
> What is the correct way to handle the watch file in a multi-tarball source  
> package?

There is none. See [1] for details.

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

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: autotrace (updated package)

[Kilian Krause]

Hi Edgar,

On Thu, Jul 28, 2011 at 05:23:04AM -0500, Edgar Antonio Palma de la Cruz wrote:
> I am looking for a sponsor for the new version 0.31.1-16
> of my package "autotrace".
> - dget 
> http://mentors.debian.net/debian/pool/main/a/autotrace/autotrace_0.31.1-16.dsc

Thanks for your work.

Cleaning up is a good thing yet the oldpatches.patch looks like it catches
more than it should:

AUTHORS   |2 
Makefile.am   |4 
Makefile.in   |  914 -
README|2
aclocal.m4| 8966 +--
autotrace.1   |4
autotrace.h   |4
autotrace.pc.in   |4 
config.h.in   |3 
configure |25257 +-
configure.in  |   91 
curve.c   |4 
fit.c |3
ltmain.sh | 3665 +--
main.c|   10 
output-pdf.c  |   16 
output-pstoedit.c |2 
output-pstoedit.h |2 
18 files changed, 28530 insertions(+), 10423 deletions(-)

Especially the configure, aclocal.m4 and ltmain.sh look like a too large
change. Can you see if really *ALL* of this is required and cut that patch
down to a more readable size? If you want to you can also plit it apart into
logical units with individual explanations why they are (still) needed.

There may also be parts of this which still need to be pushed back upstream.
Reviewing it in this shape is quite teadious however. And documenting even
more so if they satisfy different motivations.

In some respect it may even be more helpful to add dh-autoreconf (even though
I quite dislike its use in general). Even more so when I see the old d/rules
had pretty much a full autoreconf run as part of the default packaging which
makes me guess this was causing the updates we now see in the diff making
them totally irrelevant to the "bugfix" the original author had in mind.

Thanks!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: wizznic

[Kilian Krause]

Hi Edgar,

On Wed, Aug 03, 2011 at 04:53:44AM -0500, Edgar Antonio Palma de la Cruz wrote:
> El Tue, 02 Aug 2011 09:21:23 +0200
> Ansgar Burchardt  escribió:
> > Adam Borowski  writes:
> > > Right, I missed the .o and .dll files, counting only
> > > wizznic-x86-precompiled and tools/releaser/data/win/curl/curl.exe
> > > (the ones mentioned by lintian).
> > >
> > > The dlls are libjpeg, zlib, libogg, SDL, openssl -- all DFSG free
> > > with source already in main.
> > 
> > The source would need to be included in the same (source) package to
> > make sure that it is the same version and that we will still include
> > source even if another package is removed from the archive.
> > 
> > Ansgar
> > 
> > 
> 
> I get a little confused about what I do with the dfsg, I should remove
> the binaries or add a the source of them? 

There seems to be somewhat different oppinions on this. Mine is: remove all
binary files whether they can be compiled from source or not and strip the
source down to the largest set of source files that can still reliably build
your binaries. Problem with the binary files is that it's close to
impossible to reliably know how and by whom they were built and what license
they come with. The problem of people being able to run potentially
malicious code is another (usually for this conext minor) problem.

If you can - with respect to ensuring a DFSG-free license - leave them in
the tarball and document them (and potentially put a check into d/rules
looking after them not being "tainted" - how ever that may look like) that'd
be an option. Yet as said IMHO it's practically close to impossible to debug a
windows binary set with regards to libraries linked into there etc. at build
time of a Debian package.


> Also, I need to modify the d/copyright, d/changelog, d/watch
> make README.debian-source, orig.tar.bz2 and add a rule get-orig-source
> to d/rules to make a _good_ dfsg repackage?

Yes, that should do it.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: mpd-sima (updated package)

[Kilian Krause]

Hi Geoff,

On Wed, Aug 03, 2011 at 09:47:47PM +0200, Geoffroy Youri Berret wrote:
> Thanks for your review :)
> 
> Le 03/08/2011 18:29, Kilian Krause a écrit :
> > On Mon, Aug 01, 2011 at 04:42:15PM +0200, Geoffroy Youri Berret wrote:
> >> I gentle ping on this package :)
> >>
> >> I moved the packaged to "Debian Multimedia Maintainers".
> >>git://git.debian.org/pkg-multimedia/mpd-sima.git
> >>
> >> I believe the package to be in pretty good shape now.
> > […]
> > 1.) You build-depend on bash-completion. What for? Moreover you build-depend
> > on python-all which huge compared to what you will actually need IMHO.
> > Why not limit that more to what is actually required?
> [bash-completion]
> I need bash-completion because it provides dh_bash-completion.
> It'll handle debian/mpd-sima.bash-completion properly.

Right. See that now. ;-)


> [python-all]
> Well, I think need python 2.6 and python 2.7, I guess then I could save python
> 2.5 setting a build depends on python2.6 instead of python-all.
> But isn't “python-all (>= 2.6.6-3~)” similar?

Ok, in that case I guess I can consider your solution a good solution. I was
hoping that you only need some few modules to build and reducing to only
these modules with reducing the amount of build-depends (looking at the
whole tree) in mind would make sense. I'll have your word for it that this
isn't an option. 


[...]
> “4.)” somehow disappeared ^^

Yes, that was a criticism that didn't sustain a second look. ;-)



[...]
> I've uploaded a new version, tagged 0.8.0-1, to mentors.
> I haven't pushed to the git repo yet.
> 
> http://mentors.debian.net/debian/pool/main/m/mpd-sima/mpd-sima_0.8.0-1.dsc

Very good. Built, Signed, Uploaded. 

Please don't forget to update your git (including retagging the 0.8.0-1 and
deleting a eventually existing -2 tag).

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: acsccid (Updated)

[Kilian Krause]

Hi Godfrey,

On Tue, Aug 02, 2011 at 11:53:45AM +0800, Godfrey Chung wrote:
> I just updated debian/copyright. Please have a look. Thanks!

Thanks for your work.

Having a first look myself at your package I find:

1. You build-depend on autotools-dev but don't use it in debian/rules' dh
   call. Please add it to dh.

2. Your patch lacks a DEP-3 header indicating where this patch came from and
   whether upstream was notified of this to support their development in case
   it wasn't pulled from there.

3. Your override_dh_auto_install target in debian/rules lacks a tab (to make
   syntax highlighting happy) and more importantly you override
   override_dh_makeshlibs without any rationale I could see. Please put a
   comment why this is needed or remove the override.

4. Regarding the mv and symlink you may want to talk to upstream about
   supporting sysconfdir in a proper way. I think they will find it helpful
   to learn that FHS doesn't foresee /usr writeable and thus suitable for
   config files.

5. The debian/rules template header can be omited too.

6. The name "libacsccid" does not follow the recommended naming scheme for
   libraries. It should be libacsccid102 or something alike. See [1] for
   details.

7. Building your package I still see:
   udev support:no

   This seems not to be the intended output looking at the udev rules file.
   There is no Depends on udev too however. Are you sure that the built
   package works ok if built in a clean pbuilder?

8. The upstream changelog is not shipped in the binary package. Please
   consider adding it too.

[1]: 
http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: mpd-sima (updated package)

[Kilian Krause]

Hi Geoff,

On Mon, Aug 01, 2011 at 04:42:15PM +0200, Geoffroy Youri Berret wrote:
> I gentle ping on this package :)
> 
> I moved the packaged to "Debian Multimedia Maintainers".
>   git://git.debian.org/pkg-multimedia/mpd-sima.git
> 
> I believe the package to be in pretty good shape now.

Thanks for your work. From a first look:

1.) You build-depend on bash-completion. What for? Moreover you build-depend
on python-all which huge compared to what you will actually need IMHO.
Why not limit that more to what is actually required?

2.) You should leave the new upload at 0.8.0-1 because your changelog entry
never made it into unstable as a package. (Your sponsor would need to
build with -sa and -v etc. etc. which is nasty)

3.) You drop debian/html from the docs without mentioning in the changelog

5.) http://sima.codingteam.net seems no longer valid. New homepage is at...?

6.) /usr/share/common-licenses/GPL in debian/copyright should rather be the
versioned reference (GPL-3)

7.) lintian proposes to enhance simadb_cli.1.gz: "allows to" should be "allows 
one to"


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

Please comment the above and I'll put it in.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: l2tp-ipsec-vpn

[Kilian Krause]

Hi Werner,

On Wed, 2011-08-03 at 16:19 +0200, Werner Jaeger wrote:
> you should be able to find l2tp-ipsec-vpn-daemon package at
> 
> http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=l2tp-ipsec-vpn-daemon
> 
> Repository URL is
>  
> http://mentors.debian.net/debian/pool/main/l/l2tp-ipsec-vpn-daemon
> 
> So far, this package has got now review yet.
> 
> If you find the l2tp-ipsec-vpn-daemon package to be o.k. I'd be happy if
> some one could put both packages into NEW.

the postinst, postrm, prerm aren't used. You may want to delete them.

debian/rules reads:
make -f nbproject/qt-Release.mk
dist/Release/GNU-Linux-x86/L2tpIPsecVpnControlDaemon
-(snip)-

Why hard code the arch here? Will this be a problem on any Debian arch
including the kFreeBSD ones?

As I already said for the GUI - the construction with the extra
nbproject looks a bit weird as you are both upstream and Debian
maintainer. I'm not sure you aren't overcomplicating the debian/rules
file.

Regarding the test target in debian/rules you've put it for the daemon
and for the GUI yet both times without content. Any reason to add this
line here? Are you planning on adding tests (which would be great) but
they aren't ready despite your 1.0.0 version number?

I'm not too sure whether
"/usr/lib/l2tp-ipsec-vpn-daemon/L2tpIPsecVpnControlDaemon" is the best
path to put your deamon. I'd see /usr/sbin somewhat more appropriate.

Other than that good to go IMHO.

-- 
Best regards,
Kilian


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

Re: RFS: eviacam

[Kilian Krause]

Hi Cesar,

On Wed, 2011-08-03 at 13:22 +0200, Cesar Mauri wrote:
> > [...]
> >>> or so and move the SUID bit setting including creating a
> >>> group to postinst so that you limit the impact to an acceptable minimum.
> >>> Having an open root access for everybody on a system is quite a bit
> >>> too generous IMHO.
> >>
> >> I don't like also having a SUID binary but it is the only way I
> >> found to raise the priority of the process. I've moved the "chmod"
> >> to the postinst script but I couldn't create a group to setuid to
> >> because the nice system call (see nice(2)) needs superuser
> >> privileges.
> >
> > I seem to have not expressed my idea correctly:
> > - Have your binary chmod 4750
> > - with uid 0 (thus the setUID) and
> > - group "whateveryournewgroupname"
> >
> > In debian/postinst that would look like:
> > chmod 4750 $BINARY
> > chown 0:$GID $BINARY
> >
> > where $GID is the group id of the group you create in postinst.
> >
> > That will make sure it gets the UID 0 correctly so that nice(2) will work ok
> > and also will make sure that only users of the group are allowed to execute
> > it.
> >
> > Does that make sense for you?
> 
> Got it! Before creating a new group, is there any previously existing 
> group that would be suitable for such a job (i.e. that a common desktop 
> user would be part of)?

None that would fit the requirements we have here IMHO.


> I think that if we need to create a new group may be some non-expert 
> users won't be able to run eviacam properly (i.e. they might fail to add 
> their username to such group). Other options include:
> 
> i) ask the user whether to make eviacamloader SUID and explain that a 
> new group is needed and such and such.

Can be done with debconf quite easily as:
a) Ask whether SUID should be activated
b) which users should be added to the group interactively

Please set sensible defaults so that you can also work with
DEBCONF_FRONTEND=noninteractive


> ii) completely get rid of the SUID thing at the expense of less 
> responsiveness.

If that's possible and doesn't limit core functionality it sounds like a
valid option. What downsides would that bring?

I think debconf as explained above together with properly adding a new
group and importing users through debconf would be a good thing.

-- 
Best regards,
Kilian


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

Re: RFS: eviacam

[Kilian Krause]

Hi Cesar,

On Wed, Aug 03, 2011 at 05:23:43AM +0200, Cesar Mauri wrote:
> Thanks for your comments. I have (hopefully) addressed all the
> issues you pointed out. I have uploaded an updated version to the
> mentors site which appears to be lintian clean and pbuilds fine for
> sid. See below for additional details.

Thanks for your work!


[...]
> >or so and move the SUID bit setting including creating a
> >group to postinst so that you limit the impact to an acceptable minimum.
> >Having an open root access for everybody on a system is quite a bit
> >too generous IMHO.
> 
> I don't like also having a SUID binary but it is the only way I
> found to raise the priority of the process. I've moved the "chmod"
> to the postinst script but I couldn't create a group to setuid to
> because the nice system call (see nice(2)) needs superuser
> privileges.

I seem to have not expressed my idea correctly:
- Have your binary chmod 4750
- with uid 0 (thus the setUID) and 
- group "whateveryournewgroupname"

In debian/postinst that would look like:
chmod 4750 $BINARY
chown 0:$GID $BINARY

where $GID is the group id of the group you create in postinst.

That will make sure it gets the UID 0 correctly so that nice(2) will work ok
and also will make sure that only users of the group are allowed to execute
it.

Does that make sense for you?

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: l2tp-ipsec-vpn

[Kilian Krause]

Hi Werner,

On Tue, Aug 02, 2011 at 07:20:27AM +0200, Werner Jaeger wrote:
> thank you so much for this review.
> 
> I addressed and solved all the issues and uploaded the changes to
> mentors.debian.net.
> 
> BTW I'm still looking for a sponsor to upload this package.
> > http://mentors.debian.net/debian/pool/main/l/l2tp-ipsec-vpn/l2tp-ipsec-vpn_1.0.0-1.dsc

Having another look at this updated version I see that your depends still
lists "l2tp-ipsec-vpn-daemon" which has an ITP (now RFP) but no package in
Debian.

Apart from that the construction with nbproject in debian/rules looks a bit
unusual but still ok. Yet as you're upstream I wonder why this dependency is
not put into upstream makefiles.

If you want we can put l2tp-ipsec-vpn into NEW first, but it won't be
installable withtout l2tp-ipsec-vpn-daemon. How far is your ITP w.r.t.
actually producing a package?

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: rrep (updated package)

[Kilian Krause]

Hi Arno,

On Tue, Aug 02, 2011 at 05:45:46PM +0200, Arno Onken wrote:
> I am looking for a sponsor for the new version 1.3.3-2
> of my package "rrep".
> - dget http://mentors.debian.net/debian/pool/main/r/rrep/rrep_1.3.3-2.dsc

built, signed, uploaded.

Thanks!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: rrep

[Kilian Krause]

Hi Arno,

On Mon, Aug 01, 2011 at 06:10:20PM +0200, Arno Onken wrote:
> - dget http://mentors.debian.net/debian/pool/main/r/rrep/rrep_1.3.3-1.dsc

one thing I forgot to mention is also that your Build-Depends on debhelper
with 8.0.0 does rule out any backports in oldstable. For this either >= 8 or
>= 8.0.0~ should be used.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: rrep

[Kilian Krause]

Hi Arno,

On Mon, Aug 01, 2011 at 06:10:20PM +0200, Arno Onken wrote:
> I am looking for a sponsor for my package "rrep".
[...]
> - dget http://mentors.debian.net/debian/pool/main/r/rrep/rrep_1.3.3-1.dsc

Very nice work indeed.

You add autotools-dev to Build-Depends yet don't add them to the dh line in
debian/rules. I doubt this was done intentionally.

Regarding your rationale that sed doesn't have a matching algorithm I tend
to disagree. sed does have pattern matching like '/whatever/s,what,who,'
which will only rewrite all lines that have "whatever" to "whoever". Yet
I'll not regard this to stand in the way of accepting your package into
Debian. ;-)

In your copyright you mention "documentation" that is "GFDL" yet without
naming any files. I guess it'd be nice to explicitly spell out which files
are to be regarded as documentation in this context.

The Suggests: libpcre3 is really fully optional to your program? Suggests is
something that does enhance a package if available on the system yet not
block any of the core functions if not installed.

As I don't see any of these grave enough to hinder an upload, I've just
built, signed and uploaded your package.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: wizznic

[Kilian Krause]

Hi Edgar,

On Wed, Jul 27, 2011 at 03:44:01PM -0500, Edgar Antonio Palma de la Cruz wrote:
> I am looking for a sponsor for my package "wizznic".
[...]
> 
> The package appears to be lintian clean.
> It has 2 type of --pedantic notice:
> P: wizznic source: source-contains-prebuilt-windows-binary
> P: wizznic source: source-contains-prebuilt-binary
> I'm already contact the upstream for this issues, and he said that a next 
> release would be more cleaner, because this is a preview version. 

Without any further review - this will need to be repackaged as DFSG-free
for an upload. It cannot be uploaded in this shape. Sorry.

So please either repack or wait for that new upstream release without any
binary blobs (yes, any - that are not game data like level-packs and
images which are obviously not usefully available in another "source"
format).

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: libchart-php

[Kilian Krause]

Hi Daniel,

On Mon, Aug 01, 2011 at 05:36:36PM +0200, Daniel Lombraña González wrote:
> 2011/7/30 Michael Tautschnig 
> > > I have update the package with the latest available version 1.3. Please,
> > can
> > > you check if everything is OK?
> > >
> > [...]
> >
> > I just thought I'd briefly check whether your orig.tar.gz matches the
> > upstream
> > tar.gz, found different md5sums and then this:
> >
> > (omitting full diffstat output)
> >  78 files changed, 3771 insertions(+), 4496 deletions(-)
> >
> > !?
> >
> > It seems you completely reorganized the source tree. That's not quite the
> > point
> > of a .orig.tar.gz file.
> >
> 
> I'm sorry, I thought I have to reorganized the source tree to create the
> package. Now I have understood the problem, and a new version has been
> uploaded. This one has the original tar.gz. I hope this time, at least this
> issue is fixed.

Thanks for the update. Your debian/watch however still doesn't work for me.
A version that would work looks at least like this:

version=3
opts="downloadurlmangle=s#\/\/code.google.com##" \
http://code.google.com/p/libchart/downloads/list \
//libchart.googlecode.com/files/libchart-(.*)\.tar\.gz

-(snip)-

Feel free to provide an even better one if you can. =)

Apart from that you still ship the *.ttf files inside your orig.tar.gz
source. You will want to modify this as DFSG-repack (removing the ttf files
entirely from the tarball) and leave your patch in place which looks ok from
a first glimpse. A get-orig-source target inside debian/rules is the correct
place to put this.

Your standards-version is still at 3.9.1 and should be bumped to latest
3.9.2 - shouldn't be much of a problem.

The debian/copyright looks a bit weird with the URL you point to. Please use
DEP-5 (which is the to-be-standard) with its correct URL instead - and put a
full verbatim GPL-3 quote.

The URL http://libchart.googlecode.com/svn/trunk doesn't work. Neither does
http://naku.dohcrew.com/libchart/pages/introduction. At least with a regular
browser. Should they? I guess at least the latter should.

The upstream changelog at libchart/ChangeLog should be shipped also in the
package.

Ping me or Michael when the above is done as that should make the package
good enough for an initial upload.

Thanks!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: dbxml

[Kilian Krause]

Hi Daniel,

Am 30.07.2011 um 12:56 schrieb Daniel de Kok :

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

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

-- 
Best regards,
Kilian


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

Re: RFS: b43-fwcutter

[Kilian Krause]

Hi Fabrizio,

On Wed, Jul 27, 2011 at 03:39:33PM +0200, Fabrizio Regalli wrote:
> On Wed, 2011-07-27 at 15:10 +0200, Fabrizio Regalli wrote:
> 
> > .dsc is available here:
> > 
> > http://expo.debian.net/debian/pool/contrib/b/b43-fwcutter/b43-fwcutter_014-5.dsc
> 
> Please use this .dsc: (on mentors.d.n)
> 
> http://mentors.debian.net/debian/pool/contrib/b/b43-fwcutter/b43-fwcutter_014-5.dsc

Built, Signed, Uploaded. 

Thanks!

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

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

[Kilian Krause]

Hi Olivier,

On Fri, Jul 29, 2011 at 05:09:37PM +0200, Olivier Girondel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Dear mentors,
> 
> I am looking for a sponsor for my packages "lebiniou" and
> "lebiniou-data".
> 
>  Package name: lebiniou, lebiniou-data
>  Version : 3.9-1
>  Upstream Author : Olivier Girondel 
>  URL : http://biniou.net
>  License : GPLv2
>  Section : graphics
> 
> They build these binary packages:
> 
> lebiniou  - displays images that evolve with sound
> lebiniou-data - Datafiles for Le Biniou
> 
> The packages appear to be lintian (--pedantic) clean.
> 
> The upload would fix these bugs: 610042, 620899
> 
> My motivation for maintaining these packages is: I'm upstream for this
> software, which has more than fifteen years of existence running on
> GNU/Linux-based systems (esp. Debian), and *BSD. It's been appreciated
> and used as a VJing tool, and I think packaging it will make the
> procedures smoother for users as well as broadening its audience.
> 
> The packages can be found on mentors.debian.net:
> 
> - - URL: http://mentors.debian.net/debian/pool/main/l/lebiniou
> - - Source repository: deb-src http://mentors.debian.net/debian unstable
> main contrib non-free
> - - dget
> http://mentors.debian.net/debian/pool/main/l/lebiniou/lebiniou_3.9-1.dsc

what's the reason to have:

1. dh-autoreconf (none of the patches requires this)
2. OSS as default audio driver upstream (and thus Debian patch)
3. extra -O3 when -O2 is already set as the Debian default?
4. a different lebiniou tarball than the one from your upstream website

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

> and
> - - URL: http://mentors.debian.net/debian/pool/main/l/lebiniou-data
> - - Source repository: deb-src http://mentors.debian.net/debian unstable
> main contrib non-free
> - - dget
> http://mentors.debian.net/debian/pool/main/l/lebiniou-data/lebiniou-data_3.9-1.dsc

1. The public domain license is not printed verbatim in debian/copyright.
   Needs to be added.
2. Won't built for me with "pdebuild -- --twice" due to:
Making all in sequences
make[2]: Entering directory `/tmp/buildd/lebiniou-data-3.9/sequences'
./make-tar.sh
/bin/bash: ./make-tar.sh: No such file or directory
make[2]: *** [sequences.tar.gz] Error 127


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

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature