Bug#818735: RFS: qwtplot3d/0.2.7+svn191-10

2016-03-20 Thread Gudjon I. Gudjonsson 
Hi Mattia
> 
> * you're using any-amd64 and any-i386, then why do you explicitly list
>   hurd-i386 kfreebsd-amd64 kfreebsd-i386 too?
Ok. I will remove these.
> * you're changing only one binary, what about the others?  from what I'm
>   seeing the failure is in the configure step which is done by all
>   binaries, so this change wouldn't fix the FTBFS)
A mistake. But can I exclude arm only for the qt5 libraries? The qt5 libraries 
have never been in
testing so I guess it may be easier.
Do you know of any package where only the a part is built for all architectures?
> * why are you not closing the bug?
Because it isn't solved. I would prefer to port the code to use GL that works 
on arm but
until that is done I will exclude arm.
I will reduce the bugs severity as soon as version -10 is uploaded.
> * do you know that to allow the testing migration you'd still need to
>   remove the binaries from unstable by filing a bug against
>   ftp.debian.org?  actually that would be enough, even without
>   restricting the architecures where you build, then you can leave the
>   packages in FTBFS state there until it could build again.
Sorry, I didn't know but that sounds reasonable.
But if I keep the qt4 binaries in but only restrict the qt5 binaries. Do I then 
still need to file a bug?

Regards
Gudjon

Re: git-buildpackage pattern question

2016-03-20 Thread Russ Allbery 
Ross Vandegrift  writes:

> In my packaging, I've worked on 1.0.0, and updated for 1.0.1 and 1.0.2.
> So my packaging looks like this:

> o---ooooo master
>  \  \
>   o---o 1.0.0o---o 1.1.0
>\  \
> o---o 1.0.1o---o 1.1.1
>  \
>   o---o 1.0.2
>\
> o  debian/sid

> To update to 1.1.1, I've read that I should merge 1.1.1 into debian/sid.
> But this is painful - upstream 1.1.1 conflicts with 1.0.2.

This is exactly why git-buildpackage by default uses an upstream/latest
branch that tracks upstream releases.  If upstream has tarball releases,
when moving from 1.0.2, you would advance the upstream branch to 1.1.1
with:

gbp import-orig --upstream-vcs-tag=1.1.1 /path/to/tarball

and gbp will make a merge commit in the upstream/latest branch that moves
all files to the contents of the 1.1.1 tarball, forcing all files to move
to the 1.1.1 contents.  You will then, from Git's perspective, have a
commit in the upstream branch that goes from 1.0.2 -> 1.1.1, and you can
merge the upstream/latest branch into the debian/sid branch without any
conflicts.

If upstream doesn't do tarball releases, you can't use gbp import-orig (I
think), so you have to synthesize that commit yourself.  You still need a
separate branch that doesn't have your packaging files.  Conventionally,
this is upstream/latest.  This gets a bit tricky, since you have to use
the "ours" merge strategy.

I *think* something like this would work, but I haven't tested it.

git checkout -b upstream/1.1 1.1.1# assuming 1.1.1 is the upstream tag
git merge -s ours upstream/latest
git branch -d upstream/latest
git branch -m upstream/1.1 upstream/latest

The idea is that you want to move the tip of upstream/latest to a commit
that exactly matches upstream's 1.1.1 release, but which Git has recorded
as a merge between upstream's 1.1.1 branch and your existing
upstream/latest branch (which was upstream's 1.0.2 branch).  This will
give Git enough information to properly merge your new upstream/latest
branch into your debian/sid branch by just moving upstream source to 1.1.1
without changing anything about your packaging.

I think gbp import-orig, under the hood, does something more complicated
using Git plumbing to create the merge commit directly.

-- 
Russ Allbery (r...@debian.org)

git-buildpackage pattern question

2016-03-20 Thread Ross Vandegrift 
Hello all,

I've been working on packages using git-buildpackage, and have been
wondering if there's a better pattern out there.

Upstream makes periodic releases, which often receive a few maintenance
updates.  For upstream, often looks like this:

o---ooooo  master
 \  \
  o---o  1.0.0   o---o  1.1.0
   \  \
o---o  1.0.1   o---o 1.1.1
 \
  o---o 1.0.2

In my packaging, I've worked on 1.0.0, and updated for 1.0.1 and 1.0.2.
 So my packaging looks like this:

o---ooooo master
 \  \
  o---o 1.0.0o---o 1.1.0
   \  \
o---o 1.0.1o---o 1.1.1
 \
  o---o 1.0.2
   \
o  debian/sid

To update to 1.1.1, I've read that I should merge 1.1.1 into debian/sid.
 But this is painful - upstream 1.1.1 conflicts with 1.0.2.

I've developed an alternative where I rebase 1.0.2..debian/sid onto
1.1.1.  This is straightforward, but rewrites all previous packaging
commits, so they come after all upstream commits.

Does anyone have an alternative pattern to try? Thanks for any tips!

Ross

Bug#813813: RFS: msi-keyboard -- command line tool to change MSI steelseries keyboards color setup

2016-03-20 Thread Jakub Wilk 

* Giulio Paci , 2016-03-20, 03:05:

I'm looking partly shocked at the commit
6fc1eec66c259cefeeb13453c3ceeb206fb24a55 why did you *substituted* the 
pristine-tar data?  You should always just add them.


This is just because upstream never tagged a version, nor released a package.
I imported one using 0.0.1 version, but later noticed that 1.0 was set 
in the source and so I renamed the package.


Um. If upstream didn't make a release, then you ask them to make one, 
instead of declaring yourself that this random git snapshot will be 
called 1.0.


That the source says it's "1.0" is not very relevant, unless upstream 
bumps version in every commit; and they don't.


Also, you probably want to fix your debian/watch. :)

--
Jakub Wilk

Bug#818624: RFS: r-cran-pbdzmq/0.2.1+dfsg-2

2016-03-20 Thread Gordon Ball 
On 20/03/16 06:24, Mattia Rizzolo wrote:
> control: tag -1 moreinfo
> control: owner -1 !
> 
> On Fri, Mar 18, 2016 at 08:49:21PM +0100, Gordon Ball wrote:
>>   I am looking for a sponsor for my package "r-cran-pbdzmq"
> 
> hi there (3rd time ;))

And thanks again.
> 
>> http://mentors.debian.net/debian/pool/main/r/r-cran-pbdzmq/r-cran-pbdzmq_0.2.1+dfsg-2.dsc
> 
> this looks nicer from a license POV, at least!
> 
> * debian/changelog:
>   + what happened to version -1 ?

These packages (and quite a few others) are already in a PPA [1] (which
I hope to make more debian uploads), and hence I can't recycle old
versions.

> * debian/control:
>   + (Build-)Depends are not sorted, please sort them (wrap-and-sort(1)
> and cme(1) may help here)
>   + outdated Standards-Version
>   + very very short extended descript, please make it longer

Done.

> * DESCRIPTIONS:
>   + the Copyright field points to non-existant files, that may actually
> be interesting to read, where are they? (I see one is excluded in
> d/copyright, why?)

The upstream distribution contains a complete source copy of libzmq, and
built objects for windows. The package builds against system
libzmq3-dev. The excluded copyright file covers the bundled library,
which is hence unneeded. The remaining files in src/ are the bindings to
libzmq which should be covered by the package license (GPL-3).

> * inst/doc/pbdZMQ-guide.pdf
>   + PDFs are tricky [1], and should be stripped out of the tarball and
> built at build time, it surely looks feasible, may you do it?

Excluded from 0.2.1+dfsg2. It does not appear common in R packages to
build package vignettes (Rnw/Rmd) into their compiled forms (PDF/html),
so I haven't added rules to re-compile it - this should probably be done
at the debian R policy level rather than individually.

> * debian/tests:
>   + I wonder if an autodep8 thing for R would make sense, after having
> seen 3 quasi-identical tests for 3 different R packages
>

It probably would, but I don't know how to go about it. I added these
tests based on similar ones used for nodejs packages.

> 
> [1] https://ftp-master.debian.org/REJECT-FAQ.html (grep for PDF)
> 

The changes are uploaded to d/mentors [2] as r-cran-pbdzmq 0.2.1+dfsg2-1
("dfsg2" since the PPA already built against the existing DFSG tarball).

[1]: https://launchpad.net/~chronitis/+archive/ubuntu/jupyter/
[2]: http://mentors.debian.net/package/r-cran-pbdzmq

Bug#818749: marked as done (RFS: presage/0.9.1-2 [RC])

2016-03-20 Thread Debian Bug Tracking System 
Your message dated Sun, 20 Mar 2016 17:44:57 +
with message-id <20160320174456.gm32...@chase.mapreri.org>
and subject line Re: Bug#818749: RFS: presage/0.9.1-2 [RC]
has caused the Debian Bug report #818749,
regarding RFS: presage/0.9.1-2 [RC]
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
818749: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818749
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: sponsorship-requests 
Severity: important 

Dear mentors, 

I am looking for a sponsor for my package "presage" 

Package name: presage 
Version : 0.9.1-2 
Upstream Author : matteo.vesc...@yahoo.co.uk 
URL : http://presage.sourceforge.net/ 
License : GPL-2 
Section : devel 

It builds those binary packages: 

gprompter  - intelligent predictive GTK+ text editor 
prompter-dbg - intelligent predictive GTK+ text editor (debugging symbols) 
libpresage-data - intelligent predictive text entry platform (data files) 
libpresage-dev - intelligent predictive text entry platform (development files) 
libpresage-doc - intelligent predictive text entry platform (documentation) 
libpresage1-dbg - intelligent predictive text entry platform (shared library 
debugg 
libpresage1v5 - intelligent predictive text entry platform (shared library) 
presage- intelligent predictive text entry platform (tools and demos) 
presage-dbg - intelligent predictive text entry platform (tools debugging symbo 
presage-dbus - intelligent predictive text entry platform (D-Bus service) 
pyprompter - intelligent predictive wxPython text editor 
python-presage - intelligent predictive text entry platform (Python binding) 
python-presage-dbg - intelligent predictive text entry platform (Python binding 
debugg 

To access further information about this package, please visit the following 
URL: 

http://mentors.debian.net/package/presage 


Alternatively, one can download the package with dget using this command: 

dget -x 
http://mentors.debian.net/debian/pool/main/p/presage/presage_0.9.1-2.dsc 

More information about hello can be obtained from http://www.example.com. 

Changes since the last upload: 

* Depend on swig instead of swig2.0 (Closes: #816999) 
* Fix lintian error in libpresage1v5.symbols file 
symbols-file-contains-current-version-with-debian-revision. 
* Fix lintian warning command-in-menu-file-and-desktop-file. 
* Reorder link library flags for gprompter (Closes: #776720) 
* Update to latest policy. 
* Fix vcs-field-uses-insecure-uri lintian info check. 


Regards, 
Matteo Vescovi 
--- End Message ---
--- Begin Message ---
On Sun, Mar 20, 2016 at 04:23:26PM +, Matteo Vescovi wrote:
> I've also reuploaded using the same original tarball for 0.9.1 that
> is identical to the one already in the archive... I must have forgotten
> to pass a --pristine-tar when I imported the 0.9.1 tarball into git.

Uploaded.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature
--- End Message ---

Bug#818623: RFS: r-cran-uuid/0.1.2-4

2016-03-20 Thread Gordon Ball 
On 20/03/16 06:11, Mattia Rizzolo wrote:
> control: owner -1 !
> control: tag -1 moreinfo
> 
> On Fri, Mar 18, 2016 at 08:47:33PM +0100, Gordon Ball wrote:
>>   I am looking for a sponsor for my package "r-cran-uuid"
>>
>>  * Package name: r-cran-uuid
>>Version : 0.1.2-4
>>Upstream Author : Simon Urbanek 
>>  * URL : http://www.rforge.net/uuid
>>  * License : MIT + bsd-3-clause
>>Section : gnu-r
>>
>> http://mentors.debian.net/debian/pool/main/r/r-cran-uuid/r-cran-uuid_0.1.2-4.dsc
> 
> same thing as the other, MIT license no better specified with no copy
> of it in the tarball.
> 
> then, as lintian says:
> W: r-cran-uuid source: out-of-date-standards-version 3.9.6 (current is 3.9.7)
> I: r-cran-uuid: extended-description-is-probably-too-short
> W: r-cran-uuid: extra-license-file usr/lib/R/site-library/uuid/LICENSE
> 
I have uploaded a new version (0.1.2-5) [1] to d/mentors which I believe
fixes these issues.

For the moment a specific entry in d/rules removes the extra license
file, but since the standard R CDBS config removes some similar named
files (LICENSE.txt) I'll investigate filing a bug to remove this
combination too.

[1] https://mentors.debian.net/package/r-cran-uuid

Bug#818788: RFS: gmp-ecm/7.0+ds-1 [NEW MAJOR VERSION] -- Factor integers using the Elliptic Curve Method

2016-03-20 Thread Jerome Benoit 
Package: sponsorship-requests
Severity: normal

Dear Mentors,

I am looking for a sponsor for my gmp-ecm pacakge. This package brings
to Debian the latest major release of gmp-ecm, a mathematical
software suite to `Factor integers using the Elliptic Curve Method'.
This software is part of Sage.

Thanks in advance,
Jerome

[1] https://anonscm.debian.org/cgit/debian-science/packages/gmp-ecm.git

-- System Information:
Debian Release: Jessie*
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.7-ckt20-0001-mbp62 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#818749: RFS: presage/0.9.1-2 [RC]

2016-03-20 Thread Matteo Vescovi 


> just two things:
> 
> The Vcs-Git you put now requires authentication.  Vcs-Git shouldn't
> require authentication.

> The orig tarball you uploaded to mentors is different than the one
> already on the archive, this is worrisome.
> What do you expect me to do here?


Hi Mattia, 

Thanks for your review.

I've fixed the Vcs-Git stanza, reverted back to the git:// protocol 
which does not require authentication.

I've also reuploaded using the same original tarball for 0.9.1 that
is identical to the one already in the archive... I must have forgotten
to pass a --pristine-tar when I imported the 0.9.1 tarball into git.


Cheers,
- Matteo

Bug#818724: RFS: task-spooler/0.7.6-1

2016-03-20 Thread Adam Borowski 
On Sun, Mar 20, 2016 at 12:04:12PM +0300, Alexander Inyukhin wrote:
> On Sun, Mar 20, 2016 at 05:40:59AM +, Mattia Rizzolo wrote:
> > and btw, having debian/* GPL-2+ technically makes upstream unable to
> > pull patches from debian/patches/*, as GPL-2+ is incompatible with
> > GPL-2 (only).

This is incorrect.  GPL-2 and GPL-2+ are compatible, both ways, with the
combined result being effectively GPL-2 but anyone can still pick GPL-2+
parts and use them under GPL-2, GPL-3, GPL-4, GPL-4636467912 and,
unfortunately, AGPL-3 (which I consider a non-free license).

> Isn't that a one-way incompatibility?
> As far as I understand, GPL2+ is a set of licenses including GPL2,
> so GPL2+ code could be used in GPL2-only project.

So can GPL2-only code be used in a GPL2+ project (at the cost of restricting
the result to GPL2-only).

> Anyway, I do not want to restrict use of these patches.
> What license should I use?

GPL-2+ as you currently do.  This way upstream can use your patches now, and
will continue to be able even if they relicense to a higher version of GPL
in the future.

-- 
A tit a day keeps the vet away.

Re: Google Code and watchfiles

2016-03-20 Thread Sascha Steinbiss 
Hi Paul,

On 17/03/2016 13:59, Paul Wise wrote:
> On Thu, Mar 17, 2016 at 9:57 PM, Paul Wise wrote:
>> On Thu, Mar 17, 2016 at 8:58 PM, Sascha Steinbiss wrote:
>>> Indeed I tried that [1] but I didn't get a response.
>>> [1] https://lists.debian.org/debian-med/2016/02/msg3.html
>>
>> Sounds like the project is dead upstream and should be removed from
Debian?
>
> I found this, I wonder if the author plans to move there?
>
> https://github.com/averagehat/pbsim

I found this too but apparently -- and unfortunately -- there is no
connection to the original upstream.

Cheers
Sascha


-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE.

Bug#818749: RFS: presage/0.9.1-2 [RC]

2016-03-20 Thread Mattia Rizzolo 
control: tag -1 moreinfo

On Sun, Mar 20, 2016 at 11:32:56AM +, Matteo Vescovi wrote:
> dget -x 
> http://mentors.debian.net/debian/pool/main/p/presage/presage_0.9.1-2.dsc 
> 
> Changes since the last upload: 
> 
> * Depend on swig instead of swig2.0 (Closes: #816999) 
> * Fix lintian error in libpresage1v5.symbols file 
> symbols-file-contains-current-version-with-debian-revision. 
> * Fix lintian warning command-in-menu-file-and-desktop-file. 
> * Reorder link library flags for gprompter (Closes: #776720) 
> * Update to latest policy. 
> * Fix vcs-field-uses-insecure-uri lintian info check. 

just two things:

The Vcs-Git you put now requires authentication.  Vcs-Git shouldn't
require authentication.

The orig tarball you uploaded to mentors is different than the one
already on the archive, this is worrisome.
What do you expect me to do here?


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#818701: marked as done (RFS: webvirtmgr/4.8.9-3 [put in ITP, ITA, RC, NMU if applicable])

2016-03-20 Thread Debian Bug Tracking System 
Your message dated Sun, 20 Mar 2016 12:45:36 +0100
with message-id <1458474336.3014.2.ca...@iabsis.com>
and subject line Re: Bug#818701: Acknowledgement (RFS: webvirtmgr/4.8.9-3 [put 
in ITP, ITA, RC, NMU if applicable])
has caused the Debian Bug report #818701,
regarding RFS: webvirtmgr/4.8.9-3 [put in ITP, ITA, RC, NMU if applicable]
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
818701: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818701
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
  Severity: normal [important for RC bugs,
wishlist for new packages]

  Dear mentors,

  I am looking for a sponsor for my package "webvirtmgr"

 * Package name: webvirtmgr
   Version : 4.8.9-3
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : web

  It builds those binary packages:

webvirtmgr - Libvirt-based Web interface for managing virtual machines.
 webvirtmgr-supervisor - Supervisor configuration files for Webvirtmgr

  To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/webvirtmgr


  Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/w/webvirtmgr/webvirtmgr_4.8.9-3.dsc

  More information about hello can be obtained from http://www.example.com.

  Changes since the last upload:

* Adding supervisor autoconf package.
* Webvirtmgr debconf dialog for configuration.
* Fix Django 1.7 compatibility.
* Initial release.


  Regards,
   Olivier Bitsch

signature.asc
Description: This is a digitally signed message part
--- End Message ---
--- Begin Message ---
Not clean request.
-- 
Olivier Bitsch
Iabsis SARL
Gérant - Administrateur de réseaux informatiques
6 rue du Parc - Blue Business Building
F-74100 Annemasse
Mob : +33 699 554 229
Mail : olivie...@iabsis.com
Site : http://www.iabsis.comLe samedi 19 mars 2016 à 20:57 +, Debian Bug 
Tracking System a
écrit :
> Thank you for filing a new Bug report with Debian.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due
> course.
> 
> Your message has been sent to the package maintainer(s):
>  Debian Mentors 
> 
> If you wish to submit further information on this problem, please
> send it to 818...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 

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

Bug#818749: RFS: presage/0.9.1-2 [RC]

2016-03-20 Thread Matteo Vescovi 

Package: sponsorship-requests 
Severity: important 

Dear mentors, 

I am looking for a sponsor for my package "presage" 

Package name: presage 
Version : 0.9.1-2 
Upstream Author : matteo.vesc...@yahoo.co.uk 
URL : http://presage.sourceforge.net/ 
License : GPL-2 
Section : devel 

It builds those binary packages: 

gprompter  - intelligent predictive GTK+ text editor 
prompter-dbg - intelligent predictive GTK+ text editor (debugging symbols) 
libpresage-data - intelligent predictive text entry platform (data files) 
libpresage-dev - intelligent predictive text entry platform (development files) 
libpresage-doc - intelligent predictive text entry platform (documentation) 
libpresage1-dbg - intelligent predictive text entry platform (shared library 
debugg 
libpresage1v5 - intelligent predictive text entry platform (shared library) 
presage- intelligent predictive text entry platform (tools and demos) 
presage-dbg - intelligent predictive text entry platform (tools debugging symbo 
presage-dbus - intelligent predictive text entry platform (D-Bus service) 
pyprompter - intelligent predictive wxPython text editor 
python-presage - intelligent predictive text entry platform (Python binding) 
python-presage-dbg - intelligent predictive text entry platform (Python binding 
debugg 

To access further information about this package, please visit the following 
URL: 

http://mentors.debian.net/package/presage 


Alternatively, one can download the package with dget using this command: 

dget -x 
http://mentors.debian.net/debian/pool/main/p/presage/presage_0.9.1-2.dsc 

More information about hello can be obtained from http://www.example.com. 

Changes since the last upload: 

* Depend on swig instead of swig2.0 (Closes: #816999) 
* Fix lintian error in libpresage1v5.symbols file 
symbols-file-contains-current-version-with-debian-revision. 
* Fix lintian warning command-in-menu-file-and-desktop-file. 
* Reorder link library flags for gprompter (Closes: #776720) 
* Update to latest policy. 
* Fix vcs-field-uses-insecure-uri lintian info check. 


Regards, 
Matteo Vescovi

Bug#818622: marked as done (RFS: r-cran-r6/2.1.2-1 [ITP])

2016-03-20 Thread Debian Bug Tracking System 
Your message dated Sun, 20 Mar 2016 11:35:35 +
with message-id <20160320113535.gg32...@chase.mapreri.org>
and subject line Re: Bug#818622: RFS: r-cran-r6/2.1.2-1
has caused the Debian Bug report #818622,
regarding RFS: r-cran-r6/2.1.2-1 [ITP]
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
818622: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818622
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "r-cran-r6"

 * Package name: r-cran-r6
   Version : 2.1.2-1
   Upstream Author : Winston Chang 
 * URL : https://github.com/wch/R6
 * License : MIT
   Section : gnu-r

  It builds those binary packages:

r-cran-r6  - R classes with reference semantics

  To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/r-cran-r6


  Alternatively, one can download the package with dget using this command:

dget -x
http://mentors.debian.net/debian/pool/main/r/r-cran-r6/r-cran-r6_2.1.2-1.dsc


  Regards,
   Gordon Ball
--- End Message ---
--- Begin Message ---
On Sun, Mar 20, 2016 at 11:23:34AM +0100, Gordon Ball wrote:
> Yes, it seemed best to be consistent with the rest of the r- ecosystem.

yes indeed.

> > though, you wrote that this packages uses the MIT license (though
> > you maybe want "Expat" instead), except for citing the MIT license
> > in the DESCRPTION file, I can't find any copy of the license
> > itself.  This is actually a violation of the MIT. Please clarify 1)
> > how you could know upstream intended *that* MIT license (there are
> > several, you reported the most common one called Expat) 2) really
> > upstream needs to ship one copy of it.
> > 
> 
> The R extension manual [1], section 1.1.2, gives a list of accepted
> short license names (including "MIT") and indicates they refer to the
> copies on the R licensing page [2]. This gives MIT/Expat in template
> form [3]. The text in d/copyright should be a copy of [3] starting
> from "Permission". Admittedly that file does indicate that a copy
> should have been included as the LICENSE file, but I think that
> following the R manual to deduce this is the correct form of the
> license is valid.
> 
> Is the contents of LICENSE a blocker until and unless upstream changes
> this, or can the intent be taken as sufficiently clear?
> 
> 
> [1]: https://cran.r-project.org/doc/manuals/r-release/R-exts.html
> [2]: https://www.r-project.org/Licenses/
> [3]: https://www.r-project.org/Licenses/MIT

that looks just wrong to me :(

I've never thought
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
could be interpreted in some other ways.  Or is that "shall" is not
strong enough?

If I did my query within codesearch.debian.net right there are 11 source
packages in the very same situation.

Given this, I think I'm going to ignore the problem for the next hours,
and then I'll send an email to debian-legal, as it looks just wrong to
me.  Besides, *I think* we are actually complying to the MIT terms since
/usr/share/doc//copyright.gz will contain the text for the binary
distribution and debian/copyright for the source distribution, so this
is not a huge deal for debian anyway, *I think*.  IANAL


So, I uploaded this.

Please, stage a Standards-Version bump for the next upload, sort the
build-deps and fix extra-license-file (that was the only thing I'd have
to say, so I didn't hold the upload).

For the other 2 packages: I had some other remarks other than such
simple ones, please address them.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature
--- End Message ---

Bug#818622: RFS: r-cran-r6/2.1.2-1

2016-03-20 Thread Gordon Ball 
On 20/03/16 06:02, Mattia Rizzolo wrote:
> control: tag -1 moreinfo control: owner -1 !
> 
> On Fri, Mar 18, 2016 at 08:47:27PM +0100, Gordon Ball wrote:
>> I am looking for a sponsor for my package "r-cran-r6"
> 
> here we go :)
> 
Thank you for taking the time to look at these packages.

>> * Package name: r-cran-r6 Version : 2.1.2-1 Upstream
>> Author : Winston Chang  * URL :
>> https://github.com/wch/R6 * License : MIT Section
>> : gnu-r
>> 
>> http://mentors.debian.net/debian/pool/main/r/r-cran-r6/r-cran-r6_2.1.2-1.dsc
>
>> 
> well, it looks good (even if it uses CDBS which I don't like, but I
> know there is the well-maintained r-base-dev that works pretty well
> for R).

Yes, it seemed best to be consistent with the rest of the r- ecosystem.
> 
> though, you wrote that this packages uses the MIT license (though
> you maybe want "Expat" instead), except for citing the MIT license
> in the DESCRPTION file, I can't find any copy of the license
> itself.  This is actually a violation of the MIT. Please clarify 1)
> how you could know upstream intended *that* MIT license (there are
> several, you reported the most common one called Expat) 2) really
> upstream needs to ship one copy of it.
> 

The R extension manual [1], section 1.1.2, gives a list of accepted
short license names (including "MIT") and indicates they refer to the
copies on the R licensing page [2]. This gives MIT/Expat in template
form [3]. The text in d/copyright should be a copy of [3] starting
from "Permission". Admittedly that file does indicate that a copy
should have been included as the LICENSE file, but I think that
following the R manual to deduce this is the correct form of the
license is valid.

Is the contents of LICENSE a blocker until and unless upstream changes
this, or can the intent be taken as sufficiently clear?


[1]: https://cran.r-project.org/doc/manuals/r-release/R-exts.html
[2]: https://www.r-project.org/Licenses/
[3]: https://www.r-project.org/Licenses/MIT

Bug#817865: RFS: acmetool/0.0.49 [ITP] -- automatic certificate acquisition tool for Let's Encrypt

2016-03-20 Thread Peter Colberg 
Hi Dmitry,

Seeing that you have sponsored an impressive number of golang-*
packages, would you be willing to sponsor the initial upload of
acmetool [1] and its dependencies?

[1] https://bugs.debian.org/817865

The tool is promising to be useful to many Debian users that seek a
robust, but managed alternative to the official Let’s Encrypt python
client for obtaining TLS certificates for their servers.

Regards,
Peter

Bug#818724: marked as done (RFS: task-spooler/0.7.6-1)

2016-03-20 Thread Debian Bug Tracking System 
Your message dated Sun, 20 Mar 2016 09:53:06 +
with message-id <20160320095306.ge32...@chase.mapreri.org>
and subject line Re: Bug#818724: RFS: task-spooler/0.7.6-1
has caused the Debian Bug report #818724,
regarding RFS: task-spooler/0.7.6-1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
818724: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818724
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: normal


Dear mentors,

I am looking for a sponsor for my package "task-spooler"

 * Package name: task-spooler
   Version : 0.7.6-1
   Upstream Author : Lluís Batlle i Rossel 
 * URL : http://vicerveza.homeunix.net/~viric/soft/ts/
 * License : GPLv2+
   Section : misc

It builds those binary packages:

  task-spooler - personal job scheduler

To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/task-spooler

Alternatively, one can download the package with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/main/t/task-spooler/task-spooler_0.7.6-1.dsc

Changes since the last upload:

   * Imported Upstream version 0.7.6
   * Update patches
   * Bump standards version to 3.9.7
   * Use https for VCS-* fields
   * Fix typo as suggested by lintian

Regards,
   Alexander Inyukhin
--- End Message ---
--- Begin Message ---
On Sun, Mar 20, 2016 at 12:04:12PM +0300, Alexander Inyukhin wrote:
> On Sun, Mar 20, 2016 at 05:40:59AM +, Mattia Rizzolo wrote:
> > though you got Vcs-Git wrong, you can't use /cgit/ to clone.
> 
> I had checked this before upload, and it worked.

umh, this must be a fairly recent addition, then.
Sure, it doesn't help making thing less confusing, I'm certain it wasn't
possible some time ago.

I'd really love if the alioth admins could announce once again a
canonical URL.

> All of these patches are not applied by upstream.
> Some of them were forwarded before.
> 
> I sent relevant patches again and update headers.

:(
let's hope they're incorporated...

> > also, about d/copyright: I assume some years should be bumped, and I see
> > this weird diff from the previous upload:
> > 
> > - This package is free software; you can redistribute it and/or modify
> > - it under the terms of the GNU General Public License as published by
> > - the Free Software Foundation; version 2 of the License.
> > + This program is free software; you can redistribute it and/or
> > + modify it under the terms of the GNU General Public License
> > + as published by the Free Software Foundation.
> > 
> > why does it loses the version??
> 
> How do you generate that diff?

I just run debdiff against the version in the archive.
I'm not doing this RFS out of the git repository, but using mentors.d.n.

> There is a some kind of uncertainty about the license.
> The source code contains text of GPL-2 license without
> explicit license grant, but the site claims GPL2+ for that code.
> 
> A discussion about the previous upload is here:
> https://bugs.debian.org/cgi-bin/bugreport.ci?bug=781523
> https://lists.debian.org/debian-legal/2015/05/msg1.html
> 
> So, in the previous upload license version is changed from GPL2+ to GPL2.

yes, I see, that's also how I'd have interpreted it.

> I am not sure about that version number thing, though.

I don't know how you lost it ;)

> > and btw, having debian/* GPL-2+ technically makes upstream unable to
> > pull patches from debian/patches/*, as GPL-2+ is incompatible with
> > GPL-2 (only).
> 
> Isn't that a one-way incompatibility?
> As far as I understand, GPL2+ is a set of licenses including GPL2,
> so GPL2+ code could be used in GPL2-only project.

oops.
I messed this up :(

Who knows what I was thinking about (maybe the coffee I had yet to
have).  taking GPL-2+ code into a GPL-2-only project it fine, just that
the included code will have to follow GPL-2 terms, and can't take
advantage of later versions (basically, the result is a GPL-2-only
work).

> Anyway, I do not want to restrict use of these patches.
> What license should I use?

it's fine, sorry for the noise.

> I have uploaded a fixed package.
> Thanks for review!

nevermind my troubles with GPL-2/GPL-2+ before, maybe it was just too
early in the morning :(

I uploaded it :)
sorry again for causing non-existant concerns...

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad use

Bug#816004: RFS: [ITP] python-nameparser/0.3.11-1

2016-03-20 Thread Edward Betts 
Mattia Rizzolo  wrote:
> control: owner -1 !
> control: tag -1 moreinfo
> 
> On Fri, Feb 26, 2016 at 03:34:02PM +, Edward Betts wrote:
> > I am looking for a sponsor for my package "python-nameparser"
> 
> ay.

Thanks for reviewing my package.

> * debian/changelog:
>   + you are closing two bugs; don't.
> As the automated email from bartm (that definitely reached you, so
> I'm wondering why yuo haven't done so yet) on #815972 says: "Please
> retitle bug 735611 from RFP to ITP and set yourself as the owner."
> After having done so, please remove #815972 from the changelog.

You're absolutely right. I realized this was wrong and made this change, but
I'd failed to upload a new version to mentors. This is now done. I've retitled
the bug and updated the owner.

> * dist/*:
>   + why on the earth is that directory filled with tarballs of old
> releases?  Please ask upstream to stop shipping such tarballs, or
> (maybe better), why not using the tarballs he's providing on pypi,
> which seem to be nicer?
> In that case please use http://pypi.debian.net/nameparser/watch

The tarball uploaded to pypi is missing the unit tests. These seems to be a
common problem with Python modules. The upstream developer feels like the
tests are only needed by people working on the code, not for the end user.
I think it is useful to run the tests when the Debian package is built and
possible have autopkgtest run the tests as well.

I will write to the upstream author and attempt to convince them that the
tests should be included in the pypi tarball. I tried this for the
django-jinja package, but upstream wasn't interested. Do you have any other
ideas, is there a way I could build the package from the pypi but included the
tests which are only in github?

> There is also a newer upstream, please package that.

Will do.

Thanks again,
-- 
Edward.

Bug#818724: RFS: task-spooler/0.7.6-1

2016-03-20 Thread Alexander Inyukhin 
On Sun, Mar 20, 2016 at 05:40:59AM +, Mattia Rizzolo wrote:
> control: tag -1 moreinfo
> control: owner -1 !
> 
> On Sun, Mar 20, 2016 at 07:59:35AM +0300, Alexander Inyukhin wrote:
> > I am looking for a sponsor for my package "task-spooler"
> 
> sure thing :)
> 
> >   dget -x 
> > http://mentors.debian.net/debian/pool/main/t/task-spooler/task-spooler_0.7.6-1.dsc
> > 
> > Changes since the last upload:
> > 
> >* Imported Upstream version 0.7.6
> >* Update patches
> >* Bump standards version to 3.9.7
> >* Use https for VCS-* fields
> 
> though you got Vcs-Git wrong, you can't use /cgit/ to clone.

I had checked this before upload, and it worked.

> I suggest you just use /git/ for both fields, which has been valid for a
> bit more than a month.

Ok. Fixed that.

> >* Fix typo as suggested by lintian
> 
> I see there patches with Last-Update: 2012, both marked as "Forwarded:
> yes" and without Forwarded header.  I wonder, since 2012 it has not been
> applied?? (particularly weird for cppcheck.patch).
> Also, note that the Forwarded field should either be "no", "not-needed"
> or some pointers to where it has been forwarded (like a url to some bug
> thing).

All of these patches are not applied by upstream.
Some of them were forwarded before.

I sent relevant patches again and update headers.

> also, about d/copyright: I assume some years should be bumped, and I see
> this weird diff from the previous upload:
> 
> - This package is free software; you can redistribute it and/or modify
> - it under the terms of the GNU General Public License as published by
> - the Free Software Foundation; version 2 of the License.
> + This program is free software; you can redistribute it and/or
> + modify it under the terms of the GNU General Public License
> + as published by the Free Software Foundation.
> 
> why does it loses the version??

How do you generate that diff?

There is a some kind of uncertainty about the license.
The source code contains text of GPL-2 license without
explicit license grant, but the site claims GPL2+ for that code.

A discussion about the previous upload is here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781523
https://lists.debian.org/debian-legal/2015/05/msg1.html

So, in the previous upload license version is changed from GPL2+ to GPL2.
I am not sure about that version number thing, though.

Fixed that.

> Without considering that those copyright changes are not documented in
> d/copyright.
> 
> and btw, having debian/* GPL-2+ technically makes upstream unable to
> pull patches from debian/patches/*, as GPL-2+ is incompatible with
> GPL-2 (only).

Isn't that a one-way incompatibility?
As far as I understand, GPL2+ is a set of licenses including GPL2,
so GPL2+ code could be used in GPL2-only project.

Anyway, I do not want to restrict use of these patches.
What license should I use?



I have uploaded a fixed package.
Thanks for review!

Bug#818735: RFS: qwtplot3d/0.2.7+svn191-10

2016-03-20 Thread Mattia Rizzolo 
control: tag -1 moreinfo
control: owner -1 !

On Sun, Mar 20, 2016 at 09:55:55AM +0100, Gudjon I. Gudjonsson wrote:
> dget -x 
> http://mentors.debian.net/debian/pool/main/q/qwtplot3d/qwtplot3d_0.2.7+svn191-10.dsc
> 
> Changes since the last upload:
> 
>   * Disable architectures armel and armhf. It doesn't compile
> on these architectures because of opengl problems.

* you're using any-amd64 and any-i386, then why do you explicitly list
  hurd-i386 kfreebsd-amd64 kfreebsd-i386 too?
* you're changing only one binary, what about the others?  from what I'm
  seeing the failure is in the configure step which is done by all
  binaries, so this change wouldn't fix the FTBFS)
* why are you not closing the bug?
* do you know that to allow the testing migration you'd still need to
  remove the binaries from unstable by filing a bug against
  ftp.debian.org?  actually that would be enough, even without
  restricting the architecures where you build, then you can leave the
  packages in FTBFS state there until it could build again.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#816004: RFS: [ITP] python-nameparser/0.3.11-1

2016-03-20 Thread Mattia Rizzolo 
On Sun, Mar 20, 2016 at 08:35:13AM +, Edward Betts wrote:
> Mattia Rizzolo  wrote:
> > * dist/*:
> >   + why on the earth is that directory filled with tarballs of old
> > releases?  Please ask upstream to stop shipping such tarballs, or
> > (maybe better), why not using the tarballs he's providing on pypi,
> > which seem to be nicer?
> > In that case please use http://pypi.debian.net/nameparser/watch
> 
> The tarball uploaded to pypi is missing the unit tests. These seems to be a
> common problem with Python modules.

yes it is.  Indeed I've not noticed the testsuite was missing in the
tarball on pypi.

> The upstream developer feels like the
> tests are only needed by people working on the code, not for the end user.

:(

> I think it is useful to run the tests when the Debian package is built and
> possible have autopkgtest run the tests as well.

Yes, it's actually important, I'd say.
Given that the dependencies of packages changes fairly often, as does
the python version used, it's not uncommon that tests start to fail out
of a suddent, and it's usually a symptom of something broken.

> I will write to the upstream author and attempt to convince them that the
> tests should be included in the pypi tarball. I tried this for the
> django-jinja package, but upstream wasn't interested. Do you have any other
> ideas, is there a way I could build the package from the pypi but included the
> tests which are only in github?

There is, you could use the multi-tarball feature of source format 3.0,
but it's a pain to use, and there is no nice way to keep everything in
git, IOW: don't use it unless you really need to, and this is not the
case.

Given that what I'm mainly complaining here is the presence of all those
old releases compressed inside dist/* that I can't figure what they are
for, have you tried asking upstream to just delete them?

otherwise, imho this is a good case for repacking the tarball using a
version with +ds.

To be clear, the main problem with those tarballs is that I'm (and you
too, and ftpmasters are too) supposed to unpack all of them and check if
all the files in all of them are free.  Not to say that it is a complate
waste of space...
-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#818735: RFS: qwtplot3d/0.2.7+svn191-10

2016-03-20 Thread Gudjon I. Gudjonsson 
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "qwtplot3d"

 * Package name: qwtplot3d
   Version : 0.2.7+svn191-10
   Upstream Author : Michael Bieber
 * URL  : http://qwtplot3d.sourceforge.net
 * License: GPL-2, GL1PS-2
   Section : libs

It builds those binary packages:

libqwtplot3d-doc - 3D plotting library based on Qt/OpenGL (documentation)
libqwtplot3d-qt4-0v5 - 3D plotting library based on Qt4/OpenGL (runtime)
libqwtplot3d-qt4-dev - 3D plotting library based on Qt4/OpenGL (development)
libqwtplot3d-qt5-0 - 3D plotting library based on Qt5/OpenGL (runtime)
libqwtplot3d-qt5-dev - 3D plotting library based on Qt5/OpenGL (development)

To access further information about this package, please visit the following 
URL:

http://mentors.debian.net/package/qwtplot3d

Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/q/qwtplot3d/qwtplot3d_0.2.7+svn191-10.dsc

Changes since the last upload:

  * Disable architectures armel and armhf. It doesn't compile
on these architectures because of opengl problems.

Regards,
Gudjon I. Gudjonsson

Bug#817961: RFS: awesfx/0.5.1e-1 [RC] [ITA]

2016-03-20 Thread Mattia Rizzolo 
control: tag -1 moreinfo
control: owner -1 !

On Sat, Mar 12, 2016 at 07:56:07AM +0300, Dmitry Eremin-Solenikov wrote:
> Current maintainer of awesfx (Ove Kaaven) asked to consider him MIA, so I'm 
> adopting
> the package.

where asked todo so?
I can see how he is not active, but I'd like to read something about it.

>   * List myself as an uploader.

* please drop this last line from the changelog, as there is already
  "New maintainer"
* please drop debian/dirs, looking at it seems useless
* please bump standards-version to 3.9.7
* please document more stuff in the changelog:
  + DEP-5 copyright
  + patch to fix typos
  + source format 3.0 (quilt)
  + new watch file
  + rules file rewritten using dh(1) (that's not implied by the new
compat level)
* what about using dh-autoreconf instead of autotools-dev?
  see wiki.d.o/Autoreconf.  Also, you should be aware that newer
  debhelper does the very same thing autotools-dev does.

For the rest it looks good, just please check whether some more bugs can
be closed.

I'm more interested in having a proof the current maintainer ACKed the
takeover.
-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature