Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]

[lumin]

Control: block -1 by 799262

one more functional blocker, python3-opencv

opencv is (I guess) frequently used by caffe users, Debian
should have python3-opencv if we provide python3-caffe.

when is the EOL of python2.x? I forgot it.
If it is not 2017, can we first upload python2-caffe-* ?
I'll bump it in the future upload.

Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]

[lumin]

Control: block -1 by 795841
Control: block 788539 by 795841

On Wed, 2016-05-18 at 21:12 +, Gianfranco Costamagna wrote:
> Hi Lumin,
> 
> >Thank you James, I've solved this problem.
> I don't want to do the final checks until Ghislain gives me his personal ack, 
> but
> I see that the python3 dependencies might be fixed with not-much effort.
> 
> issues I would like to see fixed or answered:
> python/requirements.txt <-- please check for missing runtime dependencies.

debhelper will pick them up as python package dependencies:
  dh_python2 --requires=python/requirements.txt

> why some of them are outside that shlibs:Depends and not picked up 
> automatically?
> talking about
> python-skimage and python-protobuf

I don't remember why I put python-skimage there but I remember
that python-protobuf was put there as explicit remind for me,
indicating that protobuf is the blocker of python3-caffe-*.

> e.g. you can't run cython if you don't put it on build-dependencies.
> also all the requiremends, need to be in build-dependencies in order to be 
> picked up
> by python:Depends correctly.

Python modules listed in requirements are not required at runtime,
except for numpy and boost-python. I noticed that dh_python2
complains about "unused python:Depends" but the resulting python
package dependency is correct:

>   Depends: libcaffe-cpu1 (= 1.0.0~rc3-1), python-skimage, python-protobuf, 
> cython, ipython, python (<< 2.8), python (>= 2.7~), python-dateutil, 
> python-gflags, python-h5py, python-leveldb, python-matplotlib, 
> python-networkx, python-nose, python-numpy (>= 1:1.8.0), 
> python-numpy-abi9, python-pandas, python-pil, python-scipy, python-six, 
> python-yaml, python:any (>= 2.7.5-5~), libboost-python1.55.0, 
> libboost-system1.55.0, libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), libgoogle-glog0, 
> libprotobuf9, libpython2.7 (>= 2.7), libstdc++6 (>= 4.2.1)

Why should runtime deps be added into build-dep, which are useless
unless I provide python-caffe-* testsuite.

> for the python3 porting:
> protobuf is python3 ready 
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795841
> what about helping the maintainer in uploading it?

Really ready?
I looked into the packaging repo, both master and package-3.x branch
and I see no python3-protobuf package listed there.

http://anonscm.debian.org/cgit/pkg-protobuf/pkg-protobuf.git/tree/debian/control?h=master
http://anonscm.debian.org/cgit/pkg-protobuf/pkg-protobuf.git/tree/debian/control?h=packaging-3.x

The caffe package was ever blocked by 
* the GCC-4 -> GCC-5 transition and dependency library ABI bump
* CUDA 6.5 -> 7.0 bump
* CUDA 7.0 -> 7.5 bump
and now it is blocked by
* python3-protobuf
if python3 is really required.

> for skimage:
> the package has two RC bugs, both fixed upstream 
> #788965, #794859.
> you need to fix all the dependencies if you really want your package in 
> Stretch!
> (btw for skimage, the new release fixes all the RC bugs
> I also asked why it hasn't been packaged yet
> https://github.com/scikit-image/scikit-image/issues/2091
> )

It seems that skimage is not a blocker of Caffe.

$ apt list python3-skimage* -a
Listing... Done
python3-skimage/stable,unstable,now 0.10.1-2 all [installed]

Bug#823478: python3-protobuf3

[Jonathon Love]

hi,

so the advice i received regarding the name was that i must get it 
renamed upstream[1]. i don't think this will be possible because:


 - upstream is an established package, present in PYPI and macports
 - the developer is MIA

(additionally, the official Protocol Buffers 3 supports Python 3 [2] and 
should be coming to debian soon[3]. as the main point of this package 
was to allow the use of protocol buffers with Python 3, this reduces the 
need for this package).


hence, i propose to withdraw the package, the RFS and the ITP. also 
happy to proceed, the work is basically done, but i can't see a way to 
make it work.


with thanks

jonathon


[1] https://lists.debian.org/debian-mentors/2016/05/msg00462.html
[2] https://lists.debian.org/debian-mentors/2016/05/msg00491.html
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795841

Bug#819615: RFS: spin/6.4.5-1 [ITP] -- formal software verification tool

[Tom Lee]

Cheers for the review Mattia! I'll look into all of this. A few comments:

On Sun, May 15, 2016 at 9:19 AM, Mattia Rizzolo  wrote:

> ...
> * d/patches/01_makefile_fixes.patch:
>   + Probably use += instead of ?= in the first CFLAGS?
>   + I'd rather use install(1) instead of cp(1)
>   + Really forward at least the DESTDIR/INSTALL change
>

Yes, thanks for reminding me -- do intend to follow up with upstream. I'm
curious if this makefile was perhaps written for some crusty old version of
make that doesn't do well with the "optional assignment" syntax used for
DESTDIR/INSTALL. I had similar questions about the use of cp vs. install.
I'll see if upstream has any strong attachment to any of this.


> * d/patches/02_manpage_fixes.patch:
>   + what's blocking you from forwarding this patch?
>

Nothing at all, it just hasn't been done yet.


> * d/rules:
>   + get rid of all those useless comments
>   + DPKG_EXPORT_BUILDFLAGS and the inclusion of buildflags.mk is
> useless, please read debhelper(7)
>   + trailing whitespace at line 22
>   + what's wrong with using --sourcedirectory on the dh(1) call instead
> of overriding everything like that?
>

Oh much better idea, didn't know I could do that.


>   + I'd avoid that "INSTALL=install -D" by patching correctly the
> makefile to default INSTALL on install(1) instead of cp(1) (as I
> said above)
>

Sure.

Thanks again!

Bug#824713: marked as done (RFS: rhythmbox-plugin-alternative-toolbar/0.17.1-1)

[Debian Bug Tracking System]

Your message dated Thu, 19 May 2016 01:48:18 +0200
with message-id <20160518234818.ga17...@angband.pl>
and subject line Re: Bug#824713: RFS: 
rhythmbox-plugin-alternative-toolbar/0.17.1-1
has caused the Debian Bug report #824713,
regarding RFS: rhythmbox-plugin-alternative-toolbar/0.17.1-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.)


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

Dear Mentors,

I am looking for a sponsor for my package
"rhythmbox-plugin-alternative-toolbar"

* Package name: rhythmbox-plugin-alternative-toolbar
  Version : 0.17.1-1
  Upstream Author : David Mohammed 
* URL : https://github.com/fossfreedom/alternative-toolbar
* License : GPL3+
  Section : gnome

It builds the binary package:

rhythmbox-plugin-alternative-toolbar - Enhanced play controls and
interface for Rhythmbox

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

  http://mentors.debian.net/package/rhythmbox-plugin-alternative-toolbar


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

dget -x 
http://mentors.debian.net/debian/pool/main/r/rhythmbox-plugin-alternative-toolbar/rhythmbox-plugin-alternative-toolbar_0.16.3-1.dsc

  More information about rhythmbox-plugin-alternative-toolbar can be
obtained from https://github.com/fossfreedom/alternative-toolbar.
  Additionally I have a blog post about this work here:
https://xpressubuntu.wordpress.com/2015/11/02/rhythmbox-alternative-toolbar-updated/

Notes - this is an update to my previous version v0.16.3 that is in unstable

 - https://packages.debian.org/sid/rhythmbox-plugin-alternative-toolbar

Changes since the last upload:
 * New upstream release. (Closes: #824708)
- Option for dark theme
- Display Browse Categories horizontally or vertically
- Display app-menu correctly in budgie-desktop
- Updated translations from Launchpad.net
- correctly toggle search button via CTRL+F
- option to force the display of the app-menu if required

Tests Run:
grep -riE 'fixme|todo|hack|xxx' .
suspicious-source
pyflakes .
pyflakes3 .
pep8 --ignore W191 .
find -type f \( -iname '*.po' -o -iname '*.pot' \) -exec msgfmt
--check --check-compatibility --check-accelerators
--output-file=/dev/null {} \;

from the built and installed package:

adequate rhythbox-plugin-alternative-toolbar

Regards,
David Mohammed (fossfreedom)
--- End Message ---
--- Begin Message ---
On Thu, May 19, 2016 at 12:09:25AM +0100, David Mohammed wrote:
> * Package name: rhythmbox-plugin-alternative-toolbar
>   Version : 0.17.1-1

It's in.

-- 
A tit a day keeps the vet away.--- End Message ---

Bug#824714: marked as done (RFS: testu01/1.2.3+ds-2 [Refreshment] - testing suite for uniform random number generators)

[Debian Bug Tracking System]

Your message dated Thu, 19 May 2016 01:27:37 +0200
with message-id <20160518232737.ga15...@angband.pl>
and subject line Re: Bug#824714: RFS: testu01/1.2.3+ds-2 [Refreshment] - 
testing suite for uniform random number generators
has caused the Debian Bug report #824714,
regarding RFS: testu01/1.2.3+ds-2 [Refreshment] - testing suite for uniform 
random number generators
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.)


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

Dear Sponsors,

I am looking for a sponsor for the Debian package testu01 [1], an 
applied
mathematical suite for testing URNG. This very version is a refreshment 
of
the Debian material.

Thanks in advance,
Jerome

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

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

Kernel: Linux 3.16.7-ckt20-0001-mbp62 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
--- End Message ---
--- Begin Message ---
On Thu, May 19, 2016 at 12:13:13AM +0100, Jerome Benoit wrote:
>   I am looking for a sponsor for the Debian package testu01 [1], an 
> applied
>   mathematical suite for testing URNG. This very version is a refreshment 
> of
>   the Debian material.

Looks fine, uploaded!
Thanks for your contribution to Debian.

-- 
A tit a day keeps the vet away.--- End Message ---

Bug#824714: RFS: testu01/1.2.3+ds-2 [Refreshment] - testing suite for uniform random number generators

[Jerome Benoit]

Package: sponsorship-requests
Severity: normal

Dear Sponsors,

I am looking for a sponsor for the Debian package testu01 [1], an 
applied
mathematical suite for testing URNG. This very version is a refreshment 
of
the Debian material.

Thanks in advance,
Jerome

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

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

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

Bug#824713: RFS: rhythmbox-plugin-alternative-toolbar/0.17.1-1

[David Mohammed]

Package: sponsorship-requests
Severity: wishlist

Dear Mentors,

I am looking for a sponsor for my package
"rhythmbox-plugin-alternative-toolbar"

* Package name: rhythmbox-plugin-alternative-toolbar
  Version : 0.17.1-1
  Upstream Author : David Mohammed 
* URL : https://github.com/fossfreedom/alternative-toolbar
* License : GPL3+
  Section : gnome

It builds the binary package:

rhythmbox-plugin-alternative-toolbar - Enhanced play controls and
interface for Rhythmbox

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

  http://mentors.debian.net/package/rhythmbox-plugin-alternative-toolbar


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

dget -x 
http://mentors.debian.net/debian/pool/main/r/rhythmbox-plugin-alternative-toolbar/rhythmbox-plugin-alternative-toolbar_0.16.3-1.dsc

  More information about rhythmbox-plugin-alternative-toolbar can be
obtained from https://github.com/fossfreedom/alternative-toolbar.
  Additionally I have a blog post about this work here:
https://xpressubuntu.wordpress.com/2015/11/02/rhythmbox-alternative-toolbar-updated/

Notes - this is an update to my previous version v0.16.3 that is in unstable

 - https://packages.debian.org/sid/rhythmbox-plugin-alternative-toolbar

Changes since the last upload:
 * New upstream release. (Closes: #824708)
- Option for dark theme
- Display Browse Categories horizontally or vertically
- Display app-menu correctly in budgie-desktop
- Updated translations from Launchpad.net
- correctly toggle search button via CTRL+F
- option to force the display of the app-menu if required

Tests Run:
grep -riE 'fixme|todo|hack|xxx' .
suspicious-source
pyflakes .
pyflakes3 .
pep8 --ignore W191 .
find -type f \( -iname '*.po' -o -iname '*.pot' \) -exec msgfmt
--check --check-compatibility --check-accelerators
--output-file=/dev/null {} \;

from the built and installed package:

adequate rhythbox-plugin-alternative-toolbar

Regards,
David Mohammed (fossfreedom)

Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]

[Gianfranco Costamagna]

Hi Lumin,

>Thank you James, I've solved this problem.
I don't want to do the final checks until Ghislain gives me his personal ack, 
but
I see that the python3 dependencies might be fixed with not-much effort.

issues I would like to see fixed or answered:
python/requirements.txt <-- please check for missing runtime dependencies.


why some of them are outside that shlibs:Depends and not picked up 
automatically?
talking about
python-skimage and python-protobuf

e.g. you can't run cython if you don't put it on build-dependencies.
also all the requiremends, need to be in build-dependencies in order to be 
picked up
by python:Depends correctly.

for the python3 porting:
protobuf is python3 ready 

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795841
what about helping the maintainer in uploading it?


for skimage:
the package has two RC bugs, both fixed upstream 
#788965, #794859.
you need to fix all the dependencies if you really want your package in Stretch!
(btw for skimage, the new release fixes all the RC bugs
I also asked why it hasn't been packaged yet
https://github.com/scikit-image/scikit-image/issues/2091
)

Gianfranco

Re: upload vsftpd

[Julián Moreno Patiño]

Hello Jörg,

In advance thank you for your work in this package.

>vsftpd (3.0.3-4) unstable; urgency=medium
>
>  * Orphan this package.
>  * Set maintainer to Debian QA Group (See: #824694).

You already reported an orphan bug. It's not necessary the upload.

Kind regards,

-- 
Julián Moreno Patiño
Debian Developer
 .''`. Debian GNU/{Linux,KfreeBSD}
: :' : Free Operating Systems
`. `'  http://debian.org/
  `-   GPG Fingerprint:
C2C8 904E 314C D8FA 041D 9B00 D5FD FC15 6168 BF60
Registered GNU Linux User ID 488513


signature.asc
Description: PGP signature

Re: upload vsftpd

[Gianfranco Costamagna]

hi, sponsoring soon.

g.





Il Mercoledì 18 Maggio 2016 21:39, Jörg Frings-Fürst 
 ha scritto:
Hi,

please can someone upload the package vsftpd?

The includes only this changes:

vsftpd (3.0.3-4) unstable; urgency=medium

  * Orphan this package.
  * Set maintainer to Debian QA Group (See: #824694).

 -- Jörg Frings-Fürst   Wed, 18 May 2016 21:11:49 
+0200


The package is uploaded to mentors[1].

Many thanks..


CU
Jörg

[1] https://mentors.debian.net/debian/pool/main/v/vsftpd/vsftpd_3.0.3-4.dsc

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54538 Bausendorf

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.

upload vsftpd

[Jörg Frings-Fürst]

Hi,

please can someone upload the package vsftpd?

The includes only this changes:

vsftpd (3.0.3-4) unstable; urgency=medium

  * Orphan this package.
  * Set maintainer to Debian QA Group (See: #824694).

 -- Jörg Frings-Fürst   Wed, 18 May 2016 21:11:49 
+0200


The package is uploaded to mentors[1].

Many thanks..


CU
Jörg

[1] https://mentors.debian.net/debian/pool/main/v/vsftpd/vsftpd_3.0.3-4.dsc

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54538 Bausendorf

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#824688: marked as done (RFS: golang-gopkg-tylerb-graceful.v1/1.2.5-1)

[Debian Bug Tracking System]

Your message dated Wed, 18 May 2016 18:08:06 +
with message-id <20160518180805.gi20...@chase.mapreri.org>
and subject line Re: Bug#824688: RFS: golang-gopkg-tylerb-graceful.v1/1.2.5-1
has caused the Debian Bug report #824688,
regarding RFS: golang-gopkg-tylerb-graceful.v1/1.2.5-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.)


-- 
824688: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824688
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 the package "golang-gopkg-tylerb-graceful.v1":

  git clone 
https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-tylerb-graceful.v1.git

  
  cd golang-gopkg-tylerb-graceful.v1 && pristine-tar checkout 
../golang-gopkg-tylerb-graceful.v1_1.2.5.orig.tar.gz

For verification, these are the current branch heads:

  git show-ref --heads
  b2f4a085a5d8871281e112da84c5296514731588 refs/heads/master
  987b060cdd463d2ebb35308cee655719f84fdef9 refs/heads/pristine-tar
  8627cf224c607b547894104956ee0e863594aace refs/heads/upstream

It builds these binary packages:

  golang-gopkg-tylerb-graceful.v1-dev -- Go package for gracefully shutting 
down HTTP server

Changes since the last upload:

golang-gopkg-tylerb-graceful.v1 (1.2.5-1) unstable; urgency=medium

  * New upstream release
  * Drop patches applied upstream
  * Update Standards-Version to 3.9.8

 -- Peter Colberg   Wed, 18 May 2016 07:25:08 -0400

Regards,
Peter
--- End Message ---
--- Begin Message ---
.

On Wed, May 18, 2016 at 01:34:24PM -0400, Peter Colberg wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for the package "golang-gopkg-tylerb-graceful.v1":
> 
>   git clone 
> https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-tylerb-graceful.v1.git
>   
> 
>   cd golang-gopkg-tylerb-graceful.v1 && pristine-tar checkout 
> ../golang-gopkg-tylerb-graceful.v1_1.2.5.orig.tar.gz
> 
> For verification, these are the current branch heads:
> 
>   git show-ref --heads
>   b2f4a085a5d8871281e112da84c5296514731588 refs/heads/master
>   987b060cdd463d2ebb35308cee655719f84fdef9 refs/heads/pristine-tar
>   8627cf224c607b547894104956ee0e863594aace refs/heads/upstream
> 
> It builds these binary packages:
> 
>   golang-gopkg-tylerb-graceful.v1-dev -- Go package for gracefully shutting 
> down HTTP server
> 
> Changes since the last upload:
> 
> golang-gopkg-tylerb-graceful.v1 (1.2.5-1) unstable; urgency=medium
> 
>   * New upstream release
>   * Drop patches applied upstream
>   * Update Standards-Version to 3.9.8
> 
>  -- Peter Colberg   Wed, 18 May 2016 07:25:08 -0400
> 
> Regards,
> Peter
> 

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

Bug#824687: marked as done (RFS: golang-gopkg-hlandau-easyconfig.v1/1.0.14-1)

[Debian Bug Tracking System]

Your message dated Wed, 18 May 2016 17:44:58 +
with message-id <20160518174456.gg20...@chase.mapreri.org>
and subject line Re: Bug#824687: RFS: 
golang-gopkg-hlandau-easyconfig.v1/1.0.14-1
has caused the Debian Bug report #824687,
regarding RFS: golang-gopkg-hlandau-easyconfig.v1/1.0.14-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.)


-- 
824687: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824687
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 the package "golang-gopkg-hlandau-easyconfig.v1":

  git clone 
https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-hlandau-easyconfig.v1.git

 
  cd golang-gopkg-hlandau-easyconfig.v1 && pristine-tar checkout 
../golang-gopkg-hlandau-easyconfig.v1_1.0.14.orig.tar.gz

For verification, these are the current branch heads:

  git show-ref --heads
  9a37627b6a6c43aa818c2d8da40ba8987ce43675 refs/heads/master
  a15ce4216ac401431e1d9d9935e01cfc81370ab9 refs/heads/pristine-tar
  0a93297ad92a0049ea00267d930da2dbdb62c51b refs/heads/upstream

It builds these binary packages:

  golang-gopkg-hlandau-easyconfig.v1-dev -- Go package with easy bindings for 
configurable

Changes since the last upload:

golang-gopkg-hlandau-easyconfig.v1 (1.0.14-1) unstable; urgency=medium

  * New upstream release
  * Update Standards-Version to 3.9.8

 -- Peter Colberg   Wed, 18 May 2016 07:21:33 -0400

Regards,
Peter
--- End Message ---
--- Begin Message ---
.

On Wed, May 18, 2016 at 01:31:17PM -0400, Peter Colberg wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for the package 
> "golang-gopkg-hlandau-easyconfig.v1":
> 
>   git clone 
> https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-hlandau-easyconfig.v1.git
>   
>
>   cd golang-gopkg-hlandau-easyconfig.v1 && pristine-tar checkout 
> ../golang-gopkg-hlandau-easyconfig.v1_1.0.14.orig.tar.gz
> 
> For verification, these are the current branch heads:
> 
>   git show-ref --heads
>   9a37627b6a6c43aa818c2d8da40ba8987ce43675 refs/heads/master
>   a15ce4216ac401431e1d9d9935e01cfc81370ab9 refs/heads/pristine-tar
>   0a93297ad92a0049ea00267d930da2dbdb62c51b refs/heads/upstream
> 
> It builds these binary packages:
> 
>   golang-gopkg-hlandau-easyconfig.v1-dev -- Go package with easy bindings for 
> configurable
> 
> Changes since the last upload:
> 
> golang-gopkg-hlandau-easyconfig.v1 (1.0.14-1) unstable; urgency=medium
> 
>   * New upstream release
>   * Update Standards-Version to 3.9.8
> 
>  -- Peter Colberg   Wed, 18 May 2016 07:21:33 -0400
> 
> Regards,
> Peter
> 

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

Bug#824688: RFS: golang-gopkg-tylerb-graceful.v1/1.2.5-1

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "golang-gopkg-tylerb-graceful.v1":

  git clone 
https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-tylerb-graceful.v1.git

  
  cd golang-gopkg-tylerb-graceful.v1 && pristine-tar checkout 
../golang-gopkg-tylerb-graceful.v1_1.2.5.orig.tar.gz

For verification, these are the current branch heads:

  git show-ref --heads
  b2f4a085a5d8871281e112da84c5296514731588 refs/heads/master
  987b060cdd463d2ebb35308cee655719f84fdef9 refs/heads/pristine-tar
  8627cf224c607b547894104956ee0e863594aace refs/heads/upstream

It builds these binary packages:

  golang-gopkg-tylerb-graceful.v1-dev -- Go package for gracefully shutting 
down HTTP server

Changes since the last upload:

golang-gopkg-tylerb-graceful.v1 (1.2.5-1) unstable; urgency=medium

  * New upstream release
  * Drop patches applied upstream
  * Update Standards-Version to 3.9.8

 -- Peter Colberg   Wed, 18 May 2016 07:25:08 -0400

Regards,
Peter

Bug#824687: RFS: golang-gopkg-hlandau-easyconfig.v1/1.0.14-1

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "golang-gopkg-hlandau-easyconfig.v1":

  git clone 
https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-hlandau-easyconfig.v1.git

 
  cd golang-gopkg-hlandau-easyconfig.v1 && pristine-tar checkout 
../golang-gopkg-hlandau-easyconfig.v1_1.0.14.orig.tar.gz

For verification, these are the current branch heads:

  git show-ref --heads
  9a37627b6a6c43aa818c2d8da40ba8987ce43675 refs/heads/master
  a15ce4216ac401431e1d9d9935e01cfc81370ab9 refs/heads/pristine-tar
  0a93297ad92a0049ea00267d930da2dbdb62c51b refs/heads/upstream

It builds these binary packages:

  golang-gopkg-hlandau-easyconfig.v1-dev -- Go package with easy bindings for 
configurable

Changes since the last upload:

golang-gopkg-hlandau-easyconfig.v1 (1.0.14-1) unstable; urgency=medium

  * New upstream release
  * Update Standards-Version to 3.9.8

 -- Peter Colberg   Wed, 18 May 2016 07:21:33 -0400

Regards,
Peter

Bug#824489: RFS: dwarfutils/20160507-1 [ITA] -- utility and library to work with DWARF debug information

[Fabian Wolff]

On Wed, May 18, 2016 at 03:29:33PM +, Gianfranco Costamagna wrote:
> Hi,
> 
> >Done. I removed the override in debian/rules.
> 
> wonderful
> 
> >I went with a mixture of both patches you proposed. I also forwarded>the 
> >patches to upstream & removed the now useless exports in
> >debian/rules.
> >
> >I've reuploaded the new package to Mentors (same URL).
> 
> 
> actually that was mostly the same patch I did at the begin, but I didn't send 
> it
> to you by purpose :)
> I wanted to see your skills, and see if your conclusion were eventually the 
> same as mine.
> 
> I have to say I'm satisfied and happy with your changes, so I uploaded it on 
> unstable.

Great. Thank you!

> I put it on deferred/1, so the package will show up in ~24 hours or so.
> 
> Sorry for that deferred, but I would like to have one more day of testing :)

Sure.

> thanks for the nice contribution to Debian, and sorry for being so pedantic 
> in my
> reviews :)
> 
> please continue the nice job you did as new shiny maintainer of the package

I'll try my best!

Cheers,
Fabian

Bug#824489: marked as done (RFS: dwarfutils/20160507-1 [ITA] -- utility and library to work with DWARF debug information)

[Debian Bug Tracking System]

Your message dated Wed, 18 May 2016 15:29:33 + (UTC)
with message-id <1909380391.7270110.1463585373317.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#824489: RFS: dwarfutils/20160507-1 [ITA] -- utility 
and library to work with DWARF debug information
has caused the Debian Bug report #824489,
regarding RFS: dwarfutils/20160507-1 [ITA] -- utility and library to work with 
DWARF debug information
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.)


-- 
824489: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824489
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 "dwarfutils", which is
currently orphaned and which I would like to adopt.

* Package name: dwarfutils
  Version : 20160507-1
  Upstream Author : David Anderson
* URL : https://www.prevanders.net/dwarf.html
  License : GPL-2, LGPL-2.1, BSD-3-clause, BSD-2-clause
  Section : libs

It builds those binary packages:

  dwarfdump - utility to dump DWARF debug information from ELF objects
  libdwarf-dev - library to consume and produce DWARF debug information

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dwarfutils/dwarfutils_20160507-1.dsc

Changes since the last upload:

  * New Maintainer (Closes: #822614).
  * New upstream release (Closes: #822154, #811817, #681748).
 - Fixes CVE-2016-2091 (Closes: #813148).
 - Fixes CVE-2015-8750 (Closes: #813182).
 - Fixes CVE-2015-8538 (Closes: #807817).
  * Upgrade to source format 3.0 (quilt).
  * Upgrade to Standards version 3.9.8.
  * Clean up debian/rules.
  * Improve long description of dwarfdump (Closes: #659319).
  * Perform complete copyright review.
  * Update patches to DEP-3 format.
  * Add doc-base file for libdwarf-dev.
  * Compile with -fPIC.

Regards,
 Fabian Wolff
--- End Message ---
--- Begin Message ---
Hi,

>Done. I removed the override in debian/rules.

wonderful

>I went with a mixture of both patches you proposed. I also forwarded>the 
>patches to upstream & removed the now useless exports in
>debian/rules.
>
>I've reuploaded the new package to Mentors (same URL).


actually that was mostly the same patch I did at the begin, but I didn't send it
to you by purpose :)
I wanted to see your skills, and see if your conclusion were eventually the 
same as mine.

I have to say I'm satisfied and happy with your changes, so I uploaded it on 
unstable.
I put it on deferred/1, so the package will show up in ~24 hours or so.

Sorry for that deferred, but I would like to have one more day of testing :)

thanks for the nice contribution to Debian, and sorry for being so pedantic in 
my
reviews :)

please continue the nice job you did as new shiny maintainer of the package

Gianfranco--- End Message ---

Re: a few questions on ITP shadowsocks-libev before formal RFS

[Gianfranco Costamagna]

Hi, alternative proposal

>Now I understand my todo-list, briefly:
>- package libraries first: libcork/ipset
>- create debian/watch and ds repack
>- RFS shadowsocks-libev
>- apply for collab-maint access


- open ITP bugs for all the libraries (search for wnpp and ITP on google)

- package libcork/ipset/shadowsocks-libev all at the same time
- RFS for all of the three packages and make them blocked by each other
e.g. block shadowsocks-libev RFS bug by the other two.
- show your git skills in the meanwhile, and ask for collab-maint access

(BTW it isn't requested to have the repo in collab-maint by the current policy)

Gianfranco

Re: a few questions on ITP shadowsocks-libev before formal RFS

[Roger Shimizu]

On Thu, May 19, 2016 at 12:04 AM, Gianfranco Costamagna
 wrote:
>
> Hi,
>
>
>>If so, here's our alioth account: rosh-guest, hosiet-guest, 
>>madeye-guest.>Thank you!
>
>
> you need to send a request to join collab-maint, an alioth account doesn't 
> grant
> your permissions automatically.
> I suggest you to use an external repository to show your skills, and then ask 
> to join
> (consider that to join you have to be a Debian Maintainer or to have a Debian 
> Developer
> advocating you)
>
>>Is this (package the libraries separately) required? or something can
>>be done afterwards?
>
>
> up to your eventual sponsor, I personally require that, because it is trivial 
> to do,
> and makes lifes of ftpmasters easier and for other people too.
> (unless the library is strictly private for the tool, there is no need to 
> have an embedded copy)
>
> you might however try to persuade your sponsor about having them embedded ;)
>
>>I see source of some packages are repacked as -dfsg, but I didn't find
>>how to do "ds" repack.
>>It would be helpful if there's a wiki entry or manual.
>
>
> just call it ds, have a README.source in debian directory explaining why, and 
> the dversionmangle in watch
> file should be enough.
> Probably somebody should write some wiki :)

Dear Gianfranco,

Thanks for your reply!

Now I understand my todo-list, briefly:
- package libraries first: libcork/ipset
- create debian/watch and ds repack
- RFS shadowsocks-libev
- apply for collab-maint access

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1

Bug#824489: RFS: dwarfutils/20160507-1 [ITA] -- utility and library to work with DWARF debug information

[Fabian Wolff]

On Wed, May 18, 2016 at 06:59:10AM +, Gianfranco Costamagna wrote:
> I don't see why it can't be patched to work like almost every other tool
> that uses a build system, but I don't care a lot about upstream.
> 
> The (possible) issue I foresee is: somebody updates the upstream build system
> to install the files too, you update the packaging without checking
> that, the Debian upload is buggy because some files are missing.
> 
> in short words, I prefer an useless call, rather than a broken package!

Done. I removed the override in debian/rules.

> I'm not fluent too, thanks for checking and replying about that, it was 
> already
> fine, but I just wanted to be sure there was a rationale for the change!
> 
> let me know your opinion about the install step, and I'll do the final checks 
> + sponsoring
> 
> 
> BTW, I like when a patch/fix can be upstream, so I propose another one (feel 
> free to reject of course, you are
> the maintainer, not me!)
> --- dwarfutils-20160507.orig/libdwarf/configure.in
> +++ dwarfutils-20160507/libdwarf/configure.in
> @@ -127,11 +127,11 @@ AC_TRY_COMPILE([#include ],[  Elf
> dnl default-disabled shared
> AC_SUBST(build_shared,[none])
> AC_SUBST(dwfpic,[])
> +AC_SUBST(dwfpic,[-fPIC])
> AC_ARG_ENABLE(shared,AC_HELP_STRING([--enable-shared],
> [build shared library libdwarf.so]))
> AS_IF([ test "x$enable_shared" = "xyes"], [
> AC_SUBST(build_shared,[libdwarf.so])
> -   AC_SUBST(dwfpic,[-fPIC])
> ])
> 
> dnl default-enabled nonshared
> 
> 
> maybe it makes sense to enable it alsofor static libs then anyway.
> (probably all the if block can be removed this way, but this is something 
> that upstream has to investigate ;))

I went with a mixture of both patches you proposed. I also forwarded
the patches to upstream & removed the now useless exports in
debian/rules.

I've reuploaded the new package to Mentors (same URL).

Re: a few questions on ITP shadowsocks-libev before formal RFS

[Gianfranco Costamagna]

Hi,


>If so, here's our alioth account: rosh-guest, hosiet-guest, 
>madeye-guest.>Thank you!


you need to send a request to join collab-maint, an alioth account doesn't grant
your permissions automatically.
I suggest you to use an external repository to show your skills, and then ask 
to join
(consider that to join you have to be a Debian Maintainer or to have a Debian 
Developer
advocating you)

>Is this (package the libraries separately) required? or something can
>be done afterwards?


up to your eventual sponsor, I personally require that, because it is trivial 
to do,
and makes lifes of ftpmasters easier and for other people too.
(unless the library is strictly private for the tool, there is no need to have 
an embedded copy)

you might however try to persuade your sponsor about having them embedded ;)

>I see source of some packages are repacked as -dfsg, but I didn't find
>how to do "ds" repack.
>It would be helpful if there's a wiki entry or manual.


just call it ds, have a README.source in debian directory explaining why, and 
the dversionmangle in watch
file should be enough.
Probably somebody should write some wiki :)

G.

Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]

[Jakub Wilk]

* lumin , 2016-05-18, 12:44:

* add debian/upstream/metadata , but lintian says

W: caffe source: upstream-metadata-yaml-invalid


Is there anything wrong with this file? I have no idea


I've just commited fix for Lintian to include validation error in 
the output, so in the next version it will be:


W: caffe source: upstream-metadata-yaml-invalid mapping values are not allowed 
in this context (at document 1, line 3, column 16)

...which is (hopefully) more helpful.


But in the future, don't count on Lintian contributors reading 
debian-mentors. If you find Lintian output misleading or unhelpful, 
please file bugs! :-)


--
Jakub Wilk

Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]

[lumin]

> Title: 'Caffe: Convolutional Architecture for Fast Feature Embedding'

Thank you James, I've solved this problem.

Mentors, please check the latest caffe package on mentors:

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

debomatic result should be the same as that obtained 1 hour ago.
I think source package "caffe" is now clean in all aspects.

Re: a few questions on ITP shadowsocks-libev before formal RFS

[Roger Shimizu]

[Add Max and Boyuan from upstream to CC]

Thanks Gianfranco and Jakub!

I comment when I still have question, for other parts I'll follow your
suggestion.

On Wed, May 18, 2016 at 7:13 PM, Jakub Wilk  wrote:
> * Roger Shimizu , 2016-05-18, 02:14:
>>
>> Some questions/issues that I'm not sure:
>> - Upstream maintained debian/ folder long before, I'm going to keep the
>> original debian/changelog. So I should also keep the upstream as maintainer,
>> and add myself as the uploader?
>
> It doesn't matter who maintained the package in the package. What matters is
> who is going to maintain it now for Debian. Did you ask upstream to
> co-maintain it with you? You certainly shouldn't put anyone to
> Maintainer/Uploaders without their consent.

I contacted the upstream (now they're in CC), and they're happy to
co-maintain this with me.
BTW. I have a few packages uploaded by sponsorship, but I have no
experience on collab-maint.
I'm not sure whether I can ask you to help to set up a repo on
alioth/collab-maint for us?
If so, here's our alioth account: rosh-guest, hosiet-guest, madeye-guest.
Thank you!

>> - The package is mainly GPLv3, but it links to OpenSSL library, is that
>> OK?
>
> GPL+OpenSSL is no-no.
>
> README says that mbedtls, which is GPL-compatible, can be used as an
> alternative to OpenSSL, so you should try it.

Yes, it seems I have to try it anyway.

>> - Upstream repo includes library source code of libev, libsodium, libudns.
>> Is it OK to keep as it is, or have to remove and make another source
>> tarball?
>
> As long as they are DFSG-free, you can keep them in the source package. Just
> make sure they are not used at build time. This is best achieved by "rm
> -rf"ing them early in the build process. (If you're using dh, then beginning
> of override_dh_auto_build is probably the best place.)

This works well. Thank you!

>> - I have no idea on the following lintian error, because postrm/postinst
>> scripts are generated by dh
>>
>> 
>> E: shadowsocks-libev: postrm-contains-additional-updaterc.d-calls
>> etc/init.d/shadowsocks-libev-local
>
>
> This seems to be caused by passing --no-start to dh_installinit:
>
> dh_installinit --no-start --name=shadowsocks-libev-server@
> dh_installinit --no-start --name=shadowsocks-libev-tunnel@
> dh_installinit --no-start --name=shadowsocks-libev-redir@
> dh_installinit --no-start --name=shadowsocks-libev-local@
>
> My initsystem-fu is too weak to tell whether it's a d/rules bug, debhelper
> bug, or Lintian bug, or just something that should be overridden.

Upstream came to help.
After remove the above block (only to use the default debhelper), now
lintian is happy on everything.


On Wed, May 18, 2016 at 4:05 PM, Gianfranco Costamagna
 wrote:
>
>>- Upstream repo includes library source code of libev, libsodium,>libudns. Is 
>>it OK to keep as it is, or have to remove and make another
>>source tarball?
>
> as long as you don't use them it is fine, please try to package them 
> separately
> and use the system versions, not bundled code

Is this (package the libraries separately) required? or something can
be done afterwards?

> BTW the copyright file has to list them, so there is a tradeoff between 
> removing files to
> have a more readable /easy to maintain copyright file and tarball, and having 
> a pristine tarball from
> upstream.
>
>>- The answer of above question may affect: whether I should remove>copyright 
>>of library libev, libsodium, libudns from debian/copyright?
>
> oops answered above :)
> (BTW a repack done not because of non-dfsg files is a "ds" aka Debian Source 
> repack)

I see source of some packages are repacked as -dfsg, but I didn't find
how to do "ds" repack.
It would be helpful if there's a wiki entry or manual.

Thanks again for your helpful advice!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1

Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]

[James Clarke]

> On 18 May 2016, at 14:15, James Clarke  wrote:
> 
>> On 18 May 2016, at 13:44, lumin  wrote:
>> * add debian/upstream/metadata , but lintian says
>> 
>>> W: caffe source: upstream-metadata-yaml-invalid
>> 
>> Is there anything wrong with this file? I have no idea
>> 
>> ```
>> Homepage: http://caffe.berkeleyvision.org/
>> Name: Caffe
>> Reference:
>> Author: Jia, Yangqing and Shelhamer, Evan and Donahue, Jeff and Karayev, 
>> Sergey and Long, Jonathan and Girshick, Ross and Guadarrama, Sergio and 
>> Darrell, Trevor
>> Title: Caffe: Convolutional Architecture for Fast Feature Embedding
> 
> You need to quote the colon in "Caffe:”.

The entire field, that is (you can’t quote a subset of it afaik), i.e.

Title: 'Caffe: Convolutional Architecture for Fast Feature Embedding'

> https://wiki.debian.org/UpstreamMetadata recommends
> http://yaml-online-parser.appspot.com/ for validation.

Regards,
James




signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]

[James Clarke]

> On 18 May 2016, at 13:44, lumin  wrote:
> * add debian/upstream/metadata , but lintian says
> 
>> W: caffe source: upstream-metadata-yaml-invalid
> 
> Is there anything wrong with this file? I have no idea
> 
> ```
> Homepage: http://caffe.berkeleyvision.org/
> Name: Caffe
> Reference:
>  Author: Jia, Yangqing and Shelhamer, Evan and Donahue, Jeff and Karayev, 
> Sergey and Long, Jonathan and Girshick, Ross and Guadarrama, Sergio and 
> Darrell, Trevor
>  Title: Caffe: Convolutional Architecture for Fast Feature Embedding

You need to quote the colon in "Caffe:".
https://wiki.debian.org/UpstreamMetadata recommends
http://yaml-online-parser.appspot.com/ for validation.

Regards,
James



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]

[lumin]

debomatic result

* build pass,
* autopkgtest OK, according to log no error occurs
* lintian remains 1 warning about that weird YAML issue
* piuparts fails because of DoM problem

updated package was uploaded to mentors

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

Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]

[lumin]

On Tue, 2016-05-17 at 16:55 +0100, Ghislain Vaillant wrote:
> On 17/05/16 15:42, lumin wrote:
> > Thank you for this careful and thorough review!

http://anonscm.debian.org/cgit/debian-science/packages/caffe.git/

Let me summarize the changes this time

* remove python script for autogen, generate install control
  file in rules instead. The trick used is borrowed from
  CUDA packaging.

* update content in install control file, including removing
  debian/tmp.

* add caffe-doc package

* change target release from experimental to unstable

* add 3 new patch:
  - cmake-using-basic-blas
  - cmake-using-gnuinstalldirs
  - cmake-fix-python-module-installdir

* removed unapplied patches.

* update README.Debian

* remove custom target in rules, since standard build is
  not heavy anymore.

* fix many lintian Warnings for caffe-doc in rules

* add debian/tests/control, and a simple test debian/tests/simple

* use uversionmangle in watch, version parse ok

* add debian/upstream/metadata , but lintian says

> W: caffe source: upstream-metadata-yaml-invalid

Is there anything wrong with this file? I have no idea

```
Homepage: http://caffe.berkeleyvision.org/
Name: Caffe
Reference:
  Author: Jia, Yangqing and Shelhamer, Evan and Donahue, Jeff and Karayev, 
Sergey and Long, Jonathan and Girshick, Ross and Guadarrama, Sergio and 
Darrell, Trevor
  Title: Caffe: Convolutional Architecture for Fast Feature Embedding
  Journal: arXiv preprint arXiv:1408.5093
  Year: 2014
  URL: http://arxiv.org/abs/1408.5093
  eprint: http://arxiv.org/pdf/1408.5093.pdf
Repository-Browse: https://github.com/BVLC/caffe
```

well, the above issue seems to be the last one before it
can be uploaded.

when I'm writing this email debomatic is still compiling:
http://debomatic-amd64.debian.net/distribution#unstable/caffe/1.0.0~rc3-1/buildlog

Bug#824262: marked as done (RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system)

[Debian Bug Tracking System]

Your message dated Wed, 18 May 2016 11:11:02 + (UTC)
with message-id <1807413204.7088758.1463569862453.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep 
build system
has caused the Debian Bug report #824262,
regarding RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system
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.)


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

  Dear mentors,

  I am looking for a sponsor for my package "gnustep-make"

 * Package name: gnustep-make
   Version : 2.6.8-1
   Upstream Author : GNUstep Maintainer 
 * URL : http://gnustep.org
 * License : GPL-3+
   Section : gnustep

  It builds those binary packages:

 gnustep-common - Common files for the core GNUstep environment
 gnustep-make - GNUstep build system
 gnustep-make-doc - Documentation for GNUstep Make

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

  https://mentors.debian.net/package/gnustep-make


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

dget -x 
https://mentors.debian.net/debian/pool/main/g/gnustep-make/gnustep-make_2.6.8-1.dsc

  More information about GNUstep can be obtained from 
http://gnustep.org/information/aboutGNUstep.html

  Changes since the last upload:

  
gnustep-make (2.6.8-1) unstable; urgency=low
 .
   * Team upload.
   * Add myself as new Co-Maintainer.
   * New upstream version
   * Rremove patches applied upstream:
 + honor-CFLAGS.patch
 + info-document-missing-direntry.patch
 + library-combo-whatis-entry.patch
 + manpage-spelling-errors.patch
 + test-clean-core.patch
 + texi-section-level.patch
   * Update no-gzip-timestampss.patch.
   * Update use-makeinfo.patch.
   * Bump Standards-Version to 3.6.8 in debian/control.
   * Set debhelper combatibility level to 9.
   * Update Vcs-* fields in debian/control
   * Remove no more needed {gnustep:Depends} var in debian/control.
   * Rewrite debian/rules:
 + Use dh $@ --with autotools-dev, autoreconf and buiddirectory
 + Disable strict gnustep-make version 2 mode for now
 + Build and install doc in *-indep sequence (Closes: #823281, #806197)
 + Use --with-layout=debian in configure scripts:
   remove fhs-system-includedir.patch
   * Provide a nex debian/clean file.
   * Update debian/copyright file.
   * Update debian/watch file to version 4.
   * Replace debian/upstream/signig-key.pgp by signing-key.asc:
 remove debian/source/include-binaries file.
   * Provide a new debian/gnustep-make-doc.install file.
   * Provide a new debian/gnustep-make-doc.info file.
   * Rename debian/gnustep-make-doc.doc-base to
 debian/gnustep-make-doc.doc-base.gnustep-make.
   * Provides new debian/gnustep-make-doc.doc-base.* files.
   * Provide a new debian/gnustep-make.install file.
   * Provide a new debian/gnustep-make.lintian-overrides file.
   * Provide a new debian/gnustep-make.manpages file.
   * Provide a new debian/gnustep-make.docs file.
   * Rename debian/fhs dir to debian/dh_gnustep.
   * New debian/addons dir: move gs_make and config.mk to it.
   * Update debian/gnustep-common.dirs and debian/gnustep-common.links.
   * Provide a new debian/gnustep-common.maintscript file.
   * Provide a new debian/gnustep-common.install file.
   * Provide a new debian/gnustep-common.manpages file.
   * Provide a new debian/gnustep-common.docs file.
   * Move gnustep-config.1 manpage to gnustep-make package:
 gnustep-make now Replaces: gnustep-common (<< 2.6.8-1).


  Regards,
   Eric Heintzmann
--- End Message ---
--- Begin Message ---
Hi Eric,


>What is the second question ?
I don't remember, probably I had two questions, one was fixed by myself looking 
at the package,
I edited the email and I forgot about that bit :)


>Iain R. Learmonth has uploaded gnustep-make.
>
>Thanks to you for helping me to improve gnustep-make packaging.


thank him from my side too!
Happy to have been a little bit helpful, and have fun in maintaining your new 
shiny package!

(of course I'll be there in case of regressions or questions).

BTW the autoreconf change seems to work correctly, it is mostly built 
everywhere!

Gianfranco--- End Message ---

Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system

[Eric Heintzmann]

Hi Gianfranco,


Le 16/05/2016 15:16, Gianfranco Costamagna a écrit :
> Hi Eric,
>
> nice indeed, so please wait some more time, and ping me back in 7-15 days if 
> nobody
> picked up the work in the meanwhile.
>
>
Iain R. Learmonth has uploaded gnustep-make.

Thanks to you for helping me to improve gnustep-make packaging.

Eric

Bug#806815: RFS: lirc/0.9.4~pre1-1.3 [NMU]

[Alec Leamas]

On 15/05/16 17:19, Mattia Rizzolo wrote:

On Sun, May 15, 2016 at 03:16:01PM +, Mattia Rizzolo wrote:

Given that nothing happened here in the last 6 months, I'm closing this
RFS ticket.

Feel free to open a new one if/when you'll come back.

I mean, Stefan is (at least in Debian) very much inactive; so you either
go ahead without his review (and so reopen this RFS), or give up this
quest :)



To be honest I havn't bee too active myself the last few months. That 
said, I keep updating the packaging at mentors aiming to submit a new 
request once the upstream lirc 0.9.4 is out.


Cheers!

--alec

Re: Binaries under "/usr/lib/"

[Giulio Paci]

Hi all,


On 18/05/2016 11:48, Ben Finney wrote:
> On 18/05/2016 10:21, Tiago Ilieve wrote:
>> On 17 May 2016 at 21:06, Ben Finney  wrote:
>>> How many process calls are there? The ideal solution IMO is to:
>> Not much of them. In my case, there's just one. I was thinking about a
>> corner case, where there would be multiple process calls, possible
>> making a patch like this somewhat hard to maintain.

>>> * Make the location of application-private binaries configurable at
>>>   build time, with a simple one-point-of-truth (e.g. a Makefile
>>>   variable).
>>>
>>> * Patch every call to those application-private binaries to use the
>>>   configured location.
>>>
>>> * Submit that patch upstream, explaining why it's superior behaviour.
>>>
>>> * Maintain the patch in Debian for the (short?) time while upstream
>>>   incorporates the patch.


>> Thanks for your input. I like your suggestions, as they look pretty
>> straightforward, but this is how this is being done for other
>> packages?
>
> Differently, depending on the state of upstream.

I agree with Ben, that it depends on the package.

One approach that usually fits my needs is the one proposed by Thibaut Paumard 
[1], that I am reproposing here with minimal changes:

1) install the binaries with the original names into /usr/lib//bin
2) install a small script (possibly named ) in /usr/bin
this script should provide an interface so that calling:
 
will grant that any required variable is set to the right value
and that /usr/lib//bin/ is executed; it is also
possible to drop extensions in the new interface;
3) ideally add "help" and "path" command, in order to simplify the life
of the users.

This approach works well also in case of binary names conflicts, is usually not 
invasive and allows smooth transitions to the new approach.

For an example you can see irstlm [2]. I think the example is nice as:
- irstlm has many scripts with extensions that people are using in their own 
scripts;
- it has a "dict" command (so we have a nice conflict with a famous tool);
- recently upstream introduced "plsa" and "plsa.sh" commands, so, after 
extension removal it has a collision with itself;
- there are "compile-lm" and "score-lm" commands that are very likely to 
conflicts with many other frameworks in this field;
- I provided a bash-autocompletion file for it.

Bests,
Giulio

[1] https://lists.debian.org/debian-mentors/2012/04/msg00012.html
[2] https://anonscm.debian.org/git/debian-science/packages/irstlm.git/

Re: a few questions on ITP shadowsocks-libev before formal RFS

[Jakub Wilk]

* Roger Shimizu , 2016-05-18, 02:14:
I'm doing ITP packaging on shadowsocks-libev. I have a few questions in 
detail.


I have set up a git repo on github: https://github.com/rogers0/shadowsocks-libev
My current changes are pushed to branch: RFC

Package builds fine with command: gbp buildpackage -us -uc 
--git-ignore-branch


Some questions/issues that I'm not sure:
- Upstream maintained debian/ folder long before, I'm going to keep the 
original debian/changelog. So I should also keep the upstream as 
maintainer, and add myself as the uploader?


It doesn't matter who maintained the package in the package. What 
matters is who is going to maintain it now for Debian. Did you ask 
upstream to co-maintain it with you? You certainly shouldn't put anyone 
to Maintainer/Uploaders without their consent.


- The package is mainly GPLv3, but it links to OpenSSL library, is that 
OK?


GPL+OpenSSL is no-no.

README says that mbedtls, which is GPL-compatible, can be used as an 
alternative to OpenSSL, so you should try it.


- Upstream repo includes library source code of libev, libsodium, 
libudns. Is it OK to keep as it is, or have to remove and make another 
source tarball?


As long as they are DFSG-free, you can keep them in the source package. 
Just make sure they are not used at build time. This is best achieved by 
"rm -rf"ing them early in the build process. (If you're using dh, then 
beginning of override_dh_auto_build is probably the best place.)


- The answer of above question may affect: whether I should remove 
copyright of library libev, libsodium, libudns from debian/copyright?


If you keep them in .orig.tar, then you must also keep them in 
debian/copyright.


If you remove them from .orig.tar, then remove them from 
debian/copyright too.



- Is it needed to add "dh_autoreconf" in debian/rules?


It's not required by policy, but many sponsors will (rightfully!) insist 
to regenerate autotools stuff from source.


- I have no idea on the following lintian error, because 
postrm/postinst scripts are generated by dh



E: shadowsocks-libev: postrm-contains-additional-updaterc.d-calls 
etc/init.d/shadowsocks-libev-local


This seems to be caused by passing --no-start to dh_installinit:

dh_installinit --no-start --name=shadowsocks-libev-server@
dh_installinit --no-start --name=shadowsocks-libev-tunnel@
dh_installinit --no-start --name=shadowsocks-libev-redir@
dh_installinit --no-start --name=shadowsocks-libev-local@

My initsystem-fu is too weak to tell whether it's a d/rules bug, 
debhelper bug, or Lintian bug, or just something that should be 
overridden.


--
Jakub Wilk

Re: Bug#823478: python3-protobuf3

[Gianfranco Costamagna]

Hi,

>I know exactly what Mattia felt. :-(


git reflog is a good friend in this case :)


G.

Re: Binaries under "/usr/lib/"

[Ben Finney]

Tiago Ilieve  writes:

> Thanks for your input. I like your suggestions, as they look pretty
> straightforward, but this is how this is being done for other
> packages?

Differently, depending on the state of upstream.

> I was looking at § 9.1.1 File System Structure[1] from the Debian
> Policy Manual and it states that the need to put object files,
> internal binaries and libraries under "/lib{,32}" and "/usr/lib{,32}"
> is a requirement - however, it doesn't says how this should be done.

Right. Debian Policy states how things should be; it is not the job of
Policy to say exactly how to implement most policy requirements, because
there must be plenty of room to evolve better solutions.

So, if you want more specifics, you will need to point us to the exact
code base we're discussing so advice can be given in context.

-- 
 \   “People are very open-minded about new things, as long as |
  `\ they're exactly like the old ones.” —Charles F. Kettering |
_o__)  |
Ben Finney

Re: Bug#823478: python3-protobuf3

[Tiago Ilieve]

Jonathon,

On 18 May 2016 at 05:52, Jonathon Love  wrote:
>> umh, you force pushed everything, master, upstream and pristine-tar
>> branches.  WHY?  what did you do?
>
> oh, sorry, i never intended for you to look at that repo, assuming you'd
> look at the debian-mentors one.

This is something I've seen on "debian-mentors" mailing list more than
one time and we should urge people to don't do it: if you pushed
changes to a public repository please, never, ever "--force" a new
push. It's OK if you are doing this on a private location for yourself
(as the forced push won't affect anyone else), but it doesn't make any
sense to mention a repository in a public mailing list and then assume
that no one would clone/fetch it.

I know exactly what Mattia felt. :-(

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: package name for what upstream calls protobuf3

[Jakub Wilk]

* Jonathon Love , 2016-05-18, 18:45:

i'm in the process of packaging protobuf3:

https://github.com/Pr0Ger/protobuf3

this is an implementation of protocol buffers 2 for python 3.

according to debian policy, this should be named python3-protobuf3, but 
i think this name isn't ideal


I don't know anything about anything about Python, but if packaging 
policy says that the package name should be named after the module name, 
and it turns out that the package name is too generic or misleading or 
otherwise inadequate, then that's only because the module name had 
exactly the same problem. So please get it renamed upstream. This is not 
something that should be papered over by deviating from the usual naming 
policy.


--
Jakub Wilk

package name for what upstream calls protobuf3

[Jonathon Love]

hi,

i'm in the process of packaging protobuf3:

https://github.com/Pr0Ger/protobuf3

this is an implementation of protocol buffers 2 for python 3.

according to debian policy, this should be named python3-protobuf3, but 
i think this name isn't ideal, because it could be mistaken for:


a) an implementation of protocol buffers 3

b) the official google protocol buffers implementation

i'm proposing to call it:

python3-pr0ger-protobuf3

what should i call it?

with thanks

jonathon

Bug#823478: python3-protobuf3

[Jonathon Love]

umh, you force pushed everything, master, upstream and pristine-tar
branches.  WHY?  what did you do?
oh, sorry, i never intended for you to look at that repo, assuming you'd 
look at the debian-mentors one.

And still it doesn't build, if that was meant to fix it.
Without thinking of it I already overwrote the older files, so I can't
diff anymore :S
yeah, i've got it building on debian now, but i'm waiting for 
confirmation of what it should be called before pushing. i've asked on 
d-mentors.


sorry for the inconvenience, and thanks for your patience.

jonathon

Re: Binaries under "/usr/lib/"

[Tiago Ilieve]

Hi Ben,

On 17 May 2016 at 21:06, Ben Finney  wrote:
> How many process calls are there? The ideal solution IMO is to:

Not much of them. In my case, there's just one. I was thinking about a
corner case, where there would be multiple process calls, possible
making a patch like this somewhat hard to maintain.

> * Make the location of application-private binaries configurable at
>   build time, with a simple one-point-of-truth (e.g. a Makefile
>   variable).
>
> * Patch every call to those application-private binaries to use the
>   configured location.
>
> * Submit that patch upstream, explaining why it's superior behaviour.
>
> * Maintain the patch in Debian for the (short?) time while upstream
>   incorporates the patch.

Thanks for your input. I like your suggestions, as they look pretty
straightforward, but this is how this is being done for other
packages? I was looking at § 9.1.1 File System Structure[1] from the
Debian Policy Manual and it states that the need to put object files,
internal binaries and libraries under "/lib{,32}" and "/usr/lib{,32}"
is a requirement - however, it doesn't says how this should be done.

So, even appreciating your suggestions, I would like to hear from some
maintainers that are used to do this on their packages. This way we
can possible mix both some battle-tested approaches and your nice tips
as well.

Regards,
Tiago.

[1]: https://www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#823478: python3-protobuf3

[Mattia Rizzolo]

On Tue, May 17, 2016 at 01:07:05PM +1000, Jonathon Love wrote:
> thanks for the review, and sorry for the embarrassing "does not build"
> situation. i was packaging on ubuntu, and my experience has been that if it
> works there, it will work on debian - but apparently not, i'll be more
> careful in future.

umh, you force pushed everything, master, upstream and pristine-tar
branches.  WHY?  what did you do?
And still it doesn't build, if that was meant to fix it.
Without thinking of it I already overwrote the older files, so I can't
diff anymore :S

> i'm actually writing to ask your advice about the name of the package.
> 
> upstream is called protobuf3, but it's an implementation of protocol buffers
> 2 for python 3

Then name made me wonder too.
I would like for somebody else on the mentors list to comment on it, but
also keep in mind that there is a python policy that says the name
should be python(3)-${module name}, that is, whatever you import.

> python3-pr0ger-protobuf3
> 
> after the developer's nick:

This golang-style name would actually turn me mad :|

-- 
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#824619: marked as done (RFS: golang-github-hlandau-degoutils/0.0~git20160421.0.389a847-1)

[Debian Bug Tracking System]

Your message dated Wed, 18 May 2016 08:04:55 +
with message-id <20160518080454.ge20...@chase.mapreri.org>
and subject line Re: Bug#824619: RFS: 
golang-github-hlandau-degoutils/0.0~git20160421.0.389a847-1
has caused the Debian Bug report #824619,
regarding RFS: golang-github-hlandau-degoutils/0.0~git20160421.0.389a847-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.)


-- 
824619: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824619
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 the package "golang-github-hlandau-degoutils":

  git clone 
https://anonscm.debian.org/git/pkg-go/packages/golang-github-hlandau-degoutils.git

  
  cd golang-github-hlandau-degoutils && pristine-tar checkout 
../golang-github-hlandau-degoutils_0.0~git20160421.0.389a847.orig.tar.gz

For verification, these are the current branch heads:

  git show-ref --heads
  f514bc6ba949df1503ee7256c9e8089221ddf8e9 refs/heads/master
  2c81f74b4a06ab6aaf08b2de2f64d9c67a44135b refs/heads/pristine-tar
  308bab8ebaaa97988cc3a2c692cbfae207262326 refs/heads/upstream

It builds these binary packages:

  golang-github-hlandau-degoutils-dev -- miscellaneous utilities for Go

This package is a prerequisite for building acmetool version 0.0.51.

Changes since the last upload:

golang-github-hlandau-degoutils (0.0~git20160421.0.389a847-1) unstable; 
urgency=medium

  * New upstream snapshot
  * Update Standards-Version to 3.9.8

 -- Peter Colberg   Tue, 17 May 2016 22:46:54 -0400

Regards,
Peter
--- End Message ---
--- Begin Message ---
On Tue, May 17, 2016 at 11:02:30PM -0400, Peter Colberg wrote:
> I am looking for a sponsor for the package "golang-github-hlandau-degoutils":

o/

>   git clone 
> https://anonscm.debian.org/git/pkg-go/packages/golang-github-hlandau-degoutils.git

Finally something that doesn't need NEW and a binary upload! ;)

Uploaded!
-- 
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
--- End Message ---

Bug#824621: marked as done (RFS: golang-gopkg-cheggaaa-pb.v1/1.0.3-1)

[Debian Bug Tracking System]

Your message dated Wed, 18 May 2016 08:00:32 +
with message-id <20160518080027.gd20...@chase.mapreri.org>
and subject line Re: Bug#824621: RFS: golang-gopkg-cheggaaa-pb.v1/1.0.3-1
has caused the Debian Bug report #824621,
regarding RFS: golang-gopkg-cheggaaa-pb.v1/1.0.3-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.)


-- 
824621: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824621
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 the package "golang-gopkg-cheggaaa-pb.v1":

  git clone 
https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-cheggaaa-pb.v1.git


  cd golang-gopkg-cheggaaa-pb.v1 && pristine-tar checkout 
../golang-gopkg-cheggaaa-pb.v1_1.0.3.orig.tar.gz

For verification, these are the current branch heads:

  git show-ref --heads
  1c9792371b8fa578383976e5392413faab17ac31 refs/heads/master
  14a3ae47662f09852fd6c3928f80ace87d25ccb6 refs/heads/pristine-tar
  ffedb36e7531cf0a94972deba4b39bc2e1c3ee6e refs/heads/upstream

It builds these binary packages:

  golang-gopkg-cheggaaa-pb.v1-dev -- simple console progress bar for

This package is a prerequisite for building acmetool version 0.0.51.

Changes since the last upload:

golang-gopkg-cheggaaa-pb.v1 (1.0.3-1) unstable; urgency=medium

  * New upstream release (Closes: #824601)
  * Rename source package to golang-gopkg-cheggaaa-pb.v1
  * Rename binary package to golang-gopkg-cheggaaa-pb.v1-dev
  * Update XS-Go-Import-Path
  * Drop Conflicts/Provides/Replaces for golang-pb-dev
  * Update Standards-Version to 3.9.8

 -- Peter Colberg   Tue, 17 May 2016 22:45:21 -0400

Regards,
Peter
--- End Message ---
--- Begin Message ---
On Tue, May 17, 2016 at 11:17:04PM -0400, Peter Colberg wrote:
> I am looking for a sponsor for the package "golang-gopkg-cheggaaa-pb.v1":

o/

>   git clone 
> https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-cheggaaa-pb.v1.git

uploaded!

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

Bug#824622: marked as done (RFS: golang-gopkg-square-go-jose.v1/1.0.2-1)

[Debian Bug Tracking System]

Your message dated Wed, 18 May 2016 07:53:09 +
with message-id <20160518075307.gc20...@chase.mapreri.org>
and subject line Re: Bug#824622: RFS: golang-gopkg-square-go-jose.v1/1.0.2-1
has caused the Debian Bug report #824622,
regarding RFS: golang-gopkg-square-go-jose.v1/1.0.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.)


-- 
824622: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824622
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 the package "golang-gopkg-square-go-jose.v1":

  git clone 
https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-square-go-jose.v1.git

   
  cd golang-gopkg-square-go-jose.v1 && pristine-tar checkout 
../golang-gopkg-square-go-jose.v1_1.0.2.orig.tar.gz

For verification, these are the current branch heads:

  git show-ref --heads
  706c5da0100d600139b62485fb23b771b3733e3d refs/heads/master
  2773f950f3b6e98fe7f5311e2c7a845a60665817 refs/heads/pristine-tar
  37ea841cb4b46d87a6b0b8fd9d77efc95ff06d33 refs/heads/upstream

It builds these binary packages:

  golang-gopkg-square-go-jose.v1-dev -- Javascript Object Signing and 
Encryption (JOSE) for Go

This package is a prerequisite for building acmetool version 0.0.51.

Changes since the last upload:

golang-gopkg-square-go-jose.v1 (1.0.2-1) unstable; urgency=medium

  * New upstream release (Closes: #824600)
  * Update debian/copyright
  * Rename source package to golang-gopkg-square-go-jose.v1
  * Rename binary package to golang-gopkg-square-go-jose.v1-dev
  * Update XS-Go-Import-Path
  * Update Standards-Version to 3.9.8

 -- Peter Colberg   Tue, 17 May 2016 22:46:10 -0400

Regards,
Peter
--- End Message ---
--- Begin Message ---
On Tue, May 17, 2016 at 11:21:38PM -0400, Peter Colberg wrote:
> I am looking for a sponsor for the package "golang-gopkg-square-go-jose.v1":

o/

>   git clone 
> https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-square-go-jose.v1.git
...
>   * Rename source package to golang-gopkg-square-go-jose.v1
>   * Rename binary package to golang-gopkg-square-go-jose.v1-dev

meh, golang.

Assuming you are going to have the older one removed, I uploaded this
one!

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

Bug#820383: marked as done (RFS: photocollage/1.4.0-1 [ITP])

[Debian Bug Tracking System]

Your message dated Wed, 18 May 2016 07:39:18 +
with message-id <20160518073917.gb20...@chase.mapreri.org>
and subject line Re: Bug#820383: RFS: photocollage/1.4.0-1 [ITP]
has caused the Debian Bug report #820383,
regarding RFS: photocollage/1.4.0-1 [ITP]
to be marked as done.

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

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


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

Dear mentors,

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

 Package name: photocollage
 Version : 1.4.0-1
 Upstream Author : Adrien Vergé
 URL : https://github.com/adrienverge/PhotoCollage
 License : GPL-2+
 Section : graphics

It builds this binary package:

  photocollage - Graphical tool to make photo collage posters

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

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

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

  dget -x 
http://mentors.debian.net/debian/pool/main/p/photocollage/photocollage_1.4.0-1.dsc

More information about PhotoCollage can be obtained from
https://github.com/adrienverge/PhotoCollage and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820377

Regards,
 Adrien Vergé
--- End Message ---
--- Begin Message ---
On Tue, May 17, 2016 at 10:31:32PM +0200, Adrien Vergé wrote:
> Thanks for your remarks. I've addressed all of them, as well as
> another warning output by `pbuilder --build`.

Cool, uploaded! :)


Thanks for your contribution to Debian!

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

Bug#824625: marked as done (RFS: pentobi/12.0-1)

[Debian Bug Tracking System]

Your message dated Wed, 18 May 2016 07:10:09 +
with message-id <20160518071007.ga20...@chase.mapreri.org>
and subject line Re: Bug#824625: RFS: pentobi/12.0-1
has caused the Debian Bug report #824625,
regarding RFS: pentobi/12.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.)


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

Package name: pentobi
Version : 12.0-1
Upstream Author : Markus Enzenberger
URL : http://pentobi.sourceforge.net/
License : GPL-3.0+
Section : games

It builds those binary packages:

 pentobi - clone of the strategy board game Blokus

 pentobi-kde-thumbnailer - clone of the strategy board game Blokus -
   KDE thumbnailer

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

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

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

 dget -x http://mentors.debian.net/debian/pool/main/p/pentobi/pentobi_12.0-1.dsc

Git repository can be viewed online at

 https://anonscm.debian.org/git/pkg-games/pentobi.git

Changes since the last upload:

pentobi (12.0-1) unstable; urgency=medium

  * New upstream release.
  * d/control:
- Bump Standards-Version to 3.9.8, no changes needed.
- Unify Vcs-Git and Vcs-Browser.
- Konqueror is not KDE Frameworks 5 application and thus cannot use
  pentobi-kde-thumbnailer; removed Enhances.
  * d/copyright: Update copyright years.
  * d/patches/desktop-semicolon.patch: Add a missing ; in desktop file.
  * d/rules: Enable all hardening flags.


Regards,
Juhani Numminen
--- End Message ---
--- Begin Message ---
On Wed, May 18, 2016 at 08:16:12AM +0300, Juhani Numminen wrote:
> I am looking for a sponsor for my package "pentobi".

o/

>  https://anonscm.debian.org/git/pkg-games/pentobi.git

Uploaded! :)

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

Re: a few questions on ITP shadowsocks-libev before formal RFS

[Gianfranco Costamagna]

Hi,

>I have set up a git repo on github: 
>https://github.com/rogers0/shadowsocks-libev
>My current changes are pushed to branch: RFC


(I won't clone that right now, only answering questions)
>Package builds fine with command: gbp buildpackage -us -uc --git-ignore-branch


you should also try pbuilder or sbuild clean environments
>Some questions/issues that I'm not sure:
>- Upstream maintained debian/ folder long before, I'm going to keep
>the original debian/changelog. So I should also keep the upstream as
>maintainer, and add myself as the uploader?


I would remove the upstream packaging, we use changelog to keep track
of changes that went in Debian, not changes that were done by somebody else.


>- The package is mainly GPLv3, but it links to OpenSSL library, is>that OK? 
>Since there's concern mentioned in debian/README.Debian


please read that page
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

>- Upstream repo includes library source code of libev, libsodium,>libudns. Is 
>it OK to keep as it is, or have to remove and make another
>source tarball?


as long as you don't use them it is fine, please try to package them separately
and use the system versions, not bundled code

BTW the copyright file has to list them, so there is a tradeoff between 
removing files to
have a more readable /easy to maintain copyright file and tarball, and having a 
pristine tarball from
upstream.

>- The answer of above question may affect: whether I should remove>copyright 
>of library libev, libsodium, libudns from debian/copyright?


oops answered above :)
(BTW a repack done not because of non-dfsg files is a "ds" aka Debian Source 
repack)

please check copyright Files-Excluded: keyword


>- Is it needed to add "dh_autoreconf" in debian/rules? I have tested>it, it 
>builds well.


add dh-autoreconf to control file and 
"dh $@ --with autoreconf"
in the default call (rules file)


>- I have no idea on the following lintian error, because>postrm/postinst 
>scripts are generated by dh
>
>E: shadowsocks-libev: postrm-contains-additional-updaterc.d-calls
>etc/init.d/shadowsocks-libev-local
>E: shadowsocks-libev: postrm-contains-additional-updaterc.d-calls
>etc/init.d/shadowsocks-libev-tunnel
>E: shadowsocks-libev: postrm-contains-additional-updaterc.d-calls
>etc/init.d/shadowsocks-libev-server
>E: shadowsocks-libev: postrm-contains-additional-updaterc.d-calls
>etc/init.d/shadowsocks-libev-redir
>


maybe the broken files comes from upstream?

G.

Bug#824489: RFS: dwarfutils/20160507-1 [ITA] -- utility and library to work with DWARF debug information

[Gianfranco Costamagna]

Hi Fabian


>dh_auto_install does not do anything useful here: `make install` for

>some reason does not actually install anything but just compiles some
>examples (that won't be part of the Debian package) and then finishes
>with the note
>
>"No install provided, see comments in the README"
>
>The README basically says that the installation should be performed
>manually by copying the desired files to the desired directories,
>which is what dh_install will do in the next step. Therefore, calling
>dh_auto_install probably won't hurt, but it does waste time, which is
>why I have overwritten it with an empty rule.


I don't see why it can't be patched to work like almost every other tool
that uses a build system, but I don't care a lot about upstream.

The (possible) issue I foresee is: somebody updates the upstream build system
to install the files too, you update the packaging without checking
that, the Debian upload is buggy because some files are missing.

in short words, I prefer an useless call, rather than a broken package!

>The hardening rules do export -fPIE, but not -fPIC. Without -fPIC, I
>get the following error when trying to link the static library into
>another shared library:
>
>/usr/bin/ld: /tmp/[...]/usr/lib/libdwarf.a(dwarf_alloc.o): relocation 
>R_X86_64_PC32 against symbol `dwarf_dealloc' can not be used when making a 
>shared object; >recompile with -fPIC
>/usr/bin/ld: final link failed: Bad value
>collect2: error: ld returned 1 exit status


ok

>Your patch doesn't fix that, either (although I might have missed
>something there; I'm not exactly fluent in Autotools), whereas if I'm
>building libdwarf with -fPIC, the shared library builds and links just

>fine.

I'm not fluent too, thanks for checking and replying about that, it was already
fine, but I just wanted to be sure there was a rationale for the change!

let me know your opinion about the install step, and I'll do the final checks + 
sponsoring


BTW, I like when a patch/fix can be upstream, so I propose another one (feel 
free to reject of course, you are
the maintainer, not me!)
--- dwarfutils-20160507.orig/libdwarf/configure.in
+++ dwarfutils-20160507/libdwarf/configure.in
@@ -127,11 +127,11 @@ AC_TRY_COMPILE([#include ],[  Elf
dnl default-disabled shared
AC_SUBST(build_shared,[none])
AC_SUBST(dwfpic,[])
+AC_SUBST(dwfpic,[-fPIC])
AC_ARG_ENABLE(shared,AC_HELP_STRING([--enable-shared],
[build shared library libdwarf.so]))
AS_IF([ test "x$enable_shared" = "xyes"], [
AC_SUBST(build_shared,[libdwarf.so])
-   AC_SUBST(dwfpic,[-fPIC])
])

dnl default-enabled nonshared


maybe it makes sense to enable it alsofor static libs then anyway.
(probably all the if block can be removed this way, but this is something that 
upstream has to investigate ;))

thanks!


Gianfranco