Bug#907192: pre-RFS: tensorflow/1.10.0+dfsg-A1 [ITP] -- debian archve += 1 million lines of code

[Lumin]

Some updates about this pre-RFS:

Summary:
1. The README.Debian file is totally invalidated. Please don't review the
repo.
2. I switched to use python plus ninja for building Debian's TF, which
 may have a chance to evolve into the final solution.

On Fri, Aug 24, 2018 at 22:58 Lumin  wrote:

>
>  2. any help will be appreciated, especially for CMake.
>

Well, currently the packaging repo is totally a mess since there are 4
sets of build systems. Don't review the repo before I remove three of them,
because no one except for myself can understand what's happening there.

Bazel, the native build system for TF, is impossible to enter Debian
release.

Initially I forked upstream's contributed cmake build because cmake
can build a complete libtensorflow.so and pywrap_tensorflow_internal.
However this set of makefile is too much complicated to read and maintain.

For simplicity I forked upstream's contributed makefile build. It only
compile a core set of functionality. However, it's not able to build python
wrapper. To extend the makefile build I wrote another set of makefile
from scratch, imitating the original makefile build. Finally I find it
obsecure to understand what happend when something goes wrong.

Eventually I started to write yet another build system with python
plus ninja-build with the experience obtained from the previous attempts.
I think there won't be the fifth build system since python plus ninja
just works like what I want.

As a result, the whole todo list written in debian directory was
invalidated by
such frequent change in build system. Please don't review any file in the
packaging repo.

The python plus ninja build system can produce libtensorflow_framework.so
now.


> Details
> ---
>
> This not a real RFS, but sort of weak request for review/help.
> I'm not proficient in CMake so I'm not sure whether I'm doing
> the correct choice all the time. Anyway, The good news is that
> I'm already able to build libtensorflow.so for Debian experimental,
> on both amd64 and ppc64el architectures.
>
> At the time of writing, debomatic-amd64 has nearly finished the build
> but failed (maybe not enough memory):
>
> http://debomatic-amd64.debian.net/distribution#experimental/tensorflow/1.10.0+dfsg-A1/buildlog
> Note, this buildlog is as big as 107MB.
>
>
> Here is a list of remaining TODOs for stage A:
> ---
> (The list is copied from README.Debian at
>  https://salsa.debian.org/science-team/tensorflow ,
>  please lookup README.Debian for the full version)
>
>
> - [x] prevent the build system from downloading anything.
> - [x] deal with all the C/C++ lib dependencies.
> - [x] produce libtensorflow.so.1.10 and install it into .deb package.
> - [x] ambiguous FFT2D license.
>
> - [ ] build tests files (googletest) and run the tests.
> - [ ] make sure nothing from contrib is built. they are not officially
> supported.
> - [ ] remove useless parts from cmake build.
> - [ ] misc improvements to cmake build. (at least make it easier to read)
> - [ ] is the resulting libtensorflow.so.1.10 correct and working?
>   - [ ] write autopkgtest with some mini C/C++ programs.
>   - [ ] working on amd64?
>   - [ ] working on ppc64el?
> - [ ] make sure libtensorflow/amd64 is linked against libmkldnn
> - [ ] sort out this confusing lintian E
>   source-is-missing tensorflow/compiler/aot/codegen_test_o.golden
> - [ ] remaining lintian warnings and errors.
> - [ ] traverse the 16000+ files in the source tree and complete
> d/copyright.
>   umm.
> - [ ] Can't the blob be even smaller?
>   -rwxr-xr-x 1 debian debian 3.6G Aug 24 13:53 libtensorflow.so.1.10.0
> (unstripped)
>   -rwxr-xr-x 1 debian debian 104M Aug 24 14:00 libtensorflow.so.1.10.0
> (stripped)
> - [ ] 16GB RAM + 16GB swap is not enough to avoid triggering OOM killer?
> - [ ] get rid of static linking written for stupid windows
>   /usr/bin/ld: error: benchmark_model(.debug_info) is too large
> (0x35a9f359 bytes)
>   /usr/bin/ld: error: benchmark_model(.debug_str) is too large
> (0x6a545d15 bytes)
>   /usr/bin/ld: error: benchmark_model(.debug_loc) is too large
> (0x1f5b1950 bytes)
>   make[3]: Leaving directory
> '/<>/tensorflow-1.10.0+dfsg/obj-x86_64-linux-gnu'
>   [ 98%] Built target benchmark_model
>   /usr/bin/ld: error: compare_graphs(.debug_info) is too large
> (0x366f36be bytes)
>   /usr/bin/ld: error: compare_graphs(.debug_str) is too large
> (0x6a64010e bytes)
>   /usr/bin/ld: error: compare_graphs(.debug_loc) is too large
> (0x1fd19fe0 bytes)
> - [ ] how to prevent "make install" from building everything again?
>
> - [ ] upload to experimental.
>
>
> 

Bug#907192: pre-RFS: tensorflow/1.10.0+dfsg-A1 [ITP] -- debian archve += 1 million lines of code

[Lumin]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-scie...@lists.debian.org
Control: tags -1 +moreinfo
Control: blocks -1 by 906646 894411
Control: blocks 804612 by -1

Hi Mentors and d-Science Team,

**Many thanks** to Aron Xu for his sponsorship with a 512GB-RAM builder.
Without this machine I'll never be able to reach this step, so that
postpone this ITP forever.

key points of this mail in case if you don't want to read the whole mail


 1. able to produce libtensorflow.so now, in a Policy-friendly manner.
 2. any help will be appreciated, especially for CMake.


Details
---

This not a real RFS, but sort of weak request for review/help.
I'm not proficient in CMake so I'm not sure whether I'm doing
the correct choice all the time. Anyway, The good news is that
I'm already able to build libtensorflow.so for Debian experimental,
on both amd64 and ppc64el architectures.

At the time of writing, debomatic-amd64 has nearly finished the build
but failed (maybe not enough memory):
http://debomatic-amd64.debian.net/distribution#experimental/tensorflow/1.10.0+dfsg-A1/buildlog
Note, this buildlog is as big as 107MB.


Here is a list of remaining TODOs for stage A:
---
(The list is copied from README.Debian at
 https://salsa.debian.org/science-team/tensorflow ,
 please lookup README.Debian for the full version)


- [x] prevent the build system from downloading anything.
- [x] deal with all the C/C++ lib dependencies.
- [x] produce libtensorflow.so.1.10 and install it into .deb package.
- [x] ambiguous FFT2D license.

- [ ] build tests files (googletest) and run the tests.
- [ ] make sure nothing from contrib is built. they are not officially 
supported.
- [ ] remove useless parts from cmake build.
- [ ] misc improvements to cmake build. (at least make it easier to read)
- [ ] is the resulting libtensorflow.so.1.10 correct and working?
  - [ ] write autopkgtest with some mini C/C++ programs.
  - [ ] working on amd64?
  - [ ] working on ppc64el?
- [ ] make sure libtensorflow/amd64 is linked against libmkldnn
- [ ] sort out this confusing lintian E
  source-is-missing tensorflow/compiler/aot/codegen_test_o.golden
- [ ] remaining lintian warnings and errors.
- [ ] traverse the 16000+ files in the source tree and complete d/copyright.
  umm.
- [ ] Can't the blob be even smaller?
  -rwxr-xr-x 1 debian debian 3.6G Aug 24 13:53 libtensorflow.so.1.10.0 
(unstripped)
  -rwxr-xr-x 1 debian debian 104M Aug 24 14:00 libtensorflow.so.1.10.0 
(stripped)
- [ ] 16GB RAM + 16GB swap is not enough to avoid triggering OOM killer?
- [ ] get rid of static linking written for stupid windows
  /usr/bin/ld: error: benchmark_model(.debug_info) is too large (0x35a9f359 
bytes)
  /usr/bin/ld: error: benchmark_model(.debug_str) is too large (0x6a545d15 
bytes)
  /usr/bin/ld: error: benchmark_model(.debug_loc) is too large (0x1f5b1950 
bytes)
  make[3]: Leaving directory 
'/<>/tensorflow-1.10.0+dfsg/obj-x86_64-linux-gnu'
  [ 98%] Built target benchmark_model
  /usr/bin/ld: error: compare_graphs(.debug_info) is too large (0x366f36be 
bytes)
  /usr/bin/ld: error: compare_graphs(.debug_str) is too large (0x6a64010e 
bytes)
  /usr/bin/ld: error: compare_graphs(.debug_loc) is too large (0x1fd19fe0 
bytes)
- [ ] how to prevent "make install" from building everything again?

- [ ] upload to experimental.


---
Changes:

tensorflow (1.10.0+dfsg-A1) UNRELEASED; urgency=medium

  * Initial release. (Closes: #804612)
  * Stage A (with Debian revision "A*") indicates that the source
package only produce C and C++ library and development files.

Bug#906646: Acknowledgement (RFS: double-conversion/3.0.0+git20180802.4e8b3b5-1 [ITA, tensorflow deps])

[Lumin]

Hi mentors,

I've tested building all double-conversion's reverse dependencies including
libqt5core5a in unstable, none of them was broken.

Test platform is ppc64el instead of amd64.

Bug#907021: RFS: sleef/3.3.1-1

[Lumin]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: sleef
   Version : 3.3.1-1
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : math

  It builds those binary packages:

libsleef-dev - SLEEF Vectorized Math Library (development)
 libsleef3  - SLEEF Vectorized Math Library (libraries)

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/s/sleef/sleef_3.3.1-1.dsc

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

  https://launchpad.net/~lumin0/+archive/ubuntu/ppa/+packages

Builds
[FULLYBUILT] amd64
[BUILDING] arm64
[FULLYBUILT] armhf
[FULLYBUILT] i386
[FULLYBUILT] ppc64el
[FULLYBUILT] s390x

  Changes since the last upload:

sleef (3.3.1-1) experimental; urgency=medium

  * New upstream version 3.3.1
  * Add symbols lists for: arm64, armhf, ppc64el, s390x, mips, mips64el,
mipsel, alpha, hppa, ia64, powerpc, ppc64, powerpcspe, riscv64, sh4,
and sparc64. Symbol lists are deduplicated with symlinks.

Bug#907018: RFS: hepmc/2.06.09-3 [RC]

[Lumin]

Package: sponsorship-requests
Severity: important
X-Debbugs-CC: debian-scie...@lists.debian.org

  Dear mentors,

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

 * Package name: hepmc
   Version : 2.06.09-3
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : science

  It builds those binary packages:

hepmc-examples - Event Record for Monte Carlo Generators - example files
 hepmc-reference-manual - Event Record for Monte Carlo Generators - reference 
manual
 hepmc-user-manual - Event Record for Monte Carlo Generators - user manual
 libhepmc-dev - Event Record for Monte Carlo Generators - development files
 libhepmc4  - Event Record for Monte Carlo Generators
 libhepmcfio-dev - Monte Carlo event record FIO library - development files
 libhepmcfio4 - Monte Carlo event record FIO library

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/h/hepmc/hepmc_2.06.09-3.dsc

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

https://launchpad.net/~lumin0/+archive/ubuntu/ppa/+packages
  Builds
[FULLYBUILT] amd64
[FULLYBUILT] arm64
[FULLYBUILT] armhf
[FULLYBUILT] i386
[FULLYBUILT] ppc64el
[FULLYBUILT] s390x


  Changes since the last upload:

hepmc (2.06.09-3) unstable; urgency=medium

  * Team Upload.
  * Cherry-pick from upstream-git: enlarge tolerance of floating point error.
Thanks to Adrian Bunk. (Closes: #906708) (https://gcc.gnu.org/PR87036)
  * Update Homepage to http://hepmc.web.cern.ch/hepmc/ (Closes: #906709)
  * Update package descriptions. (Closes: #688671)
  * Bump Standards-Version to 4.2.0 .

Bug#907012: RFS: highwayhash/0~20180209-g14dedec-6

[Lumin]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: highwayhash
   Version : 0~20180209-g14dedec-6
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : science

  It builds those binary packages:

libhighwayhash-dev - Fast strong hash functions: SipHash/HighwayHash 
(development)
 libhighwayhash0 - Fast strong hash functions: SipHash/HighwayHash (library)

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/h/highwayhash/highwayhash_0~20180209-g14dedec-6.dsc

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

  
http://debomatic-amd64.debian.net/distribution#unstable/highwayhash/0~20180209-g14dedec-6/buildlog

  Changes since the last upload:

highwayhash (0~20180209-g14dedec-6) unstable; urgency=medium

  * Collect symbols update from buildd. (Closes: #897767)
+ Update symbols for arm64, ppc64el, x32 .
  * Bump Standards-Version to 4.2.0 (no change).

Bug#895729: RFS: mkl-dnn/0.15+git20180803.3f58c1 [ITP] -- tensorflow dependency (amd64 specific)

[Lumin]

control: tag -1 -moreinfo

Hi Adam,

Intel has fixed the AMD CPU test failure.
https://github.com/intel/mkl-dnn/issues/291

Let's upload the latest snapshot to experimental?
https://mentors.debian.net/debian/pool/main/m/mkl-dnn/mkl-dnn_0.16+git20180820.f51304a-1.dsc

PPA: https://launchpad.net/~lumin0/+archive/ubuntu/ppa/+packages
Dom: 
http://debomatic-amd64.debian.net/distribution#experimental/mkl-dnn/0.16+git20180820.f51304a-1/buildlog
Salsa: https://salsa.debian.org/science-team/mkl-dnn

Thanks!

On Thu, Aug 09, 2018 at 08:01:10PM +0200, Adam Borowski wrote:
> On Thu, Aug 09, 2018 at 10:16:17AM +0000, Lumin wrote:
> >  * Package name: mkl-dnn
> >Version : 0.15+git20180803.3f58c16-1
> >Upstream Author : intel
> 
> Alas, the build flags use -march=native -mtune=native which is a big no-no.
> The first makes the package crash on any processor lacking an extension that
> was present on the build machine and was used by the compiler; unless some
> kind of runtime detection is used, packages are allowed only the baseline
> ISA for the architecture.  As for -mtune=native, it makes the package build
> unreproducibly, differing based on where it was compiled.
 
Fixed in the updated package.

> The second problem is that in the testsuite, test_convolution_format_any
> fails (0/5 sub-tests).  This might be related to my machine being:
> vendor_id : AuthenticAMD
> model name: AMD Phenom(tm) II X6 1055T Processor
> 
> Log of the FTBFS attached.
 
Fixed by Intel.

> 
> Meow!
> -- 
> ⢀⣴⠾⠻⢶⣦⠀ So a Hungarian gypsy mountainman, lumberjack by day job,
> ⣾⠁⢰⠒⠀⣿⡁ brigand by, uhm, hobby, invented a dish: goulash on potato
> ⢿⡄⠘⠷⠚⠋⠀ pancakes.  Then the Polish couldn't decide which of his
> ⠈⠳⣄ adjectives to use for the dish's name.

Bug#906646: RFS: double-conversion/3.0.0+git20180802.4e8b3b5-1 [ITA, tensorflow deps]

[Lumin]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "double-conversion"

 * Package name: double-conversion
   Version : 3.0.0+git20180802.4e8b3b5-1
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : libs

  It builds those binary packages:

libdouble-conversion-dev - routines to convert IEEE floats to and from 
strings (development
libdouble-conversion1 - routines to convert IEEE floats to and from strings

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

  https://mentors.debian.net/package/double-conversion

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

dget -x 
https://mentors.debian.net/debian/pool/main/d/double-conversion/double-conversion_3.0.0+git20180802.4e8b3b5-1.dsc

  More information about hello can be obtained from

  1. salsa git repo [branch: lumin/3.0.0 instead of master]
 https://salsa.debian.org/science-team/double-conversion

  2. dom-amd64 build for sid/experimental
 
http://debomatic-amd64.debian.net/distribution#unstable/double-conversion/3.0.0-1/buildlog
 autopkgtest is broken due to some debomatic reason.

  3. dom-amd64 build + autopkgtest for ubuntu cosmic
 
http://debomatic-amd64.debian.net/distribution#cosmic/double-conversion/3.0.0+git20180802.4e8b3b5-1u1/buildlog

  4. ubuntu PPA cosmic build
 https://launchpad.net/~lumin0/+archive/ubuntu/ppa/+packages
 amd64, arm64, armhf, i386, ppc64el, s390x [all OK]


double-conversion is a Tensorflow dependency. I'm uploading
a snapshot to archive instead of the latest release 3.0.0 because
libtensorflow.so FTBFS with the stable release.

Note, it appears that this package doesn't need a transition slot
since there is no ABI change. (however upstream changed SOVERSION
due to nonsence). This package should go into experimental first,
and enter unstable only if I have finished the reverse dependency
check. Afterall this package has a high popcon.

Changes since the last upload:

double-conversion (3.0.0+git20180802.4e8b3b5-1) experimental; urgency=medium

  * [O/ITA] Add myself to Uploaders. (Closes: #815264)
  * New upstream version snapshot 3.0.0+git20180802.4e8b3b5
+ Note, the SOVERSION has been bumped to 3.0.0 in upstream's cmake
  build. However it was bumped only because they had changed the
  source directory layout, and ABI has not been changed. Hence, in
  debian/rules SOVERSION is left unchanged because bumping it doesn't
  make sense for Debian and would trigger an unnecessary rebuild
  of the reverse dependency tree.
  * Update Patches.
+ Refresh fix_m68k.patch .
- Remove fix_riscv64.patch , fixed upstream.
  * Modify source paths in rules , *.install and debian/*.docs ,
following upstream's directory layout change.
  * Append hardening flags to rules.
  * Upgrade watch file to uscan version 4.
  * Homepage: Upstream project transferred to google.
  * Add autopkgtest control file to build and run upstream tests.
  * Bump Standards-Version to 4.2.0 (no change).
  * Add -I. to CPPFLAGS in order to avoid build failure in clean chroot.

Bug#906425: RFS: sleef/3.3-1 [ITP] -- vectorized math library, pytorch deps.

[Lumin]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

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

 * Package name: sleef
   Version : 3.3-1
   Upstream Author : Naoki Shibata
 * URL : sleef.org
 * License : Boost Software License 1.0
   Section : math

  It builds those binary packages:

libsleef-dev - SLEEF Vectorized Math Library (development)
libsleef3  - SLEEF Vectorized Math Library (libraries)

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

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

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

dget -x https://mentors.debian.net/debian/pool/main/s/sleef/sleef_3.3-1.dsc

  More information about hello can be obtained from 

  1. git repo: https://salsa.debian.org/lumin-guest/sleef
  2. dom-amd64 test: 
http://debomatic-amd64.debian.net/distribution#experimental/sleef/3.3-1/buildlog

  Changes since the last upload:

sleef (3.3-1) experimental; urgency=medium

  * Initial release. (Closes: #906248)

Bug#906206: RFS: chafa/0.9.0+git20180731.5ddfe4c-3 [RC]

[Lumin]

Package: sponsorship-requests
Severity: important

  Dear mentors,

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

 * Package name: chafa
   Version : 0.9.0+git20180731.5ddfe4c-3
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : graphics

  It builds those binary packages:

chafa - Image-to-text converter supporting a wide range of symbols, etc.
libchafa-dev - development files for image-to-text converter chafa
libchafa0  - library for image-to-text converter chafa

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

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/c/chafa/chafa_0.9.0+git20180731.5ddfe4c-3.dsc

  More information about hello can be obtained from 

http://debomatic-amd64.debian.net/distribution#unstable/chafa/0.9.0+git20180731.5ddfe4c-3/buildlog

changes:

chafa (0.9.0+git20180731.5ddfe4c-3) unstable; urgency=medium

  * Package libchafa-dev should Depend on libchafa0 . (Closes: #906190)
  * Cherry-pick patch from upstream-git: Make chafa --version return 0.
(+ patches/0001-chafa-Return-TRUE-0-after-print_version.patch)
  * Update autopkgtest control file to avoid test failure.

RFS: hepmc -- [RC] on behalf of multiarch-support removal

[Lumin]

Hi,

Can anybody sponsor my team upload for "hepmc"? Thanks.

https://salsa.debian.org/science-team/hepmc
 - commit: cb8aa811bb7e8b5be46107ca9992a5ad58df73cb
 - upload: unstable

changes:

hepmc (2.06.09-2) unstable; urgency=medium

  * Team Upload.
  * Replace B-D-I:texlive-math-extra with texlive,texlive-science.
The original one no longer exists in archive. (Closes: #867090)
  * Upgrade from Debhelper compat level 7 to level 11.
  * Overhaul debian/rules in debhelper 11 style.
  * Patch src/IO_AsciiParticles.cc to amend floating point format.
The FTBFS is due to floatpoint printing format mismatch during test,
triggered by GCC-5's change. (+ gcc-5plus.patch) (Closes: #777901)
  * Deprecate DM-Upload-Allowed field.
  * Strip useless build-dependencies.
  * Annotate Upstream-Git URI in control.
  * Point Vcs-* fields to Salsa due to Alioth deprecation.

Bug#905970: RFS: chafa/0.9.0+git20180731.5ddfe4c-2

[Lumin]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: chafa
   Version : 0.9.0+git20180731.5ddfe4c-2
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : graphics

  It builds those binary packages:

chafa - Image-to-text converter supporting a wide range of symbols, etc.
 libchafa-dev - development files for image-to-text converter chafa
 libchafa0  - library for image-to-text converter chafa

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/c/chafa/chafa_0.9.0+git20180731.5ddfe4c-2.dsc

  More information about hello can be obtained from 

dom-amd64 and dom-i386 is malfunctional currently. However I've
tested the i386 build in a i386 chroot.

  Changes since the last upload:

chafa (0.9.0+git20180731.5ddfe4c-2) unstable; urgency=medium

  * Port Chafa to *-i386 architectures. (+ port-i386.patch)
  * Add -DCHAFA_REG_BIT32 to CFLAGS when building on *-i386 .

Bug#905884: closed by Adam Borowski (Re: Bug#905884: RFS: chafa/0.9.0+git20180731.5ddfe4c-1 [ITP])

[Lumin]

On Sat, Aug 11, 2018 at 11:00:03AM +, Debian Bug Tracking System wrote:
> On Sat, Aug 11, 2018 at 06:26:46AM +0000, Lumin wrote:
> > 
> >  * Package name: chafa
> >Version : 0.9.0+git20180731.5ddfe4c-1
> >  * URL : https://hpjansson.org/chafa/
> >  * License : LGPL-3
> 
> >   It builds those binary packages:
> > 
> > chafa - Image-to-text converter supporting a wide range of symbols, etc.
> > libchafa-dev - development files for image-to-text converter chafa
> > libchafa0  - library for image-to-text converter chafa
> 
> > chafa (0.9.0+git20180731.5ddfe4c-1) unstable; urgency=low
> > 
> >   * Initial release. (Closes: #905882)
> 
> Awesome!  Chafa was on my TODO list, I just lacked the tuits to package it.
> And I really prefer work to be done by people who are not me.  :)
> 
> It's drastically better than catimg for Unicode images, and than caca for
> plain ASCII.

I came across Chafa several hours ago as a catimg user, and I was
surprised by this brilliant tool. Chafa provides much better
functionality compared to CACA and catimg, and supports many
image formats.

> In NEW.

Thanks!

Bug#905884: RFS: chafa/0.9.0+git20180731.5ddfe4c-1 [ITP]

[Lumin]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

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

 * Package name: chafa
   Version : 0.9.0+git20180731.5ddfe4c-1
   Upstream Author : Hans Petter Jansson
 * URL : https://hpjansson.org/chafa/
 * License : LGPL-3
   Section : graphics

  It builds those binary packages:

chafa - Image-to-text converter supporting a wide range of symbols, etc.
libchafa-dev - development files for image-to-text converter chafa
libchafa0  - library for image-to-text converter chafa

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

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/c/chafa/chafa_0.9.0+git20180731.5ddfe4c-1.dsc

  More information about hello can be obtained from 

  
http://debomatic-amd64.debian.net/distribution#unstable/chafa/0.9.0+git20180731.5ddfe4c-1/buildlog

chafa (0.9.0+git20180731.5ddfe4c-1) unstable; urgency=low

  * Initial release. (Closes: #905882)

Nonlinear git-buildpackage workflow?

[Lumin]

Hi mentors,

I'm one of the julia package maintainers and I encountered a temporary
non-linear workflow problem.

Julia released two stable releases in parallel, 0.7 and 1.0 .
I uploaded 0.7 to unstable and planned to upload 1.0 to exp.
After a round of bug fix in the future the 1.0 release should
eventually replace the 0.7 release in sid.

The problem is, if I maintain the two releases in parallel, the
dch would become a mess when moving the 1.0 release to sid.
dch will contain duplicated changelog entries (e.g. fixing
common problems found in both 0.7 and 1.0) and the timeline
is also screwed up.

Unlike the parallel maintenance between sid and stable.
I'm not aware of any workflow suitable for this temporary situation.

Umm... Maybe the best solution is to fix the remaining
problems in 0.7 first, then prepare for the 1.0 upload (serial).
@ginggs Opinion?
-- 
Best,

Bug#895729: RFS: mkl-dnn/0.15+git20180803.3f58c1 [ITP] -- tensorflow dependency (amd64 specific)

[Lumin]

control: tag -1 +moreinfo

On Thu, Aug 09, 2018 at 08:01:10PM +0200, Adam Borowski wrote:
> On Thu, Aug 09, 2018 at 10:16:17AM +0000, Lumin wrote:
> >  * Package name: mkl-dnn
> >Version : 0.15+git20180803.3f58c16-1
> >Upstream Author : intel
> 
> Alas, the build flags use -march=native -mtune=native which is a big no-no.
> The first makes the package crash on any processor lacking an extension that
> was present on the build machine and was used by the compiler; unless some
> kind of runtime detection is used, packages are allowed only the baseline
> ISA for the architecture.  As for -mtune=native, it makes the package build
> unreproducibly, differing based on where it was compiled.

My bad, I overlooked the two flags. The cmake files have been patched
in master branch of packaging repo.

https://salsa.debian.org/science-team/mkl-dnn/commit/6e0a9bea677d398ee23ac9c2f84c3551d100a6d4
http://debomatic-amd64.debian.net/distribution#unstable/mkl-dnn/0.15+git20180803.3f58c16-1/buildlog
 
> The second problem is that in the testsuite, test_convolution_format_any
> fails (0/5 sub-tests).  This might be related to my machine being:
> vendor_id : AuthenticAMD
> model name: AMD Phenom(tm) II X6 1055T Processor

Well, I have been waiting for intel to fix test failures for a long
time. Finally the snapshot 0.15+git20180803.3f58c16 doesn't fail
any test on dom-amd64 (E5 2699v?) and my I5-7440HQ, but now it failed
on AMD cpu ...

> Log of the FTBFS attached.

Thanks for the log, I've forwarded it to upstream.
https://github.com/intel/mkl-dnn/issues/291

I shouldn't let any test failure from mkl-dnn pass, so we have to wait
for upstream to fix the problem. Fortunately, TensorFlow can be compiled
with or without mkl-dnn. It doesn't matter if the initial upload of
TensorFlow is not linked against mkl-dnn. The difference that mkl-dnn
would bring to TensorFlow is computation speed-up.

Bug#895729: RFS: mkl-dnn/0.15+git20180803.3f58c1 [ITP] -- tensorflow dependency (amd64 specific)

[Lumin]

Package: sponsorship-requests
Severity: wishlist

Disclaimer:

  Intel made some confusing naming. I should point out that mkl-dnn is
  a free software, which can be independently compiled and used without
  any component from intel-mkl . Without linking against intel-mkl, we
  would get a suboptimal performance, but intel claimed that they are
  trying to reduce the performance gap.

  1. [Apache-2.0] mkl-dnn: Intel Math Kernel Library - Deep Neural Network

  2. [non-free] intel-mkl: Intel Math Kernel Library
 intel-mkl contains another set of dnn api (mkl_dnn.h) but let's ignore it.

Dear mentors,

  I am looking for a sponsor for my package "mkl-dnn"

 * Package name: mkl-dnn
   Version : 0.15+git20180803.3f58c16-1
   Upstream Author : intel
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : science

  It builds those binary packages:

libmkldnn-dev - Math Kernel Library for Deep Neural Networks (dev)
libmkldnn-doc - Math Kernel Library for Deep Neural Networks (doc)
libmkldnn0 - Math Kernel Library for Deep Neural Networks (lib)

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

  https://mentors.debian.net/package/mkl-dnn


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

dget -x 
https://mentors.debian.net/debian/pool/main/m/mkl-dnn/mkl-dnn_0.15+git20180803.3f58c16-1.dsc

  More information about hello can be obtained from 

  
http://debomatic-amd64.debian.net/distribution#unstable/mkl-dnn/0.15+git20180803.3f58c16-1/buildlog

  Changes since the last upload:

mkl-dnn (0.15+git20180803.3f58c16-1) unstable; urgency=low

  * Initial release. (Closes: #894411)

Bug#905612: RFS: nsync/1.20.1-2

[Lumin]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: nsync
   Version : 1.20.1-2
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : science

  It builds those binary packages:

libnsync-cpp1 - C library that exports various synchronization primitives 
(C++ li
libnsync-dev - C library that exports various synchronization primitives 
(dev)
libnsync1  - C library that exports various synchronization primitives (C 
lib)

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

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/n/nsync/nsync_1.20.1-2.dsc

  More information about hello can be obtained from 

  
http://debomatic-amd64.debian.net/distribution#unstable/nsync/1.20.1-2/buildlog
  http://debomatic-i386.debian.net/distribution#unstable/nsync/1.20.1-2/buildlog

  Changes since the last upload:

nsync (1.20.1-2) UNRELEASED; urgency=medium

  * Add LDFLAG -Wl,--as-needed to strip unneeded shlibs depends.
  * Collect symbols patch from buildd.

Bug#905582: RFS: nsync/1.20.1-1 [ITP] -- tensorflow dependency

[Lumin]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-scie...@lists.debian.org

  Dear mentors,

  I am looking for a sponsor for my package "nsync", which is a
  tensorflow dependency.

 * Package name: nsync
   Version : 1.20.1-1
   Upstream Author : google
 * URL : [fill in URL of upstreams web site]
 * License : Apache-2
   Section : science

  It builds those binary packages:

libnsync-cpp1 - C library that exports various synchronization primitives 
(C++ li
libnsync-dev - C library that exports various synchronization primitives 
(dev)
libnsync1  - C library that exports various synchronization primitives (C 
lib)

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

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/n/nsync/nsync_1.20.1-1.dsc

  More information about hello can be obtained fro

  
http://debomatic-amd64.debian.net/distribution#unstable/nsync/1.20.1-1/buildlog

  Changes since the last upload:

nsync (1.20.1-1) unstable; urgency=low

  * Initial release. (Closes: #904440)

Bug#905053: RFS: trojan/1.5.1-1 [ITP]

[Lumin]

Hi GreaterFire,

Thank you for the package. I'm not sponsoring this package but I have
some comments about it. You can feel free to omit the comments tagged
"recommended".

1. Why is dh_auto_test noopped?

   The following tests FAILED:
   1 - LinuxSmokeTest-basic (Failed)

   As the software upstream, you should try to fix the bug instead of
   ignoring it.

2. [Recommended] It would be better if there are Vcs-Browser and Vcs-Git
   fields in the control file.

3. [Recommended] testsuite-autopkgtest-missing. A set of sensible test
   scripts would speed up its migration into testing.
   http://packaging.ubuntu.com/html/auto-pkg-test.html

4. package-does-not-install-examples .

   There are several example files under the source tree. Please install
   them so that the user can find them after installation.

   1. create a file debian/examples
   2. put this line in the file
   ```
   examples/*
   ```

Well, the copyright file looks good to me. Please fix the issues
mentioned above, and do lintian check if you think it's ready for the
next round of review.

```
lintian -EviI --pedantic xxx.changes
```

Feel free to ask if you encounter problem.

Bug#904229: RFS: highwayhash/0~20180209-g14dedec-5 [RC]

[Lumin]

Package: sponsorship-requests
Severity: important

  Dear mentors,

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

 * Package name: highwayhash
   Version : 0~20180209-g14dedec-5
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : science

  It builds those binary packages:

libhighwayhash-dev - Fast strong hash functions: SipHash/HighwayHash 
(development)
libhighwayhash0 - Fast strong hash functions: SipHash/HighwayHash (library)

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

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/h/highwayhash/highwayhash_0~20180209-g14dedec-5.dsc

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


http://debomatic-amd64.debian.net/distribution#unstable/highwayhash/0~20180209-g14dedec-5/autopkgtest

  Changes since the last upload:


highwayhash (0~20180209-g14dedec-5) unstable; urgency=medium

  * Refresh symbols to avoid FTBFS with GCC-8 (Closes: #897767)
  * Bump Standards-Version to 4.1.5 (no change).

Bug#902412: RFS: sodalite/0.14.2-1 [ITP]

[Lumin]

Hi Heiko Nickerl,

> I am looking for a sponsor for my package "sodalite".

Thank you for this package. I'm not sponsoring this package, but
I have some comments:

1. debian/copyright: OK

2. postinst:

   Printing something unecessary to screen during postinst looks unusual.
   I believe the messages would be better to appear in Description.

   See: Policy Section 3.9
   https://www.debian.org/doc/debian-policy/#maintainer-scripts
   "The package installation scripts should avoid producing output which
   is unnecessary for the user to see and should rely on dpkg to stave
   off boredom on the part of a user installing many packages."

Others may be good.

Bug#901958: RFS: lsmount/0.2.2-1 [ITP] -- output /proc/mounts formatted

[Lumin]

Hi Andreas Schwarz,

> I am looking for a sponsor for my package "lsmount"

Thank you for this package. I'm not sponsoring it but here are some
comments:

1. debian/copyright: OK

2. debian/rules: MINOR

   The debhelper compat level is set to 11. That means --parallel is
   default. So you don't have to specify it.

   See: debhelper(7), seciton "COMPATIBILITY LEVELS"

The rest files look good to me.

Bug#902577: RFS: highwayhash/0~20180209-g14dedec-4

[Lumin]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: highwayhash
   Version : 0~20180209-g14dedec-4
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : science

  It builds those binary packages:

libhighwayhash-dev - Fast strong hash functions: SipHash/HighwayHash 
(development)
libhighwayhash0 - Fast strong hash functions: SipHash/HighwayHash (library)

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/h/highwayhash/highwayhash_0~20180209-g14dedec-4.dsc

  More information about hello can be obtained from
  

http://debomatic-amd64.debian.net/distribution#unstable/highwayhash/0~20180209-g14dedec-4/buildlog

  Changes since the last upload:

highwayhash (0~20180209-g14dedec-4) unstable; urgency=medium

  * Depending on build-essential to really fix autopkgtest failure.
  * Add watch file to monitor upstream git HEAD.
  * Don't override debian-watch-file-is-missing, already fixed.
  * Bump Standards-Version to 4.1.4 (no change).

Bug#901304: RFS: python-cytoolz/0.9.0.1-1 [ITP, spaCy deps]

[Lumin]

Package: sponsorship-requests
Severity: wishlist
Control: block 882725 by -1

  Dear mentors,

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

 * Package name: python-cytoolz
   Version : 0.9.0.1-1
   Upstream Author : Erik Welch
 * URL : https://github.com/pytoolz/cytoolz
 * License : BSD-3-Clause
   Section : python

  It builds those binary packages:

python3-cytoolz - Toolz in Cython: High performance functional utilities

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/p/python-cytoolz/python-cytoolz_0.9.0.1-1.dsc

  More information about hello can be obtained from

  
http://debomatic-amd64.debian.net/distribution#unstable/python-cytoolz/0.9.0.1-1/buildlog

  Changes since the last upload:

python-cytoolz (0.9.0.1-1) unstable; urgency=low

  * Initial release. (Closes: #882725)

Bug#901235: RFS: python-thinc/6.11.2-1 [ITP, spaCy deps]

[Lumin]

Package: sponsorship-requests
Severity: wishlist
Control: block 901231 by -1

  Dear mentors,

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

 * Package name: python-thinc
   Version : 6.11.2-1
   Upstream Author : github.com/explosion
 * URL : https://github.com/explosion/thinc
 * License : Expat/BSD-3-Clause
   Section : python

  It builds those binary packages:

python3-thinc - Practical Machine Learning for NLP in Python

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/p/python-thinc/python-thinc_6.11.2-1.dsc

thinc is one of the spaCy dependencies:

   [✓]  cython>=0.24,<0.28.0
   [✓]  pathlib
   [✓]  numpy>=1.7
   [*]  cymem>=1.30,<1.32 # ITP/RFS
   [*]  preshed>=1.0.0,<2.0.0 # ITP/RFS
-> [*]  thinc>=6.10.1,<6.11.0
   [*]  murmurhash>=0.28,<0.29# ITP/RFS
   [*]  plac<1.0.0,>=0.9.6# ITP/RFS
   [✓]  ujson>=1.35
   [✓]  dill>=0.2,<0.3
   [✓]  regex==2017.4.5
   [✓]  requests>=2.13.0,<3.0.0
   [✓]  pytest>=3.0.6,<4.0.0
   [✓]  mock>=2.0.0,<3.0.0

  Changes since the last upload:

python-thinc (6.11.2-1) unstable; urgency=low

  * Initial release. (Closes: #901231)

Bug#901204: RFS: python-plac/0.9.6-1 [ITP, spaCy deps]

[Lumin]

Package: sponsorship-requests
Severity: wishlist 

  Dear mentors,

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

  plac is one of spaCy dependencies:

   [✓]  cython>=0.24,<0.28.0
   [✓]  pathlib
   [✓]  numpy>=1.7
   [*]  cymem>=1.30,<1.32 # ITP/RFS
   [*]  preshed>=1.0.0,<2.0.0 # ITP/RFS
   [ ]  thinc>=6.10.1,<6.11.0
   [*]  murmurhash>=0.28,<0.29# ITP/RFS
-> [*]  plac<1.0.0,>=0.9.6
   [✓]  ujson>=1.35
   [✓]  dill>=0.2,<0.3
   [✓]  regex==2017.4.5
   [✓]  requests>=2.13.0,<3.0.0
   [✓]  pytest>=3.0.6,<4.0.0
   [✓]  mock>=2.0.0,<3.0.0


 * Package name: python-plac
   Version : 0.9.6-1
   Upstream Author : Michele Simionato
 * URL : https://github.com/micheles/plac
 * License : BSD-2-Clause
   Section : python

  It builds those binary packages:

python3-plac - Smartest command line arguments parser in the world

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/p/python-plac/python-plac_0.9.6-1.dsc

  More information about hello can be obtained from 

  
http://debomatic-amd64.debian.net/distribution#unstable/python-plac/0.9.6-1/buildlog

  Changes since the last upload:

  python-plac (0.9.6-1) unstable; urgency=low

  * Initial release. (Closes: #901201)

Bug#900978: RFS: python-murmurhash/0.28.0-1 [ITP, spaCy deps]

[Lumin]

Package: sponsorship-requests
Severity: wishlist
Control: blocks 900977 by -1

  Dear mentors,

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

 * Package name: python-murmurhash
   Version : 0.28.0-1
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : python

  It builds those binary packages:

python3-murmurhash - Cython bindings for MurmurHash2

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/p/python-murmurhash/python-murmurhash_0.28.0-1.dsc

  More information about hello can be obtained from

  
http://debomatic-amd64.debian.net/distribution#unstable/python-murmurhash/0.28.0-1/buildlog

murmurhash is one of spaCy dependencies.

   [✓]  cython>=0.24,<0.28.0
   [✓]  pathlib
   [✓]  numpy>=1.7
   [*]  cymem>=1.30,<1.32 # ITP/RFS
   [*]  preshed>=1.0.0,<2.0.0 # ITP/RFS
   [ ]  thinc>=6.10.1,<6.11.0
-> [*]  murmurhash>=0.28,<0.29
   [ ]  plac<1.0.0,>=0.9.6
   [✓]  ujson>=1.35
   [✓]  dill>=0.2,<0.3
   [✓]  regex==2017.4.5
   [✓]  requests>=2.13.0,<3.0.0
   [✓]  pytest>=3.0.6,<4.0.0
   [✓]  mock>=2.0.0,<3.0.0

  Changes since the last upload:

python-murmurhash (0.28.0-1) unstable; urgency=low

* Initial release. (Closes: #900977)

Bug#900948: RFS: python-preshed/1.0.0-1 [ITP, one of spaCy deps]

[Lumin]

Package: sponsorship-requests
Severity: wishlist
Control: block 900945 by -1
Control: block -1 by 900944

  Dear mentors,

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

 * Package name: python-preshed
   Version : 1.0.0-1
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : python

  It builds those binary packages:

python3-preshed - Cython Hash Table for Pre-Hashed Keys

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/p/python-preshed/python-preshed_1.0.0-1.dsc

  More information about hello can be obtained from

  this packages was not uploaded to debomatic because cymem is current
  not available in archive, and preshed depends on cymem.

  preshed is a dependency of spaCy.

   [✓]  cython>=0.24,<0.28.0
   [✓]  pathlib
   [✓]  numpy>=1.7
   [*]  cymem>=1.30,<1.32 # ITP/RFS #900944
-> [*]  preshed>=1.0.0,<2.0.0
   [ ]  thinc>=6.10.1,<6.11.0
   [ ]  murmurhash>=0.28,<0.29
   [ ]  plac<1.0.0,>=0.9.6
   [✓]  ujson>=1.35
   [✓]  dill>=0.2,<0.3
   [✓]  regex==2017.4.5
   [✓]  requests>=2.13.0,<3.0.0
   [✓]  pytest>=3.0.6,<4.0.0
   [✓]  mock>=2.0.0,<3.0.0

  Changes since the last upload:

  python-preshed (1.0.0-1) unstable; urgency=low

  * Initial release. (Closes: #900945)

Bug#900944: RFS: python-cymem/1.31.2-1 [ITP]

[Lumin]

Package: sponsorship-requests
Severity: wishlist
Control: block 900941 by -1

  Dear mentors,

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

 * Package name: python-cymem
   Version : 1.31.2-1
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : python

  It builds those binary packages:

python3-cymem - Cython Memory Helper

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/p/python-cymem/python-cymem_1.31.2-1.dsc

  More information about hello can be obtained fro
  

http://debomatic-amd64.debian.net/distribution#unstable/python-cymem/1.31.2-1/buildlogm

  Changes since the last upload:

python-cymem (1.31.2-1) unstable; urgency=low

  * Initial release. (Closes: #900941)

Bug#900617: RFS: ujson/1.35-3 [ITA]

[Lumin]

On Sat, Jun 02, 2018 at 12:02:17PM -0400, Sandro Tosi wrote:
> > + Move Sandro Tosi  to Uploaders.
> 
> please remove me from uploaders too, thanks!
 
Re-uploaded the package.

https://mentors.debian.net/debian/pool/main/u/ujson/ujson_1.35-3.dsc

changes:

ujson (1.35-3) unstable; urgency=medium

  [ Ondřej Nový ]
  * d/control: Set Vcs-* to salsa.debian.org
  * d/copyright: Use https protocol in Format field
  * d/watch: Use https protocol

  [ Chris Lamb ]
  * debian/copyright: Use HTTPS for Source field.

  [ Mo Zhou ]
  * Package adopted. Update Maintainers and Uploaders. (Closes: #888233)
+ Move Python Team to Maintainers.
- Remove Sandro Tosi , who requested for adoption.
+ Add myself to Uploaders.
  * Sort B-D list and add the missing B-D python-unittest2.
  * BUGS: Annotate a known bug.
  * Bump Standards-Version to 4.1.4 (no change).
  * copyright: Rename BSD to BSD-3-Clause 
(invalid-short-name-in-dep5-copyright).
  * Override obsolete-url-in-packaging. The URL is a note in copyright.
  * rules: Inject hardening flags.

Re: Re: Mysterious autopkgtest tests of ujson package

[Lumin]

> 
> autodep8: /usr/share/autodep8/support/python
> 
> BTW: codesearch.debian.net is a good place to find out this sort of thing.
> 

Ah, here it is. Thanks!

Bug#900626: RFS: gemmlowp/0.0~git20180416.38ebac7-1

[Lumin]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: gemmlowp
   Version : 0.0~git20180416.38ebac7-1
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : science

  It builds those binary packages:

libgemmlowp-dev - small self-contained low-precision GEMM library

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/g/gemmlowp/gemmlowp_0.0~git20180416.38ebac7-1.dsc

  More information about hello can be obtained from

  1. 
http://debomatic-amd64.debian.net/distribution#unstable/gemmlowp/0.0~git20180416.38ebac7-1/buildlog
  2. salsa.debian.org:lumin-guest/gemmlowp.git

  Changes since the last upload:

gemmlowp (0.0~git20180416.38ebac7-1) unstable; urgency=medium

  * New upstream version 0.0~git20180416.38ebac7
  * Add watch file to monitor upstream git HEAD.
  * Bump Standards-Version to 4.1.4 (no change).
  * Move from devel section to libdevel section.
  * Remove unused override debian-watch-file-is-missing.
  * Remove debian/CMakeLists.txt because merged by upstream.
  * patches: Patch the cmake build to avoid failure.
  * Fix doc installation path and remove unused dirs. (Closes: #900474)
  * Upload to unstable.

Mysterious autopkgtest tests of ujson package

[Lumin]

Hello mentors,

I'm adopting the ujson package[1][2]. Currently there is no autopkgtest
control file under the debian directory[3], but ci.d.o, to my surprise,
is running autopkgtest[4] on this package.

As far as I know, tests are defined in debian/tests/control when the
tester is autopkgtest. No test will be run if the tests control file
doesn't exist. That being said, things happend on the ujson package
looks very confusin ... Does anyone know what happend?

One of my wild guesses is that, the ci.d.o infractructure conducts
some basic sanity tests on python packages in which the tests control file
doesn't exist. See the quote from ci.d.o log:

> set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; 
> echo "Testing with $py:" ; $py -c "import ujson; print(ujson)" ; done

Where did that test come from? Thanks.

[1] https://salsa.debian.org/python-team/modules/ujson
[2] http://tracker.debian.org/ujson
[3] https://salsa.debian.org/python-team/modules/ujson/tree/master/debian
[4] https://ci.debian.net/data/autopkgtest/unstable/amd64/u/ujson/365717/log.gz

Bug#900617: RFS: ujson/1.35-3 [ITA]

[Lumin]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: debian-pyt...@lists.debian.org, mo...@debian.org

  Dear mentors,

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

 * Package name: ujson
   Version : 1.35-3
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : python

  It builds those binary packages:

python-ujson - ultra fast JSON encoder and decoder for Python 2
 python-ujson-dbg - ultra fast JSON encoder and decoder for Python 2 (debug ext)
 python3-ujson - ultra fast JSON encoder and decoder for Python 3
 python3-ujson-dbg - ultra fast JSON encoder and decoder for Python 3 (debug 
ext)

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

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


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

dget -x https://mentors.debian.net/debian/pool/main/u/ujson/ujson_1.35-3.dsc

  More information about hello can be obtained from

  1. 
http://debomatic-amd64.debian.net/distribution#unstable/ujson/1.35-3/buildlog
  2. https://salsa.debian.org/python-team/modules/ujson

chnages:

ujson (1.35-3) unstable; urgency=medium

  [ Ondřej Nový ]
  * d/control: Set Vcs-* to salsa.debian.org
  * d/copyright: Use https protocol in Format field
  * d/watch: Use https protocol

  [ Chris Lamb ]
  * debian/copyright: Use HTTPS for Source field.

  [ Mo Zhou ]
  * Package adopted. Update Maintainers and Uploaders. (Closes: #888233)
+ Move Python Team to Maintainers.
+ Move Sandro Tosi  to Uploaders.
+ Add myself to Uploaders.
  * Sort B-D list and add the missing B-D python-unittest2.
  * BUGS: Annotate a known bug.
  * Bump Standards-Version to 4.1.4 (no change).
  * copyright: Rename BSD to BSD-3-Clause 
(invalid-short-name-in-dep5-copyright).
  * Override obsolete-url-in-packaging. The URL is a note in copyright.
  * rules: Inject hardening flags.

 -- Mo Zhou   Sat, 02 Jun 2018 06:30:23 +



signature.asc
Description: PGP signature

Bug#900407: Info received (RFS: odp-dpdk/1.19.0.0-1 [ITP])

[Lumin]

Use this command to generate a some copyright template:

  licensecheck --deb-machine -r .

Bug#900407: RFS: odp-dpdk/1.19.0.0-1 [ITP]

[Lumin]

control: tag -1 +moreinfo
control: owner -1 !

Hi Dmitry,

Thank you for the package. It looks good except for several flaws:

1. error in postrm script, which causes error on removal

  update-alternatives: error: alternative name 
(/usr/lib/x86_64-linux-gnu/libodp-linux.so.119) must not contain '/' and spaces
  dpkg: error processing package libodp-dpdk119:amd64 (--remove):
   installed libodp-dpdk119:amd64 package pre-removal script subprocess 
returned error exit status 2
  Errors were encountered while processing:
   libodp-dpdk119:amd64

2. the alternatives priority of the .so file and .so.119 file should be
   the same.

3. Similar to src:odp, the copyright file of odp-dpdk is not complete:

   grep -ri copyright | grep -vi linaro | grep -i copyright

Apart from that, I have to ask a few questions about this package:

>From README.DPDK
> DPDK only works on a selected range of network cards.

11. Does it support any open-sourced/free network card, which doesn't
require binary blobs? If it does not support open-sourced/free
hardwares, which means non-free drivers are indirectly required
by this package. In this case I'd suggest this package go to
contrib section instead of main.

-Section: libs
+Section: contrib/libs

12. This implementation is specifically optimized for several architectures.
Does that mean this implementation leverages specific instruction sets,
e.g. NEON (arm), AVX (amd64), VSX (ppc)?

Bug#896970: RFS: odp/1.19.0.0-1 [ITP]

[Lumin]

On Sat, Jun 02, 2018 at 03:24:07AM +, Lumin wrote:
> Please fix the aforementioned problems. Hopefully we'll have the last
> round of check next time. Thank you for working on this.
> 
> [1] 
> http://debomatic-amd64.debian.net/distribution#unstable/odp/1.19.0.1-1/buildlog

Forgot to check the copyright ... The copyright looks incomplete. A
simple search on the source tree would reveal many non-Linaro copyright
holders:

  grep -ri copyright | grep -vi linaro | grep -i copyright

The package will be rejected by ftp-master if we don't fix the
copyright.

When checking odp-dpdk, one more problem was found:

  root@b69fed1c16e0 ~/odp-dpdk-1.19.0.0# update-alternatives --config 
libodp-linux.so-x86_64-linux-gnu
  There are 2 choices for the alternative libodp-linux.so-x86_64-linux-gnu 
(providing /usr/lib/x86_64-linux-gnu/libodp-linux.so).
  
SelectionPath   
Priority   Status
  
  * 0/usr/lib/x86_64-linux-gnu/odp-generic/libodp-linux.so   40 
   auto mode
1/usr/lib/x86_64-linux-gnu/odp-dpdk/libodp-linux.so  40 
   manual mode
2/usr/lib/x86_64-linux-gnu/odp-generic/libodp-linux.so   40 
   manual mode


  * 0/usr/lib/x86_64-linux-gnu/odp-dpdk/libodp-linux.so.119  60 
   auto mode
1/usr/lib/x86_64-linux-gnu/odp-dpdk/libodp-linux.so.119  60 
   manual mode
2/usr/lib/x86_64-linux-gnu/odp-generic/libodp-linux.so.119   40 
   manual mode

Taking BLAS as an example, the generic and slow libblas3 provides
libblas.so.3 symlink with a priority of 10. Faster implementations
provides the same symlink with higher priorities, e.g. 40 for openblas.

Maybe you want to adjust the priority values in those postinst scripts?
The exact value is up to you, as long as it helps to tell the difference
among different implementations.

Bug#896970: Info received (Bug#896970: RFS: odp/1.19.0.0-1 [ITP])

[Lumin]

Forgot to check the copyright ... The copyright looks incomplete. A
simple search on the source tree would reveal many non-Linaro copyright
holders:

  grep -ri copyright | grep -vi linaro | grep -i copyright

The package will be rejected by ftp-master if we don't fix the
copyright.

Bug#896970: RFS: odp/1.19.0.0-1 [ITP]

[Lumin]

On Wed, May 30, 2018 at 01:40:48PM +0300, Dmitry Eremin-Solenikov wrote:
> > 1. README.Debian
> >"Library packages should contain libodp-linux.so.FOO"
> >It should be "libodp-linux.so.SOVER", which is more precise.
> 
> Hmm. I have checked buster package lists. Only blas/lapack packages
> use soname as virtual package name in provides. The rest of packages
> use libsomethingSOVER. Wouldn't it be logical to stick to convention
> used by the rest of packages?

I checked the Packages.gz file under the dist directory of the archive.
It seems that the reason why BLAS/LAPACK has taken the virtual package
name "libblas.so.3" is due to ambiguity of libblas3, which could be 
a real package and a virtual package following that convention at the
same time.

Providing libodp-linux119 and libodp-linux-dev looks good to me.
 
> New packages are uploaded to mentors.d.n. Hopefully with this upload
> I will have just two remaining issues:
>  - manpages
>  - dh_auto_test override.

If they are to be fixed in the future uploads, please at least override
the missing-manpage lintian warning, prepending a comment to it.

The empty override_dh_auto_test should have a proper comment too.
 
> I plan to look onto adding package autotests afterwards.

With those tests the package would be better.

The present package looks good to me[1], except for:

1. [optional] debian/rules: please wrap long lines to 80 characters.
2. [error] libodp-generic119.prerm.in:

 update-alternatives --remove \
 /usr/lib/@DEB_HOST_MULTIARCH@/libodp-linux.so.@ODP_SOVERSION@ \
 libodp-linux.so.@ODP_SOVERSION@-@DEB_HOST_MULTIARCH@ \
 
/usr/lib/@DEB_HOST_MULTIARCH@/odp-generic/libodp-linux.so.@ODP_SOVERSION@

   This is causing a removal failure:
   
http://debomatic-amd64.debian.net/distribution#unstable/odp/1.19.0.1-1/piuparts

Please fix the aforementioned problems. Hopefully we'll have the last
round of check next time. Thank you for working on this.

[1] 
http://debomatic-amd64.debian.net/distribution#unstable/odp/1.19.0.1-1/buildlog


signature.asc
Description: PGP signature

Bug#888859: Info received (Bug#888859: RFS: iolang/2017.09.06+dfsg-1 [ITP])

[Lumin]

control: noowner -1

I'm recently too busy to review and test such a complex package,
hence dropping it.
Currently the package can be successfully built.

Bug#896186: Info received (Bug#896186: RFS: netctl/1.16-1 [ITP])

[Lumin]

control: noowner -1

I quit reviewing this RFS, because frequent and incooperative
force-{push,squash}'es drive me crazy, which makes it hard to track the changes.

Any mentors interested in this package  can take it over. I
guess the package was nearly in shape, and the remaining reviewing work
should be the tests.

Sorry for inconvenience.

Bug#888859: RFS: iolang/2017.09.06+dfsg-1 [ITP]

[Lumin]

control: tags -1 +morefino

On Fri, Feb 23, 2018 at 12:05:41AM +0800, Yangfl wrote:
> 
> d/copyright should have provided a list of removed files (see Files-Excluded).
>
> By the way, I have made a PR to upstream to remove ConvertUTF and it
> has accepted. The next release will not affected by this.

Sounds good.

> Added deps on libjs-jquery. Source of jquery.js is now provided.
> 
> Also move Flux resource files to /usr/share/ .

As discussed previously, there are several issues remained to be solved
before the next round of review:

1. A packaging repo. This is a complicated package, with a proper
   packaging repo it will be easier to track the changes.

2. Add the upstream correctness tests to the dh_auto_test target.
   I believe this is necessary because it's a language package. Any
   unit test failure may trigger unexpected potential problems.

3. Your effort is appreciated. However, as previously discussed, you
   should make sure whether you would be interested in this package
   for a while. As you said, you don't quite use this package.
   I guess it's hard for one to keep interest on a package he/she
   doesn't care about.

thanks.

Bug#900175: RFS: nltk/3.3.0-1

[Lumin]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: nltk
   Version : 3.3.0-1
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : science

  It builds those binary packages:

python-nltk - Python libraries for natural language processing
 python3-nltk - Python3 libraries for natural language processing

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

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


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

dget -x https://mentors.debian.net/debian/pool/main/n/nltk/nltk_3.3.0-1.dsc

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

  http://debomatic-amd64.debian.net/distribution#unstable/nltk/3.3.0-1/buildlog

  Changes since the last upload:

nltk (3.3.0-1) unstable; urgency=medium

  * New upstream version 3.3.0
  * Bump X-Python3-Version to >= 3.5
  * Remove the obsolete X-Python-Version field.
  * Bump Standards-Version to 4.1.4 (no change).

Bug#896186: RFS: netctl/1.16-1 [ITP]

[Lumin]

Hi Yangfl,

On Tue, May 22, 2018 at 08:43:07PM +0800, Yangfl wrote:
> 2018-05-20 19:50 GMT+08:00 Lumin <cdlumin...@gmail.com>:
> > control: tag -1 +moreinfo
> >
> > On Fri, May 04, 2018 at 10:37:27AM +0800, Yangfl wrote:
> >> control: tag -1 - moreinfo
> >>
> >> Reuploaded.
> >
> > Please fix your packaging repo first:
> >
> >   https://salsa.debian.org/chinese-team/netctl/network/master
> >
> > The stuff in the master branch is identical to the upstream branch.
> > "debian" directory is contained in no branch. This is an error.
> > "upstream" version keeps a copy of untouched upstream source.
> > "master" branch is typically holding the debian/ folder on the top
> > of the "upstream" branch.
> >
> > You should fix the packaging repo, or I won't know what on earth
> > the changes are.
> >
> > After fixing the packaging repo, please fix the problematic
> > installation path:
> >
> >   -rw-r--r-- root/root   353 2018-04-20 10:54 ./netctl-ifplugd@.service
> >   -rw-r--r-- root/root   284 2018-04-20 10:54 ./netctl-sleep.service
> >   -rw-r--r-- root/root   289 2018-04-20 10:54 
> > ./netctl-wait-online.service
> >   -rw-r--r-- root/root   260 2018-04-20 10:54 ./netctl.service
> >   -rw-r--r-- root/root   316 2018-04-20 10:54 ./netctl@.service
> >   drwxr-xr-x root/root 0 2018-04-20 10:54 ./usr/
> >
> > Run "debc" for a quick content check after building an package.
> > Run "lintian -EviI --pedantic" and fix those lintian Warnings.
> >
> > Please don't remove the moreinfo tag if you are not sure your
> > package is totally correct.
> >
> > Thank you for the update, and please ping me when you are ready
> > for the next round of review.
> 
> Done.

The package doesn't build with the source package from pristine-tar.

The packaging repo still looks incorrect. The packaging branch is
directly built on top of the upstream master branch. Personally I
recommend to create packaging repo like this:

  1. create empty git repo
  2. download upstream source tarball, or »git archive« from upstream
 git repo.
  3. »gbp import-orig --pristine-tar upstream.orig.tar.gz«
  4. Upstream branch keeps a copy of upstream source, instead of
 a copy of the upstream git commits. Pristine-tar branch keeps
 the tarball used to build upstream source and help keep the
 package reproducible. Master branch is usually where your
 packaging work goes.
  5. write a watch [See uscan(1)] file if possible.
  6. When the next upstream release is available, download it via uscan
 or do it manually, and do gbp import-orig.

Anyway let's talk about the problems to be solved:

  1. Incorrect installation path
 W: netctl: file-in-unusual-dir netctl-ifplugd@.service

 ./netctl-auto@.service
 ./netctl-ifplugd@.service
 ./netctl-sleep.service
 ./netctl-wait-online.service
 ./netctl.service
 ./netctl@.service

  2. Incomplete copyright information

 I quickly scanned all the files, there are far more than one
 contributors in the upstream project.

 At least you should copy all the authors from AUTHORS to
 debian/copyright, and append a wildcard author to the list:

   20XX Netctl contributors

  3. rules:

 Why override the "build" and "dh_install" target?

 This patch also fixes problem 1:

```
diff --git a/debian/rules b/debian/rules
index 6aca0c9..3c7c9c6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,13 +5,11 @@
 %:
dh $@
 
-build:
-   # no build target; `make install' during build stage causes error
+override_dh_auto_build:
+   true
 
 override_dh_auto_install:
+make SHELL=/bin/bash .SHELLFLAGS="-O extglob -c" PREFIX=/usr 
DESTDIR="$(CURDIR)/debian/netctl" install
-
-override_dh_install:
mv debian/netctl/etc/netctl/examples debian/netctl/usr/share/netctl/
mkdir debian/netctl/etc/ifplugd/action.d/
mv debian/netctl/etc/ifplugd/netctl.action 
debian/netctl/etc/ifplugd/action.d/netctl
```

Please fix these issues.

Bug#896970: RFS: odp/1.19.0.0-1 [ITP]

[Lumin]

On Wed, May 23, 2018 at 07:50:57PM +0300, Dmitry Eremin-Solenikov wrote:
> Hello,
> 
> I have updated odp & odp-dpdk packages on mentors.d.n.

Please file another RFS bug for the odp-dpdk package since it is a
different source.
 
> 2018-05-06 3:56 GMT+03:00 Dmitry Eremin-Solenikov :
> > I will make my next upload use alternatives, thank you.
> 
> This upload uses alternatives to select ODP library to be used.
 
The package is going in the right way, but the alternatives still needs
to be improved.

> >> * move all the executables to /usr/bin. Their name starts with odp_, so
> >>   I don't expect them to pollute the public name space. Putting these
> >>   test programs in a private directory just makes it hard to find and
> >>   use them.
> >
> > This looks logical to me. I will move some (usefull) programs to /usr/bin
> > and will drop the rest of them.
> 
> I have moved several executables to /usr/bin and removed the rest of them.
> 
> This upload does not have manpages for those binaries, I will fix that in
> the next upload.

Reasonable.

> >>> > 11. Why is dh_auto_test overrode to empty?
> >>>
> >>> We had issues with make check before, they interacted strangely with
> >>> build environment, that is why it is disabled for now. I plan to
> >>> reenable it later.
> >>
> >> How strange is it? And what happend during the test?
> >>
> >> As per policy, network access during the build is not availble. If this
> >> is the cause of test problem, we can omit the test part. However, we
> >> should still write the tests in the override_dh_auto_test target, if our
> >> user want to test it somehow.
> >
> > Some of the validation scripts are trying to create/remove network
> > interfaces.
> >
> >>   override_dh_auto_test:
> >>   -test_binary
> >>
> >> This should be ok.
> >
> > Ack
> 
> This is not fixed yet. Also will be fixed in the next upload.

OK. Once you have managed to add working tests, adding autopkgtest test
cases is recommended. Debian's infrastructure will run these tests
regularly to make sure there is no problem that are easy to detect.
 
> Could you please review alternatives system, so that I can be sure that
> I've used them correctly?
> 
> -- 
> With best wishes
> Dmitry

Nitpickings about the updated package:

1. README.Debian
   "Library packages should contain libodp-linux.so.FOO"
   It should be "libodp-linux.so.SOVER", which is more precise. 

2. command `dot` comes from graphviz, but it is missing from B-D.

3. libodp-generic119 should provide libodp-linux.so.119 instead of
   libodp-linux119. And applications that need libodp-linux.so.119
   could declare Depends: libodp-linux.so.119 | libodp-generic119 .

   This is similar to libblas.so.3 | libblas3 setting of the BLAS
   implementations.

4. libodp-generic-dev should Privides: libodp-linux.so .
   odp-generic/libodp-linux.so should be registered in the alternatives
   system to provide a /usr/lib/DEB_HOST_MULTIARCH/libodp-linux.so .
   
   The static library /usr/lib/x86_64-linux-gnu/libodp-linux.a should
   be put to the /.../odp-generic directory, and be registered as a slave
   of the libodp-linux.so alternative.

   I also noticed that the symlink points to an invalid path.
   Please solve this issue by the alternatives system as said above.

   root@bfb95763d3d6 ~/odp-1.19.0.1# ll 
/usr/lib/x86_64-linux-gnu/libodp-linux.so
   lrwxrwxrwx 1 root root 23 May 23 16:01 
/usr/lib/x86_64-linux-gnu/libodp-linux.so -> libodp-linux.so.119.0.1

libblas3 and libopenblas-base and their corresponding -dev packages are
good examples at this point. If you have doubts, you can carefully
examine these packages which may possibly provide help. 

Please ping me if you have question, or ready for the next round of
review :-)


signature.asc
Description: PGP signature

Bug#896186: RFS: netctl/1.16-1 [ITP]

[Lumin]

control: tag -1 +moreinfo

On Fri, May 04, 2018 at 10:37:27AM +0800, Yangfl wrote:
> control: tag -1 - moreinfo
> 
> Reuploaded.

Please fix your packaging repo first:

  https://salsa.debian.org/chinese-team/netctl/network/master

The stuff in the master branch is identical to the upstream branch.
"debian" directory is contained in no branch. This is an error.
"upstream" version keeps a copy of untouched upstream source.
"master" branch is typically holding the debian/ folder on the top
of the "upstream" branch.

You should fix the packaging repo, or I won't know what on earth
the changes are.

After fixing the packaging repo, please fix the problematic
installation path:

  -rw-r--r-- root/root   353 2018-04-20 10:54 ./netctl-ifplugd@.service
  -rw-r--r-- root/root   284 2018-04-20 10:54 ./netctl-sleep.service
  -rw-r--r-- root/root   289 2018-04-20 10:54 ./netctl-wait-online.service
  -rw-r--r-- root/root   260 2018-04-20 10:54 ./netctl.service
  -rw-r--r-- root/root   316 2018-04-20 10:54 ./netctl@.service
  drwxr-xr-x root/root 0 2018-04-20 10:54 ./usr/

Run "debc" for a quick content check after building an package.
Run "lintian -EviI --pedantic" and fix those lintian Warnings.

Please don't remove the moreinfo tag if you are not sure your
package is totally correct.

Thank you for the update, and please ping me when you are ready
for the next round of review.


signature.asc
Description: PGP signature

Bug#897238: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS

[Lumin]

On Fri, May 18, 2018 at 11:49:05PM +0800, Drew Parsons wrote:
> 
> I wonder if the simplest solution is to just have 
> intel-mkl Depends: libblas.  i.e. use policy to simply prevent a sole
> mkl installation.  
>
> That way, the mkl alternative will always have a free BLAS to press
> it's preference against.

That's exactly a part of the present implementation.

It depends on libblas3 | libblas.so.3, and enhances libblas.so.3, but
never provides libblas.so.3 . Similar for lapack.

Bug#898975: RFS: lua-moses/1.6.1+git20170613-2

[Lumin]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: ti...@debian.org

Dear mentors,

I am looking for a sponsor for my package "lua-moses":

 * Package name: lua-moses
   Version : 1.6.1+git20170613-2
   Upstream Author :
 * URL :
 * License : MIT
   Section : interpreters

The package can be obtained here:

  https://salsa.debian.org/science-team/lua-moses

which has passed all the tests of debomatic-amd64:

  
http://debomatic-amd64.debian.net/distribution#unstable/lua-moses/1.6.1+git20170613-2/buildlog

Changes since the last upload:

  lua-moses (1.6.1+git20170613-2) unstable; urgency=medium
  
* Packaging repo was moved to Science Team (Salsa).
  + Update Vcs-* fields accordingly.
* Maintainer is now Science Team. Move myself to Uploaders.
  + Move myself to Uploaders.
* Install guide docs.
  + Register the docs in doc-base.
* Add support for lua 5.3
  + Also lua5.3 tests in autopkgtest control file.
* Bump Standards-Version to 4.1.4 (no changes).
* Mark the package as Multi-Arch: foreign because it contains no
  arch-dep file.



signature.asc
Description: PGP signature

Bug#898484: [cdlumin...@gmail.com: RFS: nltk/3.3.0]

[Lumin]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "nltk":

* Package name: nltk
  Version : 3.3.0
  Upstream Author : NLTK project
* URL : https://www.nltk.org/
* License : Apache-2.0
  Section : science

The package can be found here:

  https://salsa.debian.org/science-team/nltk

It passed the tests of debomatic-amd64:

  http://debomatic-amd64.debian.net/distribution#unstable/nltk/3.3.0-1/buildlog

Changes:

nltk (3.3.0-1) unstable; urgency=medium

  * New upstream version 3.3.0
  * Bump X-Python3-Version to >= 3.5
  * Remove the obsolete X-Python-Version field.
  * Bump Standards-Version to 4.1.4 (no change).


signature.asc
Description: PGP signature

Bug#897238: RFS: intel-mkl/2018.2.199-1 -- ready for review

[Lumin]

Hello Mentors and Science Team,

The existing problems previously existing in the package have been
resolved. See the following threads for discussion about the decisions
related to debconf:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897238
https://lists.debian.org/debian-science/2018/04/msg00071.html

I've built and tested the package and it looked good to me.
Does anyone willing to sponsor it?

The packaging repo can be found here:

https://salsa.debian.org/science-team/intel-mkl

And the upstream tarball can be obtained following instructions
in README.Debian.

P.S. Don't perform source-only upload since this is non-free blob.
A source+amd64+i386 upload is needed.

Thanks in advance. :-)

Best,
lumin


signature.asc
Description: PGP signature

Bug#897238: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS

[Lumin]

Hi Sébastien,

> Using a Pre-Depends here is IMO wrong. Quoting Policy §7.2:

Thanks. I didn't notice that when considering ways to avoid corner
cases.

> I also think that removing the Provides is not a good idea. The alternative is
> provided by the package, and that should be made clear in the dependency
> relationships.

> I'm sorry but I don't have an ideal solution to the problems we previously
> discussed. But IMO it's acceptable to not perfectly deal with the corner case
> where only MKL is installed, as long as some warning is displayed.

I insist on removing the Provides, even if it looks weird. For sake of
debconf correctness, I can't find a better way other than removing it.
This is a special situation where we are dealing with non-free blobs.
The choice of providing alternative while leaving the Provides field blank
is due to debconf correctness -- which is more important than the
Provides field since it directly reflects the user's choice.

* When there is only libmkl-rt as libblas.so.3 provider, libblas.so.3
  is still used as the default implementation EVEN IF THE USER REJECTS
  TO USE IT AS DEFAULT in debconf dialog.

That means when there is MKL, there MUST be another free alternative.
However, assigning Provides to MKL may lead to unexpected corner cases
where the consideration of debconf dialog turns in vain, because it is
not simple to make sure the existence of another free alternative.

In a word, MKL itself is non-free alternative to BLAS/LAPACK, and there
should be no problem to disallow MKL to satisfy libblas.so.3 / liblapack.so.3
requirement in a dependency tree where there are LOTS OF GPL-licensed
software. I'll override it if leaving Provides blank violates policy
because legal safety is greater than technological corectness.

As a compromise, let's regard MKL as a "non-free" enhancement to free
BLAS/LAPACK implementations. An Enhances: field should be nice for us,
which alleviates the discomfort of leaving Provides: blank.


signature.asc
Description: PGP signature

Bug#897238: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS

[Lumin]

Just forgot to CC the RFS bug.

- Forwarded message from Lumin <cdlumin...@gmail.com> -

Date: Sun, 6 May 2018 08:29:29 +
From: Lumin <cdlumin...@gmail.com>
To: sebast...@debian.org
Cc: debian-scie...@lists.debian.org
Subject: Re: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS
User-Agent: Mutt/1.9.5 (2018-04-13)

Hello guys,

I've just updated the MKL packaging, and added a BLAS performance tester
there. I'll test the package soon, but let me first describe the
changes.

> He put forward a simpler solution: Just don't provide libblas.so.3, such
> that MKL will never be used to satisfy the dependency of libblas.so.3 .
> Based on his idea, my new solution is the follows:
> 
>   libmkl-rt --
>   Depends: libblas3 | libblas.so.3
>   Provides: NOTHING  ... (4)
> 
> So it's totally safe now. If there is MKL, there must be a free
> libblas.so.3 implementation with a priority definitely larger than 1,
> overriding MKL in terms of auto-mode alternatives. On the other hand,
> if that alternative is manually set, then there is nothing to worry
> about. This solution is also able to resolve problems found in (1) and (3).

Now libmkl-rt doesn't provide libblas.so.3 and liblapack.so.3, and it
pre-depends on libblas3 | libblas.so.3 and liblapack3 | liblapack.so.3 .
Similar change was applied to libmkl-dev.

> Apart from all things discussed above, there is upstream confirmation
> to the ambiguous license declaration in several headers. See [1]

Now the copyright file is updated. Copyright is clean.

> Thanks. There is a small bug: in both libmkl-rt.postinst.in and
> libmkl-dev.postinst.in, when the users reply "no", you put both BLAS and 
> LAPACK
> alternatives in auto mode if MKL was selected for BLAS. You should rather 
> split
> that in two tests: one for BLAS, one for LAPACK, because in theory it's
> possible to have BLAS pointing to MKL and not LAPACK.

One more debconf menu is added to configure script. A multiselect box
will be presented to the user so that we can treat BLAS and LAPACK
separately. That multiselect menu only appear once. For example, if the
user chose to point BLAS to MKL but not LAPACK, i.e.

  libblas.so.3-x86_64-linux-gnu -> libmkl_rt.so
  liblapack.so.3-x86_64-linux-gnu -> won't be touched

then following the configuration, these symlink will be set accordingly:

  libblas.so.3-i386... -> libmkl_rt.so
  liblapack.so.3-i386... -> won't be touched
  libblas.so-{amd64,i386} -> libmkl_rt.so
  liblapack.so-{amd64,i386} -> won't be touched.

For detail see [1][2][3]. Is this acceptable? If it's good, I'll test it
soon.


Previously Sébastien expressed his interest on benchmarking. I'm
interested in that too. So apart from the debconf part, I wrote a simple
benchmarker[4] in Julia[5] for comparing several BLAS implementations.
Thanks to Julia's convenient FFI functionality, I can test all
implementations within a single run, without any modification to environment
variable or alternatives.

Test result on my laptop (CPU=i5-7440HQ) matches expectation:

dnrm2 Julia
  0.33 seconds
dnrm2 /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0
  0.74 seconds (3 allocations: 48 bytes)
  dnrm2 Error :1.1368683772161603e-13
dnrm2 /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3.10.3
  0.38 seconds (3 allocations: 48 bytes)
  dnrm2 Error :0.0
dnrm2 /usr/lib/x86_64-linux-gnu/libopenblas_haswellp-r0.2.20.so
  0.31 seconds (3 allocations: 48 bytes)
  dnrm2 Error :0.0
dnrm2 /usr/lib/x86_64-linux-gnu/libmkl_rt.so
  0.029561 seconds (3 allocations: 48 bytes)
  dnrm2 Error :0.0
dgemm Julia
  4.362279 seconds (2 allocations: 128.000 MiB, 0.20% gc time)
dgemm /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0
 47.893710 seconds (10 allocations: 160 bytes)
  dgemm Error :2.0735139719127268e-10
dgemm /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3.10.3
 10.412422 seconds (10 allocations: 160 bytes)
  dgemm Error :2.4175670445887973e-11
dgemm /usr/lib/x86_64-linux-gnu/libopenblas_haswellp-r0.2.20.so
  1.211220 seconds (10 allocations: 160 bytes)
  dgemm Error :2.770610675980814e-11
dgemm /usr/lib/x86_64-linux-gnu/libmkl_rt.so
  1.103356 seconds (10 allocations: 160 bytes)
  dgemm Error :2.7982744719588258e-11

Netlib is always the slowest one. For small matrices OpenBLAS is
very competitive. For large matrices MKL is the fastest.


[1] 
https://salsa.debian.org/science-team/intel-mkl/blob/master/debian/libmkl-rt.templates
[2] 
https://salsa.debian.org/science-team/intel-mkl/blob/master/debian/libmkl-rt.config.in
[3] 
https://salsa.debian.org/science-team/intel-mkl/blob/master/debian/libmkl-rt.postinst.in
[4] 
https://salsa.debian.org/science-team/intel-mkl/blob/master/debian/tests/blascomp.jl
[5] http://julialang.org/
My Julia version is 0.6.2, which doesn't exist in Debian archive.

- End forwarded message -

Bug#897238: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS

[Lumin]

On Wed, May 02, 2018 at 10:03:38AM -0500, Dirk Eddelbuettel wrote:
> 
> On 2 May 2018 at 14:41, Lumin wrote:
> | Seems that things are getting more complicated. Recall that here we'are
> | going to prevent users from GPL violation in situations such as this
> | one:
> | 
> |   debootstrap; apt install libmkl-rt; apt install octave; octave ... (1)
> 
> Are you sure? I do not think that is correct. Downloading and installating
> MKL, and running it with R or Octave (or any other package linking the BLAS
> interface) does not constitute a GPL violation AFAIK.

Not sure. I admit that I'm not good at long licences such as GPL.
Whether it violates GPL or not, what we do in config/postinst won't
change: make sure it's the user's explicit choice to use MKL as the
default BLAS/LAPACK implementation, and in contrast, MKL will not be
used without the explicit choice.

> (There may well be limitations on further redistribution of the aggregate
> even though even the MKL now limits redistribution as it is of course still a
> no-source-code piece of software.)

Intel's ISSL license allows redistribution, as long as no file is
changed.

> Thanks for all your work on this though. Much appreciated.
> 
> Dirk
> 
> -- 
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#896970: RFS: odp/1.19.0.0-1 [ITP]

[Lumin]

On Sat, Apr 28, 2018 at 01:58:26PM +0300, Dmitry Eremin-Solenikov wrote:
> > 5. Could you explain why these lines exist? Package libodp-linux-dev
> > seems not exist.
> 
> Packages libodp-linux-dev and libodp-linux119 are virtual package,
> provided by different implementations of ODP API. We are providing
> another ODP implementation, implemented specifically on top of DPDK
> (https://github.com/Linaro/odp-dpdk). It is not packaged (yet). These
> two implementations are binary compatible. It is planned that odp-dpdk
> will have libodp-dpdk119 (Provides: libodp-linux119) and libodp-dpdk-dev
> (Provides: libodp-linux-dev) packages.
> 
> Would you recommend how should I better document and/or implement these
> packages.

How many libodp-linux.so.119 providers are there?

If there are only a few alternatives, why should we make a virtual
package, whose SOVERSION might bump regularly? From the policy we can
find a list of authoritative virtual packages:

  https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt

All of these packages are widely used and be depended by a lot of
packages. If the list of libodp-linux.so.* providers is short, we can
write the Depends field of an application package like this:

  Depends: libodp-implement1 | libodp-impl2 | ...,

where there is no virtual package.

According to your current debian/control, it seems that there can be
only one libodp-linux119 provider existing on system at the same time.
I'd really suggest to fix it before uploading, because you planed to
upload another implementation.

I think you have just written a better solution in the TODO file, i.e. to
use the alternative mechanism. Note that, a package contains
libodp-linux implementation can leave the Provides: fields blank, and
actually providing symlinks via the alternative system.

For example:

  libodp-generic119: contains libodp-generic.so.119, which is symlinked to
  libodp-linux.so.119 via alternatives system.

  libodp-dpdk119: contains libodp-dpdk.so.119, which is symlinked to
  libodp-linux.so.119 via alternatives system.

  No package provides a real libodp-linux.so.119 library.

By doing so you will get rid of the 'package-name-doesnt-match-sonames'
warning, and be able to keep several implementations at the same time.
This situation must be better for your next package.

To implement this, you first need to rename libodp-linux.so.* to match
your package name. Then write some postinst and prerm scripts. Here is a
good example:

  
https://salsa.debian.org/science-team/openblas/blob/master/debian/libopenblas-base.postinst.in
  
https://salsa.debian.org/science-team/openblas/blob/master/debian/libopenblas-base.prerm.in

By looking around in the openblas packaging you'll also find the example
for -dev package.

> libodp-test-utils? These tools are mostly testing programs, that can be
> used either by autotests (in future) or users (to check that their ODP
> installation works).

odp-linux-tools:

-rwxr-xr-x root/root 31016 2018-04-28 14:48 
./usr/lib/odp/linux/examples/odp_l3fwd
-rwxr-xr-x root/root 18504 2018-04-28 14:48 
./usr/lib/odp/linux/examples/odp_pktio

This still look weird. The convention is that -utils/-tools packages
would install executable binaries under /usr/bin (or /usr/sbin in some
cases). I think either of the two solutions will do

* move all the executables to /usr/bin. Their name starts with odp_, so
  I don't expect them to pollute the public name space. Putting these
  test programs in a private directory just makes it hard to find and
  use them.

* provide a script to call all or some of these programs. But you still
  need to strip the "examples" substring from the path. User might want
  to find human-readable examples in the "examples" directory, but
  actually they will end up with a pile of binaries.


> > 10. Why is the package containing
> > ./usr/lib/x86_64-linux-gnu/libodp-linux.so.119.0.0
> >   named libodp-generic119?

If libodp-generic.so.119 provides alternative, the shared object can
simply be renamed to libodp-generic.so.SOVERSION.

> > 11. Why is dh_auto_test overrode to empty?
> 
> We had issues with make check before, they interacted strangely with
> build environment, that is why it is disabled for now. I plan to
> reenable it later.

How strange is it? And what happend during the test?

As per policy, network access during the build is not availble. If this
is the cause of test problem, we can omit the test part. However, we
should still write the tests in the override_dh_auto_test target, if our
user want to test it somehow.

  override_dh_auto_test:
  -test_binary

This should be ok.

Bug#896970: RFS: odp/1.19.0.0-1 [ITP]

[Lumin]

Hi Dimitry,

I'm keeping an eye on the list and these bugs. I know that
your package needs to be checked, but these days I'm a
little busy dealing with real life work so that I postponed
reviewing packages. I'll review and give you feedbacks in
this weekend.

On Thu, May 3, 2018 at 22:21 Dmitry Eremin-Solenikov <dbarysh...@gmail.com>
wrote:

> Package: sponsorship-requests
> Followup-For: Bug #896970
>
> Hi Lumin,
>
> I've updated ODP package on mentors.d.n, according to most of your
> comments. Could you please review it?
>
> --
> With best wishes
> Dmitry
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8),
> LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
-- 
Best,

Bug#897238: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS

[Lumin]

Hi Sébastien,

> > Since libmkl-rt Provides libblas.so.3, it is not totally safe even
> > if we set its priority to 1. That's because MKL will still be selected
> > when there is only one libblas.so.3 provider, namely MKL. Due to
> > this reason, I appended libopenblas-base as a dependency of libmkl-rt,
> > so that MKL will never be selected by update-alternatives in auto mode.
> > (I'm not sure what will happen if a package which provides libblas.so.3
> > and also depends libblas.so.3 . Let me simply depend on openblas
> > instead.)
> 
> I had overlooked this corner case, thanks.
> 
> It should be however very rare, because all packages that depend on a
> BLAS/LAPACK implementation use something like "Depends: libblas3 | 
> libblas.so.3"
> (i.e. a concrete package before the virtual one). But it can indeed happen if
> the user first selects MKL then the depending package.
> 
> I think depending on openblas is a bit weird. If the users reply "no" and MKL
> is the only alternative available, then I'd rather display a debconf message
> warning the user about the situation.
> 
> The test about MKL being the only option could be something like:
> 
> if [ $(update-alternatives --query libblas.so.3-@DEB_HOST_MULTIARCH@ | grep 
> ^Alternative: | wc -l) = 1 ]

Seems that things are getting more complicated. Recall that here we'are
going to prevent users from GPL violation in situations such as this
one:

  debootstrap; apt install libmkl-rt; apt install octave; octave ... (1)

Another solution which avoids directly depending on OpenBLAS came up in
my mind, which looks like:

  libmkl-rt --
  Pre-Depends: libblas3 | libblas.so.3; Provides: libblas.so.3   ... (2)

The solution (2) will keep the user safe in situation (1). However while
having a discussion with a Debian Maintainer, a bug of solution (2) was
pointed out by him:

  debootstrap; apt install libmkl-rt; apt purge libblas3; octave ... (3)

In situation (3), MKL is still the only provider of libblas.so.3, and
GPL will be violated even if the user answered "NO" when installing MKL.
If we are going to find a solution for (3), things will be even more
complex ...

He put forward a simpler solution: Just don't provide libblas.so.3, such
that MKL will never be used to satisfy the dependency of libblas.so.3 .
Based on his idea, my new solution is the follows:

  libmkl-rt --
  Depends: libblas3 | libblas.so.3
  Provides: NOTHING  ... (4)

So it's totally safe now. If there is MKL, there must be a free
libblas.so.3 implementation with a priority definitely larger than 1,
overriding MKL in terms of auto-mode alternatives. On the other hand,
if that alternative is manually set, then there is nothing to worry
about. This solution is also able to resolve problems found in (1) and (3).

> 
> The test about MKL being the only option could be something like:
> 
> if [ $(update-alternatives --query libblas.so.3-@DEB_HOST_MULTIARCH@ | grep 
> ^Alternative: | wc -l) = 1 ]

I think this is not needed if we use solution (4). MKL will never be
the only libblas.so.3 "provider" existing on system.

Apart from all things discussed above, there is upstream confirmation
to the ambiguous license declaration in several headers. See [1]

The blockers are cleared. I think I'll update the package as proposed,
and the copyright information as said in [1] before this weekend.

[1] https://github.com/intel/mkl-dnn/issues/206#issuecomment-385772103

Regards,
Lumin


signature.asc
Description: PGP signature

Bug#897238: Re: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS

[Lumin]

Hi Sébastien,

> - if MKL was not already selected and the user says no, the setting
> will be
> left untouched (either in automatic or manual mode, depending on the
> user
> customization)
> 
> - if MKL was already selected and the user says no (e.g. after a
> reconfigure),
> then MKL will be unselected (and the BLAS with the highest priority
> will
> become the current alternative)
> 
> - if the user says yes, MKL is selected (while with your actual code,
> if the
> alternative was in manual mode, then MKL would still be unselected
> even with
> priority 50)

Now I understand what you meant. I changed postinst in this [1] commit.
_mkl_rt_priority is set to 1 and will never be changed. Now we select
MKL as default by setting is in manual mode, instead of assinging a
high priority so that update-alternatives automatically selects the
highest one. This implementation is tightly matched to the literal
meaning of the debconf question.

Since libmkl-rt Provides libblas.so.3, it is not totally safe even
if we set its priority to 1. That's because MKL will still be selected
when there is only one libblas.so.3 provider, namely MKL. Due to
this reason, I appended libopenblas-base as a dependency of libmkl-rt,
so that MKL will never be selected by update-alternatives in auto mode.
(I'm not sure what will happen if a package which provides libblas.so.3
and also depends libblas.so.3 . Let me simply depend on openblas
instead.)

README.Debian [2] is also updated according to the changes.

Current HEAD is 2ce1edd8cc57ed87c080edccd36456bb9953fd22.
I haven't test the new postinst script yet.

[1] https://salsa.debian.org/science-team/intel-mkl/commit/a90fd6389940
e134baa049a69efac79a076ac870
[2] https://salsa.debian.org/science-team/intel-mkl/commit/2ce1edd8cc57
ed87c080edccd36456bb9953fd22

Bug#897238: RFS: intel-mkl/2018.2.199-1 -- Intel Math Kernel Library (Intel MKL)

[Lumin]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-scie...@lists.debian.org

Dear mentors,

  I am looking for a sponsor for my package "intel-mkl"

 * Package name: intel-mkl
   Version : 2018.2.199-1
   Upstream Author : Intel
 * URL : https://software.intel.com/en-us/mkl
 * License : Intel Simplified Software License (ISSL)
   Section : science

Thanks for people who joind the discussion about MKL packaging
at debian-science list.

Intel MKL is widely used among scientific research/computing
communities
because of it's well-optimized and super fast.
As previously discussed
in debian-science list, having intel-mkl
in Debian archive would be
useful, and would benifit our
users (especially the scientific users).
So here is the package.

Note that this is not a normal RFS since it involves huge
non-free binary blobs. (~1GB source tarball)

The packaging repo containing debian directory is here:

  https://salsa.debian.org/science-team/intel-mkl

Upstream tarball is too huge so I uploaded it nowhere.
As documented in README.Debian, the tarball can be
found here:

  https://software.intel.com/en-us/mkl

Click "Free Download". The tarball will be available after
registration. (Re-distribution is explicitly allowed even
if one is required to register before downloading).
Checksums are written in debian/rules.

Local lintian test is totally clean. Please ignore
lintian Info "unused override *", because the lintian
overrides are automatically generated.

MKL package is a bit complex, but let me try to explain it:

1. Copyright, the way to get upstream source, upstream
   source structure annotation, can be found in README.Debian

2. Installation and Usage are explained in README.Debian,
   they should give you a basic idea how this package
   is organized.

3. There is a detailed binary package index in debian/control.
   Files are carefully split into small packages. It must
   be pointed out that the two most important nodes in
   the dependency graph are libmkl-rt and libmkl-dev.
   The reason why db_input importance is set to critical
   can be fould in recent discussion in debian-science.

   libmkl-rt is a run-time dispatching library. It auto
   matically selects shared object from which symbols
   are loaded. Typically it select one shared object
   from each of the three layers: interface layer,
   threading layer, and computational layer. To reduce
   my burden, I grouped the children librarires of
   libmkl-rt with three meta packages, respectively.

   libmkl-rt plus the basic set of static libraries
   plus the headers equal to libmkl-dev.

   intel-mkl metapackage is simply a wrapper of
   libmkl-dev. I expect that most user pull mkl
   by installing intel-mkl.

   intel-mkl-cluster is intel-mkl + cluster support.

   intel-mkl-cluster is intel-mkl + cluster support
   + multiarch (i386) libraries + all other misc stuff.

4. Despite of the 1000+ line control file, I tried my
   best to keep the rest part of packaging simple
   and elegant.

   Python script debian/control.py generates all the
   .install files and all the .lintian-overrides file.
   It scans upstream tarball and put files in a
   proper package. I think the comments in the script
   should be enough for one to fully understand
   what it does.

5. The last problem is a trivial license problem.
   There are ambiguous license declaration in
   several files. I'm waiting for upstream reply[1]

intel-mkl (2018.2.199-1) experimental; urgency=low

  * Initial release. (Closes: #895881)

[1] https://github.com/intel/mkl-dnn/issues/206#issuecomment-385154890

Bug#896970: RFS: odp/1.19.0.0-1 [ITP]

[Lumin]

control: tag -1 +moreinfo
control: owner -1 !

Hi Dmitry,

Thank you for this package. Here are some problems found in your package:

1. This package misses dependency libconfig-dev

2. Please fix the lintian warnings. e.g.

 W: odp-doc: privacy-breach-generic

3. debhelper compat level and the standards-version is a bit old.
The latest compat is 11, and standards-version is 4.1.4.
See debhelper(7) section COMPATIBILITY LEVELS for compat checklist.
See https://www.debian.org/doc/debian-policy/ for the standards upgrading
checklist.

4. Please break the lines whose length exceeds 80 characters in
debian/control and rules.

5. Could you explain why these lines exist? Package libodp-linux-dev
seems not exist.

 43 Conflicts: libodp-linux-dev
 44 Provides: libodp-linux-dev

also, package libodphelper-dev depends on the non-existing package.

 53 Package: libodphelper-dev
 54 Architecture: any
 55 Section: libdevel
 56 Depends: libodphelper119 (= ${binary:Version}),
 57  libodp-linux-dev,

6. Must we provide a example package with pre-built binaries shipped?

77 Package: odp-linux-examples

   Why can't we put the source of these examples into the doc package?
   Or why don't we choose a name such as libodp-tools / libodp-utils
   to avoid ambiguity?

7. your patch directory is empty, could you please remove it?

8. Changelog: This is the first-time upload. Could you change the file
so that it looks like this:

PACKAGE (VERSION) UNRELEASED; urgency=low

  * Initial release. (Closes: #XX)

 -- maintainer   Thu, 26 Apr 2018 13:06:09 +

9. debian/docs This file looks useless ?

10. Why is the package containing
./usr/lib/x86_64-linux-gnu/libodp-linux.so.119.0.0
  named libodp-generic119?

11. Why is dh_auto_test overrode to empty?

Please feel free to ask if you have any question about
the above points. And have a good day :-)

-- 
Best,

Bug#888859: RFS: iolang/2017.09.06+dfsg-1 [ITP]

[Lumin]

control: owner -1 !
control: tag -1 +moreinfo

Hi Yangfl,

As discussed previously, the python script for automatically
generating the files should be added in the package.

-- 
Best,

Bug#883840: RFS: spglib/1.10.3-1 [ITP]

[Lumin]

On 23 April 2018 at 14:11, Andrius Merkys  wrote:
>> 6. tests: your autopkgtest testsuite failed:
>
> I will look into this. It is possible that I invoke the Python tests 
> incorrectly.

Oh, I forgot to tell you that the failure is due to output to stderr.
By redirecting
the stderr to e.g. stdout, this failure can be fixed.

Please let me know if you think the package is ready. Then I'll check
it again :-)

-- 
Best,

Bug#883840: RFS: spglib/1.10.3-1 [ITP]

[Lumin]

control: owner -1 !
control: tag -1 +moreinfo

Hi Andrius,

Thank you for the package. Here are some nitpicking about your package:

1. There seems to be ruby binding available, why isn't it packaged?

2. control: Your -dev package should also depend on the lib package.
Depends: ${misc:Depends}, libsymspg1 (= ${binary:Version})

The python package should depend on it too.

3. libsymspg1.install :

   usr/lib/libsymspg.so.1.10.3 usr/lib
   usr/lib/libsymspg.so.1 usr/lib

   wildcard is allowed in install files. The above two lines can be
reduced to one

   usr/lib/libsymspg.so.*usr/lib

   Apart from that, this looks a bit weird:
   DEBIAN/symbols DEBIAN

   You can first create an empty file debian/libsymspg1.symbols, then
   build the package. You will get a patch for updating this symbols file.
   After applying the patch, don't forget to remove the debian revision
   in the version number :-)

4. the install file of -dev package could be simplified

usr/include usr
usr/lib/libsymspg.a usr/lib

can be simplified to

usr/include
usr/lib/libsymspg.a

debhelper would assume your destination installation path is
the same as the source path, when destination is omitted.

5.  I'd suggest you install the library in the multiarch directory.
for example /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)

There are many ways to install the libxxx.so.* in the multiarch directory.
One of them, for example, is to write a install file like this:

usr/lib/libfoobar.so.1 usr/lib/##DEB_HOST_MULTIARCH##/

and we need to replace that placeholder in rules, for exmple

override_dh_auto_configure:
dh_auto_configure
sed -i -e "s@##DEB_HOST_MULTIARCH##@$(DEB_HOST_MULTIARCH)@g" libfoo1.install

6. tests: your autopkgtest testsuite failed:

http://debomatic-amd64.debian.net/distribution#unstable/spglib/1.10.3-1/autopkgtest

Please let me know if you have any question on these points :-)
You don't have to frequently dput to mentors, because I'll directly check
the packaging repo  https://salsa.debian.org/science-team/spglib

Have a good day!

-- 
Best,

Bug#896186: RFS: netctl/1.16-1 [ITP]

[Lumin]

Hi Yangfl,

Some feedbacks after checking you package:

1. Vcs-* fields are missing, which makes it hard to track
the changes. I'd recommend you to put the packaging
work on salsa or somewhere alike.

2. lintian overrides: why do you override them? Please add
   the explanation as comments in the override file.

3. Please remove empty directories under debian/ .

4. Patch headers are missing. Please add at least these information
   to the head part of patches: Author, Purpose, Forward-Upstream(bool).

5. It is funny to harden some bash scripts.
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
This line is useless and removing it from rules won't harm.

6. export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed

Same above. These lines are useless.

7. in rules:
 14 build:
 15 # pass

Well  what's this?

8. [important] It FTBFS'ed on my machine. Do you have debomatic-amd64
access?


Please feel free to ask if you have any question about these points :-)

-- 
Best,

Bug#895803: RFS: linuxbrew-wrapper/20180209-1 [RC]

[Lumin]

Package: sponsorship-requests
Severity: important

Notes:
I have DM permission to this package. However to fix an RC bug this
package needs to go through NEW, moving from the main section
to the contrib section. See the RC bug for detail.

  Dear mentors,

  I am looking for a sponsor for my package "linuxbrew-wrapper"

 * Package name: linuxbrew-wrapper
   Version : 20180209-1
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : utils

  It builds those binary packages:

linuxbrew-wrapper - Homebrew package manager for Linux

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

  https://mentors.debian.net/package/linuxbrew-wrapper


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

dget -x 
https://mentors.debian.net/debian/pool/contrib/l/linuxbrew-wrapper/linuxbrew-wrapper_20180209-1.dsc

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

  Changes since the last upload:

linuxbrew-wrapper (20180209-1) unstable; urgency=medium

  * Import upstream snapshot.
  * Move to contrib section. (Closes: #888957)
  * Add watch file to monitor git HEAD.
  * Update my name in control and copyright.
  * Update copyright, and explain why this package goes to contrib.
  * Use https link in copyright.
  * Point Vcs-* links to Salsa.
  * Bump Standards-Version to 4.1.4 .
- Remove get-orig-source target. Use watch file instead.
- Change Priority to "optional" because "extra" has been deprecated.



-- 
Best,

Bug#895729: RFS: mkl-dnn/0.13~20180406-ga5f6077-1 [ITP] -- math kernel lib for deep neural network

[Lumin]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-scie...@lists.debian.org

Dear mentors,

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

 * Package name: mkl-dnn
   Version : 0.13~20180406-ga5f6077-1
   Upstream Author : Intel
 * URL : https://github.com/intel/mkl-dnn
 * License : apache-2.0
   Section : science

MKL-DNN stands for "math kernel lib for deep neural network". I think this
library will be used in more and more machine learning / deep learning
software in the future.

The package locates at the master branch here:

https://salsa.debian.org/science-team/mkl-dnn

It was successfully built on DoM-amd64.


http://debomatic-amd64.debian.net/distribution#experimental/mkl-dnn/0.13~20180406-ga5f6077-1/autopkgtest

Here are some notes on this package:

1. Architecture: amd64

This is suggested by upstream (Intel). There are ports to other
architectures but they are not officially supported by upstream.

2. what's the relation between MKL and this MKL-DNN?

MKL-DNN is independent to MKL. MKL-DNN can be built with or
without MKL. When linked against MKL, MKL-DNN would get a performance
boost. Functionality won't be influenced if not linked against MKL.

3. why do you upload such a snapshot instead of a regular release?

The regular release 0.13 has a bug when working in Xen. That bug
is fixed in this snapshot.

-- 
Best,

Bug#893377: RFS: taptempo/1.2.1-1 [ITP]

[Lumin]

Hi François,

I'm trying to apply for DD so I'm helping newcomers to review their
packages. As agreed by Gianfranco, once we've finished polising
the packaging, he will check and sponsor the package.

Now your package is in good shape, and there is nothing left to
be dealt with except for waiting for the sponsorship.
Let's hope Gianfranco will find a time doing the sponsorship.

Regards,

On 9 April 2018 at 17:43, François Mazen <franc...@mzf.fr> wrote:
> Hi Lumin,
>
> I just want to know if I must do something to go on with the
> integration of TapTempo into Debian.
> Should I submit again a RFS for the new package version?
>
> Thanks a lot for your help,
> François
>
>
> Le mardi 03 avril 2018 à 23:13 +0200, François Mazen a écrit :
>> Hi Lumin,
>>
>> upload to mentors done, please check:
>> https://mentors.debian.net/package/taptempo
>>
>> Regards,
>>
>> François
>>
>>
>>
>> Le mardi 03 avril 2018 à 06:17 +, Lumin a écrit :
>> > Hi François,
>> >
>> > On 31 March 2018 at 21:59, François Mazen <franc...@mzf.fr> wrote:
>> > >
>> > > This program is useful to quickly find the tempo of a song.
>> > > The idea is to type "taptempo" in a terminal, then hit enter key
>> > > at
>> > > each beat while hearing a song, and display the tempo.
>> > >
>> > > The targeted people are mainly musicians who need to transcribe
>> > > music
>> > > or play the song at the exact original tempo. The typical
>> > > situation
>> > > to
>> > > use this software is when you are in a hurry and you don't have
>> > > time to
>> > > launch a big workstation like Ardour or Lmms in order to find the
>> > > tempo.
>> >
>> > Got it. Thank you for this explanation.
>> >
>> > >
>> > > > 8. When you have built the latest version of the modified
>> > > > package,
>> > > > you could run lintian against it:
>> > > >
>> > > > lintian -EviI --pedantic .changes
>> > > >
>> > > > There generally shouldn't be any Error or Warning.
>> > >
>> > > I've fixed all the error and the lintian output should be clean.
>> >
>> > You have done quite a good job making the package in a good shape,
>> > and making the upstream very standard.
>> >
>> > By the way I'm surprised that you have fixed all lintian outputs,
>> > including the pedantic stuff. The pedantic items are only optional,
>> > not what must be fixed. Errors and Warnings should be dealt with,
>> > and some lintian Info can even pass if the maintainer has a good
>> > reason.
>> >
>> > In return everything's shining and in good shape :-)
>> >
>> > > Let me know if it still require more work.
>> >
>> > Nitpicking:
>> >
>> > 1. Please collapse the two lines in changelog into one. They refer
>> > to
>> > the same thing.
>> >
>> > -  * Initial debian package.
>> > -  * Closes: #893306
>> > +  * Initial debian package. (Closes: #893306)
>> >
>> > 2. there is still an autpkgtest problem:
>> >
>> > autopkgtest [07:01:02]: test version: [---
>> > spawn taptempo --version
>> > couldn't execute "taptempo": no such file or directory
>> > while executing
>> > "spawn taptempo --version"
>> > (file
>> > "/tmp/autopkgtest.C3pEq9/build.uWo/src/debian/tests/version" line
>> > 6)
>> > autopkgtest [07:01:03]: test version: ---]
>> > autopkgtest [07:01:03]: test version:  - - - - - - - - - - results
>> > -
>> > -
>> > - - - - - - - -
>> > version  FAIL non-zero exit status 1
>> > autopkgtest [07:01:03]: test version:  - - - - - - - - - - stderr -
>> > -
>> > - - - - - - - -
>> > couldn't execute "taptempo": no such file or directory
>> > while executing
>> > "spawn taptempo --version"
>> > (file
>> > "/tmp/autopkgtest.C3pEq9/build.uWo/src/debian/tests/version" line
>> > 6)
>> >
>> > this can be fixed by the patch. It looks somewhat wired but we need
>> > it.
>> >
>> > --- a/debian/tests/control
>> > +++ b/debian/tests/control
>> > @@ -1,2 +1,2 @@
>> >  Tests: version, help, tempo
>> > -Depends: expect
>> > +Depends: expect, taptempo
>> >
>> > The autopkgtest result after patched:
>> >
>> > http://debomatic-amd64.debian.net/distribution#unstable/taptempo/1.
>> > 3.
>> > 0-1/autopkgtest
>> >
>> > build result:
>> >
>> > http://debomatic-amd64.debian.net/distribution#unstable/taptempo/1.
>> > 3.
>> > 0-1/buildlog
>> >
>> > > Should I update this new package to the mentors website?
>> >
>> > Yes, please fix the two problem mentioned above, and upload to
>> > mentors.
>> >
>> > Thank you for you contribution to Debian, and have a good day.



-- 
Best,

Bug#894863: RFS: highwayhash/0~20180209-g14dedec-3

[Lumin]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: highwayhash
   Version : 0~20180209-g14dedec-3
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : science

  It builds those binary packages:

libhighwayhash-dev - Fast strong hash functions:
SipHash/HighwayHash (development)
 libhighwayhash0 - Fast strong hash functions: SipHash/HighwayHash (library)

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/h/highwayhash/highwayhash_0~20180209-g14dedec-3.dsc

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

http://debomatic-amd64.debian.net/distribution#unstable/highwayhash/0~20180209-g14dedec-3/buildlog

  Changes since the last upload:

highwayhash (0~20180209-g14dedec-3) unstable; urgency=medium

  * Set Ccience team as the maintainer
+ Put myself to Uploaders.
  * Move the packaging repo to salsa science team's namespace
+ Update Vcs-* links in control.
  * Add gcc to autopkgtest depends to fix CI test failure.
  * Collect symbol updates for x32 from buildd.


-- 
Best,

Bug#894671: RFS: nltk/3.2.5-2 [ITA] : natural language processing lib, popcon: ~300

[Lumin]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: debian-scie...@lists.debian.org

  Dear mentors,

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

 * Package name: nltk
   Version : 3.2.5-2
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : science

  It builds those binary packages:

python-nltk - Python libraries for natural language processing
 python3-nltk - Python3 libraries for natural language processing

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

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


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

dget -x https://mentors.debian.net/debian/pool/main/n/nltk/nltk_3.2.5-2.dsc

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

http://debomatic-amd64.debian.net/distribution#unstable/nltk/3.2.5-2/buildlog

Or If you prefer sponsoring from the git repo:

https://salsa.debian.org/science-team/nltk
commit: 29ca1f3059e96cd985178e727002814edb367e06


nltk (3.2.5-2) unstable; urgency=medium

  * New Maintainer. (Closes: #816509)
+ Set Maintainer to Debian Science team.
+ Add myself as an Uploader.
  * Point Vcs-* fields to Salsa.
  * Bump debhelper compat level to 11.
  * Update Standards-Version to 4.1.3, nothing to change.
  * lintian/source: Override debian-rules-sets-DEB_BUILD_OPTIONS.
The upstream tests require some files downloaded from internet, which
are not accessible while building this package due to Debian Policy.
Hence disabling test via this variable.


-- 
Best,

Bug#893377: RFS: taptempo/1.2.1-1 [ITP]

[Lumin]

Hi François,

On 31 March 2018 at 21:59, François Mazen  wrote:
>
> This program is useful to quickly find the tempo of a song.
> The idea is to type "taptempo" in a terminal, then hit enter key at
> each beat while hearing a song, and display the tempo.
>
> The targeted people are mainly musicians who need to transcribe music
> or play the song at the exact original tempo. The typical situation to
> use this software is when you are in a hurry and you don't have time to
> launch a big workstation like Ardour or Lmms in order to find the
> tempo.

Got it. Thank you for this explanation.

>
>> 8. When you have built the latest version of the modified package,
>> you could run lintian against it:
>>
>> lintian -EviI --pedantic .changes
>>
>> There generally shouldn't be any Error or Warning.
>
> I've fixed all the error and the lintian output should be clean.

You have done quite a good job making the package in a good shape,
and making the upstream very standard.

By the way I'm surprised that you have fixed all lintian outputs,
including the pedantic stuff. The pedantic items are only optional,
not what must be fixed. Errors and Warnings should be dealt with,
and some lintian Info can even pass if the maintainer has a good
reason.

In return everything's shining and in good shape :-)

> Let me know if it still require more work.

Nitpicking:

1. Please collapse the two lines in changelog into one. They refer to
the same thing.

-  * Initial debian package.
-  * Closes: #893306
+  * Initial debian package. (Closes: #893306)

2. there is still an autpkgtest problem:

autopkgtest [07:01:02]: test version: [---
spawn taptempo --version
couldn't execute "taptempo": no such file or directory
while executing
"spawn taptempo --version"
(file "/tmp/autopkgtest.C3pEq9/build.uWo/src/debian/tests/version" line 6)
autopkgtest [07:01:03]: test version: ---]
autopkgtest [07:01:03]: test version:  - - - - - - - - - - results - -
- - - - - - - -
version  FAIL non-zero exit status 1
autopkgtest [07:01:03]: test version:  - - - - - - - - - - stderr - -
- - - - - - - -
couldn't execute "taptempo": no such file or directory
while executing
"spawn taptempo --version"
(file "/tmp/autopkgtest.C3pEq9/build.uWo/src/debian/tests/version" line 6)

this can be fixed by the patch. It looks somewhat wired but we need it.

--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,2 +1,2 @@
 Tests: version, help, tempo
-Depends: expect
+Depends: expect, taptempo

The autopkgtest result after patched:

http://debomatic-amd64.debian.net/distribution#unstable/taptempo/1.3.0-1/autopkgtest

build result:

http://debomatic-amd64.debian.net/distribution#unstable/taptempo/1.3.0-1/buildlog

> Should I update this new package to the mentors website?

Yes, please fix the two problem mentioned above, and upload to mentors.

Thank you for you contribution to Debian, and have a good day.

Bug#894197: RFS: highwayhash/0~20180209-g14dedec-2

[Lumin]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: highwayhash
   Version : 0~20180209-g14dedec-2
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : science

  It builds those binary packages:

libhighwayhash-dev - Fast strong hash functions:
SipHash/HighwayHash (development)
 libhighwayhash0 - Fast strong hash functions: SipHash/HighwayHash (library)

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/h/highwayhash/highwayhash_0~20180209-g14dedec-2.dsc

  More information about hello can be obtained from

http://debomatic-amd64.debian.net/distribution#unstable/highwayhash/0~20180209-g14dedec-2/buildlog

  Changes since the last upload:

highwayhash (0~20180209-g14dedec-2) unstable; urgency=medium

  * Remove ppc64 from Architecture list as suggested by upstream.
+ https://github.com/google/highwayhash/issues/66
- Remove ppc64 symbols.
  * Collect symbols update from buildd for arm64 and ppc64el.
  * Upload to unstable.



-- 
Best,

Bug#893377: RFS: taptempo/1.2.1-1 [ITP]

[Lumin]

Hi François,

On 26 March 2018 at 19:56, François Mazen  wrote:
> I've manually changed the timestamp of the changelog file from the
> original repo, and I haven't check that the date was wrong. I can
> update the changelog file.

I've seen new commits in the repo. Let's assume it's the latest version
we would talk about. The following discussion will be based on
https://github.com/moleculext/taptempo

> The public key is published on the sks-keyservers network. Should I
> sent it to debian keyring or other keyserver?

I can retrieve the key now.

> Should I submit a new revision of the package (1.2.1-2) or re-upload
> with the current revision number (1.2.1-1)?

Not necessary. Further changes are needed, I'll check the git repo
directly since there is delay for mentor uploads.

Here are a list of problems I have found:

0. This program seems to be a terminal bpm meter. I'm not quite good
at music stuff, so I'd like to make sure:
0.1  For what purpose can this program be used?
0.2  Who's the targeted people of this program?

1. Upstream source should not contain a "debian" directory. However,
you seem to be the upstream author, so you have two choices:
(a) remove debian directory from source, and create another packaging
 repo where the debian directory is tracked.
(b) change source/format to 3.0 (naitive). In this way you can keep
 the debian directory in upstream source.

2. The standards version is quite out of date. You could lookup the update
checklist of Debian Policy[2], and update the standards version to the
latest one (version 4.1.3).

3. Debhelper compatibility version is old. Version 11 is preferred.

4. control: the long discription is somewhat short. Could you please
explain a bit more about the program's purpose and functionality?

5. changelog: It should close the ITP bug you've submitted. e.g. Close: #XXX

6. control: I'd recommend to add the Vcs-Git and Vcs-Browser field which
point to the packaging repository. And add a homepage which points
to the upstream homepage or simply the upstream repo.

7. Hardening flags[3] should be added to rules. i.e.
export DEB_BUILD_MAINT_OPTIONS   = hardening=+all

8. When you have built the latest version of the modified package,
you could run lintian against it:

lintian -EviI --pedantic .changes

There generally shouldn't be any Error or Warning.

9. changelog: please keep the version number aligned with upstream version.
or thing may get into a mess.

I'll check the git repo again once you have updated it. If you have any
questions about the above points, just feel free to ask

[1] https://www.debian.org/doc/manuals/maint-guide/index.en.html
[2] https://www.debian.org/doc/debian-policy/
[3] https://wiki.debian.org/Hardening

-- 
Best,

Bug#894071: RFS: gemmlowp/0~20180308-gf59a96b-1 [ITP]

[Lumin]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

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

 * Package name: gemmlowp
   Version : 0~20180308-gf59a96b-1
   Upstream Author : google
 * URL : https://github.com/google/gemmlowp
 * License : apache2
   Section : science

  It builds those binary packages:

libgemmlowp-dev - small self-contained low-precision GEMM library

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/g/gemmlowp/gemmlowp_0~20180308-gf59a96b-1.dsc

  More information about hello can be obtained from

http://debomatic-amd64.debian.net/distribution#experimental/gemmlowp/0~20180308-gf59a96b-1/buildlog

  Changes since the last upload:

gemmlowp (0~20180308-gf59a96b-1) experimental; urgency=medium

  * Initial release. (Closes: #848882)




-- 
Best,

Bug#894024: RFS: highwayhash/0~20180209-g14dedec-1

[Lumin]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: highwayhash
   Version : 0~20180209-g14dedec-1
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : science

  It builds those binary packages:

libhighwayhash-dev - Fast strong hash functions:
SipHash/HighwayHash (development)
 libhighwayhash0 - Fast strong hash functions: SipHash/HighwayHash (library)

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/h/highwayhash/highwayhash_0~20180209-g14dedec-1.dsc

  More information about hello can be obtained from

http://debomatic-amd64.debian.net/distribution#experimental/highwayhash/0~20180209-g14dedec-1/buildlog

Note, one more upload after this time is needed to collect symbols
update from buildd.

  Changes since the last upload:

highwayhash (0~20180209-g14dedec-1) experimental; urgency=medium

  * New upstream snapshot 0~20180209-g14dedec
  * Remove all patches since are included in this snapshot.
  * Refresh symbols for amd64.
  * Remove debian/highwayhash.3 which was already merged in upstream source.


-- 
Best,

Bug#893377: RFS: taptempo/1.2.1-1 [ITP]

[Lumin]

Control: owner -1 !
Control: tag -1 +moreinfo

Hi François,

Several questions about your package:

1. Why is the package on mentors newer than that on github repo?
Could you please keep the packaging repo up-to-date?

https://github.com/moleculext/taptempo

2. Where is your public key? no such key on keyserver.

86A5ABD6FFDB0A0C7F5057D34797FA721C351C9E

3. There are still many problems related to package, let's
discuss on that once we have a synced git repository
to talk about.


-- 
Best,

Bug#886827: RFS: youtube-dl-gui/0.4-1 [ITP]

[Lumin]

Hi Félix,

I'm sure youtube-dl is working when invoked from command line for
downloading an youtube video. However youtube-dl-gui doesn't work
with the same URL.

I got this from youtube-dl-gui's log, and it seems to be the reason why
youtube-dlg doesn't work for me:

[Sun Mar 25 07:35:30 2018] Traceback (most recent call last):
[Sun Mar 25 07:35:30 2018]   File "/usr/bin/youtube-dl", line 6, in 
[Sun Mar 25 07:35:30 2018] from pkg_resources import load_entry_point
[Sun Mar 25 07:35:30 2018]   File
"/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
3195, in 
[Sun Mar 25 07:35:30 2018] @_call_aside
[Sun Mar 25 07:35:30 2018]   File
"/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
3179, in _call_aside
[Sun Mar 25 07:35:30 2018] f(*args, **kwargs)
[Sun Mar 25 07:35:30 2018]   File
"/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
3208, in _initialize_master_working_set
[Sun Mar 25 07:35:30 2018] working_set = WorkingSet._build_master()
[Sun Mar 25 07:35:30 2018]   File
"/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
681, in _build_master
[Sun Mar 25 07:35:30 2018] ws.require(__requires__)
[Sun Mar 25 07:35:30 2018]   File
"/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
999, in require
[Sun Mar 25 07:35:30 2018] needed =
self.resolve(parse_requirements(requirements))
[Sun Mar 25 07:35:30 2018]   File
"/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
885, in resolve
[Sun Mar 25 07:35:30 2018] raise DistributionNotFound(req, requirers)
[Sun Mar 25 07:35:30 2018] pkg_resources.DistributionNotFound: The
'youtube-dl==2018.3.14' distribution was not found and is required by
the application

The root of problem turns to be clear if you take a look at the package
content of youtube-dl provided by debian:

$ dpkg -L youtube-dl
...
/usr/lib/python3/dist-packages/youtube_dl-2018.3.14.egg-info
...

It has been migrated to python3. So tt is impossible for youtube-dl-gui
to import any python2 resource of youtube-dl. This GUI package only
works when user have installed youtube-dl with python2 version of pip
or some other methods alike.

Unfortunately, I guess this package would get stuck before its
transition to python3. Unless there is a simple way to use
python3 version of youtube-dl from python2 version of gui.
I'm not sure whether it's possible since I didn't look into the code.

Regards,
Lumin.


On 22 February 2018 at 09:51, Félix Sipma <felix+deb...@gueux.org> wrote:
> On 2018-02-22 03:27+, Lumin wrote:
>> I built the package locally, but I did not get it working correctly
>> With a YouTube URL. It downloads nothing.
>> Could you please provide a url for test so I can make sure
>> it is working?
>>
>> I will look into this problem later.
>
> It definitely works here... Are you sure entered your urls, selected the 
> output
> format and directory, clicked "add", and then clicked "start"?



-- 
Best,

Bug#888859: RFS: iolang/2017.09.06+dfsg-1 [ITP]

[Lumin]

Control: owner -1 w...@debian.org

Hi,

I'm releasing the ownership of this bug since I'm not able to deal with
it due to work in real life.

Sorry for the inconvenience.


On 22 February 2018 at 16:05, Yangfl <mmyan...@gmail.com> wrote:
> Control: tags -1 - moreinfo
>
> On Thu, 15 Feb 2018 09:11:18 + Lumin <cdlumin...@gmail.com> wrote:
>> control: owner -1 !
>> control: tags -1 +moreinfo
>>
>> Hi Yangfl,
>
> Hi Lumin,
>
> Confused I haven't received your mail via BTS. Much thanks for your
> interest and willing to sponsor.
>
>> *  URL : http://www.iolang.com
>>   Are you sure this URL is correct?
>
> Sorry, this RFS header is copied from old ITP. The one in d/control should be
>
>> Thank you for your work. Here are some comments
>> on your package.
>>
>> * -dfsg: would you please explain what is removed
>>   from original source in README.source?
>
> d/copyright should have provided a list of removed files (see Files-Excluded).
>
> By the way, I have made a PR to upstream to remove ConvertUTF and it
> has accepted. The next release will not affected by this.
>
>> * please fix the following lintian I/W/E:
>>   (reproduce with debuild -S)
>>
>> P: iolang source: insane-line-length-in-source-file docs/js/jquery.js
>> line length is 517 characters (>512)
>> P: iolang source: source-contains-prebuilt-javascript-object
>> docs/js/jquery.js line length is 517 characters (>512)
>> N: jquery
>> O: iolang source: source-is-missing docs/js/jquery.js line length is
>> 517 characters (>512)
>> P: iolang source: source-contains-prebuilt-doxygen-documentation
>> addons/SGML/source/libsgml-1.1.4/docs/html/
>> I: iolang source: quilt-patch-missing-description
>> addons-fix-missing-depends.patch
>> I: iolang source: quilt-patch-missing-description addons-no-rpath.patch
>> I: iolang source: quilt-patch-missing-description
>> libs-fix-shlib-with-executable-stack.patch
>> I: iolang source: quilt-patch-missing-description libs-soname.patch
>> I: iolang source: quilt-patch-missing-description 
>> modules-fix-atk-libname.patch
>> I: iolang source: quilt-patch-missing-description
>> modules-fix-clutter-include-dirs.patch
>> I: iolang source: quilt-patch-missing-description
>> modules-fix-openssl-wrong-variable-names.patch
>> I: iolang source: quilt-patch-missing-description modules-fix-qdbm-path.patch
>> I: iolang source: quilt-patch-missing-description modules-mariadb.patch
>> I: iolang source: quilt-patch-missing-description no-sse.patch
>> I: iolang source: quilt-patch-missing-description no-static.patch
>> E: iolang source: debian-rules-is-dh_make-template
>> I: iolang source: testsuite-autopkgtest-missing
>>
>> * the package ships a copy of jquery.js, we should be able to use
>>   the one provided by libjs-jquery.
>
> Added deps on libjs-jquery. Source of jquery.js is now provided.
>
> Also move Flux resource files to /usr/share/ .
>
>> Your package was successfully built on debomatic-amd64,
>> http://debomatic-amd64.debian.net/distribution#unstable/iolang/2017.09.06+dfsg-1/buildlog
>>
>> I'll check copyright later.
>>
>> --
>> Best,
>>
>>



-- 
Best,

Bug#891922: RFS: you-get/0.4.1040-1 [ITP]

[Lumin]

On Sat, 3 Mar 2018 at 01:46 Alex Mestiashvili 
wrote:

>
>
>
> It would be interesting to see how this program is different from
> already existing tools like youtube-dl and cclive.
>
> Thank you!


I have noticed the existence of youtube-dl. However, the user may switch
to you-get when youtube-dl fails to work at some sites, such as Bilibili
(a popular Chinese danmaku video site).

cclive supports few site,compared to youtube-dl and you-get.

Danke.

> --
Best,

Bug#891922: RFS: you-get/0.4.1040-1 [ITP]

[Lumin]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "you-get"

 * Package name: you-get
   Version : 0.4.1040-1
   Upstream Author : Mort Yao
 * URL : https://github.com/soimort/you-get
 * License : MIT
   Section : utils

  It builds those binary packages:

you-get- command-line utility to download media contents from the Web

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

  https://mentors.debian.net/package/you-get


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

dget -x 
https://mentors.debian.net/debian/pool/main/y/you-get/you-get_0.4.1040-1.dsc

  More information about hello can be obtained from

http://debomatic-amd64.debian.net/distribution#unstable/you-get/0.4.1040-1/buildlog

  Changes since the last upload:

you-get (0.4.1040-1) unstable; urgency=medium

  * Initial release. (Closes: #891074)


-- 
Best,

Bug#886827: RFS: youtube-dl-gui/0.4-1 [ITP]

[Lumin]

On Fri, 16 Feb 2018 at 01:22 Félix Sipma  wrote:

>
> > This part seems unrelated to auto update functionality. Would you
> > mind splitting it to another patch?
>
> It is a part of the patch: youtube-dl-gui tries to download youtube-dl in
> 'youtubedl_path', and then launches "youtubedl_path/youtube-dl". The next
> version should be patch free, upstream agreed to add a build option to
> turn the
> update functionality off.


Got it.

>
> > Please provide an uploaded version of this package via mentors
> > so I can check it on debomatic :-)
> > (if you don't have access to debomatic)
>
> The version on mentors should be up to date, I updated it after every
> modification.
>

I built the package locally, but I did not get it working correctly
With a YouTube URL. It downloads nothing.
Could you please provide a url for test so I can make sure
it is working?

I will look into this problem later.
-- 
Best,

Bug#886827: RFS: youtube-dl-gui/0.4-1 [ITP]

[Lumin]

On 15 February 2018 at 15:33, Félix Sipma  wrote:

> I don't get the harm in having a little more verbose initial changelog, we're
> talking about 10 lines there, not a whole book... Anyway, I've just kept the
> attribution and a line mentioning the lack of python3 support.
>

>> OK. You can override it and leave a note in lintian-overrides file.
>
> I'd really prefer keeping the warning reported, so that adding the manpage in 
> not
> forgotten later :-).

OK.

 I: youtube-dl-gui: dependency-on-python-version-marked-for-end-of-life
 (Depends: python)
>>
>> I noticed that python3-wxgtk4.0 is in the NEW queue [1].
>> Do we have a chance to build on python3-wxgtk4.0 and
>> get rid of python2?
>>
>> [1] https://ftp-master.debian.org/new/wxpython4.0_4.0.1+dfsg-1.html
>
> Sorry, I don't have the resources to do the wxgtk3.0->4.0 migration myself, 
> but
> I'll see with upstream what can be done, I'll be happy to drop python2, too

One more problem:

146 diff --git a/youtube_dl_gui/optionsmanager.py
b/youtube_dl_gui/optionsmanager.py
147 index 794f590..baa6b83 100644
148 --- a/youtube_dl_gui/optionsmanager.py
149 +++ b/youtube_dl_gui/optionsmanager.py
150 @@ -276,7 +276,7 @@ class OptionsManager(object):
151  'username': '',
152  'password': '',
153  'video_password': '',
154 -'youtubedl_path': self.config_path,
155 +'youtubedl_path': '/usr/bin/',
156  'cmd_args': '',
157  'enable_log': True,
158  'log_time': True,

This part seems unrelated to auto update functionality. Would you
mind splitting it to another patch?

Please provide an uploaded version of this package via mentors
so I can check it on debomatic :-)
(if you don't have access to debomatic)


-- 
Best,

Bug#890379: RFS: python-jsonrpc/1.10.8-1 [ITP]

[Lumin]

Hi,

On 15 February 2018 at 13:52, Ghislain Vaillant  wrote:

>> 1. please fix the following copyright issue:

> I will update d/copyright accordingly.

>> 2. This package failed to build when python2 version of sphinx exists:
>
> I don't care to be honest.
>
> It builds fine on a clean chroot with the Python 3 version of Sphinx:

OK. Let's omit the failure in an unclean build environment.

@Gianfranco: Would you mind sponsoring this package after
Ghislain uploaded updated package to mentors?
I've checked several lists [1][2][3] and the package LGTM,
expect for the license issue mentioned above.

✔ control and rules in good shape
✔ debomatic build and tests successful

[1] devref section 7.5.1 Sponsoring packages
[2] https://wiki.debian.org/SponsorChecklist
[3] https://wiki.debian.org/LucaFalavigna/NEWChecklist

-- 
Best,

Bug#886827: Fwd: Bug#886827: RFS: youtube-dl-gui/0.4-1 [ITP]

[Lumin]

-- Forwarded message --
From: Lumin <cdlumin...@gmail.com>
Date: 15 February 2018 at 14:51
Subject: Re: Bug#886827: RFS: youtube-dl-gui/0.4-1 [ITP]
To: Félix Sipma <felix+deb...@gueux.org>


Hi,

On 15 February 2018 at 09:41, Félix Sipma <felix+deb...@gueux.org> wrote:

> Changelog: is there a problem with being more verbose? I like writing about
> specificities of a package and it's one of the places (with debian/rules) 
> where
> I did write a comment concerning python3 support (needs python3-wxgtk3.0)

Bug#888859: RFS: iolang/2017.09.06+dfsg-1 [ITP]

[Lumin]

control: owner -1 !
control: tags -1 +moreinfo

Hi Yangfl,

*  URL : http://www.iolang.com
  Are you sure this URL is correct?

Thank you for your work. Here are some comments
on your package.

* -dfsg: would you please explain what is removed
  from original source in README.source?

* please fix the following lintian I/W/E:
  (reproduce with debuild -S)

P: iolang source: insane-line-length-in-source-file docs/js/jquery.js
line length is 517 characters (>512)
P: iolang source: source-contains-prebuilt-javascript-object
docs/js/jquery.js line length is 517 characters (>512)
N: jquery
O: iolang source: source-is-missing docs/js/jquery.js line length is
517 characters (>512)
P: iolang source: source-contains-prebuilt-doxygen-documentation
addons/SGML/source/libsgml-1.1.4/docs/html/
I: iolang source: quilt-patch-missing-description
addons-fix-missing-depends.patch
I: iolang source: quilt-patch-missing-description addons-no-rpath.patch
I: iolang source: quilt-patch-missing-description
libs-fix-shlib-with-executable-stack.patch
I: iolang source: quilt-patch-missing-description libs-soname.patch
I: iolang source: quilt-patch-missing-description modules-fix-atk-libname.patch
I: iolang source: quilt-patch-missing-description
modules-fix-clutter-include-dirs.patch
I: iolang source: quilt-patch-missing-description
modules-fix-openssl-wrong-variable-names.patch
I: iolang source: quilt-patch-missing-description modules-fix-qdbm-path.patch
I: iolang source: quilt-patch-missing-description modules-mariadb.patch
I: iolang source: quilt-patch-missing-description no-sse.patch
I: iolang source: quilt-patch-missing-description no-static.patch
E: iolang source: debian-rules-is-dh_make-template
I: iolang source: testsuite-autopkgtest-missing

* the package ships a copy of jquery.js, we should be able to use
  the one provided by libjs-jquery.

Your package was successfully built on debomatic-amd64,
http://debomatic-amd64.debian.net/distribution#unstable/iolang/2017.09.06+dfsg-1/buildlog

I'll check copyright later.

-- 
Best,

Bug#890379: RFS: python-jsonrpc/1.10.8-1 [ITP]

[Lumin]

control: merge -1 880442
control: owner -1 !
control: tag -1 +moreinfo

Hi Ghislain,

Some comments on this package:

1. please fix the following copyright issue:
   (reproduce with $ licensecheck -r .)

./jsonrpc/six.py: MIT/X11 (BSD like)
   Copyright (c) 2010-2013 Benjamin Peterson

There is six.py. What's the relationship between it and python3-six?
My preliminary guess is that upstream just copied that file to their
project.

2. This package failed to build when python2 version of sphinx exists:

make[2]: Entering directory
'/home/lumin/packages/sponsor/python-jsonrpc-1.10.8/docs'
sphinx-build -b html -d _build/doctrees   source _build/html
Running Sphinx v1.6.7
making output directory...

Configuration error:
There is a programable error in your configuration file:

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/sphinx/config.py", line 157,
in __init__
execfile_(filename, config)
  File "/usr/lib/python2.7/dist-packages/sphinx/util/pycompat.py",
line 150, in execfile_
exec_(code, _globals)
  File "/usr/lib/python2.7/dist-packages/six.py", line 709, in exec_
exec("""exec _code_ in _globs_, _locs_""")
  File "", line 1, in 
  File "conf.py", line 109, in 
import sphinx_rtd_theme
ImportError: No module named sphinx_rtd_theme

make[2]: *** [Makefile:45: html] Error 1
make[2]: Leaving directory
'/home/lumin/packages/sponsor/python-jsonrpc-1.10.8/docs'
make[1]: *** [debian/rules:21: override_dh_auto_build] Error 2
make[1]: Leaving directory '/home/lumin/packages/sponsor/python-jsonrpc-1.10.8'
make: *** [debian/rules:9: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
debuild: fatal error at line 1152:
dpkg-buildpackage -rfakeroot -us -uc -ui -i failed


-- 
Best,

Bug#886827: RFS: youtube-dl-gui/0.4-1 [ITP]

[Lumin]

control: owner -1 !
control: tag -1 +moreinfo

Hi Félix,

Some comments on your package:

changelog
---

* One line is enough for the initial upload, e.g.
 "Initial release. (Closes: #753350)"

compat & control
-

* I'd recommend to use debhelper compat level 11
  since 10 is old.

* This package looks like a front-end of youtube-dl,
   why is "youtube-dl" in Recommends section
   instead of Depends section?

* Python2 faces its end of life. Does upstream support
  python3? see [1]

rules
---

You may need to add this to override_dh_auto_test target
if you bump debhelper compat to 11:

override_dh_auto_test:
ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
YOUR TEST STUFF
endif

lintian


Would you mind to fix the following: (lintian -EviI --pedantic)

W: youtube-dl-gui: binary-without-manpage usr/bin/youtube-dl-gui
I: youtube-dl-gui: dependency-on-python-version-marked-for-end-of-life
(Depends: python)
P: youtube-dl-gui: image-file-in-usr-lib
usr/lib/python2.7/dist-packages/youtube_dl_gui/data/pixmaps/arrow_down_32px.png

[1] https://www.debian.org/doc/packaging-manuals/python-policy/python3.html

-- 
Best,

Bug#889800: RFS: highwayhash/0~20180103-geeea446-2

[Lumin]

Package: sponsorship-requests
Severity: important

  Dear mentors,

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

 * Package name: highwayhash
   Version : 0~20180103-geeea446-2
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : science

  It builds those binary packages:

libhighwayhash-dev - Fast strong hash functions:
SipHash/HighwayHash (development)
 libhighwayhash0 - Fast strong hash functions: SipHash/HighwayHash (library)

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/h/highwayhash/highwayhash_0~20180103-geeea446-2.dsc

  More information about hello can be obtained from

http://debomatic-amd64.debian.net/distribution#experimental/highwayhash/0~20180103-geeea446-2/buildlog

  Changes since the last upload:


highwayhash (0~20180103-geeea446-2) experimental; urgency=medium

  * Cherry-pick upstream fix for ppc64.
+ up_add_file_update_makefile_for_ppc64_vsx.patch
  * Collect symbols update for arm64 and x32 from buildd.
Refresh symbols for amd64. (Closes: #877130)
  * Don't build anymore on architectures that are not supported by upstream.
  * Check DEB_BUILD_PROFILES on the overriden dh_auto_test target.
  * Fix package-uses-deprecated-source-override-location.
  * Override symbols-file-contains-debian-revision which is a false-positive.

-- 
Best,

Bug#887728: RFS: nvidia-cudnn/7.0.5~cuda9.0-1 [ITP / ppc64el help needed]

[Lumin]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: a...@debian.org pkg-nvidia-de...@lists.alioth.debian.org

Dear mentors,

  I am looking for a sponsor for my package "lua-moses"

 * Package name: nvidia-cudnn
   Version : 7.0.5~cuda9.0-1
   Upstream Author : NVIDIA
 * URL : https://developer.nvidia.com/cudnn
 * License : ***PROPRIETARY***
   Section : non-free/libs

  It builds those binary packages:

libcudnn7 - NVIDIA CUDA Deep Neural Network library (cuDNN)
libcudnn-dev - NVIDIA CUDA Deep Neural Network library (cuDNN), Header File

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

https://salsa.debian.org/lumin-guest/nvidia-cudnn

##NOTE##

  I didn't upload the package to debomatic-amd64, nor the mentors because the
  source package is too large to me (~660MB). My local amd64 build
with cowbuilder
  was successful.

##ppc64el HELP NEEDED##

  I have no resource to test the ppc64el build, so I need someone to
help me with
  the following steps:

  1. build on ppc64el to see if the rules is working for ppc64el
  2. update *.symbols.ppc64el, stripping the debian revision.

##LICENSE##

  Similar to nvidia-cuda-toolkit package.
  Two nvidia people that I contacted before are BCC'ed.
  To nvidia people: The license is shipped in debian/copyright, see
the git repo:
https://salsa.debian.org/lumin-guest/nvidia-cudnn

  Changes since the last upload:

nvidia-cudnn (7.0.5~cuda9.0-1) unstable; urgency=medium

  * Initial release. (Closes: #862524)


-- 
Best,

Bug#887699: RFS: lua-moses/1.6.1+git20170613-1 [ITP]

[Lumin]

Package: sponsorship-requests
Severity: wishlist

Note: The first time upload was rejected by ftpmaster due to
license issues. I have fixed them in this version.
This ITP package will fix an RC bug of another package
lua-torch-nn, because lua-moses was added as a new dependency
by upstream.

  Dear mentors,

  I am looking for a sponsor for my package "lua-moses"

 * Package name: lua-moses
   Version : 1.6.1+git20170613-1
   Upstream Author : https://github.com/Yonaba
 * URL : https://github.com/Yonaba/Moses
 * License : MIT
   Section : interpreters

  It builds those binary packages:

lua-moses  - Utility library for functional programming in Lua

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

  https://mentors.debian.net/package/lua-moses


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

dget -x 
https://mentors.debian.net/debian/pool/main/l/lua-moses/lua-moses_1.6.1+git20170613-1.dsc

  More information about hello can be obtained from

http://debomatic-amd64.debian.net/distribution#unstable/lua-moses/1.6.1+git20170613-1/buildlog

  Changes since the last upload:

lua-moses (1.6.1+git20170613-1) unstable; urgency=medium

  * Initial release. (Closes: #870124)

-- 
Best,

Bug#887683: RFS: highwayhash/0~20180103-geeea446-1 [RC/experimental]

[Lumin]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: highwayhash
   Version : 0~20180103-geeea446-1
   Upstream Author :
 * URL :
 * License :
   Section : science

  It builds those binary packages:

libhighwayhash-dev - Fast strong hash functions:
SipHash/HighwayHash (development)
 libhighwayhash0 - Fast strong hash functions: SipHash/HighwayHash (library)

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/h/highwayhash/highwayhash_0~20180103-geeea446-1.dsc

  More information about hello can be obtained from

http://debomatic-amd64.debian.net/distribution#experimental/highwayhash/0~20180103-geeea446-1/buildlog

  note, the lintian warning libhighwayhash0:
symbols-file-contains-debian-revision
  is a false positive.

  Changes since the last upload:

highwayhash (0~20180103-geeea446-1) experimental; urgency=medium

  * Import upstream snapshot eeea4463df1639c7ce271a1d0fdfa8ae5e81a49f .
  * Remove all patches because they were merged by upstream.
- makefile-disable-siptreehash-and-make-solib.patch
- makefile-target-install.patch
  * compat: Bump debhelper compat to 11
  * control: Add new B-D "rename" and Vcs-* fields
  * control: Add missing depends to dev package (Closes: #877207)
  * control: Bump Standards-Version to 4.1.3 (no change)
  * copyright: fix insecure-copyright-format-uri
  * rules: fix build and installation.
  * Symbols: refresh. (Closes: #877130)
  * Update my name.


-- 
Best,

Bug#870127: RFS: lua-moses/1.6.1+git20170613-1 -- [ITP] Utility library for functional programming in Lua

[Lumin]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "lua-moses"

 * Package name: lua-moses
   Version : 1.6.1+git20170613-1
   Upstream Author : Yonaba
 * URL :http://yonaba.github.io/Moses/
 * License : MIT
   Section : interpreters

  It builds those binary packages:

lua-moses  - Utility library for functional programming in Lua

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

  https://mentors.debian.net/package/lua-moses


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

dget -x 
https://mentors.debian.net/debian/pool/main/l/lua-moses/lua-moses_1.6.1+git20170613-1.dsc

  More information about hello can be obtained from

http://debomatic-amd64.debian.net/distribution#unstable/lua-moses/1.6.1+git20170613-1/buildlog

Note, this new packages FIXES an RC bug of another pacakge,
because that package added this package as a new dependency.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870029

  Changes since the last upload:

lua-moses (1.6.1+git20170613-1) unstable; urgency=medium

  * Initial release. (Closes: #870124)

Bug#870125:

[Lumin]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "lua-moses"

 * Package name: lua-moses
   Version : 1.6.1+git20170613-1
   Upstream Author : Yonaba
 * URL :http://yonaba.github.io/Moses/
 * License : MIT
   Section : interpreters

  It builds those binary packages:

lua-moses  - Utility library for functional programming in Lua

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

  https://mentors.debian.net/package/lua-moses


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

dget -x 
https://mentors.debian.net/debian/pool/main/l/lua-moses/lua-moses_1.6.1+git20170613-1.dsc

  More information about hello can be obtained from

http://debomatic-amd64.debian.net/distribution#unstable/lua-moses/1.6.1+git20170613-1/buildlog

Note, this new packages FIXES an RC bug of another pacakge,
because that package added this package as a new dependency.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870029

  Changes since the last upload:

lua-moses (1.6.1+git20170613-1) unstable; urgency=medium

  * Initial release. (Closes: #870124)

Bug#869664: RFS: ptpython/0.39~20170703-1 [ITP]

[Lumin]

Hi Andrey,

This package is aimed at experimental because I found
a problem by chance, when executing one of my
scripts. However the same problem won't occur when
using ipython3 or python3. So ipython3 cannot be simply
replaced by ptipython3 for me.

Due to that reason, I plan to move it to unstable if no
one complains about similar problems or other bugs.

https://github.com/jonathanslenders/ptpython/issues

~/g/w/a/digit-recognizer ❯❯❯ /usr/bin/ptipython3 mnist-th-convnet.py
[ .. omitted ... ]
Traceback (most recent call last):
  File "/usr/bin/ptpython3", line 11, in 
load_entry_point('ptpython==0.39', 'console_scripts', 'ptpython3')()
  File "/usr/lib/python3/dist-packages/ptpython/entry_points/run_ptpython.py",
line 55, in run
six.exec_(compile(open(a[''][0], "rb").read(), a[''][0], 'exec'))
  File "mnist-th-convnet.py", line 49, in 
net = Net()
  File "mnist-th-convnet.py", line 24, in __init__
super(Net, self).__init__()
NameError: name 'Net' is not defined


~/g/w/a/digit-recognizer ❯❯❯ /usr/bin/ipython3 mnist-th-convnet.py
[ .. omitted ... ]
-> Iter 1 | loss   2.196 | Bch Train Accu 0.28
-> Iter 2 | loss   1.967 | Bch Train Accu 0.47
-> Iter 3 | loss   1.853 | Bch Train Accu 0.53


On 25 July 2017 at 13:23, Andrey Rahmatullin <w...@debian.org> wrote:
> Why is this aimed at experimental?
>
> --
> WBR, wRAR



-- 
Best,
Lumin

Bug#869664: RFS: ptpython/0.39~20170703-1 [ITP]

[Lumin]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

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

 * Package name: ptpython
   Version : 0.39~20170703-1
   Upstream Author : jonathanslenders
 * URL : https://github.com/jonathanslenders/ptpython
 * License : BSD-3-Clause
   Section : python

  It builds those binary packages:

ptpython3  - Better Python 3 REPL
 python3-ptpython - Better Python REPL (python3)

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

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/p/ptpython/ptpython_0.39~20170703-1.dsc

http://debomatic-amd64.debian.net/distribution#experimental/ptpython/0.39~20170703-1/buildlog

  Changes since the last upload:

ptpython (0.39~20170703-1) experimental; urgency=medium

  * Initial release. (Closes: #869534)

Bug#849273: RFS: gemmlowp/0~20170407-g719389f-1 [ITP]

[Lumin]

Hi,

On 16 June 2017 at 04:33, Ying-Chun Liu (PaulLiu)  wrote:
> I've reviewed your package. The package looks quite good to me.
> The only thing missing is the README.source
> https://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource

Updated the package and uploaded to mentors.

https://mentors.debian.net/debian/pool/main/g/gemmlowp/gemmlowp_0~20170609-g36ffd29-1.dsc

> The orig.tar.gz seems to be repacked from upstream git repo.
> Please mention the steps on how you create the orig.tar.gz
> Like you git clone it. And re-tar it, exclude some directories like .git.

The orig.tar.gz file is created manually with this command

  git archive HASH | gzip > xxx.orig.tar.gz

> Or, provide a way to generate the orig.tar.gz by debian/rules
> get-orig-source

Thank you for this snippet, I found many rules file ships such a part
in its rules file, but it will occupy half of the rules file if I put it in.
I described how to make the orig.tar.gz file in README.Source.

Is this acceptable?


BTW, concerining TensorFlow:

gemmlowp is likely the last dependency package to be uploaded.
TensorFlow upstream has cmake build scripts, but those scripts
will download many other dependency source packages and
compile them instead of using the pre-compiled ones provided
by distribution. There is a feature request about this in the
upstream issue list which is still open.

Bug#864271: [Pkg-protobuf-devel] Bug#864271: RFS: protobuf/3.3.1-0.1 [NMU]

[Lumin]

Hi GCS,

Thank you for the quick reply.

On 6 June 2017 at 10:06, László Böszörményi (GCS)  wrote:
>> Clarification-moreinfo:
>>   this tag is for protbuf maintainers to approve this NMU.
>  You misspelled the package name and the tag as well, among other things.

Sorry for the typo, I fixed that tag via control several hours ago.

> Upload sponsorship is for packages you maintain or heavily outdated
> with unresponsive maintainers. I do not see this scenario and the NMU
> is a NACK from me.

Indeed, that's why the [NMU] and "moreinfo" tags are added.

>>   * Bump ABI version to 13, renaming lib packages.
>  I'm not near to any Linux box at at the moment, just a question: did
> you check any possible reverse dependency? Did you check the GCC 7
> build issue or adding the Ruby bindings?
> In short, why is the rush and without contacting us first, its
> maintainers, you want to NMU it? Especially with mistakes like you add
> the changelog entry with a patch - grrr!

I intent to ping you maintainers about a package update since there
is a new upstream version available and a patch for ruby package available.

I didn't do the things you listed but I really checked the bug list
before sending out the ping mail. My original intention is that, if you
guys really had a plan to update this package, I can continue to
help more about it.

Sorry if the "RFS/NMU" keywords make you unhappy. But a basically
working and compiling package is better than simple a word in mail
  "how about we update the package"

This thread is indeed the start of contacting you, and such
an RFS with "moreinfo" and "NMU" is safe from being uploaded
accidentally.

Bug#864271: RFS: protobuf/3.3.1-0.1 [NMU]

[Lumin]

Package: sponsorship-requests
Severity: normal
Tags: morinfo
X-Debbugs-CC: pkg-protobuf-de...@lists.alioth.debian.org

Clarification-moreinfo:
  this tag is for protbuf maintainers to approve this NMU.

  Dear mentors,

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

 * Package name: protobuf
   Version : 3.3.1-0.1
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : devel

  It builds those binary packages:

libprotobuf-dev - protocol buffers C++ library (development files)
 libprotobuf-java - Java bindings for protocol buffers
 libprotobuf-lite13 - protocol buffers C++ library (lite version)
 libprotobuf13 - protocol buffers C++ library
 libprotoc-dev - protocol buffers compiler library (development files)
 libprotoc13 - protocol buffers compiler library
 protobuf-compiler - compiler for protocol buffer definition files
 python-protobuf - Python bindings for protocol buffers
 python3-protobuf - Python 3 bindings for protocol buffers

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

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

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

dget -x 
http://debomatic-amd64.debian.net/debomatic/experimental/pool/protobuf_3.3.1-0.1/protobuf_3.3.1-0.1.dsc

  More information about hello can be obtained from

http://debomatic-amd64.debian.net/distribution#experimental/protobuf/3.3.1-0.1/buildlog

  Changes since the last upload:

protobuf (3.3.1-0.1) experimental; urgency=medium

  * Non-maintainer upload.
  * New upstream release.
  * Replace Build-Deps google-mock and libgtest-dev with googletest.
Both google-mock and libgtest-dev are stub packages now.
+ Update gmock and gtest source path in rules.
  * Remove patches included in upstream code:
- Restore-New-Callback-into-google-protobuf-namespace.patch
- expect_death.patch
- java-test-scope.patch
- python3_long_fix.patch
- misleading-indentation.patch (Not merged but the bug is fixed)
  * Refresh remaining patches.
  * Bump ABI version to 13, renaming lib packages.

The package at mentors is not the latest, please use the debomatic dsc link.
The whole patchset for packaging update is attached.


3.0.0-9_to_3.3.1-0.1_patches.tar.gz
Description: GNU Zip compressed data

Bug#863229: RFS: lua-torch-cutorch/0~20170511-g92e9c08-1

[Lumin]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "lua-torch-cutorch"

 * Package name: lua-torch-cutorch
   Version : 0~20170511-g92e9c08-1
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : science

  It builds those binary packages:

libtorch-thc - libTHC.so for Torch framework (library)
 libtorch-thc-dev - libTHC.so for Torch framework (development)
 lua-torch-cutorch - CUDA backend for Torch framework

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

  https://mentors.debian.net/package/lua-torch-cutorch


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

dget -x 
https://mentors.debian.net/debian/pool/contrib/l/lua-torch-cutorch/lua-torch-cutorch_0~20170511-g92e9c08-1.dsc

  More information about hello can be obtained from

http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-cutorch/0~20170511-g92e9c08-1/buildlog

  Changes since the last upload:

lua-torch-cutorch (0~20170511-g92e9c08-1) experimental; urgency=medium

  * Import upstream snapshot.

Note, please do *amd64* instead of source upload since this is a
contrib package.

Bug#833193: RFS: chapel/1.15-1 [ITP]

[lumin]

On Fri, 2017-05-12 at 20:41 +, Ben Albrecht wrote:
> 
> We understand that Debian plans to upgrade to Python 3. We're not
> intending to install user-visible Python scripts or modules. The
> Python code that we use is used internally by our compiler and build
> scripts. In this case, is it necessary for us to patch all the Python
> code shebangs to point to /usr/bin/python3? Note that upstream would
> not accept this change.
> 

Since the python scripts are for internal use, I think it's ok not
to provide the python3 version.

Bug#833193: RFS: chapel/1.15-1 [ITP]

[Lumin]

Hi Ben,

> We do install the Chapel modules and runtime to versioned directories
> like this:
>
> /usr/share/chapel/1.15/modules etc
>
> The documentation is installed to
>
>  /usr/share/doc/chapel/1.15/rst etc
>
> Is it obviously better in your opinion to use
>
>  /usr/share/chapel-1.15/modules
>
> e.g.? If so, can you say why?

This way users will not be able to install 2 different versions of chapel
at the same time. For example, chapel/1.15 package will conflict
with chapel/1.16 on some standard files e.g.:

  /usr/share/doc/chapel/changelog.Debian.gz  (in chapel/1.15)
  /usr/share/doc/chapel/changelog.Debian.gz  (in chapel/1.16)

If you really plan to provide room for users to install multiple versions
at the same time, I'd suggest you change the binary package name
from chapel -> chapel-1.15 , this does not affect your

  /usr/share/chapel

directory. That is to say, you name the binary package as chapel-1.15
and the docs will be installed to /usr/share/doc/chapel-1.15
(/usr/share/doc/)
and (/usr/share/chapel) is controlled by yourself.


> The upstream project supports both Python 2.7 and Python 3.
> Would it be sufficient to depend on Python >= 2.7?
> I don't think it would make sense to update the scripts to
> have a Python 3 shebang (like #!/usr/bin/env python3).
> Do we assume that /usr/bin/env python returns a python 3 in
> some cases?

Debian's Python Policy:
https://www.debian.org/doc/packaging-manuals/python-policy/ch-python3.html

A python2.7 package "python-*" may install files under this directory
/usr/lib/python2.7/xxx

while a Python3 package "python3-*" may install files under a
different directory
/usr/lib/python3/xxx

This does not require changing the first line of python code. My point is
that providing another package that supports python3 and install stuff to
one of python3's search path.


Thank you for working on it!