Bug#847941: RFS: libvecpf/1.1.0-1 ITP: libvecpf -- Vector Printf Library

2017-01-19 Thread Tobias Frost 
Hi Frederic,

currently I'm short on time and as new packages are currently not the
priority (won't be part of Stretch anyway) please let me defer that to
past-freeze. Ping me again then and I'll take a look.

--
tobi

Am Mittwoch, den 11.01.2017, 09:58 +0100 schrieb Frederic Bonnard:
> Hi Tobias, Gianfranco.
> 
> Tobias, Thierry agreed and I change the owner, I hope it's better
> now.
> 
> Any of you would have time to review the package?
> I added Gianfranco as is my usual sponsor,  but I forgot to Cc him in
> my
> initial request.
> Thanks,
> 
> F.
> 
> On Mon, 19 Dec 2016 08:12:06 +0100, Tobias Frost 
> wrote:
> > Control: tags -1 wontfix
> > Control: block 806720 by -1
> > 
> > Hi Frederick,
> > 
> > the ITP is owned by Thierry Fauck, did you check with him if it is
> > ok
> > to take this ITP? (Should be done via the BTS and then the ITP's
> > meta
> > data should be corrected accordingly.
> > 
> > Please remove the wontfix when this has been resolved. 
> > 
> > --
> > tobi
> >

Bug#851937: RFS: farbfeld/2.20170109-1 ITP

2017-01-19 Thread Dmitry Bogatov 

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name : farbfeld
  Version  : 2.20170109-1
  Upstream Author  : Laslo Hunhold 
* Url  : http://tools.suckless.org/farbfeld
* Licenses : ISC
  Programming Lang : C
  Section  : graphics

 Farbfeld is a lossless image-format designed to be parsed and piped
 easily. It is designed to be as simple as possible, leaving the task
 of compression to outside tools, beating PNG's filesize in many
 cases.
 .
 This package contains tools for converting between farbfeld format
 and other image formats (png, jpeg, ppm, pam, git)

It builds those binary packages:

  * farbfeld

Please note, that package is maintained with dgit(1) tool using
dgit-maint-merge(7) workflow. In particular, it means that quilt
patches are squashed in source package and are not intended for
review. For more information about how to sponsor this package,
see dgit-sponsorship(7).

  Git repository: 
https://anonscm.debian.org/cgit/users/kaction-guest/farbfeld.git
  Git branch: master
  Orig tar.gz: from tag 2.20170109

With /bin/sh following commands should suffice:

  $ git clone https://anonscm.debian.org/cgit/users/kaction-guest/farbfeld.git 
farbfeld
  $ cd farbfeld
  $ git archive -o ../farbfeld_2.20170109.orig.tar.xz 2.20170109
  $ dgit sbuild

Regards,
  Dmitry Bogatov

Bug#851936: RFS: openmeca/2.1.5-1 [ITP: #850590]

2017-01-19 Thread dada 

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my first package "openmeca"

* Package name: openmeca
* Version : 2.1.5-1
* Upstream Author : Damien André (myself)
* URL : https://gitlab.com/damien.andre/openmeca
* License : GPL v3
* Section : science

It builds those binary packages:
  openmeca   - Multibody mechanical simulator

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

  https://mentors.debian.net/package/openmeca

Alternatively, one can download the package with dget using this 
command:
  dget -x 
https://mentors.debian.net/debian/pool/main/o/openmeca/openmeca_2.1.5-1.dsc


A git repository of the debianized version of openmeca is also 
available on Alioth:

  https://anonscm.debian.org/cgit/debian-science/packages/openmeca.git/

More information about openmeca can be obtained from :
  https://gitlab.com/damien.andre/openmeca
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850590


Best Regards,Damien andré
--
http://www.unilim.fr/pages_perso/damien.andre/

Re: Backporting shibboleth-sp2 2.6.0+dfsg1-4 to jessie: dh-systemd, piuparts and lintian errors

2017-01-19 Thread Ferenc Wágner 
Etienne Dysli-Metref  writes:

> Since shibboleth-sp2 2.6.0+dfsg1-4 migrated to testing during the
> holidays, I'm now backporting it to jessie. So far there is nothing to
> change, however piuparts gives me the following error (which does not
> appear on stretch):
>
>> 0m34.6s ERROR: FAIL: Package purging left files on system:
>>   /etc/systemd/system/multi-user.target.wants/shibd.service -> 
>> /lib/systemd/system/shibd.service  not owned
>>   /etc/systemd/system/shibd.service -> /dev/null  not owned
>>   /var/lib/systemd/deb-systemd-helper-enabled/not owned
>>   /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/   
>>  not owned
>>   
>> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/shibd.service
>>not owned
>>   /var/lib/systemd/deb-systemd-helper-enabled/shibd.service.dsh-also  not 
>> owned
>>   /var/lib/systemd/deb-systemd-helper-masked/ not owned
>>   /var/lib/systemd/deb-systemd-helper-masked/shibd.servicenot owned
>
> It looked like dh-systemd wasn't properly cleaning up despite
> shibboleth-sp2-utils's postrm script looking like it would: [...]

I couldn't reproduce this on a real jessie system, only in a piuparts
chroot.  I think the reason is that piuparts removes init-system-helpers
(the home of deb-systemd-helper) before the shibboleth-sp2-utils postrm
could instruct it to clean up.  I'm not sure what we could do about
this.

> So I bumped the build-dep up a bit to: dh-systemd (>= 9.20160709).

Why?  I mean, where did this version number come from?
-- 
Feri

Re: mpgrafic - mpirun test program as root in automatic build

2017-01-19 Thread Sean Whitton 
On Thu, Jan 19, 2017 at 08:21:36AM +0800, Paul Wise wrote:
> On Thu, Jan 19, 2017 at 7:44 AM, Sean Whitton wrote:
> 
> > This is temporarily false: #852071
> 
> Is there a typo in that bug? I get a 404

#851071, sorry!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: OpenMPI rpath entries (Was: question on binary-or-shlib-defines-rpath)

2017-01-19 Thread Nico Schlömer 
Hm, I'm now getting errors from dpkg-shlibdeps (i.e., and installation
time):
```
dpkg-shlibdeps: error: couldn't find library libtrilinos_trilinosss.so.12
needed by
debian/libtrilinos-amesos12/usr/lib/powerpc64le-linux-gnu/libtrilinos_amesos.so.12.11
(ELF format: 'elf64-powerpcle'; RPATH:
':/usr//lib:/usr/lib/powerpc64le-linux-gnu/openmpi/lib')
```
See [1] for full detail. (Btw, notice the RPATH settings from openmpi.)

CMake I think installs the libraries in alphabetical order, so
`libtrilinos_amesos.so.12.11` is handled before its dependency
`libtrilinos_trilinosss.so.12` and cannot find the latter -- makes sense.

What's the suggested workaround here?

Cheers,
Nico

[1]
https://launchpadlibrarian.net/303079195/buildlog_ubuntu-zesty-ppc64el.trilinos_12.11~20170119114916-33933755-1zesty1_BUILDING.txt.g
z


On Thu, Jan 19, 2017 at 3:03 PM Nico Schlömer 
wrote:

I can confirm that the RPATH is
```
RPATH: ':/usr//lib:/usr/lib/powerpc64le-linux-gnu/openmpi/lib'
```
I'll just wait for the next ompi upload then.


Cheers,
Nico

On Thu, Jan 19, 2017 at 2:10 PM Alastair McKinstry 
wrote:



On 19/01/2017 11:20, James Cowgill wrote:
> Hi,
>
> On 18/01/17 22:39, Nico Schlömer wrote:
>> I'm co-maintaining the Trilinos package [1] in Debian and recently found
>> a bunch of new lintian warnings of the kind
>> binary-or-shlib-defines-rpath [2]. It say in the description of the
warning:
>> ```
>> To fix this problem, look for link lines like:
>>
>> gcc test.o -o test -Wl,--rpath,/usr/local/lib
>>
>> or
>>
>> gcc test.o -o test -R/usr/local/lib
>>
>> and remove the -Wl,--rpath or -R argument.
>> ```
>> Indeed, the Trilinos installation contains many of those lines, but they
>> are necessary too. When executing the test binaries (which are compiled
>> in the build tree alongside the libraries), they have to find the linked
>> shared libraries. Messing with the rpath is necessary.
>>
>> That's not true later on when the libraries are _installed_, of course.
>> For this, CMake has the switch CMAKE_SKIP_INSTALL_RPATH [3], which
>> serves exactly that purpose. For some reason, lintian doesn't seem to be
>> happy with that though.
> The CMAKE_SKIP_INSTALL_RPATH option only affects the rpaths which CMake
> itself inserts. It does not affect any rpaths manually added with other
> -Wl,--rpath options. The culprit here is probably openmpi which adds all
> of these rpath entries:
>
> $ mpicc -show
> [...] -Wl,-rpath -Wl,/usr//lib -Wl,-rpath
> -Wl,/usr/lib/x86_64-linux-gnu/openmpi/lib [...]
>
> Maybe it shouldn't do that. The /usr//lib one is clearly useless and the
> it seems that most of the libraries from
> /usr/lib/x86_64-linux-gnu/openmpi/lib are symlinked into
> /usr/lib/x86_64-linux-gnu anyway.
>
Agreed. Will remove these on the next upload.

Best regards
Alastair

--
Alastair McKinstry, , ,
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.

Bug#851799: RFS: hamlib/3.1.0-1

2017-01-19 Thread Sean Whitton 
control: tag -1 +moreinfo
control: owner -1 !

Dear Ervin,

On Wed, Jan 18, 2017 at 10:39:34PM +0100, Ervin Hegedüs wrote:
> I am looking for a sponsor for my package "hamlib"

Thanks for your RFS.  Some issues with this upload:

- debhelper compat bump not in changelog

- debhelper build-dep needs to be >9

- why not use debhelper compat 10?

- did the std-ver bump require any changes?  it's conventional to say in
  the changelog
  
- "added lua binding" involves several changes, which should all be in
  the changelog (new binary packages; build-dep on dh_lua;
  many new files in debian/; lots of changes to rules)

- new debian/trash (what is this file?  why not debian/clean?)

- just to confirm, have you verified that there is no ABI break with
  this new version of the library?  I haven't checked yet.

If you're able to address the issues I've raised in this message, please
remove the moreinfo tag in this bug, and don't forget to re-run `dch -r`
to refresh the changelog timestamp.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#851884: RFS: fdkaac/0.6.3-1

2017-01-19 Thread Marius Gavrilescu 
Sean Whitton  writes:

> Dear Marius,
>
> Could you update your Vcs-Git repository with the new version, please?

Dear Sean,

My Vcs-Git ( https://git.ieval.ro/git/fdkaac.git ) already has the new
version.
-- 
Marius Gavrilescu


signature.asc
Description: PGP signature

Bug#851884: RFS: fdkaac/0.6.3-1

2017-01-19 Thread Sean Whitton 
Dear Marius,

Could you update your Vcs-Git repository with the new version, please?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#851884: RFS: fdkaac/0.6.3-1

2017-01-19 Thread Marius Gavrilescu 
Andrey Rahmatullin  writes:

> On Thu, Jan 19, 2017 at 03:30:39PM +, Marius Gavrilescu wrote:
>>   * Mark as XS-Autobuild: yes
> Why do you think you need that in a contrib package?

That... is a great point! It only makes sense for non-free packages.

I believe I added that as I saw the package was BD-Uninstallable on all
arches bug amd64. But that was because libfdk-aac-dev was not available
on those arches when the buildds tried to build fdkaac (libfdk-aac-dev
is now available on most arches).

I've removed XS-Autobuild: yes from d/control and the corresponding
changelog item. The new package is now on mentors.
-- 
Marius Gavrilescu


signature.asc
Description: PGP signature

Bug#851884: RFS: fdkaac/0.6.3-1

2017-01-19 Thread Andrey Rahmatullin 
On Thu, Jan 19, 2017 at 03:30:39PM +, Marius Gavrilescu wrote:
>   * Mark as XS-Autobuild: yes
Why do you think you need that in a contrib package?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bonjour

2017-01-19 Thread Roland 



Besoin d'argent pour un projet personnel???
Contactez nous pour plus d'informations pour obtenir un prêt.



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

Bug#851884: RFS: fdkaac/0.6.3-1

2017-01-19 Thread Marius Gavrilescu 

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: fdkaac
   Version : 0.6.3-1
   Upstream Author : nu774 
 * URL : https://github.com/nu774/fdkaac
 * License : Zlib
   Section : sound

It builds those binary packages:

  fdkaac - command line encoder frontend for libfdk-aac

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

  https://mentors.debian.net/package/fdkaac


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

  dget -x 
https://mentors.debian.net/debian/pool/contrib/f/fdkaac/fdkaac_0.6.3-1.dsc

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

Changes since the last upload:

  * New upstream version
  * Bump Standards-Version to 3.9.8
  * Mark as XS-Autobuild: yes
  * Use hardening compilation options

Regards,
-- 
Marius Gavrilescu


signature.asc
Description: PGP signature

Re: OpenMPI rpath entries (Was: question on binary-or-shlib-defines-rpath)

2017-01-19 Thread Nico Schlömer 
I can confirm that the RPATH is
```
RPATH: ':/usr//lib:/usr/lib/powerpc64le-linux-gnu/openmpi/lib'
```
I'll just wait for the next ompi upload then.

Cheers,
Nico

On Thu, Jan 19, 2017 at 2:10 PM Alastair McKinstry 
wrote:

>
>
> On 19/01/2017 11:20, James Cowgill wrote:
> > Hi,
> >
> > On 18/01/17 22:39, Nico Schlömer wrote:
> >> I'm co-maintaining the Trilinos package [1] in Debian and recently found
> >> a bunch of new lintian warnings of the kind
> >> binary-or-shlib-defines-rpath [2]. It say in the description of the
> warning:
> >> ```
> >> To fix this problem, look for link lines like:
> >>
> >> gcc test.o -o test -Wl,--rpath,/usr/local/lib
> >>
> >> or
> >>
> >> gcc test.o -o test -R/usr/local/lib
> >>
> >> and remove the -Wl,--rpath or -R argument.
> >> ```
> >> Indeed, the Trilinos installation contains many of those lines, but they
> >> are necessary too. When executing the test binaries (which are compiled
> >> in the build tree alongside the libraries), they have to find the linked
> >> shared libraries. Messing with the rpath is necessary.
> >>
> >> That's not true later on when the libraries are _installed_, of course.
> >> For this, CMake has the switch CMAKE_SKIP_INSTALL_RPATH [3], which
> >> serves exactly that purpose. For some reason, lintian doesn't seem to be
> >> happy with that though.
> > The CMAKE_SKIP_INSTALL_RPATH option only affects the rpaths which CMake
> > itself inserts. It does not affect any rpaths manually added with other
> > -Wl,--rpath options. The culprit here is probably openmpi which adds all
> > of these rpath entries:
> >
> > $ mpicc -show
> > [...] -Wl,-rpath -Wl,/usr//lib -Wl,-rpath
> > -Wl,/usr/lib/x86_64-linux-gnu/openmpi/lib [...]
> >
> > Maybe it shouldn't do that. The /usr//lib one is clearly useless and the
> > it seems that most of the libraries from
> > /usr/lib/x86_64-linux-gnu/openmpi/lib are symlinked into
> > /usr/lib/x86_64-linux-gnu anyway.
> >
> Agreed. Will remove these on the next upload.
>
> Best regards
> Alastair
>
> --
> Alastair McKinstry, , ,
> https://diaspora.sceal.ie/u/amckinstry
> Misentropy: doubting that the Universe is becoming more disordered.
>
>
>

Re: OpenMPI rpath entries (Was: question on binary-or-shlib-defines-rpath)

2017-01-19 Thread Alastair McKinstry 


On 19/01/2017 11:20, James Cowgill wrote:
> Hi,
>
> On 18/01/17 22:39, Nico Schlömer wrote:
>> I'm co-maintaining the Trilinos package [1] in Debian and recently found
>> a bunch of new lintian warnings of the kind
>> binary-or-shlib-defines-rpath [2]. It say in the description of the warning:
>> ```
>> To fix this problem, look for link lines like: 
>>
>> gcc test.o -o test -Wl,--rpath,/usr/local/lib
>>
>> or 
>>
>> gcc test.o -o test -R/usr/local/lib
>>
>> and remove the -Wl,--rpath or -R argument.
>> ```
>> Indeed, the Trilinos installation contains many of those lines, but they
>> are necessary too. When executing the test binaries (which are compiled
>> in the build tree alongside the libraries), they have to find the linked
>> shared libraries. Messing with the rpath is necessary.
>>
>> That's not true later on when the libraries are _installed_, of course.
>> For this, CMake has the switch CMAKE_SKIP_INSTALL_RPATH [3], which
>> serves exactly that purpose. For some reason, lintian doesn't seem to be
>> happy with that though.
> The CMAKE_SKIP_INSTALL_RPATH option only affects the rpaths which CMake
> itself inserts. It does not affect any rpaths manually added with other
> -Wl,--rpath options. The culprit here is probably openmpi which adds all
> of these rpath entries:
>
> $ mpicc -show
> [...] -Wl,-rpath -Wl,/usr//lib -Wl,-rpath
> -Wl,/usr/lib/x86_64-linux-gnu/openmpi/lib [...]
>
> Maybe it shouldn't do that. The /usr//lib one is clearly useless and the
> it seems that most of the libraries from
> /usr/lib/x86_64-linux-gnu/openmpi/lib are symlinked into
> /usr/lib/x86_64-linux-gnu anyway.
>
Agreed. Will remove these on the next upload.

Best regards
Alastair

-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered. 




signature.asc
Description: OpenPGP digital signature

Re: OpenMPI rpath entries (Was: question on binary-or-shlib-defines-rpath)

2017-01-19 Thread James Cowgill 
On 19/01/17 12:20, Thibaut Paumard wrote:
> Le 19/01/2017 à 12:20, James Cowgill a écrit :
>> On a separate note: does this interfere with the alternatives system
>> which openmpi currently has? If an rpath is used, it will override any
>> libraries in the default linker search path so even if the mpi
>> alternative is changed, many applications will still use libmpi from
>> /usr/lib/x86_64-linux-gnu/openmpi/lib.
> 
> This is as it should be. The two alternative implementations (openmpi
> and mpich) are not binary-compatible.

Ahh sorry, I misread where the symlinks were pointing to. Indeed only
the .so files from the -dev package are under the alternatives system.

James



signature.asc
Description: OpenPGP digital signature

Re: OpenMPI rpath entries (Was: question on binary-or-shlib-defines-rpath)

2017-01-19 Thread Thibaut Paumard 
Le 19/01/2017 à 12:20, James Cowgill a écrit :
> On a separate note: does this interfere with the alternatives system
> which openmpi currently has? If an rpath is used, it will override any
> libraries in the default linker search path so even if the mpi
> alternative is changed, many applications will still use libmpi from
> /usr/lib/x86_64-linux-gnu/openmpi/lib.

This is as it should be. The two alternative implementations (openmpi
and mpich) are not binary-compatible.

Regards, Thibaut.

Re: OpenMPI rpath entries (Was: question on binary-or-shlib-defines-rpath)

2017-01-19 Thread James Cowgill 
Hi,

On 18/01/17 22:39, Nico Schlömer wrote:
> I'm co-maintaining the Trilinos package [1] in Debian and recently found
> a bunch of new lintian warnings of the kind
> binary-or-shlib-defines-rpath [2]. It say in the description of the warning:
> ```
> To fix this problem, look for link lines like: 
> 
> gcc test.o -o test -Wl,--rpath,/usr/local/lib
> 
> or 
> 
> gcc test.o -o test -R/usr/local/lib
> 
> and remove the -Wl,--rpath or -R argument.
> ```
> Indeed, the Trilinos installation contains many of those lines, but they
> are necessary too. When executing the test binaries (which are compiled
> in the build tree alongside the libraries), they have to find the linked
> shared libraries. Messing with the rpath is necessary.
> 
> That's not true later on when the libraries are _installed_, of course.
> For this, CMake has the switch CMAKE_SKIP_INSTALL_RPATH [3], which
> serves exactly that purpose. For some reason, lintian doesn't seem to be
> happy with that though.

The CMAKE_SKIP_INSTALL_RPATH option only affects the rpaths which CMake
itself inserts. It does not affect any rpaths manually added with other
-Wl,--rpath options. The culprit here is probably openmpi which adds all
of these rpath entries:

$ mpicc -show
[...] -Wl,-rpath -Wl,/usr//lib -Wl,-rpath
-Wl,/usr/lib/x86_64-linux-gnu/openmpi/lib [...]

Maybe it shouldn't do that. The /usr//lib one is clearly useless and the
it seems that most of the libraries from
/usr/lib/x86_64-linux-gnu/openmpi/lib are symlinked into
/usr/lib/x86_64-linux-gnu anyway.

On a separate note: does this interfere with the alternatives system
which openmpi currently has? If an rpath is used, it will override any
libraries in the default linker search path so even if the mpi
alternative is changed, many applications will still use libmpi from
/usr/lib/x86_64-linux-gnu/openmpi/lib.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Re: question on binary-or-shlib-defines-rpath

2017-01-19 Thread Gianfranco Costamagna 
Hello Nico,


>I'm co-maintaining the Trilinos package [1] in Debian and recently found a 
>bunch of new lintian warnings of the kind binary-or-shlib-defines-rpath [2]. 
>It say in >the description of the warning:


Usually lintian is right on such tags :p

You can look at src:ettercap, where I have implemented such RPATH nightmare 
handling in cmake.
I would wild guess something like
"CMAKE_INSTALL_RPATH_USE_LINK_PATH" is set to TRUE
and build logs agrees with me :)

-- Trilinos_SET_INSTALL_RPATH='TRUE'
-- CMAKE_INSTALL_RPATH_USE_LINK_PATH='TRUE'

I'm too lazy to remember why I did the ettercap hack [1], somewhere we want 
people
that build from source to be able to ./binary without having to install it
(so the RPATH is needed), so I created a DISABLE_RPATH flag that disables such 
feature, and
added it to the debian/rules file.

I remember such USE_LINK_PATH being the culprit of my issue.


[1] 
https://github.com/Ettercap/ettercap/commit/3c72c92cfe5870f47cfc9e1e021dcc26286ac710

HTH

Gianfranco

Bug#851756: RFS: telegram-desktop/1.0.0-2

2017-01-19 Thread Gianfranco Costamagna 
Hello

>This is alpha version. It is not in upstream changelog on [1].


something I wondered too, maybe tagging it differently from official releases
might help
>To be noted upstream author does not always publish the tags in time.
>

>P.S.: I don't know how to put this remote changelog into the package.
ask upstream to include a changelog in the source code/tarball
and use dh_installchangelogs

G.

Re: question on binary-or-shlib-defines-rpath

2017-01-19 Thread Nico Schlömer 
Thanks Sean for the reply.

> If so, it's probably a Lintian bug.

I thought it might be. Just filed a bug for it [1].

Cheers,
Nico

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



On Thu, Jan 19, 2017 at 12:50 AM Sean Whitton 
wrote:

Dear Nico,

On Wed, Jan 18, 2017 at 10:39:47PM +, Nico Schlömer wrote:
> That's not true later on when the libraries are _installed_, of course.
For
> this, CMake has the switch CMAKE_SKIP_INSTALL_RPATH [3], which serves
exactly
> that purpose. For some reason, lintian doesn't seem to be happy with that
> though.

I believe that this Lintian tag checks only the contents of your final
binary packages.  Are you absolutely sure that you do not install any of
these test suite files?  If so, it's probably a Lintian bug.

--
Sean Whitton