Bug#824787: marked as done (RFS: acmetool/0.0.51)

[Debian Bug Tracking System]

Your message dated Thu, 19 May 2016 21:17:22 +
with message-id <20160519211720.gr20...@chase.mapreri.org>
and subject line Re: [Letsencrypt-devel] Bug#824787: RFS: acmetool/0.0.51
has caused the Debian Bug report #824787,
regarding RFS: acmetool/0.0.51
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.)


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

  git clone https://anonscm.debian.org/git/letsencrypt/acmetool.git
   
  cd acmetool && pristine-tar checkout ../acmetool_0.0.51.orig.tar.gz  

For verification, these are the current branch heads:

  git show-ref --heads
  b4e506ba03160462e258d0b769a6eef0ecf5b52d refs/heads/master
  d426d432fe2c3cdc87db3dc177d561e006bb8ca7 refs/heads/pristine-tar
  31837d34e6892b788020ddad9c18171985936c81 refs/heads/upstream

It builds these binary packages:

  acmetool -- automatic certificate acquisition tool for Let's Encrypt

Changes since the last upload:

acmetool (0.0.51-1) unstable; urgency=medium

  * New upstream release
  * Drop patches applied upstream
  * Build depend on
- golang-gopkg-cheggaaa-pb.v1-dev
- golang-gopkg-square-go-jose.v1-dev
- golang-github-hlandau-degoutils-dev (>= 0.0~git20160421.0.389a847)
  * Build depend on dh-golang (>= 1.17~) and install with --no-source
  * Do not compress example scripts
  * Add lintian overrides for spelling error false positives

 -- Peter Colberg   Wed, 18 May 2016 07:48:14 -0400

Regards,
Peter
--- End Message ---
--- Begin Message ---
On Thu, May 19, 2016 at 02:03:28PM -0400, Peter Colberg wrote:
> I am looking for a sponsor for the package "acmetool":
> 
>   git clone https://anonscm.debian.org/git/letsencrypt/acmetool.git

Done, enjoy! :)

-- 
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#824787: RFS: acmetool/0.0.51

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "acmetool":

  git clone https://anonscm.debian.org/git/letsencrypt/acmetool.git
   
  cd acmetool && pristine-tar checkout ../acmetool_0.0.51.orig.tar.gz  

For verification, these are the current branch heads:

  git show-ref --heads
  b4e506ba03160462e258d0b769a6eef0ecf5b52d refs/heads/master
  d426d432fe2c3cdc87db3dc177d561e006bb8ca7 refs/heads/pristine-tar
  31837d34e6892b788020ddad9c18171985936c81 refs/heads/upstream

It builds these binary packages:

  acmetool -- automatic certificate acquisition tool for Let's Encrypt

Changes since the last upload:

acmetool (0.0.51-1) unstable; urgency=medium

  * New upstream release
  * Drop patches applied upstream
  * Build depend on
- golang-gopkg-cheggaaa-pb.v1-dev
- golang-gopkg-square-go-jose.v1-dev
- golang-github-hlandau-degoutils-dev (>= 0.0~git20160421.0.389a847)
  * Build depend on dh-golang (>= 1.17~) and install with --no-source
  * Do not compress example scripts
  * Add lintian overrides for spelling error false positives

 -- Peter Colberg   Wed, 18 May 2016 07:48:14 -0400

Regards,
Peter

Bug#819394: RFS: stormlib/9.20-1 [ITP]

[Pali Rohár]

On Wednesday 27 April 2016 13:01:20 Gianfranco Costamagna wrote:
> Hi, the packaging seems good now, I would like to ask you a final question:
> 
> how do you feel about using the same license for debian packaging and 
> upstream?
> (asking about changing GPL-3+ to MIT).

Ok, I changed debian files to MIT (same as upstream).

> Forwarding patches otherwise would be impossible without a relicense.
> 
> and the copyright still needs to be updated:
> 
> >So in this case, how to update copyright? Just for src/lzma? Or for all
> >other embedded libraries even when they are not used and needed?
> 
> 
> you have to list *every* copyright and license on copyright file, regardless
> of it being used or not.
> This is a showstopper for ftpmasters.

Done, now all embedded libraries have entry in copyright file.

Package is now updated on mentors server. Something more is needed?

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

Re: Adding runtime dependencies that aren't caught by shlibs:Depends

[Jakub Wilk]

* Jens Reyer , 2016-05-19, 16:57:
First off, I'm not sure about every single dependency if it is needed 
at all.


Quick grep over the *.dll.so indeed shows that they use a bunch of 
libraries you mentioned:


$ strings /usr/lib/i386-linux-gnu/wine/*.dll.so | grep '^lib.*[.]so[.]' | sort 
-u | grep -v '!'
libGLU.so.1
libOSMesa.so.8
libOpenCL.so.1
libX11.so.6
libXext.so.6
libc.so.6
libfontconfig.so.1
libfreetype.so.6
libgnutls.so.30
libjpeg.so.62
liblber-2.4.so.2
liblcms2.so.2
libldap_r-2.4.so.2
libm.so.6
libncurses.so.5
libodbc.so.2
libopenal.so.1
libpcap.so.0.8
libpng16.so.16
libpthread.so.0
libresolv.so.2
libtiff.so.5
libwine.so.1
libxml2.so.2
libxslt.so.1
libz.so.1

I guess a better method of obtaining the list of used shared libraries 
is to grep for "SONAME_" in include/config.h (after it was created by 
the configure script).


Once you have the list of needed shlibs, the simplest way to compute 
package dependency is to create an ELF that depends on all of them, and 
then use dpkg-shlibdeps against it.


You can steal the idea of how to create such ELF here:
https://bitbucket.org/jwilk/python-dctypes/src/default/dctypes2elf

--
Jakub Wilk

Re: Adding runtime dependencies that aren't caught by shlibs:Depends

[Gianfranco Costamagna]

Hi Jens,

>Now, assuming that we really need all of them, but that there is no way
>to automatically add them: is there any way to compute the needed
>runtime dependency for a given builddep, in order to avoid hardcoding
>this list and update it with every soname change of a depended upon
>package?


unfortunately I think there isn't a way.

BTW if you do dlopen of a library, there is no guarantee that the latest 
release will work,
so even if such a way would exist, it won't be the safe thing to do.
shlibs:Depends guarantees that the correct library is picked up at runtime, and 
if you want
to dlopen it I guess the only way is to manually runtime-depend on the library 
itself.

(we had the same libpng related discussion before on #820566 I think)

Gianfranco

Adding runtime dependencies that aren't caught by shlibs:Depends

[Jens Reyer]

Hi,

I'm working on adding more runtime dependencies to wine (see #823991).
Wine uses the dh sequencer and all relevant binary packages have a
"Depends: ${shlibs:Depends}". This adds some runtime dependencies, but
by far not for every build-dependency -dev package.

If I try to do that manually I come up with the following list of
builddeps and assumed runtime dependencies:

  libxi-dev,  libxi6
  libxt-dev,  libxt6
  libxmu-dev, libxmu6
  libxrandr-dev,  libxrandr2
  libxrender-dev, libxrender1
  libxkbfile-dev, libxkbfile1
  libxxf86vm-dev, libxxf86vm1
  libxxf86dga-dev,libxxf86dga1
  libxinerama-dev,libxinerama1
  libxcomposite-dev,  libxcomposite1
  libpng-dev, libpng16-16
  libssl-dev, libssl1.0.2
  libgsm1-dev,libgsm1
  libjpeg-dev,libjpeg62-turbo
  libtiff-dev,libtiff5
  libxslt1-dev,   libxslt1.1
  unixodbc-dev,   libodbc1
  libcups2-dev,   libcups2
  libdbus-1-dev,  libdbus-1-3
  freeglut3-dev,  freeglut3
  libosmesa6-dev, libosmesa6
  libgnutls28-dev,libgnutls30
  libgettextpo-dev,   libgettextpo0


First off, I'm not sure about every single dependency if it is needed at
all. Is it reasonable to depend on (or recommend) all these packages,
given that the builddeps were added for a good reason? Or am I on the
completely wrong track here?

So far we only added dependencies manually for:
  libncurses5-dev,libncurses5
  libfreetype6-dev,   libfreetype6
  libfontconfig1-dev, libfontconfig1
But I'd assume we just didn't get bugreports for most of the others,
because Wine is such a big beast and many dependencies are just used
seldom and/or installed anyway.

Now, assuming that we really need all of them, but that there is no way
to automatically add them: is there any way to compute the needed
runtime dependency for a given builddep, in order to avoid hardcoding
this list and update it with every soname change of a depended upon
package?

We do so for libncurses5-dev and libfreetype6-dev by stripping the
"-dev" from the builddep line that contains "ncurses" or "freetype". But
this approach unfortunately doesn't work for all packages' naming schemes.

Greets
jre

Bug#823521: RFS: irstlm/6.00.05-1 -- IRST Language Modeling Toolkit

[Giulio Paci]

Hi Balint and all,

On 16/05/2016 16:50, Bálint Réczey wrote:
> Hi Giulio,
> 
> 2016-05-08 14:32 GMT+02:00 Giulio Paci :
>> Hi Balint and all,
>>
>> Il 08/mag/2016 14:15, "Bálint Réczey"  ha scritto:
>>>
>>> Control: owner -1 bal...@balintreczey.hu
>>>
>>> 2016-05-06 23:44 GMT+02:00 Gianfranco Costamagna
>>> :
 Hi Balint, so I presume you want to set yourself as owner of this bug,
 right?
>>>
>>> Sure, and I'm also about to upload the package in the current state.
>>> Feel free to continue the discussion about bringing irstlm under Debian
>>> Science
>>> in this bug or or on the team's mailing list.
>>
>> I currently do not need this version (I am using the old one in production,
>> so I think we can wait a few days before uploading this package and upload
>> it under Debian science).
>>
>> If I understand correctly, given its current state, the only things that I
>> need to do are:
>> 1) ensure that I am part of Debian Science team;
>> 2) change maintainer and uploaders;
>> 3) move git repository under Debian Science and update Vcs fields in the
>> package;
>> 4) update changelog.
>>
>> Is that all?
> 
> I think so.
> 
>>
>> In order to move the repository, is it fine if I setup a new repository in
>> Debian Science, change my remote url and push there? Or will I cause
>> troubles  acting in this way (eg.: too many commits emails)?
>> Do you have a better migration workflow?
> 
> I think pushing is OK.

As you probably noticed I moved the package under Debian Science and Mattia 
already uploaded the new version. :-)

> Since I have uploaded the package and FTP Masters already accepted it
> I close this bug.
> 
> Regarding the package, providing a symbols file would be nice. :-)

Given my previous attempt at providing symbols files for C++ packages I am 
reluctant to do so.
If possible I will avoid adding that file for a while:
upstream is not answering my emails since a while and I still have to instruct 
them about SONAMEs and many other things (e.g., binary name conflicts, scripts 
extensions,
...); I would like to have better interaction with them, before trying to keep 
track of symbols.

> Feel free to ping me on ask for sponsorship on debian-science in the
> future, there is no
> need to file formal RFS-s to BTS if there are people who regularly
> sponsor upload for you. :-)

Fine, thank you. :-)

Cheers,
Giulio

Bug#823478: marked as done (RFS: python3-protobuf3/0.2.1-2 [ITP])

[Debian Bug Tracking System]

Your message dated Thu, 19 May 2016 21:30:03 +1000
with message-id <93ac73f2-7af5-2e06-2a15-76ac3f15a...@thon.love>
and subject line Re: Bug#823478: python3-protobuf3
has caused the Debian Bug report #823478,
regarding RFS: python3-protobuf3/0.2.1-2 [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.)


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

 * Package name: python3-protobuf3
   Version : 0.2.1-2
   Upstream Author :Sergey Petrov 
 * URL : https://github.com/Pr0Ger/protobuf3
 * License : MIT
   Section : python

It builds the binary package:

  python3-protobuf3 - implementation of Google's Protocol Buffers for Python 3

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

https://mentors.debian.net/package/python3-protobuf3


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

dget -x 
https://mentors.debian.net/debian/pool/main/p/python3-protobuf3/python3-protobuf3_0.2.1-2.dsc

More information about hello can be obtained from 
https://github.com/Pr0Ger/protobuf3

with thanks
   Jonathon
--- End Message ---
--- Begin Message ---

package is being withdrawn, as per discussion.--- End Message ---

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

[lumin]

On Thu, 2016-05-19 at 06:32 +, Gianfranco Costamagna wrote:
> Hi Lumin,

> >Why should runtime deps be added into build-dep, which are useless
> >unless I provide python-caffe-* testsuite.
> 
> 
> not sure then, it should be fine that way!

An update to this, according to
https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html
Even if I want to add some testsuite for python-caffe, I don't need
to add those runtime deps in control, I can add them in tests/control
instead, by adding "Depends" field that supprted by d/tests/control.

> >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
> 
> I mean: "protobuf code is declared to be python3 ready"
> 
> so I guess it is a matter of adding a package in control file, adding python3 
> in rules and some little overrides.
> my request was: can you please share that trivial patch at least on the bug 
> report?
> maybe somebody will pick it up and NMU the package

OpenCV 3.0 can yield python3-opencv package with just a small patch,
which is provided by a user in an opencv debian bug.
Protobuf might be similar.

> >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.
> 
> 
> no, this isn't a blocker, but keep in mind that our goal is stretch, and 
> python2 code doesn't fit too much in it.
> I guess in case the dependencies will become python3 ready, you will add a 
> new python3-caffe-cpu package, right?

And I agree, on behalf of the release team I should make python3-*
packages in the initial upload. I decide to bump python from
2 to 3. python3-caffe can be built easily with packages outside
of Debian archive. One of the unapplied patches I removed
is for python3->python2 downgrade reversal.

opencv and protobuf is still on the way of 2 to 3, in Debian.

> can two python packages be produced by caffe or just one at each time?

One each time. Cmake requires a option PYTHON_VERSION=X where X can be
either "2" or "3".

> in the latter case you will need to drop python-caffe-cpu, add 
> python3-caffe-cpu and breaks+replaces to ensure an
> upgrade path from the python2 to the python3 version.

let's bump python version for this package.

> For sure if having the python3 dependencies in place is a matter of some 
> days, we should consider that, but
> no, this isn't a blocker right now.
> (I'm more worried about the whole breakage that comes at gcc and cuda 
> updates, will you be able to keep the package
> "installable and buildable" in unstable at each transition?)

CPU version is safe. and
no need to worry about GCC and CUDA, the source of trouble
is the compatibility between NVCC and GCC. 
That's exactly why I'm now a maintainer of CUDA 
I helped the 6.5->7.0 and 7.0->7.5 bump of CUDA, and the NVCC
usability got into a better situation, where caffe-cuda
survived.

CUDA 8.0 is comming soon, if NVCC 8.x fails to work with GCC-6,
we just lock build-dep at GCC-5. Safe too.

Actually I guess CUDA 8.5 release date is prior to stretch freeze.

> >It seems that skimage is not a blocker of Caffe.
> 
> 
> it is, the package is not in testing, so I guess caffe won't be able to 
> migrate.
> Don't forget that the goal is Stretch, not unstable, so you need to fix/help 
> in fixing the dependencies if you want
> your package to be buildable/installable on Stretch too.

Well one more bad news...

> the maintainer already did some work there
> https://github.com/scikit-image/scikit-image/issues/2091#issuecomment-220156849
> 
> so you think you can help him?
> (I could, if you ask me)

I'm not familiar with that package, and I think if I'm going
to help caffe's recursive dependency package maintainers,
I intend to first have a look at opencv or protobuf.

Stretch freeze is Q1 2017, I'm afraid whether caffe can
be uploaded into stretch in time.

* python3-opencv upload
* python3-protobuf upload
* python3-skimage NON-DFSG bugs

> Gianfranco

Thank you.

Bug#823478: python3-protobuf3

[Mattia Rizzolo]

On Thu, May 19, 2016 at 02:52:27PM +1000, Jonathon Love wrote:
> 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

this "developer is MIA" should be a good reason by itself.  It's never
great to introduce in the archive a software where the development
stopped.

> (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).

Agree.
Also, introducing both would mean having in the archive 2 things that do
the exact same thing.

> hence, i propose to withdraw the package, the RFS and the ITP.

This seems the better solution, yes.

> also happy to
> proceed, the work is basically done, but i can't see a way to make it work.

For all the reason you exponed, I think the best way is to withdraw the
package.

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

Re: Binaries under "/usr/lib/"

[Tiago Ilieve]

Giulio,

On 18 May 2016 at 07:15, Giulio Paci  wrote:
> One approach that usually fits my needs is the one proposed by Thibaut 
> Paumard [1], that I am reproposing here with minimal changes:

Thanks for sharing this pretty detailed case. As my issue with
"pythonpy" was way more simpler, I ended up updating the new path in
its bash-completion file[2] (and cleaning it, removing unneeded
entries).

Of course your suggestions are useful for more complex packages and
your contribution here will not be in vain.

Regards,
Tiago.

[1]: https://lists.debian.org/debian-mentors/2012/04/msg00012.html
[2]: 
https://anonscm.debian.org/git/collab-maint/pythonpy.git/tree/debian/patches/0002-fix-bash-completion.patch?id=fb1165d

-- 
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#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]

[Gianfranco Costamagna]

Hi Lumin,


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


ok
>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-*.


ok

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


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


not sure then, it should be fine that way!

>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

I mean: "protobuf code is declared to be python3 ready"

so I guess it is a matter of adding a package in control file, adding python3 
in rules and some little overrides.
my request was: can you please share that trivial patch at least on the bug 
report?
maybe somebody will pick it up and NMU the package

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


no, this isn't a blocker, but keep in mind that our goal is stretch, and 
python2 code doesn't fit too much in it.
I guess in case the dependencies will become python3 ready, you will add a new 
python3-caffe-cpu package, right?


can two python packages be produced by caffe or just one at each time?
in the latter case you will need to drop python-caffe-cpu, add 
python3-caffe-cpu and breaks+replaces to ensure an
upgrade path from the python2 to the python3 version.

For sure if having the python3 dependencies in place is a matter of some days, 
we should consider that, but
no, this isn't a blocker right now.
(I'm more worried about the whole breakage that comes at gcc and cuda updates, 
will you be able to keep the package
"installable and buildable" in unstable at each transition?)
>It seems that skimage is not a blocker of Caffe.


it is, the package is not in testing, so I guess caffe won't be able to migrate.
Don't forget that the goal is Stretch, not unstable, so you need to fix/help in 
fixing the dependencies if you want
your package to be buildable/installable on Stretch too.

the maintainer already did some work there
https://github.com/scikit-image/scikit-image/issues/2091#issuecomment-220156849

so you think you can help him?
(I could, if you ask me)

Gianfranco