Bug#846325: RFS: netperfmeter/1.6.1-1

2017-01-18 Thread Tobias Frost
Control: noowner -1

Timeout... 
Therefore removing the owner tag and no longer indicating that I will
sponsor the upload.

On Fri, 30 Dec 2016 12:18:56 +0100 Tobias Frost  wrote:
> ping?
> 
> 



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

2017-01-18 Thread Коля Гурьев

19.01.2017 00:23, Gianfranco Costamagna пишет:

I see tag for 1.0.1 pushed on github [1]


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

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.

[1] https://desktop.telegram.org/changelog



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

2017-01-18 Thread Paul Wise
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

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

2017-01-18 Thread Sean Whitton
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


signature.asc
Description: PGP signature


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

2017-01-18 Thread Sean Whitton
Hello,

On Wed, Jan 18, 2017 at 02:25:41PM +0800, Paul Wise wrote:
> On Wed, Jan 18, 2017 at 5:13 AM, Boud Roukema wrote:
> 
> > I've looked a bit at buildd.debian.org, but it's not completely
> > trivial to decide which is correct - do the buildd builds on the
> > debian build machines run dh_auto_tests as (i) root, as (ii) an unprivileged
> > user running fakeroot, or as (iii) an unprivileged user?
> 
> (iii) an unprivileged user
> 
> fakeroot is only used at `debian/rules install` time.

This is temporarily false: #852071

-- 
Sean Whitton


signature.asc
Description: PGP signature


question on binary-or-shlib-defines-rpath

2017-01-18 Thread Nico Schlömer
Hi everyone,

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.

Any hints?
Cheers,
Nico

[1] https://tracker.debian.org/pkg/trilinos
[2] https://lintian.debian.org/tags/binary-or-shlib-defines-rpath.html
[3] https://cmake.org/cmake/help/v3.0/variable/CMAKE_SKIP_INSTALL_RPATH.html


Bug#851799: RFS: hamlib/3.1.0-1

2017-01-18 Thread Ervin Hegedüs
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name  : hamlib
 Version : 3.1.0-1
 Upstream Author : Kamal Mostafa , Colin Tuckley 

 * URL   : https://sourceforge.net/projects/hamlib/
 * License   : LGPLv2
 Section : hamradio

It builds those binary packages:

libhamlib++-dev - Development C++ library to control radio transceivers and 
receive
libhamlib-dev - Development library to control radio transceivers and receivers
libhamlib-doc - Documentation for the hamlib radio control library
libhamlib-utils - Utilities to support the hamlib radio control library
libhamlib2 - Run-time library to control radio transceivers and receivers
libhamlib2++c2 - Run-time C++ library to control radio transceivers and 
receivers
libhamlib2-perl - Run-time perl library to control radio transceivers and 
receivers
libhamlib2-tcl - Run-time Tcl library to control radio transceivers and 
receivers
lua-hamlib2 - Run-time Lua library to control radio transceivers and receivers
python-libhamlib2 - Run-time Python library to control radio transceivers and 
receive

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/h/hamlib/hamlib_3.1.0-1.dsc

More information about hello can be obtained from
https://sourceforge.net/projects/hamlib

Changes since the last upload:

 * Team upload
 * New upstream release
 * Changed manpages directory in manpage-hyphen-fixes.patch
 * Added Lua binding
 * Fixed broken libhamlib2-tcl package
 * Bump Standards-version to 3.9.8

Regards,
 Ervin Hegedüs

-- 
I � UTF-8



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

2017-01-18 Thread Gianfranco Costamagna
Hello

>Version : 1.0.0-2~rc2

>https://mentors.debian.net/debian/pool/contrib/t/telegram-desktop/telegram-desktop_1.0.0-2~rc2.dsc



I see tag for 1.0.1 pushed on github [1]

Isn't it a good release? I didn't look at the code, but instead of an rc, I 
would prefer a stable
1.0.1 (even if it is just a tag and not a release, so I might be *very* wrong)

G.


[1] https://github.com/telegramdesktop/tdesktop/releases



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

2017-01-18 Thread Andrey Rahmatullin
On Wed, Jan 18, 2017 at 10:07:34PM +0300, Коля Гурьев wrote:
> > Why is it in contrib?
> From what I understand, there are packages with dependencies on non-free
> software in contrib section. This program does not work if Telegram server
> is stopped for any reason. But this server is proprietary, more accurately,
> it does not even distribute in public. So I thought the package has to be in
> contrib.  Correct me, please, if I am wrong.
Clients for proprietary servers are packaged in main, e.g. pyicqt.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


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

2017-01-18 Thread Niels Thykier
Etienne Dysli-Metref:
> On 17/01/17 18:30, Niels Thykier wrote:
 E: libshibsp7: postinst-must-call-ldconfig 
 usr/lib/x86_64-linux-gnu/libshibsp.so.7.0.0
>>
>> This lintian error:
>>
>>  * is aimed at stretch or later, and
>>  * should be ignored for stable and stable-backports

Correction; I was wrong - this lintian error is correct for a lintian
from stable (I confused it with a newer lintian tag).

This occurs because you are using debhelper from backports, which uses a
trigger instead of maintscript to call ldconfig.  The end result is the
same for you though - ignore the warning. :)

> 
> After having overridden this lintian error, it turns out it was a bit of
> a red herring: piuparts still reports files left after purging.
> 
> [...]

Correct, this lintian warning is completely unrelated to your piuparts
issue.

> 
> So is the postrm script from shibboleth-sp2-utils not executed?
> 

It is definitely called - if it wasn't, almost everything would be
failing on piuparts.d.o and dpkg in stable would completely an utterly
broken with us drowning in RC bugs. :)

Most likely, there is an issue with either the postrm script OR the
helpers used in it.  I am not an expert on the helpers, so I cannot help
there.

Thanks,
~Niels




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

2017-01-18 Thread Коля Гурьев
I already fixed a few things: debian/changelog, the list of build 
dependencies. My fork on Github is specified temporally in 
debian/control. I just don't know a more appropriate value for this 
field at the moment.


I've putted the current changes back to [1].

I would appreciate your advice about my debian/rules. What can I improve it?

[1] 
https://mentors.debian.net/debian/pool/contrib/t/telegram-desktop/telegram-desktop_1.0.0-1.dsc


18.01.2017 19:05, Mattia Rizzolo пишет:

Now, I usually don't sponsor NEW packages for new people without a
record of past contributions to Debian, as I don't trust them to stick
around and actually maintain the package), but I'm inclined to make an
exception to this rule of mine on the basis that I'd love to have this
package for myself (but be aware, I really expct the package to be
maintained…).


I will do my best for that.

By the way, this is my nickname in Telegram: https://t.me/mymedia

18.01.2017 19:22, Andrey Rahmatullin пишет:

Why is it in contrib?


From what I understand, there are packages with dependencies on 
non-free software in contrib section. This program does not work if 
Telegram server is stopped for any reason. But this server is 
proprietary, more accurately, it does not even distribute in public. So 
I thought the package has to be in contrib.  Correct me, please, if I am 
wrong.




Bug#851789: RFS: python-h5netcdf/0.3.1-1 [ITP]

2017-01-18 Thread Ghislain Vaillant
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-h5netcdf"

* Package name: python-h5netcdf
  Version : 0.3.1-1
  Upstream Author : Stephan Hoyer 
* URL : https://github.com/shoyer/h5netcdf
* License : BSD
  Section : python


It builds those binary packages:

 python-h5netcdf - netCDF4 support for Python 2 via h5py
 python3-h5netcdf - netCDF4 support for Python 3 via h5py


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

  https://mentors.debian.net/package/python-h5netcdf


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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-h5netcdf/python-h5netcdf_0.3.1-1.dsc

Or checkout the packaging repository at:

  https://anonscm.debian.org/git/debian-science/packages/python-h5netcdf.git


Changes since the last upload:

  * Initial release. (Closes: #851378)


Regards,
Ghislain Vaillant



Fattura TIM linea Fissa - Gennaio 2017 - scadenza 12/01/2017

2017-01-18 Thread Telecom Italia-TIM
<<< text/html: Unrecognized >>>


Bug#851762: RFS: hamlib/3.1.0-1+nmu1 [NMU]

2017-01-18 Thread Ervin Hegedüs
Hi Adrey,

On Wed, Jan 18, 2017 at 11:16:16PM +0500, Andrey Rahmatullin wrote:
> On Wed, Jan 18, 2017 at 04:57:44PM +0100, Ervin Hegedüs wrote:
> > I'm member of the team (as guest:
> > https://alioth.debian.org/users/airween-guest/). As I wrote, I
> > noticed the team through the list - no response.
> In that case this upload should be a team upload and not a NMU. See
> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu-team-upload

thanks a lot!


a.
 

-- 
I � UTF-8



Bug#851762: RFS: hamlib/3.1.0-1+nmu1 [NMU]

2017-01-18 Thread Andrey Rahmatullin
On Wed, Jan 18, 2017 at 04:57:44PM +0100, Ervin Hegedüs wrote:
> I'm member of the team (as guest:
> https://alioth.debian.org/users/airween-guest/). As I wrote, I
> noticed the team through the list - no response.
In that case this upload should be a team upload and not a NMU. See
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu-team-upload

-- 
WBR, wRAR


signature.asc
Description: PGP signature


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

2017-01-18 Thread Andrey Rahmatullin
Why is it in contrib?

-- 
WBR, wRAR


signature.asc
Description: PGP signature


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

2017-01-18 Thread Mattia Rizzolo
Control: owner -1 !
Control: tag -1 moreinfo

On Wed, Jan 18, 2017 at 04:46:46PM +0300, Коля Гурьев wrote:
>   I am looking for a sponsor for my package "telegram-desktop"

Hi!

I am an heavy user of telegram, and I was looking forward for this
package, despite the privacy concerns, etc.

>   Alternatively, one can download the package with dget using this command:
> 
> dget -x 
> https://mentors.debian.net/debian/pool/contrib/t/telegram-desktop/telegram-desktop_1.0.0-2~rc2.dsc

I will be reviewing this package more deeply, bug few things I can tell
you already:

* changelog for the first upload should use a -1 version, and only
  contain on line "Initial upload.  (Closes: #x)" or somesuch, so
  please get rid of all the rest
* Vcs-* fields should point to a *packaging* repository, not the
  upstream git repo; that said, I'd love to see a git repository used
  for packaging this, this is the tool I prefer for this job:
  http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html
* please use `wrap-and-sort -ast` (or somesuch) to make a diff-frindly
  list of build-deps
* d/rules is incredibly verbose, I can't believe such a thing is needed
  (once I'll look deeply I can tell you more, I just know I'm not happy
  to see such d/rules).
* The bug you reference is still a RFP, you should turn it into an ITP
  https://www.debian.org/devel/wnpp/#howto-rfp if you don't know the BTS
  and how to deal with it, read all of https://www.debian.org/Bugs/ and
  subpages.


Now, I usually don't sponsor NEW packages for new people without a
record of past contributions to Debian, as I don't trust them to stick
around and actually maintain the package), but I'm inclined to make an
exception to this rule of mine on the basis that I'd love to have this
package for myself (but be aware, I really expct the package to be
maintained…).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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#851762: RFS: hamlib/3.1.0-1+nmu1 [NMU]

2017-01-18 Thread Ervin Hegedüs
Hi Adrey,

On Wed, Jan 18, 2017 at 08:35:50PM +0500, Andrey Rahmatullin wrote:
> On Wed, Jan 18, 2017 at 04:29:43PM +0100, Ervin Hegedüs wrote:
> > > Why are doing this NMU?
> > because lintian indicated that I must give NMU as version to that
> > package
> I've meant why are you doing this upload of someone else's package.

because there aren't any member, who did it. Anyway, I just would
like to help to maintain (I've made soma part of the upstream
version, I thought I can help...).

I'm member of the team (as guest:
https://alioth.debian.org/users/airween-guest/). As I wrote, I
noticed the team through the list - no response.
 
> > Okay, thanks for your feedback - what should I do now? 
> As this is a team-maintained package you should join the team and work on
> this package as a team member. 

see above.

> Note though that you have only a week to
> get this package uploaded to sid before the freeze.

I know that, that's why I uploades to mentors.debian.org.
 

a.



Bug#851762: RFS: hamlib/3.1.0-1+nmu1 [NMU]

2017-01-18 Thread Andrey Rahmatullin
On Wed, Jan 18, 2017 at 04:29:43PM +0100, Ervin Hegedüs wrote:
> > Why are doing this NMU?
> because lintian indicated that I must give NMU as version to that
> package
I've meant why are you doing this upload of someone else's package.

> Okay, thanks for your feedback - what should I do now? 
As this is a team-maintained package you should join the team and work on
this package as a team member. Note though that you have only a week to
get this package uploaded to sid before the freeze.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#851762: RFS: hamlib/3.1.0-1+nmu1 [NMU]

2017-01-18 Thread Ervin Hegedüs
Hi,

On Wed, Jan 18, 2017 at 08:15:53PM +0500, Andrey Rahmatullin wrote:
> Control: tags -1 + moreinfo
> 
> Why are doing this NMU?

because lintian indicated that I must give NMU as version to that
package

> Does it fix any bugs?
yes, till I worked on the package, I've found a bug (a binary
package is empty), but I didn't reported that, just fixed it in new
version. I don't know that the Bump-Standard-Version modifaction
is fixup or not.

> Have you read about the NMU
> procedure at
> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu
> and followed it?


yes - post factum (now).

I've made the package about two weeks ago, and wrote a
notification to debian-hams@ list, but still didn't get any
answer.

> Besides, it even has a wrong version suffix.

Okay, thanks for your feedback - what should I do now? 


a.



Bug#851762: RFS: hamlib/3.1.0-1+nmu1 [NMU]

2017-01-18 Thread Andrey Rahmatullin
Control: tags -1 + moreinfo

Why are doing this NMU? Does it fix any bugs? Have you read about the NMU
procedure at
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu
and followed it?
Besides, it even has a wrong version suffix.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#851762: RFS: hamlib/3.1.0-1+nmu1 [NMU]

2017-01-18 Thread Ervin Hegedüs
Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

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

* Package name  : hamlib
Version : 3.1.0-1+nmu1
Upstream Author : Kamal Mostafa , Colin Tuckley 

* URL   : https://sourceforge.net/projects/hamlib/
* License   : LGPLv2
Section : hamradio

It builds those binary packages:

libhamlib++-dev - Development C++ library to control radio transceivers and 
receive
libhamlib-dev - Development library to control radio transceivers and receivers
libhamlib-doc - Documentation for the hamlib radio control library
libhamlib-utils - Utilities to support the hamlib radio control library
libhamlib2 - Run-time library to control radio transceivers and receivers
libhamlib2++c2 - Run-time C++ library to control radio transceivers and 
receivers
libhamlib2-perl - Run-time perl library to control radio transceivers and 
receivers
libhamlib2-tcl - Run-time Tcl library to control radio transceivers and 
receivers
lua-hamlib2 - Run-time Lua library to control radio transceivers and receivers
python-libhamlib2 - Run-time Python library to control radio transceivers and 
receive

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/h/hamlib/hamlib_3.1.0-1+nmu1.dsc

More information about hamlib can be obtained from 
https://sourceforge.net/projects/hamlib/

Changes since the last upload:

 * NMU
 * New upstream release
 * Changed manpages directory in manpage-hyphen-fixes.patch
 * Added Lua binding
 * Fixed broken libhamlib2-tcl package
 * Bump Standards-version to 3.9.8



Regards,
 Ervin Hegedüs



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

2017-01-18 Thread Ole Streicher
Paul Wise  writes:
> On Wed, Jan 18, 2017 at 3:58 PM, Ole Streicher wrote:
>
>> Also when using cowbuilder? At least I see the whole build done by root
>> when running in my cowbuilder chroot. That was the point that lead to
>> the trouble here...
>
> Yep. I tested this with id and override_dh_auto_* in cowbuilder:
>
>  fakeroot debian/rules clean
>debian/rules override_dh_auto_clean
> uid=0(root) gid=0(root) groups=0(root),1234(pbuilder)
>  debian/rules build
>debian/rules override_dh_auto_configure
> uid=1234(pbuilder) gid=1234(pbuilder) groups=1234(pbuilder)
>debian/rules override_dh_auto_build
> uid=1234(pbuilder) gid=1234(pbuilder) groups=1234(pbuilder)
>debian/rules override_dh_auto_test
> uid=1234(pbuilder) gid=1234(pbuilder) groups=1234(pbuilder)
>  fakeroot debian/rules binary
>debian/rules override_dh_auto_install
> uid=0(root) gid=0(root) groups=0(root),1234(pbuilder)

OK, I finally found it: I had a line 

BUILDUSERNAME=

in my .pbuilderrc, which was obviously interpreted as root.

Thanks

Ole



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

2017-01-18 Thread Etienne Dysli-Metref
On 17/01/17 18:30, Niels Thykier wrote:
>>> E: libshibsp7: postinst-must-call-ldconfig 
>>> usr/lib/x86_64-linux-gnu/libshibsp.so.7.0.0
>
> This lintian error:
> 
>  * is aimed at stretch or later, and
>  * should be ignored for stable and stable-backports

After having overridden this lintian error, it turns out it was a bit of
a red herring: piuparts still reports files left after purging.

> 0m39.2s 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.service not owned

So is the postrm script from shibboleth-sp2-utils not executed?



signature.asc
Description: OpenPGP digital signature


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

2017-01-18 Thread Коля Гурьев

Package: sponsorship-requests
  Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "telegram-desktop"

 * Package name: telegram-desktop
   Version : 1.0.0-2~rc2
   Upstream Author : John Preston 
 * URL : https://desktop.telegram.org/
 * License : GPLv3
   Section : net

  It builds those binary packages:

telegram-desktop - official telegram messaging app

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


  https://mentors.debian.net/package/telegram-desktop


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

dget -x 
https://mentors.debian.net/debian/pool/contrib/t/telegram-desktop/telegram-desktop_1.0.0-2~rc2.dsc


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


  Changes since the last upload:

  * Fixed restart when choosing language
  * Made x32 build, but only inside chroot jail
  * Updated README for Debian
  * Renamed binary
  * Solve command-in-menu-file-and-desktop-file problem, fix icon links
  * Solve binary-or-shlib-defines-rpath lintian error
  * Initial build (Closes: #767418)

  Regards,
   Nicholas Guriev



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

2017-01-18 Thread Paul Wise
On Wed, Jan 18, 2017 at 3:58 PM, Ole Streicher wrote:

> Also when using cowbuilder? At least I see the whole build done by root
> when running in my cowbuilder chroot. That was the point that lead to
> the trouble here...

Yep. I tested this with id and override_dh_auto_* in cowbuilder:

 fakeroot debian/rules clean
   debian/rules override_dh_auto_clean
uid=0(root) gid=0(root) groups=0(root),1234(pbuilder)
 debian/rules build
   debian/rules override_dh_auto_configure
uid=1234(pbuilder) gid=1234(pbuilder) groups=1234(pbuilder)
   debian/rules override_dh_auto_build
uid=1234(pbuilder) gid=1234(pbuilder) groups=1234(pbuilder)
   debian/rules override_dh_auto_test
uid=1234(pbuilder) gid=1234(pbuilder) groups=1234(pbuilder)
 fakeroot debian/rules binary
   debian/rules override_dh_auto_install
uid=0(root) gid=0(root) groups=0(root),1234(pbuilder)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Bug#851696: marked as done (RFS: python-qtpy/1.2.0-1)

2017-01-18 Thread Debian Bug Tracking System
Your message dated Wed, 18 Jan 2017 10:18:08 +
with message-id <1484734688.18572.27.ca...@gmail.com>
and subject line Re: Bug#851696: RFS: python-qtpy/1.2.0-1
has caused the Debian Bug report #851696,
regarding RFS: python-qtpy/1.2.0-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.)


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

* Package name: python-qtpy
  Version : 1.2.0-1
  Upstream Author : The Spyder Development Team
* URL : https://github.com/spyder-ide/qtpy
* License : Expat
  Section : python

It builds those binary packages:

  python-qtpy - abtraction layer for PySide/PyQt4/PyQt5 (Python 2)
  python3-qtpy - abtraction layer for PySide/PyQt4/PyQt5 (Python 3)

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

   https://mentors.debian.net/package/python-qtpy

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-qtpy/python-qtpy_1.2.0-1.dsc

Successful build on debomatic:

  
http://debomatic-amd64.debian.net/distribution#unstable/python-qtpy/1.2.0-1/buildlog

Changes since the last upload:

   * Switch to git-dpm
   * New upstream release
   * Bump minimum Python versions (2.7, 3.3)
   * Add new dependency on pyqt5.qtmultimedia
   * Simplify setup for tests in pybuild
   * Drop superfluous Testsuite field
   * Upgrade packaging to debhelper 10
   * Support the nocheck build profile
 - Add versioned dependency on dpkg-dev
 - Mark test dependencies as !nocheck
 - Disable tests if nocheck requested
   * Fix whitespaces in rules file

Regards,
Ghislain Vaillant
--- End Message ---
--- Begin Message ---
Uploaded by Fred Picca--- End Message ---


Bug#851606: RFS: rmlint/2.4.6-1 [ITP]

2017-01-18 Thread Axel Beckert
Hi Carlos,

Carlos Maddela wrote:
>rmlint (2.4.6-1) unstable; urgency=medium
> 
>  * Initial upload to Debian. Thanks to Axel Beckert for getting
>it all started. (Closes: #845155)
> 
> -- Carlos Maddela   Tue, 17 Jan 2017 04:45:28 +1100

Thanks a lot for taking care of the rmlint Debian package!

I'll surely have a look it, but chances are high that I will do so
only after 24th of January due to the imminent freeze in Testing.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



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

2017-01-18 Thread Etienne Dysli-Metref
On 17/01/17 18:30, Niels Thykier wrote:
>>> E: libshibsp7: postinst-must-call-ldconfig 
>>> usr/lib/x86_64-linux-gnu/libshibsp.so.7.0.0
> 
> This lintian error:
> 
>  * is aimed at stretch or later, and
>  * should be ignored for stable and stable-backports

Thanks Niels! :)

That's a bit strange though because I'm running lintian from stable
(2.5.30+deb8u4). It wouldn't surprise me if I were running a more recent
version. I'll create an override for this test in jessie-backports then.

Cheers,
  Etienne



signature.asc
Description: OpenPGP digital signature


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

2017-01-18 Thread Ole Streicher
Paul Wise  writes:
> On Wed, Jan 18, 2017 at 3:37 PM, Boud Roukema wrote:
>
>> I guess by "both of these" you mean "most of the build steps (apart from
>> the 'debian/rules install' step)"?
>
> What I wrote wasn't clear and wasn't strictly true, sorry!
>
> When manually building from source:
>
> You always build/test as a normal user.
> You install as either root or normal user, depending on the install
> prefix.
>
> When doing Debian package builds:
>
> You always build/test as a normal user.
> You always install using fakeroot.

Also when using cowbuilder? At least I see the whole build done by root
when running in my cowbuilder chroot. That was the point that lead to
the trouble here...

Best

Ole



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

2017-01-18 Thread Boud Roukema

On Wed, 18 Jan 2017, Paul Wise wrote:


When manually building from source:

You always build/test as a normal user.
You install as either root or normal user, depending on the install prefix.

When doing Debian package builds:

You always build/test as a normal user.
You always install using fakeroot.


Thanks for the clarification :). That's consistent
with my experience, and seems like reasonable policy.

Cheers
Boud