Bug#810836: RFS: nvme-cli - User space tooling to control NVMe drives.

2016-01-13 Thread Gianfranco Costamagna 
Control: block -1 by 810033

>I am looking for a sponsor for my package "nvme-cli":


Hi Steve, I see you already did a review on the ITP bug, can you please follow
up on this RFS bug?

(RFS bugs are seen by -mentors list, while ITP aren't)

if you aren't going to sponsor the package nevermind then, and thanks in 
advance for the 

first review!

cheers,

Gianfranco

Bug#810870: RFS: propellor/2.15.3-1 -- property-based host configuration management in haskell

2016-01-13 Thread PICCA Frederic-Emmanuel 
accepted :)

Bug#810870: marked as done (RFS: propellor/2.15.3-1 -- property-based host configuration management in haskell)

2016-01-13 Thread Debian Bug Tracking System 
Your message dated Wed, 13 Jan 2016 10:29:44 +
with message-id 

and subject line RE:Bug#810870: RFS: propellor/2.15.3-1 -- property-based host 
configuration management in haskell
has caused the Debian Bug report #810870,
regarding RFS: propellor/2.15.3-1 -- property-based host configuration 
management in haskell
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.)


-- 
810870: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810870
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 a new version of propellor.

* Package name: propellor
  Version : 2.15.3-1
  Upstream Author : Joey Hess 
* URL : https://propellor.branchable.com/
* License : BSD-2-clause
  Section : admin

Changes since the last upload:

  * New upstream version.
  * Fix override of Lintian tag debian-watch-may-check-gpg-signature.

Download with dget:

dget -x 
http://mentors.debian.net/debian/pool/main/p/propellor/propellor_2.15.3-1.dsc

Or build it with gbp:

git clone https://git.spwhitton.name/propellor -b debian
git checkout debian/2.15.3-1
git verify-tag debian/2.15.3-1 # if you have my key
gbp buildpackage -sa

Note to potential sponsor: due to an unorthadox changelog, you must
explicitly pass -sa to either gbp or dpkg-buildpackage in order to
include the *.orig.tar.xz file in your *.changes file.

Thanks.

Sean Whitton


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
accepted :)--- End Message ---

Bug#808141: sponsorship-requests: Dear mentors, I am looking for a sponsor for my package eclipse-titan.

2016-01-13 Thread Pilisi Gergely 
Hi,

sorry for removing the bug from my mail, won't happen again. :)
I'm trying to reproduce this:

"About ditching hardening-wrapped in favour of just using what
dpkg-buildflags do:
whatever I use the .dsc you provided, just removed hardening-wrapper or
enable the hardening build flags using DEB_BUILD_MAINT_OPTIONS, the
build fails with

In file included from jnimw.cc:8:0:
jnimw.h:14:17: fatal error: jni.h: No such file or directory
compilation terminated.
../Makefile.genrules:87: recipe for target 'jnimw.o' failed "

This is a typical error message if the compiler can't find a valid JDK on
your system. Do you have /usr/lib/jvm/default-java on your system?
It's a symlink to the default jdk: default-java -> java-1.7.0-openjdk-amd64
I think if openjdk-7-jdk is installed then then the default-java symlink
must be there.

BR,
Gergely

Bug#810870: RFS: propellor/2.15.3-1 -- property-based host configuration management in haskell

2016-01-13 Thread PICCA Frederic-Emmanuel 
uploaded.

thanks for your work :)

De : Sean Whitton [spwhit...@spwhitton.name]
Envoyé : mercredi 13 janvier 2016 04:19
À : sub...@bugs.debian.org
Objet : Bug#810870: RFS: propellor/2.15.3-1 -- property-based host 
configuration management in haskell

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for a new version of propellor.

* Package name: propellor
  Version : 2.15.3-1
  Upstream Author : Joey Hess 
* URL : https://propellor.branchable.com/
* License : BSD-2-clause
  Section : admin

Changes since the last upload:

  * New upstream version.
  * Fix override of Lintian tag debian-watch-may-check-gpg-signature.

Download with dget:

dget -x 
http://mentors.debian.net/debian/pool/main/p/propellor/propellor_2.15.3-1.dsc

Or build it with gbp:

git clone https://git.spwhitton.name/propellor -b debian
git checkout debian/2.15.3-1
git verify-tag debian/2.15.3-1 # if you have my key
gbp buildpackage -sa

Note to potential sponsor: due to an unorthadox changelog, you must
explicitly pass -sa to either gbp or dpkg-buildpackage in order to
include the *.orig.tar.xz file in your *.changes file.

Thanks.

Sean Whitton

Re: RFS: snetmanmon, a simple network manager and monitor

2016-01-13 Thread Gianfranco Costamagna 
Hi,

>> -format should be 3.0 quilt not native
>
>That doesn't work. I already have had spend time before with trying to 
>use 3.0 and it didn't played well with the build system I'm using for 
>snetmanmon (cmake).


it works, I can confirm you it works, on many projects I maintain.
Maybe you just need to have a source orig tarball?

examples of projects cmake based I maintain in quilt mode: ettercap, casablanca,
websocketpp, hedegewars, cld and many others


>Ah, yes, have forgotten that. But if you'r building snetmanmon from 
>source (and with source I mean its git repository) you already have git 
>installed. I've not spend time to look up how to build a working source 
>package (which would not require git). So something else might be needed 
>for a source package (e.g. a fixed file named 'version').


no. debian builders have no git installed, they have a minimal set of packages, 

and if you want your package to build on debian you need to provide a orig 
tarball,
and set the version somewhere.


>>> override_dh_auto_install:
>>> mkdir -p debian/snetmanmon/etc
>>> cp snetmanmon.conf.full_example  debian/snetmanmon/etc/snetmanmon.conf
>>
>> I would prefer being upstream to install the file in etc,
>> and for sure use of "install" instead of cp
>
>That cp there isn't used to install anything in the target system. It 
>just is used to copy the file into the directory used to build the 

>debian package.

this is non-sense to me, you can't ever install stuff on target system (unless
you go home-by-home and install it :p )

you install on debian/package/ the resulting filesystem of your package, and 
that
is installed with dpkg when the deb file is extracted.

For sure I would appreciate use of "dh_install" such as is done in websocketpp 
package.

but even more I would appreciate your build system (the upstream one)
to do something like
INSTALL(FILES whatever DESTINATION etc)
(look e.g. ettercap/share/CMakeLists.txt)

this will install the stuff in ${DESTDIR}/etc IIRC

and you won't need to override it in rules file, just tweak the install file if 
needed.

the cp e.g. is wrong in many cases, e.g. doesn't set the correct file 
permissions.
if you commit a chmod 755 of a config file on your repository, the file will 
probably end
up with the wrong permissions on user systems.

install -m0644 is better, but cmake install("FILES" should work also on other 
linux distros
(and maybe not only linux of course)


>Reason is the same as I mentioned before in regard to >the copyright. I don't 
>want files with the same content in my source 
>repository just because the debian package build system requires them. 
>That means I want the various example configuration files wherever I 
>seem them to fit in the source repository of snetmanmon, but not where 
>Debian or some other package build system requires them. The resulting 
>package will install them just fine in /etc.


in this case you need (and probably this is the best option) to have the Debian 
packaging separate
from your upstream development, and then use
gbp import-orig orig-tarball to import the new release into your Debian 
packaging
(there is a ton of documentation regarding this)

this way you release your upstream tarball, import it in the Debian packaging 
with quilt, and upload
on debian.

the pro is that you don't have to release a new tarball each time you have to 
deal with a Debian upload
(other Linux distros might not appreciate a release just for Debian changes)

and that you don't have to poison your source tree with "useless files" 
(useless in upstream context).

the cons is that you have to maintain two branches, but at the end it is the 
best feasible approach.


>Will test it. Will see when I find the time.

no problem, take your time :)

the first package is somewhat difficult to achieve ;)

cheers!

Gianfranco

Bug#808141: sponsorship-requests: Dear mentors, I am looking for a sponsor for my package eclipse-titan.

2016-01-13 Thread Pilisi Gergely 
The new package is done, everything is fixed, I hope. I didn't changed
anything in the source, just under the debian/ directory. Should I upload
the package as before or use the dquilt method as
https://www.debian.org/doc/manuals/maint-guide/update suggests?
If I'm right, the update method is for the change in the upstream source,
or?

2016-01-13 12:38 GMT+01:00 Pilisi Gergely :

>
>
> 2016-01-13 12:24 GMT+01:00 Mattia Rizzolo :
>
>>
>> mattia@chase ~ % apt-file search /usr/lib/jvm/default-java
>> default-jre-headless: /usr/lib/jvm/default-java
>>
>> Indeed adding it to build-deps the package builds.
>> Make sure to do your test builds inside a clean chroot.
>>
>
> Oh, just missed this dep, thank you.
>
>
>>
>> BTW, I don't see an update package on mentors (if you meant to upload
>> one).  I can't do much if I can't see what you've done till now :)
>
>
> I want to fix everything what you asked. I'm almost done, just testing the
> copyright part. If it looks good then I'll upload the new package. ;)
> Will back to you soon.
>
>

Bug#808141: sponsorship-requests: Dear mentors, I am looking for a sponsor for my package eclipse-titan.

2016-01-13 Thread Mattia Rizzolo 
On Wed, Jan 13, 2016 at 08:56:55AM +0100, Pilisi Gergely wrote:
> I'm trying to reproduce this:
> 
> "About ditching hardening-wrapped in favour of just using what
> dpkg-buildflags do:
> whatever I use the .dsc you provided, just removed hardening-wrapper or
> enable the hardening build flags using DEB_BUILD_MAINT_OPTIONS, the
> build fails with
> 
> In file included from jnimw.cc:8:0:
> jnimw.h:14:17: fatal error: jni.h: No such file or directory
> compilation terminated.
> ../Makefile.genrules:87: recipe for target 'jnimw.o' failed "
> 
> This is a typical error message if the compiler can't find a valid JDK on
> your system. Do you have /usr/lib/jvm/default-java on your system?
> It's a symlink to the default jdk: default-java -> java-1.7.0-openjdk-amd64
> I think if openjdk-7-jdk is installed then then the default-java symlink
> must be there.

it's not.  Inside the chroot where I build the package:
root@chase:~# ls -l /usr/lib/jvm/
total 0
lrwxrwxrwx 1 root root  20 Dec 12 23:44 java-1.7.0-openjdk-amd64 -> 
java-7-openjdk-amd64
drwxr-xr-x 7 root root 220 Jan 13 11:14 java-7-openjdk-amd64

now, if you need such things, you should build-depend on something that
provides that file.

mattia@chase ~ % apt-file search /usr/lib/jvm/default-java
default-jre-headless: /usr/lib/jvm/default-java

Indeed adding it to build-deps the package builds.
Make sure to do your test builds inside a clean chroot.

BTW, I don't see an update package on mentors (if you meant to upload
one).  I can't do much if I can't see what you've done till now :)

-- 
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#808141: sponsorship-requests: Dear mentors, I am looking for a sponsor for my package eclipse-titan.

2016-01-13 Thread Pilisi Gergely 
2016-01-13 12:24 GMT+01:00 Mattia Rizzolo :

>
> mattia@chase ~ % apt-file search /usr/lib/jvm/default-java
> default-jre-headless: /usr/lib/jvm/default-java
>
> Indeed adding it to build-deps the package builds.
> Make sure to do your test builds inside a clean chroot.
>

Oh, just missed this dep, thank you.


>
> BTW, I don't see an update package on mentors (if you meant to upload
> one).  I can't do much if I can't see what you've done till now :)


I want to fix everything what you asked. I'm almost done, just testing the
copyright part. If it looks good then I'll upload the new package. ;)
Will back to you soon.

boost : no match for call to boost::factory

2016-01-13 Thread Corentin Desfarges 
Dear mentors,

I'm trying to package the new upstream release of FW4SPL for the debian-med
project. But I get this strange error during the build :

[ 19%] Building CXX object
> fwCoreTest/CMakeFiles/fwCoreTest.dir/tu/src/FactoryRegistryTest.cpp.o
> cd /build/fw4spl-0.10.2.2/obj-x86_64-linux-gnu/fwCoreTest && /usr/bin/c++
>   -DBOOST_ALL_DYN_LINK -DBOOST_DEBUG_PYTHON -DBOOST_LINKING_PYTHON
> -DBOOST_THREAD_DONT_PROVIDE_DEPRECATED_FEATURES_SINCE_V3_0_0
> -DBOOST_THREAD_PROVIDES_FUTURE -DBOOST_THREAD_VERSION=2
> -DFWCORETEST_VER=\"0-0\" -DQT_NO_KEYWORDS -DSPYLOG_LEVEL=2 -DWXUSINGDLL
> -D__WXGTK__ -I/build/fw4spl-0.10.2.2/SrcLib/core/fwCore/test/tu/include
> -I/build/fw4spl-0.10.2.2/SrcLib/core/fwCore/include
> -I/build/fw4spl-0.10.2.2/obj-x86_64-linux-gnu/fwCore/include
> -I/build/fw4spl-0.10.2.2/SrcLib/tests/fwTest/include
> -I/build/fw4spl-0.10.2.2/obj-x86_64-linux-gnu/fwTest/include
> -I/build/fw4spl-0.10.2.2/SrcLib/core/fwComEd/include
> -I/build/fw4spl-0.10.2.2/obj-x86_64-linux-gnu/fwComEd/include
> -I/build/fw4spl-0.10.2.2/SrcLib/core/fwCom/include
> -I/build/fw4spl-0.10.2.2/obj-x86_64-linux-gnu/fwCom/include
> -I/build/fw4spl-0.10.2.2/SrcLib/core/fwThread/include
> -I/build/fw4spl-0.10.2.2/obj-x86_64-linux-gnu/fwThread/include
> -I/build/fw4spl-0.10.2.2/SrcLib/core/fwData/include
> -I/build/fw4spl-0.10.2.2/obj-x86_64-linux-gnu/fwData/include
> -I/build/fw4spl-0.10.2.2/SrcLib/core/fwCamp/include
> -I/build/fw4spl-0.10.2.2/obj-x86_64-linux-gnu/fwCamp/include
> -I/build/fw4spl-0.10.2.2/SrcLib/core/fwMemory/include
> -I/build/fw4spl-0.10.2.2/obj-x86_64-linux-gnu/fwMemory/include
> -I/build/fw4spl-0.10.2.2/SrcLib/core/fwTools/include
> -I/build/fw4spl-0.10.2.2/obj-x86_64-linux-gnu/fwTools/include
> -I/build/fw4spl-0.10.2.2/SrcLib/core/fwMedData/include
> -I/build/fw4spl-0.10.2.2/obj-x86_64-linux-gnu/fwMedData/include
> -I/build/fw4spl-0.10.2.2/SrcLib/core/fwRuntime/include
> -I/build/fw4spl-0.10.2.2/obj-x86_64-linux-gnu/fwRuntime/include
> -I/usr/include/libxml2
> -I/build/fw4spl-0.10.2.2/SrcLib/core/fwServices/include
> -I/build/fw4spl-0.10.2.2/obj-x86_64-linux-gnu/fwServices/include
> -I/build/fw4spl-0.10.2.2/SrcLib/core/fwActivities/include
> -I/build/fw4spl-0.10.2.2/obj-x86_64-linux-gnu/fwActivities/include
> -I/build/fw4spl-0.10.2.2/SrcLib/core/fwMath/include
> -I/build/fw4spl-0.10.2.2/obj-x86_64-linux-gnu/fwMath/include
> -I/build/fw4spl-0.10.2.2/SrcLib/core/fwDataCamp/include
> -I/build/fw4spl-0.10.2.2/obj-x86_64-linux-gnu/fwDataCamp/include
> -I/build/fw4spl-0.10.2.2/SrcLib/core/fwDataTools/include
> -I/build/fw4spl-0.10.2.2/obj-x86_64-linux-gnu/fwDataTools/include  -g -O2
> -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2  -Wall -Wextra -Wconversion -Wno-unused-parameter
> -Wno-ignored-qualifiers -fvisibility=hidden --std=c++11   -o
> CMakeFiles/fwCoreTest.dir/tu/src/FactoryRegistryTest.cpp.o -c
> /build/fw4spl-0.10.2.2/SrcLib/core/fwCore/test/tu/src/FactoryRegistryTest.cpp
> In file included from
> /usr/include/boost/function/detail/maybe_include.hpp:18:0,
>  from
> /usr/include/boost/function/detail/function_iterate.hpp:14,
>  from
> /usr/include/boost/preprocessor/iteration/detail/iter/forward1.hpp:52,
>  from /usr/include/boost/function.hpp:64,
>  from
> /build/fw4spl-0.10.2.2/SrcLib/core/fwCore/include/fwCore/util/FactoryRegistry.hpp:13,
>  from
> /build/fw4spl-0.10.2.2/SrcLib/core/fwCore/test/tu/src/FactoryRegistryTest.cpp:10:
> /usr/include/boost/function/function_template.hpp: In instantiation of
> 'static R boost::detail::function::function_obj_invoker1 T0>::invoke(boost::detail::function::function_buffer&, T0) [with
> FunctionObj = boost::factory; R =
> std::shared_ptr; T0 =
> std::__cxx11::basic_string]':
> /usr/include/boost/function/function_template.hpp:940:38:   required from
> 'void boost::function1::assign_to(Functor) [with Functor =
> boost::factory; R =
> std::shared_ptr; T0 =
> std::__cxx11::basic_string]'
> /usr/include/boost/function/function_template.hpp:728:7:   required from
> 'boost::function1::function1(Functor, typename
> boost::enable_if_c::value,
> int>::type) [with Functor =
> boost::factory; R =
> std::shared_ptr; T0 =
> std::__cxx11::basic_string; typename
> boost::enable_if_c::value,
> int>::type = int]'
> /usr/include/boost/function/function_template.hpp:1077:16:   required from
> 'boost::function::function(Functor, typename
> boost::enable_if_c::value,
> int>::type) [with Functor =
> boost::factory; R =
> std::shared_ptr; T0 =
> std::__cxx11::basic_string; typename
> boost::enable_if_c::value,
> int>::type =

Re: boost : no match for call to boost::factory

2016-01-13 Thread Gianfranco Costamagna 
Hi,

>I'm trying to package the new upstream release of FW4SPL for the debian-med 
>project. But I get this strange error during the build :
>
>(std::__cxx11::basic_string)'>   return 
>(*f)(BOOST_FUNCTION_ARGS);
>Is someone have any idea about the cause of this issue ?
>The concerned lines of FW4SPL haven't changed, and I didn't have any problem 
>in the past, with an older boost version.



I saw many of the __cxx11 issues when I did some work in libstdc++ transition.
If you have such issues, it might mean that some dependencies you use in your 
build-depependencies didn't get rebuilt on top of the new gcc-5, or that
the transition changed some other prototypes somewhere.
I can't help more, with alioth down, and a missing complete build log.

cheers,

G.

Bug#810012: RFS: averell/1.2.4-1 ITP 773793

2016-01-13 Thread Gianfranco Costamagna 
control: tags -1 moreinfo

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

please address the lintian warnings you have, open an ITP, rebase the changelog 
in
a since -1 entry and then remove the moreinfo tag


(I'm not sure I'll sponsor the package, since I know almost nothing about 
erlang)

thanks,

Gianfranco





Il Martedì 5 Gennaio 2016 15:57, Jean Parpaillon  ha 
scritto:
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "averell"
Package name: averell
Version : 1.2.4-1
Upstream Author : Jean Parpaillon
URL : https://github.com/jeanparpaillon/averell
License : Apache 2
Section : httpd

It builds those binary packages:

   averell- An incredibly stupid web server

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

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


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

dget -x http://mentors.debian.net/debian/pool/main/a/averell/averell_1.
2.4-1.dsc

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

Changes since the last upload:

* Allow .avlaccess file for per-dir configuration
* Migrate to cowboy 2.0
* Build with Makefile instead of rebar


Regards,
Jean Parpaillon

Bug#810921: RFS: rep-gtk/1:0.90.8.2-1 [ITA] -- GTK+ binding for librep

2016-01-13 Thread Mattia Rizzolo 
control: owner -1 !
control: tag -1 moreinfo


On Wed, Jan 13, 2016 at 07:12:38PM +, Jose M Calhariz wrote:
> A long time ago I tried to adopt sawfish and is build-depends.  But my
> main sponsor being too busy for helping me.  So I am searching for
> someone that can help sponsor the packages, close the ITA and help me
> fix the last bits for making the packages fit for Debian.

I'll take care of this one too.

-- 
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#810921: RFS: rep-gtk/1:0.90.8.2-1 [ITA] -- GTK+ binding for librep

2016-01-13 Thread Jose M Calhariz 
Package: sponsorship-requests
Severity: normal

A long time ago I tried to adopt sawfish and is build-depends.  But my
main sponsor being too busy for helping me.  So I am searching for
someone that can help sponsor the packages, close the ITA and help me
fix the last bits for making the packages fit for Debian.

The packages are very old.  I can't update sawfish without updating
it's build-depends.  The latest changes are on collab-maint.  I am
reviewing the packages one more time.  So expect more small changes.

 * Package name: rep-gtk
   Version : 1:0.90.8.2-1
   Upstream Author : Christopher Bratusek
 * URL : http://download.tuxfamily.org/librep/rep-gtk/
 * License : GPL
   Section : lisp


-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Bug#809623: RFS: telegram-purple/1.2.3-1

2016-01-13 Thread BenWiederhake.GitHub 

Hello,


They generate the orig tarball.
The watchfile is to check for the newest version.
These are unrelated things.


no. they are completely related things.
uscan downloads the tarball from the watch file, and if the uscan downloaded 
tarball doesn't fit your needs
you have to call the repack script directly from the watch file.
with a get-orig-source target
https://wiki.debian.org/onlyjob/get-orig-source


Oh, wow. This will take a bit time until I grasp everything well enough 
to publish something with this :P


Most prominently, I don't like the "everythingisoneline" approach of the 
watchfile. I guess someone has already suggested changing it to the 
"usual" YAML-based approach?



this is my virtualbox watch file

version=3

opts=downloadurlmangle=s/^/http:/,dversionmangle=s/-dfsg\d*$//,uversionmangle=s/-.*//
 \
http://download.virtualbox.org/virtualbox/([\d\.\-]+)/VirtualBox-([\d\.\-]+).tar.bz2
 \
debian /bin/sh debian/get-orig-source.sh


I... I believe I understand this. However, testing this will be a pain, 
and automatic testing probably impossible.


Is there some kind of established "best practice" for testing these? Or 
is the best practice just to "run by hand until it works, then wait 
until it breaks for DEHS"?



I know and agree that d/genorigtar.sh and d/rawtar are ugly, and they
will be dropped in the next version, in favor of relatively clean
chaining of git-archive and tar --concatenate.
(Obviously not part of the build process, so no need to put any of that
into Build-Depends.)


sure, even better, maybe if you integrate with watch file.


I can do that, sure. Can you tell me who profits from this, though? It's 
a bit demoralizing to have to write and test things like these if noone 
will ever profit from this.


I understand that d/watch is needed by DEHS to monitor how outdated the 
Debian repository is, in some sense. So I wrote a d/watch for that, and 
made sure it works and will continue to work.


I also understand that some maintainers prefer working with uscan to 
fetch and integrate the newest upstream version. But that doesn't apply 
here, as the preferred mode of updating is doing a "git pull".


My script would probably do the following thing:
- delete the file fetched by uscan, since it's utterly incomplete
- use the upstream version to clone (as in git-clone) the repository
- ./configure && make dist || (echo "Too old upstream version; doesn't 
support orig tarballs yet."; exit 1)

- delete all temporary files
Ugh.

And all that so that someone can say "dh get-orig-source".
So, who does this? (And can I assume git to be installed? I don't like 
having such a big b-d ...)



BTW submodules should in my opinion be considered as different sources, and 
packaged
separately.
Otherwise you will have a mess of files with no common history, difficult to 
track and fix
(specially for security issues)


Already extensively documented in d/README.source

In short, the reason is: tgl ("the" submodule) is way too unstable and 
volatile to ever be packaged separately.


There is only one other program that might enter the Debian repository 
(tg-cli, I don't see any RFP or ITP for it) will never be used together 
with telegram-purple, and will most definitely never use a compatible 
version of tgl.



Currently, we assume that the builder eventually invokes ./configure
with whatever arguments he pleases and the usual semantics. This
approach does not need anything explicit in d/rules.
autoreconf is only called when we change configure.ac, in which case the
new configure-script will be put into git. At no point, there's a need
for the "user" (here: builder) to call auto{,re}conf.



Oh. Maybe the entry "autotools-dev" in Build-Depends is superfluous, then?


exactly, but you need to call autoreconf each time you configure the script.
it might sound silly to you,  but in case a new architecture is added in Debian
(e.g. recent ppc64el and arm64), your scripts will be outdated,


None of our scripts assume any architecture or have a list of all of 
them. What part of which script would become "outdated"? What would change?



BTW the version should always be a -1 revision, until the -1 reaches debian 
(specifically new queue)


Hmm, but this makes it easier for me to track which versions there were.

But okay, I'll push the next version as 1.2.4-1 if you wish.


you don't have to bump the debian revision, this will make harder for a sponsor 
to track it, and
useless for Debian users (they won't find the intermediate releases)


Huh? I'm confused. I make sure that all versions have a different 
number, and go increasing as per dpkg --compare-versions. Why is it 
*harder* to track progress?


I mean, sure, I can change my behavior regarding that, I just think it's 
a good idea if I also know the reason for it :P


Regards,
Ben

Bug#809623: RFS: telegram-purple/1.2.3-1

2016-01-13 Thread Gianfranco Costamagna 
Hi again,



>Oh, wow. This will take a bit time until I grasp everything well enough 
>to publish something with this :P
>
>Most prominently, I don't like the "everythingisoneline" approach of the 
>watchfile. I guess someone has already suggested changing it to the 
>"usual" YAML-based approach?


you should just call uscan [--debug] and have your new tarball ready to go

>I... I believe I understand this. However, testing this will be a pain, 
>and automatic testing probably impossible.
>
>Is there some kind of established "best practice" for testing these? Or 
>is the best practice just to "run by hand until it works, then wait 
>until it breaks for DEHS"?


I don't follow, uscan just calls the script you are calling manually, and in
addition it calls it with the parameters (version and so on).

you just need to look at vbox get-orig-source script, it should be easy to 
understand

>I can do that, sure. Can you tell me who profits from this, though? It's 
>a bit demoralizing to have to write and test things like these if noone 
>will ever profit from this.


other people will be able to look at the sources, integrate a new release
without having to know how exactly all of this works
>I understand that d/watch is needed by DEHS to monitor how outdated the 
>Debian repository is, in some sense. So I wrote a d/watch for that, and 
>made sure it works and will continue to work.


sure, but adding a script called, it doesn't break that part

>I also understand that some maintainers prefer working with uscan to 
>fetch and integrate the newest upstream version. But that doesn't apply 
>here, as the preferred mode of updating is doing a "git pull".


this might make sense then :)

>My script would probably do the following thing:
>- delete the file fetched by uscan, since it's utterly incomplete
>- use the upstream version to clone (as in git-clone) the repository
>- ./configure && make dist || (echo "Too old upstream version; doesn't 
>support orig tarballs yet."; exit 1)
>- delete all temporary files
>Ugh.


seems an overkill :)

>And all that so that someone can say "dh get-orig-source".
>So, who does this? (And can I assume git to be installed? I don't like 
>having such a big b-d ...)


git is needed for everybody who wants to work on Debian, not needed
to be a b-d :)

>Already extensively documented in d/README.source


ack
>In short, the reason is: tgl ("the" submodule) is way too unstable and 
>volatile to ever be packaged separately.


this makes sense even if it should be avoided, but it is up to your sponsor
that part :)

>There is only one other program that might enter the Debian repository 
>>(tg-cli, I don't see any RFP or ITP for it) will never be used together 
>with telegram-purple, and will most definitely never use a compatible 
>version of tgl.


ok

>None of our scripts assume any architecture or have a list of all of 
>them. What part of which script would become "outdated"? What would change?


I don't remember, config.sub and config.guess were outdated in many packages 
because
of missing autotools-dev and autoreconf.

I don't think this harms somewhere, so why not run it automatically?

(I'm a cmake guy, I can't provide a better rationale, I run it because it 
works(TM))
>Hmm, but this makes it easier for me to track which versions there were.
>
>But okay, I'll push the next version as 1.2.4-1 if you wish.


no problem, you can bump the revision, just when the package will be ready 
somebody will
have to merge everything in a single -1 revision and upload on unstable

>Huh? I'm confused. I make sure that all versions have a different 
>number, and go increasing as per dpkg --compare-versions. Why is it 
>*harder* to track progress?
>
>I mean, sure, I can change my behavior regarding that, I just think it's 
>a good idea if I also know the reason for it :P


nah it is fine, just I like to press "CTRL+R" telegram-purple, find the dget 
line
and press enter :)

too lazy to go on mentors, search the last revision, copy-paste the link and 
then dget
(for this git is better for sure)

cheers,

Gianfranco

Re: RFS: snetmanmon, a simple network manager and monitor

2016-01-13 Thread Wookey 
+++ Alexander Holler [2016-01-12 21:04 +0100]:
> Am 11.01.2016 um 21:22 schrieb Gianfranco Costamagna:
> 
> >and fix the below:
> >-changelog: one single entry with "initial debian version or whatever and 
> >Closes: #ITP bug"
> >-control: seems fine, you can drop the debug package now that Debian has 
> >ddbg infrastructure
> >(automatic debug packages creation)
> >  std-version should be 3.9.6
> 
> Can do that.
> 
> >-format should be 3.0 quilt not native
> 
> That doesn't work. I already have had spend time before with trying to use
> 3.0 and it didn't played well with the build system I'm using for snetmanmon
> (cmake).

I've not been following this thread, so may be off the mark, but just
thought I should say that I've just uploaded about 50 packages which
use quilt 3.0 and cmake (and are built from git with git-buildpackage)
http://anonscm.debian.org/cgit/debian-science/packages/ros

It works fine, although you do need to use 
dpkg-source --after-build .
to tidy up build artifacts before doing clean builds in sbuild for some 
packages.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Bug#810950: RFS: ecere-sdk/0.44.14-1 -- Please sponsor this bug fix release to the Ecere SDK

2016-01-13 Thread Jérôme St-Louis 

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for this new release to my package "ecere-sdk".
This addresses build reproducibility issues, a bug causing the M68K 
build to fail, and improved dependencies that should allow building on 
additional platforms.


* Package name: ecere-sdk
   Version : 0.44.14-1
   Upstream Author : Ecere Corporation 
* URL : http://ecere.org
* License : BSD-3 clauses
  Section : Development

It builds those binary packages:

ecere-dev - Ecere SDK Development Tools
ecere-extras - Extras for the Ecere SDK
ecere-samples - Project samples for the Ecere SDK
ecere-sdk - Ecere cross-platform SDK
libecc0 - eC Compiler Library
libecere0 - Ecere Runtime Library
libecereaudio0 - Ecere Audio
libecerecom0 - eC Core Runtime Library
libeda0 - Ecere Data Access
libedasqlite0 - EDA SQLite Driver

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

  http://mentors.debian.net/package/ecere-sdk


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

  dget -x 
http://mentors.debian.net/debian/pool/main/e/ecere-sdk/ecere-sdk_0.44.14-1.dsc


  More information about the Ecere SDK can be obtained from 
http://ecere.org


  Changes since the last upload:


ecere-sdk (0.44.14-1) unstable; urgency=low

   * Packaged Ecere SDK 0.44.14
   * Fixed control file to build if upx-ucl is not available
   * Made dependency on linux-libc6-dev specific to Linux
   * Changes:
  - Addresses build reproducibility issues
  - Fixed compiler bug causing build to fail on M68K
  - Documentor: Minor fixes
  - Spelling fixes
  - GUI/ListBox: Fixed clearing cell data

 -- Jerome St-Louis   Wed, 13 Jan 2016 22:00:00 -0500


  Regards,

 Jerome St-Louis

Bug#810921: RFS: rep-gtk/1:0.90.8.2-1 [ITA] -- GTK+ binding for librep

2016-01-13 Thread Mattia Rizzolo 
On Wed, Jan 13, 2016 at 07:12:38PM +, Jose M Calhariz wrote:
>  * Package name: rep-gtk

ok, let the party begin! :)

* you removed a old transition package.
  + \o/ yay less cruft in the archive!
  + FYI, I confirmed by `dak rm -Rbn rep-gtk-gnome` that it is a leaf
package.
  + also please remove debian/rep-gtk-gnome.NEWS
* debian/control:
  + a version costriction in a Suggest is really useless.  As in, you
have no assurances *at all* that it'll be followed.
But then, you build-dep on librep >= $version, so you'll get a
depends on that version, so not all might be lost :)
tl;dr: you don't need to do anything here, but be aware that
versioned Suggests are meaningless.
  + the build-dep on autotools-dev is useless, please remove it.
  + I still get vcs-field-not-canonical by lintian.  indeed Vcs-Git is
wrong (there is a /git/ too much in the middle).  otherwise, you
might want to use https:// for Vcs-Git too instead of the dumb
git://.  As you prefer.
  + I have a extended-description-is-probably-too-short, please fix.
* debian/changelog:
  + 2 trailing whitespaces at line 4.
  + "remove upstream debian directory" ???  what's this?
  + "New localization of files for package rep-gtk." and this?
  + "Replace sed command by dh_listpackages." this is not there anymore
  + "Merge the packaging work of Christopher Roy Bratusek." be more
verbose in this.  short dh, compat 9, dep5, blablabla
  + s/read ability/readability/ maybe?
  + mention the removal of rep-gtk-gnome.
  + you need to target experimental, unstable won't be able to satisfy
the dependency on librep until the transition start (where you'll
need to re-upload the packages on unstable.  actually it would be
enough to have them ready, bug given that there are a lot of
changes, and you are a sponsored person where there are reviews
going on, better have them in experimental, and re-upload them in
unstable later).
* debian/rules:
  + override_dh_configure is unneed.  as I said with librep, those flags
are already exported in compat 9.
- also , there is trailing whitespace here, but if you remove the
  whole line...
  + override_dh_install just to call dh_install ? ;)
  + override_dh_installexamples => be aware you can also write the
directory name in debian/examples (up to you if you prefer small
files in debian/ or lines in d/rules)
  + don't DH_VERBOSE need to be exported to work?
* you're building static libraries.  Do you really need them?  In Debian
  we don't like static libraries.  Given that this is a standard autofoo
  package, --disable-static to configure should do the trick.
  + this will also get rid of unstripped-static-library and
non-empty-dependency_libs-in-la-file lintian tags.
* something to say about https://bugs.debian.org/680449 ?


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

Re: Changing maintainer for package in mentors

2016-01-13 Thread Ben Wiederhake 

Initially, Hugues Morrisset was entered as Maintainer and Ben Wiederhake
(me) as Uploader in debian/rules. However, Hugues has gone inactive and
agreed that I take the lead in debianizing telegram-purple. But now
mentors won't let me do anything, because I'm not the maintainer in the
eyes of the system.


yes, this is a known issue, because e.g. you can't remove the package,
but I guess it is a "non-issue"
because the package content should be correct anyway.


The package *content* is correct, true. But not the metadata!


For the record, in case someone has the same issue again:
Ask the "Maintainer" (in my case: Hugues Morrisset) to delete the 
package, wait a minute, and upload it again from the right account. This 
seems to reset all metadata in mentors.


With regards
Ben Wiederhake

Bug#809623: RFS: telegram-purple/1.2.3-1

2016-01-13 Thread Gianfranco Costamagna 
Hi,

>
>Seems like it, true, but sadly is necessary. The package is in version 
>control, and unless we provide pre-bundled origtars somewhere (which 
>won't happen), this has to build the origtar by invoking "make dist" in 
>the source tree.


why you cant provide pre-bundled origtars? I know some project that does 
exactly the same.

they have submodules and when they tag a new release, they also upload the 
version together
with the "minimal" one

e.g.
https://github.com/vslavik/poedit/releases

>Now this is getting absurd: the whole point of dh get-orig-source is to 
>>support people for who "git pull" is too complicated. But suddenly I can 
>assume that git is installed, although git is not pulled by build-essential?


I'm not talking about buildd machines. uscan usually is called by *developers*
who want to try to build the package.

e.g. a normal user does apt-get source telegram-purple (because it is outdated
and he want the new and shiny version)

he do the apt-get source, he do the uscan --debug, and at the end he can build
everything (maybe an uupdate).
(let us assume the new release doesn't need packaging changes of course)

>Well, either that, or roughly 8 packages that are absolutely and utterly 
>useless building libtgl. (I'm not overestimating! 3 packages for 
>tl-parser and tgl each, plus 2 packages for "generate")
>
>I agree with you that this should be avoided at *most* costs, but not at 
>*all* costs.


I fully agree there, if it can be avoided fine, but if not... we should deal
with a common sense and a trade-off.

Now I come with a question.
You want to maintain the package only in Debian? or in all linux distro around 
the globe?

you are doing the repack work as Debian work, this means that other linux 
derivatives
won't ever gain from the work, and they will need to do it again.

Pushing the tarball (complete and reduced) upstream, will save a lot of work 
for everybody



and simplify a lot the Debian packaging
(just a simple watch file, with no repack at all).

Do you agree on this point?
(I'm not saying my POV is the correct one, but sometimes Upstream and Debian 
have to fight a little
bit and find a common way :) )

cheers!

Gianfranco

Bug#809623: RFS: telegram-purple/1.2.3-1

2016-01-13 Thread BenWiederhake.GitHub 

Control: tags -1 - moreinfo

Hello,

thanks for taking a look at this package :D


I'm not sure if anybody picked up the work for this bug, but lets do
another review:

- -please drop commented default stuff from rules file
- -please merge changelog in one single entry
  (also "mentors" is not a target series)


These (and only these; see below) are already fixed in 1.2.4-2, which 
was uploaded 8 days ago [1]


I guess I did something wrong if you haven't seen that, even though I 
thought it should be done this way. Can you tell me what I should do 
differently next time?



- -please drop rawtar and genorigtar.sh, they seem useless with the
current watch file.


They generate the orig tarball.
The watchfile is to check for the newest version.
These are unrelated things.

As already documented in d/README.source, the orig-tarball can't be 
gathered from the obvious sources:

- Github (definitely)
- pristine-tar (definitely)
- git-buildpackage (afaik)
They all fail for the same reason: missing support for submodules within 
submodules. (Or gbp simply requires more setup than I thought.)


I know and agree that d/genorigtar.sh and d/rawtar are ugly, and they 
will be dropped in the next version, in favor of relatively clean 
chaining of git-archive and tar --concatenate.
(Obviously not part of the build process, so no need to put any of that 
into Build-Depends.)



- -please use autoreconf and b-d on dh-autoreconf if possible


I'm not entirely sure what you mean by this.

Currently, we assume that the builder eventually invokes ./configure 
with whatever arguments he pleases and the usual semantics. This 
approach does not need anything explicit in d/rules.
autoreconf is only called when we change configure.ac, in which case the 
new configure-script will be put into git. At no point, there's a need 
for the "user" (here: builder) to call auto{,re}conf.


Oh. Maybe the entry "autotools-dev" in Build-Depends is superfluous, then?

On a side note: 1.2.4 isn't going to make it anyway. Apparently, it's 
horribly unstable on Windows.


Regards,
Ben Wiederhake
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809623#79

Bug#809623: RFS: telegram-purple/1.2.3-1

2016-01-13 Thread Gianfranco Costamagna 
Hi,



>These (and only these; see below) are already fixed in 1.2.4-2, which 
>was uploaded 8 days ago [1]


dget -u 
http://mentors.debian.net/debian/pool/main/t/telegram-purple/telegram-purple_1.2.4-2.dsc

this is the file I downloaded now and it looks better.

Maybe when you have too many versions, you can consider deleting the package 
from mentors and uploading it
again, just to avoid sponsors to download an older version


>I guess I did something wrong if you haven't seen that, even though I >thought 
>it should be done this way. Can you tell me what I should do 

>differently next time?

maybe delete and reupload :)
but honestly it was my fault, I didn't look at the whole RFS bug thread.

>They generate the orig tarball.
>The watchfile is to check for the newest version.
>These are unrelated things.


no. they are completely related things.
uscan downloads the tarball from the watch file, and if the uscan downloaded 
tarball doesn't fit your needs
you have to call the repack script directly from the watch file.
with a get-orig-source target
https://wiki.debian.org/onlyjob/get-orig-source

this is my virtualbox watch file

version=3

opts=downloadurlmangle=s/^/http:/,dversionmangle=s/-dfsg\d*$//,uversionmangle=s/-.*//
 \
http://download.virtualbox.org/virtualbox/([\d\.\-]+)/VirtualBox-([\d\.\-]+).tar.bz2
 \
debian /bin/sh debian/get-orig-source.sh
>As already documented in d/README.source, the orig-tarball can't be 
>gathered from the obvious sources:
>- Github (definitely)
>- pristine-tar (definitely)
>- git-buildpackage (afaik)
>They all fail for the same reason: missing support for submodules within 
>submodules. (Or gbp simply requires more setup than I thought.)


ok this seems legit then :)

>I know and agree that d/genorigtar.sh and d/rawtar are ugly, and they 
>will be dropped in the next version, in favor of relatively clean 
>chaining of git-archive and tar --concatenate.
>(Obviously not part of the build process, so no need to put any of that 
>into Build-Depends.)


sure, even better, maybe if you integrate with watch file.

BTW submodules should in my opinion be considered as different sources, and 
packaged
separately.
Otherwise you will have a mess of files with no common history, difficult to 
track and fix
(specially for security issues)

>I'm not entirely sure what you mean by this.
>
>Currently, we assume that the builder eventually invokes ./configure 
>with whatever arguments he pleases and the usual semantics. This 
>approach does not need anything explicit in d/rules.
>autoreconf is only called when we change configure.ac, in which case the 
>new configure-script will be put into git. At no point, there's a need 
>for the "user" (here: builder) to call auto{,re}conf.

>Oh. Maybe the entry "autotools-dev" in Build-Depends is superfluous, then?


exactly, but you need to call autoreconf each time you configure the script.
it might sound silly to you, but in case a new architecture is added in Debian
(e.g. recent ppc64el and arm64), your scripts will be outdated, and just 
rebuilding the package
with an updated toolchain will make them build on new architectures.

so, b-d on dh-autoreconf and call --with autoreconf from the default dh call

>On a side note: 1.2.4 isn't going to make it anyway. Apparently, it's 
>horribly unstable on Windows.


who cares? :)

I mean, if the bugs are windows-only related this shouldn't be a stopper for 
Debian

BTW the version should always be a -1 revision, until the -1 reaches debian 
(specifically new queue)

you don't have to bump the debian revision, this will make harder for a sponsor 
to track it, and
useless for Debian users (they won't find the intermediate releases)

cheers,

G.

Bug#810853: RFS: moosefs/2.0.83-1 [ITP] -- fault tolerant, reliable, highly available, highly performing, scaling-out network distributed file system)

2016-01-13 Thread Paul Wise 
On Wed, Jan 13, 2016 at 5:17 AM, Piotr Robert Konopelko wrote:

> I forgot to mention, that there is a fork of MooseFS in Debian repository 
> already, called LizardFS.

Please let the security team know so that they can add the fork to
their code copies metadata.

https://wiki.debian.org/EmbeddedCodeCopies

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#808141: sponsorship-requests: Dear mentors, I am looking for a sponsor for my package eclipse-titan.

2016-01-13 Thread Gianfranco Costamagna 
Hi,
>The new package is done, everything is fixed, I hope. I didn't changed 
>anything in the source, just under the debian/ directory. Should I upload the 
>package as >before or use the dquilt method as 
>https://www.debian.org/doc/manuals/maint-guide/update suggests?
>If I'm right, the update method is for the change in the upstream source, or?


please read

http://mentors.debian.net/intro-maintainers

(TL:TR)
gbp buildpackage -S -sa
dput mentors ../filename_foo_source.changes


cheers

G.

Bug#808141: sponsorship-requests: Dear mentors, I am looking for a sponsor for my package eclipse-titan.

2016-01-13 Thread Mattia Rizzolo 
On Wed, Jan 13, 2016 at 02:44:25PM +0100, Pilisi Gergely wrote:
> Hi,
> 
> the new package is available on the mentors site:

ok, new iteration :)

1)
Well, I'm conviced that --verbose passed to dh is not what I had in mind
with "verbose building".
I still see

  (C++)  Object.cc
  (CC)   record.c
  (C++)  OCSV.cc
  (CC)   record_of.c
  (CC)   union.c
  (C++)  Tag.cc
  (C++)  PredefFunc.cc
  (C++)  TableConstraint.cc
  (C++)  AST.cc
  (C++)  TokenBuf.cc

that's ↑ not's verbose at all.

Here's an hint for you: this a makefile-based project.  to have GNU make
be more verbose, is enough to export V=1.  This gave me indeed a verbose
output of compilation flags, but somehow the build failed this way (??).
It's very easy to make this program fail to build, feel fragile...

2)
hardening-wrapper can just go away, the package builds fine anyway.
The canonical way to have hardening buildflags is to export
DEB_BUILD_MAINT_OPTIONS=hardening=+all in d/rules (instead of
DEB_BUILD_HARDENING).
Having a look at Makefile.cfg I see:
* CFLAGS ain't used (instead there is a CCFLAGS variable);
* CXXFLAGS ignores the external env.
You may need to patch it a bit.

3)
please fix the following lintian warnings:
W: eclipse-titan: script-with-language-extension usr/bin/ttcn3_archive.pl
I: eclipse-titan: package-contains-empty-directory usr/share/titan/etc/asciiart/
W: eclipse-titan: manpage-has-errors-from-man 
usr/share/man/man1/ttcn3_logfilter.1.gz 11: warning: macro `..' not defined
W: eclipse-titan: manpage-has-errors-from-man 
usr/share/man/man1/ttcn3_logformat.1.gz 54: a space character is not allowed in 
an escape name
W: eclipse-titan: executable-not-elf-or-script usr/bin/ttcn3_archive.pl

4)
there are a bunch of debug-file-with-no-debug-symbols and that
postinst-has-useless-call-to-ldconfig that makes me itch.  I feel there
is something weird going on, but I wouldn't know what it is.

5)
do you even look at what lintian says on mentors?
I: eclipse-titan source: wildcard-matches-nothing-in-dep5-copyright 
mctr2/editline (paragraph at line 5)
I: eclipse-titan source: unused-file-paragraph-in-dep5-copyright paragraph at 
line 5

the order of the paragraphs in d/copyright is important.  the wildcard
in the second paragraph overrides the first.  so you need to swap them.
Furthermore I don't see a paragraph for debian/, as I can read it now
the copyright for debian/* is of "Ericsson Telecom AB".




-- 
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#809623: RFS: telegram-purple/1.2.3-1

2016-01-13 Thread Gianfranco Costamagna 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Control: tags -1 moreinfo

Hi,

I'm not sure if anybody picked up the work for this bug, but lets do
another review:

- -please drop commented default stuff from rules file
- -please use autoreconf and b-d on dh-autoreconf if possible
- -please merge changelog in one single entry
 (also "mentors" is not a target series)
- -please drop rawtar and genorigtar.sh, they seem useless with the
current watch file.

note: I didn't test the program, there is something to fix
before :)

cheers,

G.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWll34AAoJEPNPCXROn13ZIwYQAJSU1K6/dQ9rwgRIdWbUtwKn
hsJwLIwDO+dMMpMt8X925SveoyQxsivMyASZ6lDr2C6GySEdgsTBl4gnqebSeYrh
BkjD37jEcAMeGWxVLsGWnEeTdU1viMHziPSNcebZE7OdP6dLesSW4B/iBCqQ2WCd
ZXhYHZ8Yo2hF9/5u3X1Prfnjnuyo4rCZnTxQLeES1whgEqK+Vo0lX89k91JYWPiJ
XHAHOSuP4yrpdYPFSVbB+HrjbHZWqFeBdfCrxOqTtWqH+XMJ4zjW4TCdIaVieUib
8HrZH4yVJx/1gY5RUUxEeamA72lxByvnJeGPhpaW6XAtX8TSn425BAVaEeb0suq3
gzVmNtps5wphXexJpqXMJJkxA13YSCHCq+5YC1sS68EFrOb4mUsfL7njrQB46HGU
ZHccEcewD/6e1Yv+lSTOdej3wMfcfyflDBGCLg+x5s+wHSeSXwL/y5VxNlSqBIW/
va9ZW6SoN702oTnY/khyL1yY6USqfbW2HZUbLTbHmfzSBEK2FdoAzOGDhXrGeXmX
Sgnne6Gluv0Y+9Tyf85JbiU9pyGZft8w7HnlJkFi3DsW1oQ5UmFm11TP3nsFIvPR
LrIDAzU/lc7YzWEOfrvZQTCI3jturV19fAOxJ8/4Be0KBSppuZt7msvK4VyUep8H
bKy4Ye3PgqIdIXNoahXW
=AOmJ
-END PGP SIGNATURE-

Bug#810853: RFS: moosefs/2.0.83-1 [ITP] -- fault tolerant, reliable, highly available, highly performing, scaling-out network distributed file system)

2016-01-13 Thread Piotr Robert Konopelko 

> On 13 Jan 2016, at 3:53 PM, Paul Wise  wrote:
> 
> On Wed, Jan 13, 2016 at 5:17 AM, Piotr Robert Konopelko wrote:
> 
>> I forgot to mention, that there is a fork of MooseFS in Debian repository 
>> already, called LizardFS.
> 
> Please let the security team know so that they can add the fork to
> their code copies metadata.
> 
> https://wiki.debian.org/EmbeddedCodeCopies

Thanks for the suggestion, I just posted info to:

debian-security-trac...@lists.debian.org


Best regards,

-- 
Piotr Robert Konopelko

Bug#809642: sponsorship-requests: RFS: digikam/4:4.14.0-1.1~bpo8+1 [NMU]

2016-01-13 Thread Gianfranco Costamagna 
Hi,
I did a dch --bpo and uploaded on debomatic

http://debomatic-amd64.debian.net/distribution#jessie-backports/digikam/4.14.0-3~bpo8+1/buildlog

Matthias, does it work for you? I can upload it on backports if nobody objects.

I did some basic tests and the application is starting correctly on a clean 
jessie+bpo system.

(I could use a version on mentors, but you need to fix the versioning scheme)

cheers,

Gianfranco




Il Domenica 10 Gennaio 2016 16:15, Steve M. Robbins  ha 
scritto:
Hello Matthias,

Thank you for your interest in backporting digikam.  I can't speak for the 
other maintainers, but I personally do not have time to maintain backports and 
I would welcome your efforts to do so.

I have not looked at your package.  But I was a little surprised that the 
proposed backport of 4.14.0-1 was versioned 4.14.0-1.1~bpo8+1.   I did read 
through http://backports.debian.org/Contribute/ (thanks to Mattia Rizzolo for 
the reference!) and under the "basic rules" it says to simply append "~bpo..." 
to the version.  Do you really also need to change from "-1" to "-1.1"? 

Best,
-Steve


On January 2, 2016 12:13:59 PM Gianfranco Costamagna wrote:
> Control: tags -1 moreinfo
> 
> Hi Matthias, if you need a backport, please ask the team or the previous
> uploaders to perform it.
> 
> I cced the actual maintainers for the package, they will follow up with an
> upload if possible (I hope).
> 
> BTW this kind of requests are usually performed with a bug against the
> package, unless the package is mostly unmaintained.
> 
> cheers,
> 
> G.
> 
> 
> 
> 
> Il Sabato 2 Gennaio 2016 11:34, Matthias Erich Popp  ha
> scritto: Package: sponsorship-requests
> Severity: normal
> 
> Package: sponsorship-requests
>   Severity: normal
> 
>   Dear mentors,
> 
>   I am looking for a sponsor for my package "digikam"
> 
> * Package name: digikam
>Version : 4:4.14.0-1.1~bpo8+1
> * URL : http://www.digikam.org
>Section : graphics
> 
>   It builds those binary packages:
> 
> digikam- digital photo management application for KDE
> digikam-data - digiKam architecture-independant data
> digikam-doc - handbook for digiKam
> digikam-private-libs - private libraries for digiKam and kipi plugins
> kipi-plugins - image manipulation/handling plugins for KIPI aware programs
> kipi-plugins-common - kipi-plugins architecture-independent data
> showfoto   - image viewer/editor for KDE
> 
>   To access further information about this package, please visit the
> following URL:
> 
>  http://mentors.debian.net/package/digikam
> 
> 
>   Alternatively, one can download the package with dget using this command:
> 
> dget -x
> http://mentors.debian.net/debian/pool/main/d/digikam/digikam_4.14.0-1.1~bpo8
> +1.dsc
> 
>   More information about hello can be obtained from http://www.example.com.
> 
>   Changes since the last upload:
> 
>   * Non-maintainer upload.
>   * Rebuild for jessie-backports.t changelog entry]
> 
> 
>   Regards,
>Matthias Erich Popp
> 
> 
> 
> -- System Information:
> Debian Release: 8.2
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (450,
> 'stable'), (4, 'testing'), (3, 'unstable'), (2, 'oldstable') Architecture:
> amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.2.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)

Re: boost : no match for call to boost::factory

2016-01-13 Thread Corentin Desfarges 
Hi

I don't know if it's usefull (alioth is still down), but this is the
complete build log :

http://filebin.ca/2TKEHV1l4WvK/log.txt

Thank you for your answer,

Best regards,

Corentin

Bug#808141: sponsorship-requests: Dear mentors, I am looking for a sponsor for my package eclipse-titan.

2016-01-13 Thread Pilisi Gergely 
Hi,

the new package is available on the mentors site:

https://mentors.debian.net/package/eclipse-titan

BR,
Gergely

2016-01-13 14:13 GMT+01:00 Gianfranco Costamagna <
costamagnagianfra...@yahoo.it>:

> Hi,
> >The new package is done, everything is fixed, I hope. I didn't changed
> anything in the source, just under the debian/ directory. Should I upload
> the package as >before or use the dquilt method as
> https://www.debian.org/doc/manuals/maint-guide/update suggests?
> >If I'm right, the update method is for the change in the upstream source,
> or?
>
>
> please read
>
> http://mentors.debian.net/intro-maintainers
>
> (TL:TR)
> gbp buildpackage -S -sa
> dput mentors ../filename_foo_source.changes
>
>
> cheers
>
> G.
>

Bug#805632: marked as done (RFS: plowshare/2.1.2-1)

2016-01-13 Thread Debian Bug Tracking System 
Your message dated Wed, 13 Jan 2016 18:03:55 +0100
with message-id <20160113170355.ga6...@jwilk.net>
and subject line Re: Bug#805632: RFS: plowshare/2.1.2-1
has caused the Debian Bug report #805632,
regarding RFS: plowshare/2.1.2-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.)


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

Package name: plowshare
Version : 2.1.2-1
Section : web

It builds those binary packages:

  plowshare  - download and upload files from file sharing websites
  plowshare4 - transitional dummy package

Get with:

  dget -x
http://mentors.debian.net/debian/pool/main/p/plowshare/plowshare_2.1.2-1.dsc


plowshare (2.1.2-1) unstable; urgency=medium

  * New upstream releases.
- debian/NEWS: note support for user modules.
- debian/NEWS, debian/README: note the new plowmod tool.
- debian/rules: install new upstream changelog.
- debian/plowshare.links, debian/plowshare.manpages: add plowmod.
- debian/plowshare.docs: README -> README.md.
- debian/control: suggest git for use with plowmod.

  * debian/gbp.conf, debian/get-version, debian/rules:
- Remove dependency on git history from the build process.

  * debian/plowshare.completion, debian/rules:
- Install completion for each command.

  * debian/plowshare.links, debian/plowshare.manpages: sort alphabetically.

  * debian/plowshare.install:
- no longer install dummy module config file (Closes: #801815).

 -- Carl Suster   Wed, 14 Oct 2015 15:33:28 +0200


Please also consider uploading the related package
plowshare-modules/0~git20150815.86308d4-1 which is simply a more recent
upstream git snapshot and may be updated independently of plowshare:


http://mentors.debian.net/debian/pool/main/p/plowshare-modules/plowshare-modules_0~git20150815.86308d4-1.dsc


Cheers,
Carl



signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---

* Carl Suster , 2016-01-06, 00:35:
I forgot to reply to the question about forwarding 791467. I discussed 
it with upstream and they weren't interested in disabling javascript or 
really investigating the issue at all.


That's disappointing. :-(

It's probably worth documenting status quo in the patch header; or maybe 
in a more prominent place, such as README.Debian.


Anyway, uploaded.

--
Jakub Wilk--- End Message ---

Bug#805632: marked as done (RFS: plowshare/2.1.2-1)

2016-01-13 Thread Debian Bug Tracking System 
Your message dated Wed, 13 Jan 2016 16:25:43 + (UTC)
with message-id <1849830019.7321282.1452702343673.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#805632: RFS: plowshare/2.1.2-1
has caused the Debian Bug report #805632,
regarding RFS: plowshare/2.1.2-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.)


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

Package name: plowshare
Version : 2.1.2-1
Section : web

It builds those binary packages:

  plowshare  - download and upload files from file sharing websites
  plowshare4 - transitional dummy package

Get with:

  dget -x
http://mentors.debian.net/debian/pool/main/p/plowshare/plowshare_2.1.2-1.dsc


plowshare (2.1.2-1) unstable; urgency=medium

  * New upstream releases.
- debian/NEWS: note support for user modules.
- debian/NEWS, debian/README: note the new plowmod tool.
- debian/rules: install new upstream changelog.
- debian/plowshare.links, debian/plowshare.manpages: add plowmod.
- debian/plowshare.docs: README -> README.md.
- debian/control: suggest git for use with plowmod.

  * debian/gbp.conf, debian/get-version, debian/rules:
- Remove dependency on git history from the build process.

  * debian/plowshare.completion, debian/rules:
- Install completion for each command.

  * debian/plowshare.links, debian/plowshare.manpages: sort alphabetically.

  * debian/plowshare.install:
- no longer install dummy module config file (Closes: #801815).

 -- Carl Suster   Wed, 14 Oct 2015 15:33:28 +0200


Please also consider uploading the related package
plowshare-modules/0~git20150815.86308d4-1 which is simply a more recent
upstream git snapshot and may be updated independently of plowshare:


http://mentors.debian.net/debian/pool/main/p/plowshare-modules/plowshare-modules_0~git20150815.86308d4-1.dsc


Cheers,
Carl



signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
Hi, I'm closing this RFS then :)

cheers,

G.




Il Mercoledì 6 Gennaio 2016 0:39, Carl Suster  ha scritto:
I forgot to reply to the question about forwarding 791467. I discussed it with
upstream and they weren't interested in disabling javascript or really
investigating the issue at all. As far as they're concerned, the security risk
is totally acceptable, which is fair enough.

Note that Vincent uploaded the plowshare-modules package in the meantime, so
please ignore that request.


Cheers,
Carl--- End Message ---