Bug#791463: closing RFS: udfclient/0.8-1 [ITP] -- userland implementation of the UDF filesystem

2015-12-11 Thread Gianfranco Costamagna
Hi Pali, can you please reupload?

Andrew are you still interested in looking at it?

cheers,

G.


>Hi Gianfranco, I did not updated package because I did not know that

>some step is needed to do. My last uploaded version worked and I thought
>that it was OK.



Lintian leaves me with error when Build-Depending from qt5-default :-( (Was: C++ / Qt help for Ugene needed)

2015-12-11 Thread Andreas Tille
Hi,

On Thu, Dec 10, 2015 at 08:28:36PM +0100, Gert Wollny wrote:
> On Thu, 2015-12-10 at 14:07 +0100, Andreas Tille wrote:
> > I'd be really delighted if you get this built!
> 
> It should build now, at least here it just did in an freshly updated
> pbuilder environment. 

Thanks to Gert's and Gianfranco's help I made quite some progress.  Currenly
I'm left with a riddle about the role of qt5-default which is a metapackage
and lintian throws an error when Build-Depending from a metapackage.  So I
thought that would be simple and made sure that ugene would Build-Depend
from all of qt5-default's Dependencies which are

   qtbase5-dev, qtchooser

Since qtbase5-dev is in the Build-Depends anyway I simply did

   s/qt5-default/qtchooser/

in the current status of Git ... and ended up in:


...
dh_auto_configure -- UGENE_WITHOUT_NON_FREE=1
qmake -makefile -nocache "QMAKE_CFLAGS_RELEASE=-g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 
-D_FORTIFY_SOURCE=2" "QMAKE_CFLAGS_DEBUG=-g -O2 -fstack-protector-strong 
-Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2" 
"QMAKE_CXXFLAGS_RELEASE=-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2" 
"QMAKE_CXXFLAGS_DEBUG=-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2" 
QMAKE_LFLAGS_RELEASE=-Wl,-z,relro QMAKE_LFLAGS_DEBUG=-Wl,-z,relro QMAKE_STRIP=: 
PREFIX=/usr UGENE_WITHOUT_NON_FREE=1
qmake: could not find a Qt installation of ''
dh_auto_configure: qmake -makefile -nocache QMAKE_CFLAGS_RELEASE=-g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 
-D_FORTIFY_SOURCE=2 QMAKE_CFLAGS_DEBUG=-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 
QMAKE_CXXFLAGS_RELEASE=-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 
QMAKE_CXXFLAGS_DEBUG=-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 
QMAKE_LFLAGS_RELEASE=-Wl,-z,relro QMAKE_LFLAGS_DEBUG=-Wl,-z,relro QMAKE_STRIP=: 
PREFIX=/usr UGENE_WITHOUT_NON_FREE=1 returned exit code 1
debian/rules:21: recipe for target 'override_dh_auto_configure' failed
make[1]: *** [override_dh_auto_configure] Error 2
make[1]: Leaving directory '/build/ugene-1.19.0+dfsg'


So what else might qt5-default do besides installing dependencies
to make qmake happy?  Should I simply override the lintian error?

Kind regards

Andreas.

-- 
http://fam-tille.de



Bug#791463: closing RFS: udfclient/0.8-1 [ITP] -- userland implementation of the UDF filesystem

2015-12-11 Thread Pali Rohár
On Wednesday 09 December 2015 18:05:29 Gianfranco Costamagna wrote:
> On Wed, 09 Dec 2015 16:40:21 + Bart Martens
>  wrote:
> > Package udfclient has been removed from mentors.
> > 
> > 
> Hi Pali, did you forget to update the package?
> 
> cheers,
> 
> G.
> 

Hi Gianfranco, I did not updated package because I did not know that
some step is needed to do. My last uploaded version worked and I thought
that it was OK.

-- 
Pali Rohár
pali.ro...@gmail.com



Bug#807099: RFS: corsix-th/0.50-1 ITP 610087 - A Theme Hospital engine reimplementation.

2015-12-11 Thread Alexandre Detiste
Le dimanche 6 décembre 2015, 20:34:42 Markus Koschany a écrit :
> Several Expat copyright holder are missing in
> CorsixTH/Lua/languages
> CorsixTH/Src/jit_opt.h
> SpriteEncoder/*
> LevelEdit/*
> 
> GPL-3+
> SpriteEncoder/parser.cpp
> SpriteEncoder/tokens.h

This license has this special exception; does this mean
it can be considered Expat-licensed as the whole game ?

   As a special exception, you may create a larger work that contains
   part or all of the Bison parser skeleton and distribute that work
   under terms of your choice

> 
> zlib:
> WindowsInstaller/ReplaceInFile.nsh


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


DNS fails in pbuilder

2015-12-11 Thread Andreas Tille
Hi,

since one week I'm observing that when moving to different networks
pbuilder fails to resolve any host names.  I was able to cure it by
copying my local /etc/resolv.conf to
/var/cache/pbuilder/base.cow/etc/resolv.conf but in principle I do
not even understand how this could have worked before without any
such tricks in changing network environments.

Any clue how this worked and how I can get it working again?

I tried pbuilder 0.221.1 from testing and 0.221.3 from unstable.

Kind regards

 Andreas.

-- 
http://fam-tille.de



Re: Lintian leaves me with error when Build-Depending from qt5-default :-( (Was: C++ / Qt help for Ugene needed)

2015-12-11 Thread Jakub Wilk

* Andreas Tille , 2015-12-11, 13:29:
Currenly I'm left with a riddle about the role of qt5-default which is 
a metapackage and lintian throws an error when Build-Depending from a 
metapackage.


If you have a question or doubts about Lintian output, please aways 
quote what Lintian said exactly.


Anyway, contrary to what Lintian might have said, qt5-default is not a 
metapackage. From the package description:


This package sets Qt 5 to be the default Qt version to be used when 
using development binaries like qmake. It provides a default 
configuration for qtchooser, but does not prevent alternative Qt 
installations from being used.


This package should not be used for building Debian packages. Take a 
look at http://pkg-kde.alioth.debian.org/packagingqtstuff.html for more 
information.


--
Jakub Wilk



Bug#791463: closing RFS: udfclient/0.8-1 [ITP] -- userland implementation of the UDF filesystem

2015-12-11 Thread Andrew Shadura
On 11 December 2015 at 12:58, Gianfranco Costamagna
 wrote:
> Hi Pali, can you please reupload?
>
> Andrew are you still interested in looking at it?

Gianfranco, if you wish to sponsor it, please go ahead. And please
make sure Pali uses the feature of bmake package I developed for his
specific use case ;)

-- 
Cheers,
  Andrew



Re: Lintian leaves me with error when Build-Depending from qt5-default :-( (Was: C++ / Qt help for Ugene needed)

2015-12-11 Thread Gianfranco Costamagna
Hi again,





>Thanks to Gert's and Gianfranco's help I made quite some progress.  Currenly
>I'm left with a riddle about the role of qt5-default which is a metapackage
>and lintian throws an error when Build-Depending from a metapackage.  So I
>thought that would be simple and made sure that ugene would Build-Depend
>from all of qt5-default's Dependencies which are
>
>   qtbase5-dev, qtchooser
>
>Since qtbase5-dev is in the Build-Depends anyway I simply did
>
>   s/qt5-default/qtchooser/
>
>in the current status of Git ... and ended up in:


>So what else might qt5-default do besides installing dependencies
>to make qmake happy?  Should I simply override the lintian error?


I told you in the last mail all the dependencies needed.


https://sources.debian.net/src/qviaggiatreno/2013.7.3-8/debian/rules/
just an
export QT_SELECT=5
in rules should do the trick.

cheers,

G.



Re: guitarix package in debian

2015-12-11 Thread Ross Gammon
Hi Hermann,

On 12/08/2015 09:59 AM, Hermann Meyer wrote:
> Hello
> 
> I'm the upstream maintainer of the guitarix project, and I've noticed
> that guitarix is marked as autoremoval in debian/testing because of this
> bug:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805666
> 
> The bug mentioned above is fixed in upstream since some time, as I'm
> myself been a debian/sid user.
> 
> I've tried to reach the debian maintainer (Roland Stigge) of the
> guitarix project for some time now, to no avail.
> To avoid the removal, just a new upload of the latest version is needed,
> so I like to ask here, if someone her could do that?

Thanks for helping to take care of guitarix in Debian as well as upstream.

I see on the bug you have correctly tagged it as fixed upstream.

Unfortunately, it sometimes happens that a maintainer goes missing (most
of the time only temporarily). But it is not cool to just take over and
upload a new version.
There is some information here about maintainers that are missing in action:
https://wiki.debian.org/Teams/MIA

As upstream, you could further help by adding a link in the Debian BTS
to the upstream commit that fixes the bug, or attach a patch.

Then someone could more easily do a Non Maintainer Upload (NMU) to keep
guitarix in debian testing (or get it back there after removal).

Regards,

Ross



signature.asc
Description: OpenPGP digital signature


Bug#791463: closing RFS: udfclient/0.8-1 [ITP] -- userland implementation of the UDF filesystem

2015-12-11 Thread Gianfranco Costamagna

Hi Andrew,

>Gianfranco, if you wish to sponsor it, please go ahead. And please
>make sure Pali uses the feature of bmake package I developed for his
>specific use case ;)


I'm not a bmake-savvy person, I don't think I'll be able to check if the 
packaging
is really error prone...

cheers,

G.



Re: DNS fails in pbuilder

2015-12-11 Thread Mattia Rizzolo
On Fri, Dec 11, 2015 at 02:04:04PM +0100, Andreas Tille wrote:
> Hi,
> 
> since one week I'm observing that when moving to different networks
> pbuilder fails to resolve any host names.  I was able to cure it by
> copying my local /etc/resolv.conf to
> /var/cache/pbuilder/base.cow/etc/resolv.conf but in principle I do
> not even understand how this could have worked before without any
> such tricks in changing network environments.

I broke it with 0.221, https://bugs.debian.org

> Any clue how this worked and how I can get it working again?
> 
> I tried pbuilder 0.221.1 from testing and 0.221.3 from unstable.

Should be fixed by 0.221.2, are you sure it's still broken, because
several people confirmed me it's fixed...

-- 
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#807099: RFS: corsix-th/0.50-1 ITP 610087 - A Theme Hospital engine reimplementation.

2015-12-11 Thread Markus Koschany
Am 11.12.2015 um 12:35 schrieb Alexandre Detiste:
> Le dimanche 6 décembre 2015, 20:34:42 Markus Koschany a écrit :
>> Several Expat copyright holder are missing in
>> CorsixTH/Lua/languages
>> CorsixTH/Src/jit_opt.h
>> SpriteEncoder/*
>> LevelEdit/*
>>
>> GPL-3+
>> SpriteEncoder/parser.cpp
>> SpriteEncoder/tokens.h
> 
> This license has this special exception; does this mean
> it can be considered Expat-licensed as the whole game ?
> 
>As a special exception, you may create a larger work that contains
>part or all of the Bison parser skeleton and distribute that work
>under terms of your choice

I would add the following paragraph to debian/copyright to avoid any
confusion.

License: GPL-3+-with-exception
 On Debian systems, the complete text of the GNU General Public License
 version 3 can be found in `/usr/share/common-licenses/GPL-3'.
 .
 As a special exception, you may create a larger work that contains
 part or all of the Bison parser skeleton and distribute that work
 under terms of your choice, so long as that work isn't itself a
 parser generator using the skeleton or a modified version thereof
 as a parser skeleton.  Alternatively, if you modify or redistribute
 the parser skeleton itself, you may (at your option) remove this
 special exception, which will cause the skeleton and the resulting
 Bison output files to be licensed under the GNU General Public
 License without this special exception.

Bonus points if these files are generated automatically during the build.

Markus




signature.asc
Description: OpenPGP digital signature


Bug#807626: RFS: taskwarrior/2.5.0+dfsg-1

2015-12-11 Thread Tobias Frost
Control: owner -1 !

Am Freitag, den 11.12.2015, 02:50 +0100 schrieb Sebastien Badia:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "taskwarrior"
> 
> * Package name: taskwarrior
>   Version : 2.5.0+dfsg-1
>   Upstream Author : Paul Beckingham 
> * URL : http://taskwarrior.org
> * License : MIT
>   Section : utils
> 
> It builds those binary packages:
> 
>   task - feature-rich console based todo list manager
> 
> To access further information about this package, please visit the
> following URL:
> 
>  http://mentors.debian.net/package/task
> 
> Alternatively, one can download the package with dget using this
> command:
> 
>   dget -x http://mentors.debian.net/debian/pool/main/t/task/task_2.5


Bug#807627: RFS: taskd/1.1.0+dfsg-1 [ITP]

2015-12-11 Thread Tobias Frost
Control: owner -1 !

Am Freitag, den 11.12.2015, 02:51 +0100 schrieb Sebastien Badia:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "taskd"
> 
> * Package name: taskd
>   Version : 1.1.0+dfsg-1
>   Upstream Author : Paul Beckingham 
> * URL : http://taskwarrior.org
> * License : MIT
>   Section : utils
> 
> It builds those binary packages:
> 
>   taskd - Synchronisation server for taskwarrior
> 
> To access further information about this package, please visit the
> following URL:
> 
>  http://mentors.debian.net/package/taskd
> 
> Alternatively, one can download the package with dget using this
> command:
> 
>   dget -x http://mentors.debian.net/debian/pool/main/t/taskd/taskd_1


Bug#791463: closing RFS: udfclient/0.8-1 [ITP] -- userland implementation of the UDF filesystem

2015-12-11 Thread Pali Rohár
Now I uploaded my last version of udfclient to mentors again.

But I did not used bmake for two reasons:

1) I have older Debian and Ubuntu systems which do not support bmake, so 
cannot test or use that package

2) It needs to patch original tarball, my debian/rules file is also 
short and does not need to patch software just for compilation

-- 
Pali Rohár
pali.ro...@gmail.com


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


Bug#791463: closing RFS: udfclient/0.8-1 [ITP] -- userland implementation of the UDF filesystem

2015-12-11 Thread Andrew Shadura
On 11 December 2015 at 18:01, Pali Rohár  wrote:
> Now I uploaded my last version of udfclient to mentors again.
>
> But I did not used bmake for two reasons:
>
> 1) I have older Debian and Ubuntu systems which do not support bmake, so
> cannot test or use that package
>
> 2) It needs to patch original tarball, my debian/rules file is also
> short and does not need to patch software just for compilation

Please install the latest bmake and use it (you have to build and test
your package on unstable anyway!), and it's not a big deal to patch
the Makefile after all, you just dropping the patch into the right
place.

-- 
Cheers,
  Andrew



Re: guitarix package in debian

2015-12-11 Thread Hermann Meyer



Am 11.12.2015 um 14:56 schrieb Ross Gammon:

Hi Hermann,

On 12/08/2015 09:59 AM, Hermann Meyer wrote:

Hello

I'm the upstream maintainer of the guitarix project, and I've noticed
that guitarix is marked as autoremoval in debian/testing because of this
bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805666

The bug mentioned above is fixed in upstream since some time, as I'm
myself been a debian/sid user.

I've tried to reach the debian maintainer (Roland Stigge) of the
guitarix project for some time now, to no avail.
To avoid the removal, just a new upload of the latest version is needed,
so I like to ask here, if someone her could do that?

Thanks for helping to take care of guitarix in Debian as well as upstream.

I see on the bug you have correctly tagged it as fixed upstream.

Unfortunately, it sometimes happens that a maintainer goes missing (most
of the time only temporarily). But it is not cool to just take over and
upload a new version.
There is some information here about maintainers that are missing in action:
https://wiki.debian.org/Teams/MIA

As upstream, you could further help by adding a link in the Debian BTS
to the upstream commit that fixes the bug, or attach a patch.

Then someone could more easily do a Non Maintainer Upload (NMU) to keep
guitarix in debian testing (or get it back there after removal).

Regards,

Ross



Thanks for your response Ross

Well, indeed what I would like to ask here was a Non Maintainer Upload.
I ain't looking for someone to take over the debian maintenance for 
guitarix,

but just help out by a single upload of the latest version.
I've had all the time a good contact to Roland and
I'm pretty sure that Roland would be fine with a NMU.
Just I wonder why I couldn't reach Roland in the last couple of month,
so I decide to take some action, to force a update of guitarix in debian.
I would love to have the latest version in debian/sid, instead only the 
fixes.

There are a couple of other bug-fixes included in the latest version,
which never get reported to debian, so a update to the last stable version
would be the best solution.

regards
hermann







Bug#804390: RFS: 9wm/1.3.4-1 [ITA]

2015-12-11 Thread Jacob Adams

On 12/06/2015 09:05 AM, Mattia Rizzolo wrote:
> control: owner -1 !
> control: tag -1 + moreinfo
>
> Hi!
>
> First, please be a bit more patiente with your pings; following up only
> 5 days later is very much not helpful.
Sorry about that. I should have realized how soon it was before I pinged.
> On Wed, Nov 25, 2015 at 03:10:28PM -0500, Jacob Adams wrote:
>>   I am looking for a sponsor for my package "9wm"
>>
>>  * Package name: 9wm
>>Version : 1.3.4-1
>>Upstream Author : Neale Pickett 
>>  * URL : https://woozle.org/neale/g.cgi/x11/9wm
>>  * License : Expat
>>Section : x11
>
> The review:
>
> * trailing whitespace on debian/control:29
Fixed
> * please be a lot more verbose on the changelog.  "Redo packaging" is
>   not satisfactory at all.  Every change should be documented.
I've updated it to reflect all changes. Should I update the timestamp?
(It was generated by dch when I first made the changelog).
> * debian/patches/*: if possible a URL of the forwarded patch would be
>   nice
They've all been forwarded via email, so no urls unfortunately. I did,
however, have one unnecessary patch in there so I've removed it. I just
emailed upstream about the two patches I'm still using (The FHS one was
rejected without any reasoning as it was with a few others and simply
not applied so I've asked for a reason. The -fPIC one is new).
> * debian/rules:
>   + trailing whitespace at line 11
>   + with debhelper compat 9 exporting the build flags that way is not
> needed anymore, so lines 3-4-5 can go away
Fixed.
> * you removed the postinst and prerm with the update-alternatives calls,
>   that looks useful to me; why?
Because I did not look over the previous packaging closely enough :)
I've added them back. I've also modified them slightly to call set -e in
order to avoid a lintian warning.
> * even if you try to enable the hardening in d/rules, that doesn't work,
>   and blhc still complains (and also lintian)
I'm not sure what to do about this. Should I just have a patch that
appends $(shell dpkg-buildflags --get $VAR) for CFLAGS and LDFLAGS?
After removing the unecessary lines from d/rules the buildflags appear
to somewhat work but I've had to add a patch to compile objects with
-fPIC as otherwise I get

cc -fPIE -pie -Wl,-z,relro -Wl,-z,now  9wm.o event.o manage.o menu.o
client.o grab.o cursor.o error.o  -lXext -lX11 -o 9wm
/usr/bin/ld: 9wm.o: relocation R_X86_64_32 against `.rodata' can not be
used when making a shared object; recompile with -fPIC
9wm.o: error adding symbols: Bad value

> * From piuparts:
>   0m51.6s INFO: Running adequate version 0.12.1 now.
>   0m51.8s ERROR: WARN: Inadequate results from running adequate!
>  9wm: missing-alternative x-window-manager
>
>   0m51.8s ERROR: WARN: Running adequate resulted in inadequate tags found:  
> missing-alternative 
>   0m59.0s INFO: PASS: Installation and purging test.
>   1m1.2s INFO: apt-cache knows about the following packages: 9wm
>   1m8.3s INFO: Installation of ['tmp/9wm_1.3.4-1_amd64.deb'] ok
>   1m15.4s INFO: Running adequate version 0.12.1 now.
>   1m21.1s ERROR: WARN: Broken symlinks:
> /usr/bin/x-window-manager -> /etc/alternatives/x-window-manager
> /usr/share/man/man1/x-window-manager.1.gz -> 
> /etc/alternatives/x-window-manager.1.gz
> /etc/alternatives/x-window-manager.1.gz -> /usr/share/man/man1/9wm.1.gz
> /etc/alternatives/x-window-manager -> /usr/bin/9wm
>   1m22.9s ERROR: FAIL: Package purging left files on system:
> /etc/alternatives/x-window-manager -> /usr/bin/9wm not owned
> /etc/alternatives/x-window-manager.1.gz -> /usr/share/man/man1/9wm.1.gz   
>  not owned
> /usr/bin/x-window-manager -> /etc/alternatives/x-window-managernot 
> owned
> /usr/share/man/man1/x-window-manager.1.gz -> 
> /etc/alternatives/x-window-manager.1.gz   not owned
>
>   1m22.9s ERROR: FAIL: Installation, upgrade and purging tests.
>   1m24.3s ERROR: piuparts run ends.
All these should be fixed by the above.
>
>
> Please also triage the debian bugs:
>   + #681740 was fixed in 1.2-10
Should I just close it?
>   + #349680 not sure what to do, but sice you're becoming the maintainer
> that's your call.  probably the best course of action, given where
> the links in that bug end, is to just close the bug.
I've closed it. plan9port and 9wm are two different things.

I've uploaded a new version of 9wm to mentors.

Thanks for your help!
Jacob





signature.asc
Description: OpenPGP digital signature


Bug#807718: RFS: ethstats/1.1.0-1 (adopted upstream, refreshed packaging)

2015-12-11 Thread Peter Pentchev
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: ethstats
   Version : 1.1.0-1
   Upstream Author : Peter Pentchev 
 * URL : http://devel.ringlet.net/net/ethstats/
 * License : public domain
   Section : net

I've taken the liberty of adopting the package's upstream maintenance and
refreshing the Perl programming style, as well as adding several new
minor features and optimizations.  There is a single binary package:

  ethstats   - script that quickly measures network device throughput

It has been tested with Lintian and sbuild.

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

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

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

  dget -x 
http://mentors.debian.net/debian/pool/main/e/ethstats/ethstats_1.1.0-1.dsc

Here's the Debian changelog entry:

ethstats (1.1.0-1) unstable; urgency=medium

  * Remove the obsolete DM-Upload-Allowed source control field.
  * Switch the Vcs-* tags to my GitLab full-source repository.
  * Bump the debhelper compatibility level to 9 with no changes.
  * Declare compliance with Debian Policy 3.9.6 with no changes.
  * Use perl:Depends for the binary package.
  * Update the copyright file:
- convert it to version 1.0 of the copyright-format spec
- merge the PD paragraphs and explicitly place my changes into
  the public domain, too
- bump the year on my debian/* copyright notice
  * Use the dpkg-dev default for the Debian tarball's compression.
  * Note that I'm adopting the ethstats tool's upstream maintenance:
- add the Homepage source control field
- update the watch file
- add the upstream PGP signing key
- add an upstream metadata file
- update the upstream location in the copyright file
  * Add Multi-Arch: foreign to the binary package.
  * New upstream release from devel.ringlet.net:
- drop the 01-getopt and 02-interface patches, applied upstream
- use the upstream build system and add a build dependency on perl
  for the test suite
- use the upstream mandoc manual page and drop the build dependency
  on docbook-to-man

 -- Peter Pentchev   Fri, 11 Dec 2015 19:54:07 +0200

Thanks in advance for your time!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature


Re: Lawyer.com Referral Preference Request (121120151612497275)

2015-12-11 Thread Lawyer.com Support
Greetings Mr. Rice,

Thank you for contacting Lawyer.com.

I have validated your request and updated your free listing, please view
your updated profile here: http://www.lawyer.com/philip-robert-rice.html

If you are looking for increased online presence, and preferential access
to our Referral Service, I recommend taking a look at our Premium Membership
.

Please feel free to reach out to me with any questions, or if I can be of
assistance in any other way.


On Fri, Dec 11, 2015 at 2:33 PM, Lawyer.com Referrals <
referr...@corp.lawyer.com> wrote:

>
> -- Forwarded message --
> From: 
> Date: Fri, Dec 11, 2015 at 4:58 PM
> Subject: Lawyer.com Referral Preference Request (121120151612497275)
> To: referr...@corp.lawyer.com
>
>
>
> 
> referral areas:Traffic
>
> other practice areas:
>
> opt out:No
>
> Profile:
>
> Email:debian-mentors@lists.debian.org
>
> Member Rep:Matt Germann
>
> opt out reason:
> 
> user ip:205.197.242.171
>
> referral id: http://www.lawyer.com/ad/referral/review.php?rid=
>
>


-- 
Regards,

Lawyer.com Support






*Email advertisement sent as a service of Lawyer.com*
*25 Mountainview Boulevard, Basking Ridge, NJ  07920*
*To unsubscribe, reply to this email with your request.*


Bug#804390: RFS: 9wm/1.3.4-1 [ITA]

2015-12-11 Thread Mattia Rizzolo
On Fri, Dec 11, 2015 at 05:19:01PM -0500, Jacob Adams wrote:
> On 12/06/2015 09:05 AM, Mattia Rizzolo wrote:
> > First, please be a bit more patiente with your pings; following up only
> > 5 days later is very much not helpful.
> Sorry about that. I should have realized how soon it was before I pinged.

No worries, just be aware we (in debian, that's general) we're not used
to reply in real time or few hours or 1 day...

> > On Wed, Nov 25, 2015 at 03:10:28PM -0500, Jacob Adams wrote:
> > * trailing whitespace on debian/control:29
> Fixed

oops, there is also one in debian/control:25 (sorry)

> > * please be a lot more verbose on the changelog.  "Redo packaging" is
> >   not satisfactory at all.  Every change should be documented.
> I've updated it to reflect all changes. Should I update the timestamp?
> (It was generated by dch when I first made the changelog).

The timestamp down there is not really relevant, though you might
consider updating it right before uploading (usually I do a dummy commit
before start working on the package, keeping the distribution UNRELEASED
and an empty changelog, and at the end I do `gbp dch --auto -R`, which
also updates the timestamp.

Btw, you added 2 trailing whitespaces at line 5 and 11.
Anyway, the changelog looks nearly good to me now, see below.

> > * debian/patches/*: if possible a URL of the forwarded patch would be
> >   nice
> They've all been forwarded via email, so no urls unfortunately. I did,
> however, have one unnecessary patch in there so I've removed it. I just
> emailed upstream about the two patches I'm still using (The FHS one was
> rejected without any reasoning as it was with a few others and simply
> not applied so I've asked for a reason. The -fPIC one is new).

ok, if they where private email, then 'yes' is totally fine.

> > * debian/rules:
> >   + trailing whitespace at line 11
> >   + with debhelper compat 9 exporting the build flags that way is not
> > needed anymore, so lines 3-4-5 can go away
> Fixed.

cool!  I love how cute they look packages with that quasi-empty d/rules!

> > * you removed the postinst and prerm with the update-alternatives calls,
> >   that looks useful to me; why?
> Because I did not look over the previous packaging closely enough :)
> I've added them back. I've also modified them slightly to call set -e in
> order to avoid a lintian warning.

:)

> > * even if you try to enable the hardening in d/rules, that doesn't work,
> >   and blhc still complains (and also lintian)
> I'm not sure what to do about this. Should I just have a patch that
> appends $(shell dpkg-buildflags --get $VAR) for CFLAGS and LDFLAGS?

The problem is that that makefile overwrites CFLAGS from the env.  This
is enough to deal with it (it's on top of the other patch of yours):

--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,4 @@
-CFLAGS = -DSHAPE -Wall -Werror -fPIC
+CFLAGS := $(CFLAGS) -DSHAPE -Wall -Werror -fPIC
 LDLIBS = -lXext -lX11
 BIN = $(DESTDIR)/usr/bin/
 

> After removing the unecessary lines from d/rules the buildflags appear
> to somewhat work but I've had to add a patch to compile objects with
> -fPIC as otherwise I get

yeah, of course you need -fPIC (google can give you thousands of posts
that explain why it is needed).

> > * From piuparts:
> All these should be fixed by the above.

yeah, it is.

> > Please also triage the debian bugs:
> >   + #681740 was fixed in 1.2-10
> Should I just close it?

yes, and also settinging the correct "fixed" value :)
I realize that this might seems mean, but I don't feel ok at sponsoring
a package in debian to a person that doesn't grasp the basis of the
debian infra/tooling/procedures like basic bugs handling in the Debian
tracker, like this; even if it's actually difficult to have such
knowledge *before* starting doing stuff.

It's hard to verify before uploading the very first package of the
sponsoree, so I'm happy to have these 2 bugs to check this :)

Though I am also happy because even if this seems to be your first
package in debian you seems to know something about packaging and about
tools, guess you did packaging work somewhere else?

> >   + #349680 not sure what to do, but sice you're becoming the maintainer
> > that's your call.  probably the best course of action, given where
> > the links in that bug end, is to just close the bug.
> I've closed it. plan9port and 9wm are two different things.

cool!

None of the stuff above is a blocker for an upload, so this is mostly
waiting for you to ack, and maybe have a chance of improving the quality
and trying to do things better, even if not required.

More stuff:

* you removed debian/9wm.docs in favour of debian/docs which is really
  the same thing, but in the second one you have a duplicated entry.
  + fix the changelog, there you say only 'Remove unnecessary files' but
you actually renamed it
- this for me is a blocker, because I care about d/changelog telling
  me the truth.
  + remove the duplicated entry.  

Bug#804390: RFS: 9wm/1.3.4-1 [ITA]

2015-12-11 Thread Jacob Adams


On 12/11/2015 06:43 PM, Mattia Rizzolo wrote:
> On Fri, Dec 11, 2015 at 05:19:01PM -0500, Jacob Adams wrote:
>> On 12/06/2015 09:05 AM, Mattia Rizzolo wrote:
>>> First, please be a bit more patiente with your pings; following up only
>>> 5 days later is very much not helpful.
>> Sorry about that. I should have realized how soon it was before I pinged.
> No worries, just be aware we (in debian, that's general) we're not used
> to reply in real time or few hours or 1 day...
>
>>> On Wed, Nov 25, 2015 at 03:10:28PM -0500, Jacob Adams wrote:
>>> * trailing whitespace on debian/control:29
>> Fixed
> oops, there is also one in debian/control:25 (sorry)
How are you catching these? I don't mean to leave them and I don't mind
fixing them, but I can't see trailing whitespace  (because it looks like
blank space :) ) and so seem to accidentally leave it everywhere.
>
>>> * please be a lot more verbose on the changelog.  "Redo packaging" is
>>>   not satisfactory at all.  Every change should be documented.
>> I've updated it to reflect all changes. Should I update the timestamp?
>> (It was generated by dch when I first made the changelog).
> The timestamp down there is not really relevant, though you might
> consider updating it right before uploading (usually I do a dummy commit
> before start working on the package, keeping the distribution UNRELEASED
> and an empty changelog, and at the end I do `gbp dch --auto -R`, which
> also updates the timestamp.
Ok I just updated it as it wasn't hard.
>
> Btw, you added 2 trailing whitespaces at line 5 and 11.
> Anyway, the changelog looks nearly good to me now, see below.
>
>>> * debian/patches/*: if possible a URL of the forwarded patch would be
>>>   nice
>> They've all been forwarded via email, so no urls unfortunately. I did,
>> however, have one unnecessary patch in there so I've removed it. I just
>> emailed upstream about the two patches I'm still using (The FHS one was
>> rejected without any reasoning as it was with a few others and simply
>> not applied so I've asked for a reason. The -fPIC one is new).
> ok, if they where private email, then 'yes' is totally fine.
>
>>> * debian/rules:
>>>   + trailing whitespace at line 11
>>>   + with debhelper compat 9 exporting the build flags that way is not
>>> needed anymore, so lines 3-4-5 can go away
>> Fixed.
> cool!  I love how cute they look packages with that quasi-empty d/rules!
>
>>> * you removed the postinst and prerm with the update-alternatives calls,
>>>   that looks useful to me; why?
>> Because I did not look over the previous packaging closely enough :)
>> I've added them back. I've also modified them slightly to call set -e in
>> order to avoid a lintian warning.
> :)
>
>>> * even if you try to enable the hardening in d/rules, that doesn't work,
>>>   and blhc still complains (and also lintian)
>> I'm not sure what to do about this. Should I just have a patch that
>> appends $(shell dpkg-buildflags --get $VAR) for CFLAGS and LDFLAGS?
> The problem is that that makefile overwrites CFLAGS from the env.  This
> is enough to deal with it (it's on top of the other patch of yours):
>
> --- a/Makefile
> +++ b/Makefile
> @@ -1,4 +1,4 @@
> -CFLAGS = -DSHAPE -Wall -Werror -fPIC
> +CFLAGS := $(CFLAGS) -DSHAPE -Wall -Werror -fPIC
>  LDLIBS = -lXext -lX11
>  BIN = $(DESTDIR)/usr/bin/
>  
Ok I used that. Lintian still complains however, so I'm not sure what
else to do.
>> After removing the unecessary lines from d/rules the buildflags appear
>> to somewhat work but I've had to add a patch to compile objects with
>> -fPIC as otherwise I get
> yeah, of course you need -fPIC (google can give you thousands of posts
> that explain why it is needed).
>
>>> * From piuparts:
>> All these should be fixed by the above.
> yeah, it is.
>
>>> Please also triage the debian bugs:
>>>   + #681740 was fixed in 1.2-10
>> Should I just close it?
> yes, and also settinging the correct "fixed" value :)
> I realize that this might seems mean, but I don't feel ok at sponsoring
> a package in debian to a person that doesn't grasp the basis of the
> debian infra/tooling/procedures like basic bugs handling in the Debian
> tracker, like this; even if it's actually difficult to have such
> knowledge *before* starting doing stuff.
>
> It's hard to verify before uploading the very first package of the
> sponsoree, so I'm happy to have these 2 bugs to check this :)
Ok I marked it as fixed in 1.2-10 and then closed it.
Obviously I need to learn the BTS. The next thing I'll do for Debian is
fix a few bugs in other packages to get the hang of it.
Any other bits of Debian infrastructure I should learn? I'm relatively
familiar with the package tracker and sources.
>
> Though I am also happy because even if this seems to be your first
> package in debian you seems to know something about packaging and about
> tools, guess you did packaging work somewhere else?

I did some packaging before on a few things for Debian but never got a
sponsor. In both 

Bug#804390: RFS: 9wm/1.3.4-1 [ITA]

2015-12-11 Thread Mattia Rizzolo
On Fri, Dec 11, 2015 at 08:47:15PM -0500, Jacob Adams wrote:
> On 12/11/2015 06:43 PM, Mattia Rizzolo wrote:
> > On Fri, Dec 11, 2015 at 05:19:01PM -0500, Jacob Adams wrote:
> >> On 12/06/2015 09:05 AM, Mattia Rizzolo wrote:
> How are you catching these? I don't mean to leave them and I don't mind
> fixing them, but I can't see trailing whitespace  (because it looks like
> blank space :) ) and so seem to accidentally leave it everywhere.

I find trailing whitespaces quite annoying, they can too easily lead to
diff noise, can make unecessary hard to understand why a patch doesn't
apply between different versions, etc.

I set up vim (that's my editor :P) to show me them with a bullet.

listchars=trail:·

↑ this should be enough to show them.

> > Btw, you added 2 trailing whitespaces at line 5 and 11.

You got another one at line 12 :P

> >>> * even if you try to enable the hardening in d/rules, that doesn't work,
> >>>   and blhc still complains (and also lintian)
> >> I'm not sure what to do about this. Should I just have a patch that
> >> appends $(shell dpkg-buildflags --get $VAR) for CFLAGS and LDFLAGS?
> > The problem is that that makefile overwrites CFLAGS from the env.  This
> > is enough to deal with it (it's on top of the other patch of yours):
> >
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1,4 +1,4 @@
> > -CFLAGS = -DSHAPE -Wall -Werror -fPIC
> > +CFLAGS := $(CFLAGS) -DSHAPE -Wall -Werror -fPIC
> >  LDLIBS = -lXext -lX11
> >  BIN = $(DESTDIR)/usr/bin/
> >  
> Ok I used that. Lintian still complains however, so I'm not sure what
> else to do.

This is weird.  With that on both lintian and blhc shut up here.

Though not sure what you meant by "I used that", because it's not in the
patch in the package.

> >>> Please also triage the debian bugs:
> >>>   + #681740 was fixed in 1.2-10
> >> Should I just close it?
> > yes, and also settinging the correct "fixed" value :)
> Ok I marked it as fixed in 1.2-10 and then closed it.
> Obviously I need to learn the BTS. The next thing I'll do for Debian is
> fix a few bugs in other packages to get the hang of it.

For example, to do that in one single email you could have:
* put control@ in (b)cc to the 681740-done@ email
* used the Version: pseudo-header, that when used in -done@ emails means
  "this got fixed in this version".  That's what happens with
  automatically close emails at package uploads (even if those use
  Source-Version instead of Version, but that's the same).

> Any other bits of Debian infrastructure I should learn? I'm relatively
> familiar with the package tracker and sources.

Guess that's good enough for now; just go around all the links that are
in tracker.d.o pages and you'll get a good overview.
Then if you haven't already please have a look at the policy and devref:
https://www.debian.org/doc/debian-policy/
https://www.debian.org/doc/manuals/developers-reference/

> > tools, guess you did packaging work somewhere else?
> 
> I did some packaging before on a few things for Debian but never got a
> sponsor. In both cases I never got a response from upstream so I gave up
> as I felt overwhelmed by all the stuff I had to do. Third time's the
> charm I guess :)

:)
Maybe try again now? ;)

> I've add Author fields. Should I add you to the Author field of the
> CFLAGS patch?

No need.


So, there is only that thing about CFLAGS to sort out.  Note that I'm
fine as it is now, btw, just tell me that ain't an error.

-- 
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#806190: RFS: python-bibtexparser/0.6.1-1 [ITP] -- Python library to parse bibtex files

2015-12-11 Thread Mattia Rizzolo
Control: tag -1 moreinfo

On Wed, Nov 25, 2015 at 10:02:41AM +0100, Alex Mestiashvili wrote:
>   https://mentors.debian.net/package/bibtexparser

There is no package with that name in mentors, nor there is an open ITP
for it.

Can you please open an ITP bug (or fix the bug metadata if there is
already one and, i.e., the source package name isn't the same) and
(re)upload your package to mentors.d.n?

-- 
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#807434: marked as done (RFS: aggressive-indent-mode/1.4.2-1 [ITP] -- Emacs minor mode that reindents code after every change)

2015-12-11 Thread Debian Bug Tracking System
Your message dated Sat, 12 Dec 2015 04:28:18 +
with message-id 
and subject line closing RFS: elpa-aggressive-indent/1.4.2-1 [ITP] -- Emacs 
minor mode that reindents code after every change
has caused the Debian Bug report #807434,
regarding RFS: aggressive-indent-mode/1.4.2-1 [ITP] -- Emacs minor mode that 
reindents code after every change
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.)


-- 
807434: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807434
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 "elpa-aggressive-indent",
which I prepared using dh_elpa.

 Package name: elpa-aggressive-indent
 Version : 1.4.2-1
 Upstream Author : Artur Malabarba 
 URL : https://github.com/Malabarba/aggressive-indent-mode
 License : GPL-2+
 Section : lisp

It builds the binary packages elpa-aggressive-indent.  Although the
upstream repository is called "aggressive-indent-mode", the author has
specified its ELPA package name as "aggressive-indent" so the Debian
package name is "elpa-aggressive-indent".

This is a very useful minor mode for writing LISP, especially when
rearranging forms with paredit or smartparens.  Since all relevant lines
are immediately reindented when you make a change, you can clearly make
sense of the structure of your code.

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

http://mentors.debian.net/package/elpa-aggressive-indent

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

  dget -x 
http://mentors.debian.net/debian/pool/main/e/elpa-aggressive-indent/elpa-aggressive-indent_1.4.2-1.dsc

Regards,

Sean Whitton


signature.asc
Description: Digital signature
--- End Message ---
--- Begin Message ---
Package elpa-aggressive-indent has been removed from mentors.--- End Message ---


Bug#807099: [corsix-th] 01/01: copyright: add last missing BSD-licensed files:

2015-12-11 Thread Alexandre Detiste
Ok, let's forward this to the RFS bug so other can have a look at it too.

I'm going through the pain of documenting all those file in the source
package instead of simply repacking it as "+ds1" or something
in the hope these features (level editor...) can be enabled
in a future release.

> [Simon McVittie ]
> On 11/12/15 11:58, Alexandre Detiste wrote:
> > +Files: SpriteEncoder/*
> > +Copyright: 2013 Albert "Alberth" Hofkamp
> > +License: BSD-3-Clause
> > +Comment:
> > + SpriteEncoder/parser.cpp & SpriteEncoder/tokens.h are G.P.L-3+
> > + but have this exception:
> > + .
> > + "As a special exception, you may create a larger work that contains
> > + part or all of the Bison parser skeleton and distribute that work
> > + under terms of your choice, so long as that work isn't itself a
> > + parser generator using the skeleton or a modified version thereof
> > + as a parser skeleton."
> 
> I think that's better spelled as:
> 
> Files: SpriteEncoder/*
> Copyright: ...
> License: BSD-3-Clause
> 
> Files:
>  SpriteEncoder/parser.cpp
>  SpriteEncoder/tokens.h
> Copyright: ...
> License: BSD-3-Clause and GPL-3+ with Bison exception
>  [normal GPL-3 stuff copied from the file itself]
>  .
>  As a special exception, you may create a larger work that contains
>  part or all of the Bison parser skeleton and distribute that work
>  under terms of your choice, so long as that work isn't itself a
>  parser generator using the skeleton or a modified version thereof
>  as a parser skeleton.
> Comment:
>  The source for these files is parser.y, which is BSD-3-Clause.
>  .
>  On Debian systems, ... /usr/share/common-licenses ...
> 
> 



Bug#807627: RFS: taskd/1.1.0+dfsg-1 [ITP]

2015-12-11 Thread Tobias Frost
Control: reopen -1

Am Freitag, den 11.12.2015, 02:51 +0100 schrieb Sebastien Badia:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "taskd"
> 
> * Package name: taskd
>   Version : 1.1.0+dfsg-1
>   Upstream Author : Paul Beckingham 
> * URL : http://taskwarrior.org
> * License : MIT
>   Section : utils
> 
> It builds those binary packages:
> 
>   taskd - Synchronisation server for taskwarrior
> 
> To access further information about this package, please visit the
> following URL:
> 
>  http://mentors.debian.net/package/taskd
> 
> Alternatively, one can download the package with dget using this
> command:
> 
>   dget -x http://mentors.debian.net/debian/pool/main/t/taskd/taskd_1


Bug#807626: marked as done (RFS: taskwarrior/2.5.0+dfsg-1)

2015-12-11 Thread Debian Bug Tracking System
Your message dated Fri, 11 Dec 2015 18:32:01 +0100
with message-id <1449855121.14332.9.ca...@frost.de>
and subject line Re: Bug#807626: RFS: taskwarrior/2.5.0+dfsg-1
has caused the Debian Bug report #807626,
regarding RFS: taskwarrior/2.5.0+dfsg-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.)


-- 
807626: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807626
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 "taskwarrior"

* Package name: taskwarrior
  Version : 2.5.0+dfsg-1
  Upstream Author : Paul Beckingham 
* URL : http://taskwarrior.org
* License : MIT
  Section : utils

It builds those binary packages:

  task - feature-rich console based todo list manager

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

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

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

  dget -x 
http://mentors.debian.net/debian/pool/main/t/task/task_2.5.0+dfsg-1.dsc

Note: This upload introduce the new upstream version 2.5.0.

Thanks in advance, cheers,

Seb


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


Bug#807627: marked as done (RFS: taskd/1.1.0+dfsg-1 [ITP])

2015-12-11 Thread Debian Bug Tracking System
Your message dated Fri, 11 Dec 2015 18:28:36 +0100
with message-id <1449854916.14332.7.ca...@frost.de>
and subject line Re: Bug#807627: RFS: taskd/1.1.0+dfsg-1 [ITP]
has caused the Debian Bug report #807627,
regarding RFS: taskd/1.1.0+dfsg-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.)


-- 
807627: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807627
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 "taskd"

* Package name: taskd
  Version : 1.1.0+dfsg-1
  Upstream Author : Paul Beckingham 
* URL : http://taskwarrior.org
* License : MIT
  Section : utils

It builds those binary packages:

  taskd - Synchronisation server for taskwarrior

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

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

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

  dget -x 
http://mentors.debian.net/debian/pool/main/t/taskd/taskd_1.1.0+dfsg-1.dsc

Note: This is the first upload of taskd package (ITP).

Thanks in advance, cheers,

Seb


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Uploaded. Many thanks for your contributions.--- End Message ---


Bug#807700: RFS: steamcmd - Command-line interface for Steam

2015-12-11 Thread Alexandre Detiste
Package: sponsorship-requests
Version: RFS: steamcmd - Command-line interface for Steam
Severity: wishlist

Dear mentors,

  I am looking for a sponsor for my package "hello":

 * Package name: steamcmd
   Version : upstream package is sadly not versioned
   Upstream Author : Valve
 * URL : https://developer.valvesoftware.com/wiki/SteamCMD
 * License : commercial
   Section : non-free/games

  It builds those binary packages:

steamcd:i386 - Command-line interface for Steam

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

  http://anonscm.debian.org/cgit/pkg-games/steamcmd.git/

  This is the initial upload.

  A few considerations: this program needs to run from a writable
  location & will automatically update itself the first time it's ran.

  So, I could have stuffed the current 'steamcmd' binary & 'steamcmd.sh'
  of the day in the package, but that would hadn't enabled someone to
  reproduce that package, so instead I used the binary
  timestamped 2013/02/05 from the tarball.

  https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz

  This package reuse much work done on the src:steam package
  & depends on steam:i386 binary package to ensure that all needed
  depedencies are already installed and that user has already
  accepted the EULA.

  Regards,

  Alexandre Detiste



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (450, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-1-amd64 (SMP w/6 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Re: DNS fails in pbuilder

2015-12-11 Thread Andreas Tille
On Fri, Dec 11, 2015 at 01:26:31PM +, Mattia Rizzolo wrote:
> > I tried pbuilder 0.221.1 from testing and 0.221.3 from unstable.
> 
> Should be fixed by 0.221.2, are you sure it's still broken, because
> several people confirmed me it's fixed...

I confirm that the problem persits in 0.221.3

 Andreas.

-- 
http://fam-tille.de



Bug#801262: tagging 801262

2015-12-11 Thread Mattia Rizzolo
On Wed, Oct 14, 2015 at 05:28:12AM +0200, John Paul Adrian Glaubitz wrote:
> tags 801262 + pending

erm, did something follow this tagging?

usually such a tag means "package's good, I'm going to upload this very
soon", but in ~2 months I don't see this package anywhere.

Also this tag moves the package at the bottom of the sponsorship list,
which don't help getting sponsored...

-- 
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#801703: marked as done (RFS: eclipse-titan/5.3-1 [ITP])

2015-12-11 Thread Debian Bug Tracking System
Your message dated Sat, 12 Dec 2015 03:02:33 +
with message-id <20151212030233.gb18...@chase.mapreri.org>
and subject line Re: Bug#801703: RFS: eclipse-titan/5.3-1 [ITP]
has caused the Debian Bug report #801703,
regarding RFS: eclipse-titan/5.3-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.)


-- 
801703: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801703
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 "eclipse-titan":

Package name: eclipse-titan
Version : 5.3-1
Upstream Author : Eclipse Foundation
URL : www.eclipse.org
License : Eclipse Public License - v 1.0
Section : utils

It builds this binary package:

eclipse-titan

TTCN-3 is a standardized, modular language specifically designed for testing.
Eclipse Titan offers a free and open source (FOSS) compiler both for TTCN-3 and
for ASN.1 (Abstract Syntax Notation One).

You can download the package with wget using this command:

wget https://www.dropbox.com/s/qkzdjefpp2ura11/eclipse-titan_5.3.tar.gz

More information about eclipse-titan can be obtained from
https://github.com/eclipse/titan.core

This is the first upload so there isn’t any changelog.


Best Regards,
Gergely Pilisi



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.0.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
On Tue, Oct 13, 2015 at 06:30:23PM +0200, Gergely Pilisi wrote:
> I am looking for a sponsor for my package "eclipse-titan":

Let me go a bit over what Gianfranco said, in a more structured and
in-depth manner:

* please use mentors.debian.net when requestion sponsorship
* please file a ITP bug when working on a NEW package
* run lintian on that .changes file, you'll notice *a lot* of issues,
  you should be able to fix just about all of them (maybe don't waste
  time on binary-without-manpage and no-upstream-changelog)
  + lintian will tell you a huge subset of what a sponsor would be going
to ask you here anyway, most importantly:
- no hardcoding of dep in that way
- very very old standards-version
- no build-dep on dh
- source-contains-git-control-dir — uh? how did you build that
  source package?
- use dh-autoreconf
- build-depends-on-build-essential
- somewhere you got troubles at conveying build flags from the
  environment



I'm going to close this bug, since in 2 months it received no replies
from the sponsoree.  I invite you to open a new bug, once you're done
with the above requests.


Thanks!

-- 
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#757180: marked as done (RFS: pw3270/5.0.0 [ITP] -- GTK IBM 3270 terminal emulator)

2015-12-11 Thread Debian Bug Tracking System
Your message dated Sat, 12 Dec 2015 04:13:18 +
with message-id <20151212041318.gd28...@chase.mapreri.org>
and subject line old RFS, closing
has caused the Debian Bug report #757180,
regarding RFS: pw3270/5.0.0 [ITP] -- GTK IBM 3270 terminal emulator
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.)


-- 
757180: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757180
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 packages: lib3270, lib3270-dev,
libreoffice-extension-pw3270, oorexx, oorexx-dev, php5-tn3270, pw3270,
pw3270-plugin-dbus and pw3270-plugin-rexx.

Upstream Author: Perry Werneck 
URL:
http://www.softwarepublico.gov.br/dotlrn/clubs/pw3270/one-community?page_num=0
License: GPL v2

Pw3270 is an IBM 3270 Terminal emulator for gtk. It can be used to
communicate with any IBM host that supports 3270-style connections over
TELNET.
It features a rich GTK+3 interface, ssl connections, sending/receiving
files to/from mainframe and bindings for libreoffice, php, dbus and oorexx.
It was developed by Perry Werneck, under request of Banco do Brasil S.A.,
the major bank in Brazil and a great user os free software.

Binaries and sources can be obtained from:
http://download.opensuse.org/repositories/home:/PerryWerneck:/pw3270/xUbuntu_14.04/


Regards,

---
Fábio Lima (fa...@fabiolima.eti.br)
--- End Message ---
--- Begin Message ---
This RFS is really old, ~1,5 year with the last mail being > 1y too.

I'm closing it.

Dear sponsoree: if you're still interested in havin this package in
Debian please feel free to open a new one, following the instruction
already gived, e.g. filing a ITP, and using mentors.debian.net.

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