Bug#902284: Translated Code of Conduct in Simplified Chinese

[Lumin]

On Sun, Jun 24, 2018 at 02:53:08PM +, Yanhao Mo wrote:
> On Sun 06/24 13:51, Lumin wrote:
> > [2] 
> > https://salsa.debian.org/chinese-team/fortunes-zh/blob/master/foss.d/code_of_conduct.cookie
> 
> Line 39, "由其" should be "尤其". Others look good to me.
> 
> -- 
> Yanhao Mo

Fixed, and thank you for proofreading it.

https://salsa.debian.org/chinese-team/fortunes-zh/commit/c5c4a5f151d797df2f1641b7c352f3f38e4cac14

Bug#902284: Translated Code of Conduct in Simplified Chinese

[Lumin]

Package: www.debian.org
Severity: wishlist
X-Debbugs-CC: 073p...@gmail.com, debian-l10n-chin...@lists.debian.org

I've translated Debian's code of conduct[1] into Simplified Chinese.
The translation is available here[2] in fortune format.

Can someone check the translation? Thanks in advance!

[1] https://www.debian.org/code_of_conduct
[2] 
https://salsa.debian.org/chinese-team/fortunes-zh/blob/master/foss.d/code_of_conduct.cookie


signature.asc
Description: PGP signature

Bug#863507: [numba/armel,armhf] tests broken

[Lumin]

control: found -1 0.37.0-1
control: forwarded -1 https://github.com/numba/numba/issues/3053

Bug#863508: [numba/armel] LLVM error duing sphinx build

[Lumin]

control: retitle -1 [numba/armel] LLVM Error during sphinx build
control: found -1 0.37.0-1
control: forwarded -1 https://github.com/numba/numba/issues/3052

This problem didn't appear in armhf/0.37.0-1

Bug#863509: [numba/mips,mipsel] bus error during test

[Lumin]

control: forwarded -1 https://github.com/numba/numba/issues/3051
control: retitle -1 [numba/mips,mipsel] Bus Error at test_sum
control: found 0.37.0-1

Bug#863511: [numba/ppc64el] segfault

[Lumin]

control: forwarded -1 https://github.com/numba/numba/issues/3050

still exists in 0.37.0

Bug#863512: numba/x390x: segfault

[Lumin]

numba 0.37.0-1 

https://github.com/numba/numba/issues/3049

https://buildd.debian.org/status/fetch.php?pkg=numba=s390x=0.37.0-1=1521778366=0


= test session starts ==
platform linux2 -- Python 2.7.14+, pytest-3.3.2, py-1.5.2, pluggy-0.6.0 -- 
/usr/bin/python2.7
cachedir: ../../../.cache
rootdir: /<>, inifile:
collecting ... collected 6836 items

numba/tests/test_alignment.py::TestAlignment::test_record_alignment PASSED [  
0%]
numba/tests/test_alignment.py::TestAlignment::test_record_misaligned PASSED [  
0%]
numba/tests/test_annotations.py::TestAnnotation::test_exercise_code_path 
SKIPPED [  0%]
numba/tests/test_annotations.py::TestAnnotation::test_exercise_code_path_with_lifted_loop
 SKIPPED [  0%]
numba/tests/test_annotations.py::TestAnnotation::test_html_output_with_lifted_loop
 SKIPPED [  0%]
numba/tests/test_api.py::TestNumbaModule::test_numba_module PASSED   [  0%]
numba/tests/test_array_analysis.py::TestEquivSet::test_insert_equiv PASSED [  
0%]
numba/tests/test_array_analysis.py::TestEquivSet::test_intersect PASSED  [  0%]
numba/tests/test_array_analysis.py::TestArrayAnalysis::test_base_cases FAILED [ 
 0%]
numba/tests/test_array_analysis.py::TestArrayAnalysis::test_misc Segmentation 
fault
E: pybuild pybuild:330: test: plugin custom failed with: exit code=139: cd 
/<>/.pybuild/cpython2_2.7_numba/build && python2.7 -Wd -m pytest 
numba/tests -v -rs
dh_auto_test: pybuild --test --test-pytest -i python{version} -p 2.7 returned 
exit code 13
make[1]: Leaving directory '/<>'
   create-stamp debian/debhelper-build-stamp

Bug#901377: ping (was: Re: skimage: FTBFS and Debci failure with NumPy 1.14)

[Lumin]

Dear skimage maintainer,

Briefly speaking, we plan to team-upload skimage (= 0.14.0) to resolve
this RC bug if the original maintainers allows us to do so. We'll try
to fix this after one week if the original maintainers didn't take action.

skimage failed to build from source since numpy (>= 1.14) was uploaded
to Debian unstable, and the cause of the trouble is exactly numpy api
changes. In upstream repo, there are several commits that adapts the
source to the api changes but they don't apply to Debian's source 
without change. So I think the most efficient way is to import 0.14.0 .

Please tell us if we can fix this RC by importing skimage (= 0.14.0).
Thanks.


signature.asc
Description: PGP signature

Bug#901377: skimage: FTBFS and Debci failure with NumPy 1.14

[Lumin]

> Since the recent upload of python-numpy on 2018-05-05, skimage has been 
> failing its autopkgtests [1] and has now also started to FTBFS in 
> unstable [2] with several errors similar to the following:

I see some changes adapting numpy 1.14 api change at upstream repo,
however they doesn't apply without change. Maybe we'd better wait
for the maintainer to upload skimage 0.14, which was updated for
numpy 1.14 api change.

Bug#901383: whalebuilder is broken after the ruby upgrade

[Lumin]

Package: whalebuilder
Version: 0.6
Severity: serious
Justification: functionality totally broken

~/p/skimage.pkg ❯❯❯ whalebuilder build debdev ./skimage_0.13.1-3.dsc
Traceback (most recent call last):
13: from /usr/bin/whalebuilder:331:in `'
12: from /usr/lib/ruby/2.5.0/tmpdir.rb:89:in `mktmpdir'
11: from /usr/bin/whalebuilder:338:in `block in '
10: from /usr/lib/ruby/vendor_ruby/gpgme/crypto.rb:311:in `verify'
 9: from /usr/lib/ruby/vendor_ruby/gpgme/ctx.rb:79:in `new'
 8: from /usr/lib/ruby/vendor_ruby/gpgme/crypto.rb:313:in `block in 
verify'
 7: from /usr/lib/ruby/vendor_ruby/gpgme/crypto.rb:313:in `each'
 6: from /usr/lib/ruby/vendor_ruby/gpgme/crypto.rb:314:in `block (2 
levels) in verify'
 5: from /usr/bin/whalebuilder:339:in `block (2 levels) in '
 4: from /usr/lib/ruby/vendor_ruby/gpgme/signature.rb:81:in `to_s'
 3: from /usr/lib/ruby/vendor_ruby/gpgme/signature.rb:42:in `from'
 2: from /usr/lib/ruby/vendor_ruby/gpgme/ctx.rb:79:in `new'
 1: from /usr/lib/ruby/vendor_ruby/gpgme/signature.rb:43:in `block in 
from'
/usr/lib/ruby/vendor_ruby/gpgme/ctx.rb:333:in `get_key': EOFError (EOFError)



ruby/unstable,unstable,now 1:2.5.1 amd64 [installed,automatic]
ruby-gpgme/unstable,unstable,now 2.0.16-1+b1 amd64 [installed,automatic]

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#901231: ITP: python-thinc -- Practical Machine Learning for NLP in Python [spaCy deps]

[Lumin]

Package: wnpp
Severity: wishlist
Owner: lumin 

* Package name: python-thinc
  Version : x.y.z
  Upstream Author : Name 
* URL : http://www.example.org/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Programming Lang: python
  Description : Practical Machine Learning for NLP in Python

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

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#901201: ITP: python-plac -- Smartest command line arguments parser in the world [spaCy deps]

[Lumin]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 

* Package name: python-plac
  Version : x.y.z
  Upstream Author : Name 
* URL : http://www.example.org/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : Smartest command line arguments parser in the world

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

Bug#896295: Tensorflow is missing

[Lumin]

Hello Debian-Science folks,

Please feel free to CC me if you need any input about deep learning.

> From: Andreas Tille
> the description says:
> 
>  ...  Alternatively, Keras could run on Google's
>  TensorFlow (not yet available in Debian, but coming up).
> 
> Is there some estimated time frame to package TensorFlow?

No estimated time frame for it. TensorFlow provides bazel build for
linux and cmake build for windows.  Bazel itself is blocking for years,
and a DD, Paul Liu, who worked on it in the past had said that it was
hard to deal with. I guess the bazel build system is still blocking
currently.
 
> If not please try to deactivate this alternative since the package does
> not work as this bug report explains.

I'd suggest patching upstream source to use Theano as the default
backend, and comment it clearly in the descriptions.

> From: Stephen Sinclair
> Regarding Tensorflow packaging I do not know, someone on debian-science
> mentioned difficulties with its build system. I do hope these are
> resolvable but it seems to be a big issue.

That so-called "someone" was me, actually. Bazel build is actually a big
issue, and I have no plan to patch the windows cmake build in a
reasonable time frame.

You may have found that Debian-team holds a tensorflow repo on Salsa,
but that's merely an old copy of upstream code.
https://salsa.debian.org/science-team/tensorflow

I'm currently maintaing several TensorFlow dependencies. Hope that
They will be helpful sometime in the future.

farmhash
gemmlowp
highwayhash

The full list of dependency can be found in the third_part directory
of tensorflow source.

Bug#901026: Inappropriate cookies found in fortunes-zh

[Lumin]

Package: fortunes-zh
Version: 2.8
Severity: severe
Justification: really inappropriate content found in cookie files.

I'm really sorry that I overlooked some really inappropriate contents
in recently imported joke cookie file.

Some offensive cookies are included in fortunes-zh 2.8, especially
the one which starts with "有个妈妈对小女孩说".

I'm removing those cookies ASAP.

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#900977: ITP: python-murmurhash -- Cython bindings for MurmurHash2 [spaCy deps]

[Lumin]

Package: wnpp
Severity: wishlist
Owner: lumin 

* Package name: python-murmurhash
  Version : 0.28.0
  Upstream Author : Matthew Honnibal
* URL : https://github.com/explosion/murmurhash
* License : MIT
  Programming Lang: python(cython)
  Description : Cython bindings for MurmurHash2

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

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#900945: ITP: python-preshed -- Cython Hash Table for Pre-Hashed Keys [spaCy dependency]

[Lumin]

Package: wnpp
Severity: wishlist
Owner: lumin 

* Package name: python-preshed
  Version : 1.0.0
  Upstream Author : Matthew Honnibal
* URL :  https://github.com/explosion/preshed
* License : MIT
  Programming Lang: python(cython)
  Description : Cython Hash Table for Pre-Hashed Keys

preshed is one of spacy's dependencies:

   [✓]  cython>=0.24,<0.28.0
   [✓]  pathlib
   [✓]  numpy>=1.7
   [*]  cymem>=1.30,<1.32 # another ITP/RFS
-> [*]  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

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#900941: ITP: python-cymem -- Cython Memory Helper [SpaCy dependency]

[Lumin]

Package: wnpp
Severity: wishlist
Owner: lumin 

* Package name: python-cymem
  Version : 1.31.2
  Upstream Author : Matthew Honnibal
* URL : https://github.com/explosion/cymem/
* License : MIT
  Programming Lang: Python(Cython)
  Description : Cython Memory Helper

cymem is one of spacy's dependencies:

   [✓]  cython>=0.24,<0.28.0
   [✓]  pathlib
   [✓]  numpy>=1.7
-> [*]  cymem>=1.30,<1.32
   [ ]  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

Bug#900477: Rebase the MIPS patch to upstream master

[Lumin]

control: tags -1 +patch
control: noowner -1

Done.

https://github.com/JuliaLang/openlibm/pull/152#issuecomment-394227619

Git-format patch is attached.
From feabc70eccb180dd09a2ceee27d517bbb713d7a5 Mon Sep 17 00:00:00 2001
From: Mo Zhou 
Date: Mon, 4 Jun 2018 03:50:46 +
Subject: [PATCH 3/3] patches: Rebase MIPS patch to upstream master

---
 debian/patches/add-mips-support.patch | 41 ++-
 1 file changed, 9 insertions(+), 32 deletions(-)

diff --git a/debian/patches/add-mips-support.patch b/debian/patches/add-mips-support.patch
index dcfb413..b9c88ae 100644
--- a/debian/patches/add-mips-support.patch
+++ b/debian/patches/add-mips-support.patch
@@ -5,7 +5,7 @@ Author: Radovan Birdic 
 Last-Update: 2017-01-24
 --- a/Make.inc
 +++ b/Make.inc
-@@ -92,6 +92,10 @@
+@@ -68,6 +68,10 @@ ifeq ($(ARCH),x86_64)
  override ARCH := amd64
  endif
  
@@ -16,20 +16,15 @@ Last-Update: 2017-01-24
  # If CFLAGS does not contain a -O optimization flag, default to -O3
  ifeq ($(findstring -O,$(CFLAGS)),)
  CFLAGS_add += -O3
 a/Makefile
-+++ b/Makefile
-@@ -4,9 +4,11 @@
- SUBDIRS = src $(ARCH) bsdsrc
- ifneq ($(ARCH), arm)
- ifneq ($(ARCH), powerpc)
-+ifneq ($(ARCH), mips)
- SUBDIRS += ld80
- endif
- endif
-+endif
+@@ -120,7 +124,7 @@ SFLAGS_add  += $(SFLAGS_arch)
+ LDFLAGS_add += $(LDFLAGS_arch)
  
- define INC_template
- TEST=test
+ CFLAGS_add += -std=c99 -Wall -I$(OPENLIBM_HOME) -I$(OPENLIBM_HOME)/include -I$(OPENLIBM_HOME)/$(ARCH) -I$(OPENLIBM_HOME)/src -DASSEMBLER -D__BSD_VISIBLE -Wno-implicit-function-declaration
+-ifneq ($(filter $(ARCH),i387 amd64 powerpc),)
++ifneq ($(filter $(ARCH),i387 amd64 powerpc mips),)
+ CFLAGS_add += -I$(OPENLIBM_HOME)/ld80
+ else
+ ifneq ($(filter $(ARCH),aarch64),)
 --- a/include/openlibm_fenv.h
 +++ b/include/openlibm_fenv.h
 @@ -10,6 +10,8 @@
@@ -395,24 +390,6 @@ Last-Update: 2017-01-24
 +extern inline int fedisableexcept(int __mask);
 +extern inline int fegetexcept(void);
 +
 a/src/Make.files
-+++ b/src/Make.files
-@@ -38,6 +38,7 @@
- 
- ifneq ($(ARCH), arm)
- ifneq ($(ARCH), powerpc)
-+ifneq ($(ARCH), mips)
- # C99 long double functions
- $(CUR_SRCS) +=	s_copysignl.c s_fabsl.c s_llrintl.c s_lrintl.c s_modfl.c
- 
-@@ -58,6 +59,7 @@
- 	s_clogl.c s_ctanhl.c s_ccosl.c s_cbrtl.c
- endif
- endif
-+endif
- 
- # C99 complex functions
- $(CUR_SRCS) +=	s_ccosh.c s_ccoshf.c s_cexp.c s_cexpf.c \
 --- a/src/fpmath.h
 +++ b/src/fpmath.h
 @@ -39,6 +39,8 @@
-- 
2.17.1



signature.asc
Description: PGP signature

Bug#900667: fcitx automatically resets X keyboard layout

[Lumin]

Package: fcitx
Version: 1:4.2.9.6-2
Severity: normal

My locale settings is en_US[default], de_DE, zh_CN.
The default X11 layouts under this locale setting is

> /etc ❯❯❯ sudo localectl
>System Locale: LANG=en_US.UTF-8
>VC Keymap: us
>   X11 Layout: us,de
>  X11 Variant: ,

Overriding the layout setting with the following command works as
expected:

setxkbmap -layout de

However this layout will be overriden again by fcitx, into "us,de".
This is very annoying since de layout is basically different from
us layout.

My X environment is based on dwm, so there is only fcitx that is
suspicious.

Bug#900665: Remote access is broken when the default shell is non-POSIX shell

[Lumin]

Package: deepin-terminal
Version: 3.0.0+ds-1
Severity: important
Justification: conditionally broken functionality

deepin-terminal's remote access functionality is broken when the
default user shell is not POSIX-compliant, e.g. fish shell.

> set: Warning: $PATH entry "/home/linuxbrew/.linuxbrew/bin" is not valid (No 
> such file or directory)
> fish: Unsupported use of '&&'. In fish, please use 'COMMAND; and COMMAND'.
> echo Welcome to Deepin Terminal, please make sure that rz and sz commands 
> have been installed in the server before right clicking to upload and 
> download files. && exec $SHELL -l
 
 Apart from that, the warning about "/home/linuxbrew/.linuxbrew/bin" is
 a false positive, which means a problem lies in the upstream script.

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.

Bug#900644: Missing runtime depends: zssh

[Lumin]

Package: deepin-terminal
Version: 3.0.0+ds-1
Severity: normal

See debian/patches/0001-..., /usr/bin/zssh is used, but the
corresponding package didn't appear in the runtime depends list.

Bug#900635: deepin-menu doesn't work

[Lumin]

Package: deepin-menu
Version: 3.3.5-1
Severity: important

Dear maintainer,

Deepin-menu doesn't launch from deepin-terminal. Both "settings" and
"about" dialogs of deepin-terminal does not appear.

There is no debug option for deepin-terminal. How should I look into this?

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.

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#900547: Acknowledgement ([zh_CN] translation needs to be polished)

[Lumin]

control: tag -1 +patch

the patch was pushed to the master branch to the forked repo

  https://salsa.debian.org/chinese-team/dpkg


signature.asc
Description: PGP signature

Bug#900547: [zh_CN] translation needs to be polished

[Lumin]

Package: dpkg
Version: 1.19.0.5+b1
Severity: wishlist
control: owner -1 !

I'm the zh_CN programs translator. Some translation flaws were found
recently, for instance,

  po/zh_CN.po
  2232:msgstr "  已解包 %.250s，但仍未配置。\n"

Such translation is correct, but not good enough ...
Please let me own this bug so that I won't forget this.

BTW, for a long time (> half year) I haven't touched the zh_CN
translation, and Alioth was replaced by Salsa, so what's the preferred
translation update channel? Patch via BTS, or merge request on Salsa?

Bug#900477: Rebase the MIPS patch to upstream master

[Lumin]

Package: libopenlibm2
Version: 0.5.6+dfsg-1
Severity: normal
Control: owner -1 !

I've got the access to the MIPS porter.

Bug#900474: Fix doc installation path

[Lumin]

Package: libgemmlowp-dev
Version: 0~20180308-gf59a96b-1
Severity: normal

/usr/share/doc/gemmlowp-dev
/usr/share/doc/gemmlowp-dev/meta
/usr/share/doc/gemmlowp-dev/meta/README
/usr/share/doc/libgemmlowp-dev

Bug#900472: Fails to build on several architectures

[Lumin]

Package: libgemmlowp-dev
Version: 0~20180308-gf59a96b-1
Severity: normal

As reported to upstream
https://github.com/google/gemmlowp/issues/136

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#888233: ITA: ujson -- ultra fast JSON encoder and decoder for Python 2/3

[Lumin]

control: retitle -1 ITA: ujson -- ultra fast JSON encoder and decoder for 
Python 2/3
control: owner -1 !

Bug#900252: Gnome hangs when switching keyboard layout

[Lumin]

Package: gnome-shell
Version: 3.28.2-1
Severity: important

I have two keyboard layouts, English (US) and German (DE), which are
configured via gnome control center -> region and language -> input
sources.

When switching the keyboard layout between English and German,
the gnome shell will hang at a small probability. I don't know
how to manually trigger that, but it happens occasionally.

This problem should be set to imporant because it may be annoying for
multi-lingual users.

Bug#900251: Please don't compress the mutt examples

[Lumin]

Package: mutt
Version: 1.10.0-1
Severity: important

Dear Mutt maintainers,

Please don't compress the mutt config examples, because I guess some
users have directly sourced these files in their personal config files.
At least I did so.

After upgrading from mutt 1.9.5 to 1.10.0, some files turned into
compressed format, e.g.

  /usr/share/doc/mutt/examples/gpg.rc  -->  gpg.rc.gz

It broke my mutt config file. So I have to make corresponding changes:

   # Import GnuPG
  -source /usr/share/doc/mutt/examples/gpg.rc
  +source "gzip -c -d /usr/share/doc/mutt/examples/gpg.rc |"

Thanks.

Bug#900183: Upstream CUDA bug

[Lumin]

Package: nvidia-cuda-toolkit
Version: 9.1.85-4+b1
Severity: important

CUDA 9.1 has a bug which causes caffe-contrib to fail the unit tests.

  https://github.com/BVLC/caffe/issues/6164

There is applicable workaround for caffe-contrib before uploading CUDA 9.2
to the archive.

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#900098: nvidia-cuda-toolkit 9?

[Lumin]

Package: nvidia-cuda-toolkit
Version: 9.1.85-4+b1
Severity: wishlist

Forwarding user's Request For Backport to the BTS.

On Thu, May 24, 2018 at 08:40:35AM -0700, Andres Cimmarusti wrote:
> I would also be interested in having this in backports.
> 
> Copying the CUDA Debian maintainers
> 
> On Mon, Feb 5, 2018 at 4:43 AM, Mark H. Kim  wrote:
> 
> I see that nvidia-cuda-toolkit is v9 on buster but still v8 on
> stretch-backports. Considering that TensorFlow, one of the biggest reasons
> for installing CUDA, has moved onto using v9, it might make sense to start
> supporting v9 on stretch-backports. Could this be done? Who should I
> contact for this?
> 
> All the best,
> Mark
> --
> Mark Hyun-ki Kim | em...@markhkim.com / markh...@acm.org / 
> markh...@nasw.org | @markhkim | markhkim.com
> 
> 

Bug#899513: Debian中文团队邮件地址即将失效，可能需要一位DD在5月末前采取行动

[Lumin]

(In order to draw attention from admins of debian-chinese team, this
mail is written in Simplified Chinese deliberately.)

// Encoding: UTF-8, Simplified Chinese

致 Debian 中文团队：

随着 Alioth 逐步被弃用，相关的邮件列表服务也受到波及。虽然数月前
Boyuan 已经在 debian-chinese-gb 邮件列表提出邮件列表迁移问题[1]，但并
没有的到任何答复。

现在仍然在使用中文团队 Alioth 地址[2]的软件包应该都已经收到了相应的
RC BUG， 比如[3]。按照 Boyuan 的建议，我们有以下两个选择来处理中文团队
邮件地址的问题：

 「1」邮件地址整体迁移到 »team+chin...@tracker.debian.org«
 「2」让一位 DD 出面向 Alioth Lists Team 申请邮件地址续期。

鉴于选项「2」的最后截至日期是本月末，恳请中文团队的各位管理员尽快
决定一个统一的解决方案。另外必须说明，我和 Boyuan 均是 DM，没有
足够权限来进行决策和相应操作。

非常感谢。

[1] https://lists.debian.org/debian-chinese-gb/2018/01/msg6.html
[2] chinese-develop...@lists.alioth.debian.org
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899513


signature.asc
Description: PGP signature

Bug#900061: Please remove theoretically unneeded patch from debian directory

[Lumin]

control: tag -1 +pending

On Fri, May 25, 2018 at 05:10:52PM +0200, Graham Inggs wrote:
> Hi, I think you replied to me only, and not the bug.

Noticed that, and I have updated my mutt config.
 
> I'm happy to sponsor an upload if you think it is urgent, but I think it can
> wait until pandas 0.23.
 
This is not urgent.

After removing the patch, debomatic build seems to be successful.

http://debomatic-amd64.debian.net/distribution#unstable/pandas/0.22.0-6.1/buildlog

And my laptop has also built it successfully, passing all the unit tests.

So I directly pushed the change.

https://salsa.debian.org/science-team/pandas/commit/2e02f24129fb3bc28155279ff139e35fa1e9950a

> 
> On 25/05/2018 16:00, Lumin wrote:
> > control: tag -1 +moreinfo
> > 
> > On Fri, May 25, 2018 at 03:37:12PM +0200, Graham Inggs wrote:
> > > On 25/05/2018 15:25, Lumin wrote:
> > > > I didn't test the package without the patch. However, theoretically
> > > > speaking, this patch should be removed ASAP.
> > > 
> > > Would you please test the package without the patch, and make the change 
> > > on
> > > Salsa if successful?
> > 
> > I guess that my laptop cannot finish the build before I go to sleep.
> > Let's have DoM-amd64 to test it
> > 
> > http://debomatic-amd64.debian.net/distribution#unstable/pandas/0.22.0-6.1/buildlog
> > 
> > Result should be available in several hours. The debdiff of the
> > tester package is as follows
> > 
> >/tmp ❯❯❯ debdiff pandas_0.22.0-6.dsc pandas_0.22.0-6.1.dsc
> >diff -Nru pandas-0.22.0/debian/changelog pandas-0.22.0/debian/changelog
> >--- pandas-0.22.0/debian/changelog   2018-04-24 19:09:20.0 
> > +
> >+++ pandas-0.22.0/debian/changelog   2018-05-25 13:46:58.0 
> > +
> > 
> >[...]
> >diff -Nru pandas-0.22.0/debian/patches/series 
> > pandas-0.22.0/debian/patches/series
> >--- pandas-0.22.0/debian/patches/series  2018-04-24 17:35:34.0 
> > +
> >+++ pandas-0.22.0/debian/patches/series  2018-05-25 13:46:58.0 
> > +
> >@@ -3,7 +3,7 @@
> > deb_skip_stata_on_bigendians
> > deb_disable_googleanalytics
> > deb_skip_sequencelike_on_armel
> >-deb_fix_test_failure_test_basic_indexing
> >+#deb_fix_test_failure_test_basic_indexing
> > # Try to skip -- migth have been addressed upstream
> > # deb_skip_test_pytables_failure
> > # up_buggy_overflows
> > 
> 


signature.asc
Description: PGP signature

Bug#900061: Please remove theoretically unneeded patch from debian directory

[Lumin]

Package: python3-pandas
Version: 0.22.0-6
Severity: normal

Dear Pandas Maintainers,

I introduced a patch to pandas at the last time I team upload it.
The patch is specific to a test failure of pandas 0.20.3 , and the
workaround, I guess, is now not needed anymore.

>  pandas (0.20.3-11) unstable; urgency=medium
>
>
>* Workaround test failure of test_basic_indexing() in file
>  pandas/tests/series/test_indexing.py .
>  + patches/deb_fix_test_failure_test_basic_indexing

However please note that, I had added a comment in the patch, saying

> 26 Note: Please remove this patch when version >= 0.21.

I didn't test the package without the patch. However, theoretically
speaking, this patch should be removed ASAP.


signature.asc
Description: PGP signature

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#899513: Invalid maintainer address chinese-develop...@lists.alioth.debian.org

[Lumin]

Dear Debian Chinese Team,

The email address of Chinese team is getting invalid soon, due to the
deprecation of Alioth. I'm writing to discuss about a proper solution.

As suggested by Boyuan, we can either

  (1) Use «team+chin...@tracker.debian.org»
  (2) Let a DD contact the Alioth Lists Team, asking them to preserve
  this email address. (The deadline is May 31)

Which one to choose?

Regards,
lumin

On Thu, May 24, 2018 at 09:43:55AM +0200, Christoph Biedl wrote:
> Package: src:fortune-zh
> Version: 2.7
> Severity: serious
> User: ad...@alioth-lists.debian.net
> Usertag: alioth-lists-maintainer
> 
> Dear uploader of fortune-zh,
> 
> as you've probably heard, Debian's alioth services are shutting down.
> This affects your package fortune-zh since the list address
> chinese-develop...@lists.alioth.debian.org used in the Maintainer:
> field was not transferred to the alioth-lists service that provides a
> continuation for the lists in the @lists.alioth.debian.org domain.
> 
> Addresses that were not migrated have been disabled some time  ago. As
> a result your package is now in violation of a "must" in the Debian
> policy (3.3, working email address), making it unfit for release.
> 
> Please fix this before long. Among other reasons, keep in mind bug
> reports and important notifications about your package might not reach
> you.
> 
> Your options:
> 
> * Upload another version with a new maintainer address of your choice,
> 
> * Migrate the list to the new system. This is still possible,
>   please appoint a Debian developer as a list owner first, then
>   contact the alioth lists migration team <ad...@alioth-lists.debian.net>
>   and provide all the necessary information.
> 
>   More information about the new service can be found here:
>   <https://wiki.debian.org/Alioth/MailingListContinuation>
> 
> * More options, even if imperfect, can be found at
>   <https://wiki.debian.org/Salsa/AliothMigration#Import_mailing_list>
> 
> 
> The first option is probably suitable only if the address was used just
> in a small number of packages since this requires an upload for each of
> them. To our knowledge, the usage count of
> chinese-develop...@lists.alioth.debian.org is 12.
> 
> The second option is available for a limited time only, by end of
> May 2018 the most. So if you're interested in going this way, start the
> process as soon as possible.
> 
> Note, as mails to the maintainer address will not get through, this
> bugreport is Cc'ed (X-Debbugs-CC:) to all uploaders of the package.
> 
> Regards,
> 
> Christoph and some alioth-lists maintainers




signature.asc
Description: PGP signature

Bug#899343: CUDA 9.2 Available. Along with GCC-7 Support

[Lumin]

Package: nvidia-cuda-toolkit
Version: 9.1.85-4+b1
Severity: normal
Justification: (wishlist -> normal) new upstream version fixes RC #892415.

CUDA 9.2 is available now:

  https://developer.nvidia.com/cuda-downloads

Nvidia-driver blocks[1] the new version of CUDA:

  CUDA 9.2 (9.2.88) >= 396.26

  nvidia-driver/unstable,unstable,now 390.48-3 amd64 [installed]

As per upstream release note, the following compilers are supported:

  Clang 5.0
  GCC 7.X

That being said, I haven't test any program with CUDA 9.2 yet.

I guess the next default clang version of Debian would be clang 6.0,
skipping clang 5.0 . Besides, the current default GCC is 7.X, but
I guess doko would bump it to 8.X before the Buster release.
That is to say, even if CUDA 9.2 came along with new compiler support,
there are still potential RC bugs (triggered by compiler removal).

[1] https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html


signature.asc
Description: PGP signature

Bug#899303: [Feature Request] Add option to use libeatmydata

[Lumin]

Package: apt
Version: 1.6.1

Dear APT developers,

I'd like to request for an APT feature, where one could add an option
via either /etc/apt/apt.conf or command line argument specifing whether
to use libeatmydata1 to silent the fsync call and friends.

Eatmydata is used to speed up debootstrap speed for pbuilder. Despite
the risk that data may go into an incosistent state on error, this 
library brings a literally insane speed up.

I believe there will be users who are willing to take the risks and
boost the APT speed.

Do you agree to add this feature? If you don't have enough time to
implement this, please let me know. I'd be happy to contribute a patch.

Thanks.


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#899159: Acknowledgement ([numpy/grave] Incorrect Memory offset in numpy.uint8 arrays)

[Lumin]

Sorry, I made a stupid mistake.
uint8 ranges from 0 to 255.


signature.asc
Description: PGP signature

Bug#899159: [numpy/grave] Incorrect Memory offset in numpy.uint8 arrays

[Lumin]

Package: python3-numpy
Version: 1:1.14.3-2
Severity: grave
X-Debbugs-CC: debian-scie...@lists.debian.org

Dear Numpy maintainers,

As a student/researcher, I cannot bear any library that *SILENTLY*
produces totally wrong result. This time numpy just triggered me,
and I wish you can understand that after examing the minimal
repro code:

import numpy as np
print(np.__path__, np.__version__)
N = 257

# integer: good
x = np.zeros((N, N), dtype=np.int)
for i in range(N):
for j in range(N):
x[i,j] = max(i, j)
print(x)

# uint8: fatal
x = np.zeros((N, N), dtype=np.uint8)
for i in range(N):
for j in range(N):
x[i,j] = max(i, j)
print(x)

Output:

['/usr/lib/python3/dist-packages/numpy'] 1.14.3
[[  0   1   2 ... 254 255 256]
 [  1   1   2 ... 254 255 256]
 [  2   2   2 ... 254 255 256]
 ...
 [254 254 254 ... 254 255 256]
 [255 255 255 ... 255 255 256]
 [256 256 256 ... 256 256 256]]
[[  0   1   2 ... 254 255   0]
 [  1   1   2 ... 254 255   0]
 [  2   2   2 ... 254 255   0]
 ...
 [254 254 254 ... 254 255   0]
 [255 255 255 ... 255 255   0]
 [  0   0   0 ...   0   0   0]]

It means that the memory offset calculation for numpy.uint8
array is totally incorrect!

This is producible by Debian's numpy package and that from Pypi.


signature.asc
Description: PGP signature

Bug#899133: FTBFS on Architecture:all

[Lumin]

Package: caffe-cpu
Version: 1.0.0-7
Severity: serious

d/rules will install a file that won't be built during an arch-indep
build. That's the root of this FTBFS.

Bug#898941: caffe-cpu: Very different results for gpu and cpu calculations due to possibly problematic BLAS dependency

[Lumin]

Hi Christoph,

Thank you for this bug report. I'll take a look into it.

Sébastien, I found no code in caffe that is specific to any BLAS
implementation. Do you have any idea about the reported result variation
between netlib blas and openblas? Or do they have different level of
numerical stability assurance?

> Package: caffe-cpu
> Severity: important
> 
> Dear Maintainer,
> 
> I'm getting very different results in cpu mode compared to gpu mode, when 
> using the libblas3 (version 3.7.0-2) package. 
> After installing the libopenblas-base package (version 0.2.19-3) the problems 
> disappeared. I don't know whether
> this is a dependency problem of the package or it is a known problem in 
> libblas3. I was able to uninstall and install
> libopenblas-base while libblas3 was still being installed, which is a little 
> bit confusing to me.
> 
> Note that I reported the bug initially here: 
> https://github.com/twhui/MSG-Net/issues/2
> 
> Note also that this bug has been found with a recompiled package with matlab 
> support enabled. I used this howto
> https://github.com/BVLC/caffe/blob/master/docs/install_apt_debian.md, and 
> changed only the matlab options. However, 
> I don't think that the behaviour is visible in matlab only, though I didn't 
> try this.
> 
> Kind Regards
> Christoph
> 
> -- System Information:
> Debian Release: 9.4
>   APT prefers stable
>   APT policy: (1000, 'stable'), (900, 'stable'), (500, 'stable-updates')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.9.0-6-amd64 (SMP w/8 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages caffe-cpu depends on:
> pn  caffe-tools-cpu  
> ii  libblas3 [libblas.so.3]  3.7.0-2
> pn  libcaffe-cpu1
> ii  libopenblas-base [libblas.so.3]  0.2.19-3
> pn  python3-caffe-cpu
> 
> caffe-cpu recommends no packages.
> 
> Versions of packages caffe-cpu suggests:
> pn  caffe-doc 
> pn  libcaffe-cpu-dev  
> 

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#898483: Acknowledgement (failed creating configuration directroy: unsupported)

[Lumin]

control: tag -1 +patch

I think the problem lays in main.cpp :

   81 // Set configuration directory
   82 //sprintf(writedir, "%s.%s", userdir, application);
   83 sprintf(writedir, "%s%s", userdir, application);
   84 if(!PHYSFS_setWriteDir(writedir)) {
   85 // try to create the directory
   86 char* mkdir = new char[strlen(application) + 2];
   87 sprintf(mkdir, "%s", application);
   88 if(!PHYSFS_setWriteDir(userdir) || !PHYSFS_mkdir(mkdir)) {
   89 std::ostringstream msg;
   90 msg << "Failed creating configuration directory '" <<
   91 writedir << "': " << PHYSFS_getLastError();

Looks like that the author forgot to concat the "userdir" and "mkdir"
before really creating it. If that's where the root of problem lies,
a possible fix could be:

char* mkdir = new char[strlen(userdir) + strlen(application) + 2];
sprintf(mkdir, "%s%s", userdir, applicatoin);
if(!PHYSFS_setWriteDir(userdir) || !PHYSFS_mkdir(mkdir)) {

Not verified. Hope it helps.


signature.asc
Description: PGP signature

Bug#898483: failed creating configuration directroy: unsupported

[Lumin]

Package: lincity-ng
Version: 2.9~git20150314-3
Severity: serious

Dear lincity-ng maintainer,

When there is no ~/.lincity-ng directory under user's home, lincity-ng
will fail on start.

~ ❯❯❯ lincity-ng
Starting lincity-ng (version 2.9.beta)...
Unexpected exception: Failed creating configuration directory 
'/home/lumin/.lincity-ng': unsupported

The user must manually delete the plain file ~/.lincity-ng, and manually
create the directory ~/.lincity-ng to make it work.

For a user who doesn't know the way to fix, the package is totally
unusable, hence I'm marking this bug as RC.

Best,

Bug#898482: upstream's binary patch to cuda 9.1.85

[Lumin]

Package: nvidia-cuda-toolkit
Version: 9.1.85-4+b1
Severity: wishlist

Dear cuda maintainers,

Nvidia just released several binary patches for CUDA toolkit...

   
https://developer.nvidia.com/cuda-downloads?target_os=Linux_arch=x86_64_distro=Fedora_version=25_type=runfilelocal

Patch1 is gemm performance update.

Patch2 is a bug fix to the PTX assembler (ptxas)

Patch3 is a gemm fix.


Well ... Maybe there is no need to include them? I think we should just
wait for the next major/minor release. Let's hope for a better compiler
support from upstream.

Bug#898480: RFS: nltk/3.3.0

[Lumin]

Package: sponsorship-request
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#897506: Cannot reproduce

[Lumin]

control: severity -1 important
Hi,

Thank you for this report, but I cannot reproduce this build failure
neither on my computer, nor DoM-amd64. Hence I'm lowering the severity
of this bug.

http://debomatic-amd64.debian.net/distribution#unstable/caffe/1.0.0-6/buildlog

Bug#898321: Numba 0.38.0 needs llvmlite >= 0.23.0

[Lumin]

Package: python3-llvmlite
Version: 0.22.0-2

This is a blocker of Numba update.

898319: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898319

Bug#898319: Numba 0.38.0 is available

[Lumin]

Package: python3-numba
Version: 0.37.0-1
Severity: wishlist

As per upstream changelog, 0.38.0 is backed by LLVM 6.0, which requires
python-llvmlite >= 0.23.0 .

Apart from that, 0.38.0 also brings initial support to ppc64el, but it
needs LLVM 6.0.1 .

The 0.38.0 update is blocked by llvmlite.

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#897894: lua-torch-torch7 test failed with MKL

[Lumin]

Package: lua-torch-torch7
Version: 0~20170926-g89ede3b-3
Severity: minor

When we switch the alternative libblas.so.3 to MKL, torch will fail to
run the unittests:

  $ th
  > torch.test()

I havn't looked into this problem yet, but this failure could be avoided
by switch back to openblas or some other BLAS libraries.

Bug#897767: highwayhash: ftbfs with GCC-8

[Lumin]

On Fri, May 04, 2018 at 12:21:55PM +, Matthias Klose wrote:
> dpkg-gensymbols: warning: debian/libhighwayhash0/DEBIAN/symbols doesn't match 
> completely debian/libhighwayhash0.symbols
> --- debian/libhighwayhash0.symbols 
> (libhighwayhash0_0~20180209-g14dedec-3_amd64)
> +++ dpkg-gensymbolsJArbQP 2018-05-02 11:58:36.131189433 +
> @@ -14,8 +14,8 @@
>   
> _ZSt7shuffleIN9__gnu_cxx17__normal_iteratorIPmSt6vectorImSaImRSt23mersenne_twister_engineImLm64ELm312ELm156ELm31ELm13043109905998158313ELm29ELm6148914691236517205ELm17ELm8202884508482404352ELm37ELm1873444759240704ELm43ELm6364136223846793005EEEvT_SA_OT0_@Base
>  0~20180209-g14dedec
>   _ZZN11highwayhash4AVX211ConcatenateERKNS0_4V128IjEEmS4_E5table@Base 
> 0~20170419-g1f4a24f
>   _ZZN11highwayhash8Portable15HHStatePortable5ResetEPKmE5init0@Base 
> 0~20170419-g1f4a24f
> dh_makeshlibs: failing due to earlier errors
> make: *** [debian/rules:22: binary-arch] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess 
> returned exit status 2

Hi Matthias,

Thank you for reporting this. The build failure was simply due to the
symbol change. This issue can be fixed by a symbols patch when GCC-8
becomes the default compiler.


signature.asc
Description: PGP signature

Bug#897668: [breeze-cursor] Severe Visibility Issue

[Lumin]

Package: breeze-cursor-theme
Version: 4:5.12.4-1
Severity: important

Dear maintainer,

I'm setting severity to important because the visibility of a cursor
theme is really important.

The problematic cursor is the cross cursor of Breeze and Breeze_Snow,
which are located at the svg files in source tree:

  ./cursors/Breeze_Snow/src/cursors.svg
  ./cursors/Breeze/src/cursors.svg

They look good, but when we actually use the cross cursor in a
low-contrast background it is definitely a pain to find the location of
cursor on the screen.

For example, my cursor theme is Breeze. When I'm taking a screenshot
with flameshot, the whole screen is shadowed, according to source code,
the cursor will be set to the cross. However, unlike other breeze cursors
which are padded with a white margin, the cross cursor is padded with
nothing. In this case the cursor has a very low contrast to the
background hence very hard to caught by eyes.

Similarly, I checked Breeze_Snow. And I guess the cross cursor will also
be hard to find when the background is basically grey or white.

I suggest a fix with high-contrast margin added to the cross cursor.

Thanks.

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#896986: [galternatives] feature request: symlink search / filter

[Lumin]

Hi,

That's just a `str.startswith(...)` search, but not a `... in str` search.

On 28 April 2018 at 11:58, Yangfl  wrote:
> The list in the left panel is searchable. Click and enter the desired item
> name / press Ctrl+F to find the item you want.



-- 
Best,

Bug#896986: [galternatives] feature request: symlink search / filter

[Lumin]

Package: galternatives
Version: 0.92.4
Severity: wishlist

Dear maintainer,

Thank you for maintaining this software. However
it's no easy to manually search for an item... even
if the list is sorted.

~ ❯❯❯ update-alternatives --get-selections | wc -l
180


-- 
Best,

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#896572: message: Cannot use GPU in CPU-only Caffe (caffe-cuda build)

[Lumin]

control: tag -1 +moreinfo

Hello Programmeur,

Thank you for this report.
However this issue seems strange ... it should not happen ...

According to the source file,

include/caffe/util/device_alternate.hpp
4:#ifdef CPU_ONLY  // CPU-only Caffe.
10:#define NO_GPU LOG(FATAL) << "Cannot use GPU in CPU-only Caffe: check mode."

This error message will only appear when your caffe is compiled CPU-only.
Could you please provide me the following information:

1. Type this command in your terminal: `which caffe`, and paste the
output in the mail.
If it is not /usr/bin/caffe, then the answer is clear: you are
running your self-built
CPU-only caffe.

2. The output of the following two commands:
1. "apt list libcaffe\*"
2. "apt show libcaffe-cuda1"

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#896136: [uscan] Git mode fails to download due to custom pretty format

[Lumin]

Package: devscripts
Version: 2.18.1

Hi,

uscan failes to download upstream tarball from this watch file

version=4
opts="mode=git, pgpmode=none, pretty=0~%cd-g%h" \
https://github.com/google/farmhash \
HEAD debian uupdate

the error log is shown at [1].
However if I remove the custom pretty format, the error will disappear.

[1]

uscan info: Upstream URL(+tag) to download is identified as
https://github.com/google/farmhash HEAD
uscan info: Filename (filenamemangled) for downloaded file:
farmhash-0~20171030-g2f0e005.tar.xz
uscan: Newest version of farmhash on remote site is
0~20171030-g2f0e005, local version is 0~20170626-g23eecfb
uscan:=> Newer package available from
  https://github.com/google/farmhash HEAD
uscan info: Downloading upstream package: farmhash-0~20171030-g2f0e005.tar.xz
uscan info: Execute: git
--git-dir=../farmhash-0~20171030-temporary.21832.git archive
--format=tar --prefix=farmhash-0~20171030-g2f0e005/
--output=/home/lumin/packages/farmhash.pkg/farmhash/../farmhash-0~20171030-g2f0e005.tar
HEAD
fatal: not a git repository: '../farmhash-0~20171030-temporary.21832.git'
uscan die: git archive failed



-- 
Best,

Bug#895881: ITP: intel-mkl/2018.2.199 -- Intel(R) Math Kernel Library (Intel(R) MKL)

[Lumin]

Package:wnpp
Severity: wishlist
Owner: cdlumin...@gmail.com

* Package name: intel-mkl
  Version : 2018.2.199
  Upstream Author : Intel
* URL : https://software.intel.com/en-us/mkl
* License : Intel Simplified Software License (ISSL)
  Programming Lang: C/C++/Fortran
  Description : Intel® Math Kernel Library (Intel® MKL)

MKL is redistributable, as explicitly declared by Intel:
   https://software.intel.com/en-us/mkl/license-faq
   which means MKL can enter non-free.

I'm working on this git repo:
   https://salsa.debian.org/science-team/intel-mkl

Co-maintainers are welcome :-)

Previous discussions related to MKL in d-Science list:
   https://lists.debian.org/debian-science/2018/03/msg00070.html

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