Bug#932797: [Pkg-javascript-devel] Bug#932797: Bug#932797: node-gyp should be installed in /usr/share/nodejs/node-gyp

[Nilesh Patra]

Hi

>
https://salsa.debian.org/gi-boi-guest/node-node-sass/blob/master/scripts/build.js#L59
> replace
> require.resolve(path.join('node-gyp', 'bin', 'node-gyp.js'))
> by
> 'node-gyp'

 On doing that, I'm again getting the same error message which was reported
earlier. Are there other files which need path resolution too? Please let
me know.

Regards
Nilesh

Bug#932797: [Pkg-javascript-devel] Bug#932797: Bug#932797: Bug#932797: node-gyp should be installed in /usr/share/nodejs/node-gyp

[Nilesh Patra]

Well that's odd.
Do simply calling "node-gyp" from terminal work at all ?

Yes, it does. Calling "gyp" from the terminal works too.  However when I
did the changes in build.js scipt (via quilt) and try to build it, I get
the same error as reported. I even tried hard-coding the path to
node-gyp.js but that doesn't seem to work out too. Please let me know if
there are other files that I should make changes to.

Regards
Nilesh

On Tue, 23 Jul 2019, 23:33 Jérémy Lal,  wrote:

>
>
> Le mar. 23 juil. 2019 à 17:18, Nilesh Patra  a
> écrit :
>
>> Hi
>>
>> >
>> https://salsa.debian.org/gi-boi-guest/node-node-sass/blob/master/scripts/build.js#L59
>> > replace
>> > require.resolve(path.join('node-gyp', 'bin', 'node-gyp.js'))
>> > by
>> > 'node-gyp'
>>
>>  On doing that, I'm again getting the same error message which was
>> reported earlier. Are there other files which need path resolution too?
>> Please let me know.
>>
>
> Well that's odd.
> Do simply calling "node-gyp" from terminal work at all ?
>
>

Bug#932797: [Pkg-javascript-devel] Bug#932797: Bug#932797: Bug#932797: Bug#932797: node-gyp should be installed in /usr/share/nodejs/node-gyp

[Nilesh Patra]

This in rules works (workaround)
>
> export NODE_PATH := ${CURDIR}:/usr/share
>

Thanks! This works and I was able to build node-node-sass.

Regards
Nilesh

Bug#932956: ITP: node-node-sass -- Wrapper around libsass

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-node-sass
  Version : 4.12.0
  Upstream Author : Andrew Nesbitt  (
http://andrew.github.com)
* URL : https://github.com/sass/node-sass
* License : Expat
  Programming Lang: JavaScript
  Description : Wrapper around libsass

 Node-sass is a library that provides binding for Node.js to LibSass.
 .
 LibSass is the C version of the popular stylesheet preprocessor, Sass.
 .
 It allows you to natively compile .scss files to css at
 incredible speed and automatically via a connect middleware.
 .
 Node.js is an event-based server-side JavaScript engine.

This package is a dependency of node-mermaid.I am interested in maintaining
this package long time.
It would be great if it could be given an bug number to close.

Regards
Nilesh

Bug#934665: upload grpc and protobuf to unstable

[Nilesh Patra]

 But the latest available package version is 3.10.1-1 and the rebuild
> should be done with that.
>

Rebuilt with the new version, these are the newer failing depends:
anbox, astroidmail, bookkeeper, collectd, containerd, cubemap,docker.io,
etcd, gazebo, go-dep, gobgp, ignition-transport, mahimahi, nageru, ola,
opencv, osmosis, shogun, vlc

Thanks and Regards
Nilesh

Bug#934665: upload grpc and protobuf to unstable

[Nilesh Patra]

On Sun, 17 Nov 2019, 23:44 Pirate Praveen,  wrote:

> So as summary, the packages that might be failed due to protobuf change are
>
> cubemap, ignition-transport (with ignition-msgs might fix gazebo), ola,
> osmosis
>
> I will file bugs against these.
>

Thanks a lot!

These packages should rebuilt without ccache in chroot and confirm if
> ccache caused the failure: nageru, opencv
>

I will try checking them.

I also rebuilt for gRPC, and I found no failed rebuilds on the reverse
build dependencies for the same.

Thanks and regards
Nilesh

Bug#782922: Help for issues with lazyarray needed

[Nilesh Patra]

On Thu, 5 Mar 2020, 14:16 Andreas Tille,  wrote:

> Control: tags -1 pending
>
> Hi,
>
> I have updated lazyarray in Git[1] (by moving it to Debian Science
> team).  The old package was lagging way behind upstream and a Python3
> port is available by upstream so I just create the python3-lazyarray
> package fixing the open bugs.
>
> Unfortunately there is an open issue[2].  Since the latest upstream
> commit has only one failure (in contrast to the latest tagges upstream
> version which is according to commit logs not really the latest) I
> based the source tarball on the latest commit.  Unfortunately there
> is one remaining issue for Python3.7 and two for Python3.8
>
>
>dh_auto_test -O--buildsystem=pybuild
> I: pybuild base:217: cd
> /build/lazyarray-2.10.0+hg20170630.23ccca1/.pybuild/cpython3_3.7_lazyarray/build;
> python3.7 -m nose -v test
> test.test_lazyarray.test_create_with_int ... ok
> ...
> ==
> FAIL: test.test_lazyarray.test__issue4
> --
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest
> self.test(*self.arg)
>   File
> "/build/lazyarray-2.10.0+hg20170630.23ccca1/.pybuild/cpython3_3.7_lazyarray/build/test/test_lazyarray.py",
> line 701, in test__issue4
> assert_equal(b[mask1].shape, partial_shape(mask1, b.shape),
> a[mask1].shape)
> AssertionError: Tuples differ: (4, 1, 3) != (4,)
>




> First tuple contains 2 additional elements.
> First extra element 1:
> 1
>
> - (4, 1, 3)
> + (4,) : (4, 1, 3)
>
> --
> Ran 87 tests in 0.027s
>
> FAILED (failures=1)
>

I had tried this,
I think Passing [:-1] in the mask2 initialisation would fix this. We also
need to cast this into a numpy array.


>
>
> I continued manually in the pbuilder chroot to get Python3.8 issues:
>
> pbuilder-chroot# cd
> /build/lazyarray-2.10.0+hg20170630.23ccca1/.pybuild/cpython3_3.8_lazyarray/build;
> python3.8 -m nose -v test
> ...
> ==
> ERROR: test.support.testresult.get_test_runner_class
> --
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest
> self.test(*self.arg)
> TypeError: get_test_runner_class() missing 1 required positional argument:
> 'verbosity'
>
> ==
> ERROR: test.support.testresult.get_test_runner
> --
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest
> self.test(*self.arg)
> TypeError: get_test_runner() missing 2 required positional arguments:
> 'stream' and 'verbosity'
>
> --
> Ran 45 tests in 7.327s
>
> FAILED (SKIP=1, errors=2)
>

I'll try this by midnight today. If I can, I'll try a fix for this, and
make a MR, or a patch.
Would that work?


> I somehow suspect that the latter issue is not really hard and I wonder
> whether I can get some help from DPMT?
>
> My current plan is to ignore the test suite errors for the moment,
> upload a Python3 enabled package to new queue.  Once it has passed new I
> will see whether we found some solution for the said issues.  If not
> I'll file a new RC bug to prevent testing migration.  I'd like to do
> that means to get the latest version of pynn built to keep on with the
> Python3 migration for this package.
>
> Any help for the remaining issues is welcome.
>
> Kind regards
>
>   Andreas.
>
> [1] https://salsa.debian.org/science-team/lazyarray
> [2] https://bitbucket.org/apdavison/lazyarray/issues/6/test-failure
>
> --
> http://fam-tille.de
>
>

Bug#950666: [Pkg-javascript-devel] Bug#950666: node-terser FTBFS: test failures

[Nilesh Patra]

Hi

On Wed, 05 Feb 2020 13:41:37 +0100 Jonas Smedegaard  wrote:

> control: tags -1 +confirmed
> control: retitle -1 node-terser FTBFS: fails 7 tests in "bin/uglifyjs"
and "bin/uglifyjs with input file globs"
>
> Quoting Adrian Bunk (2020-02-04 16:29:34)
> > Source: node-terser
> > Version: 4.1.2-4
> > Severity: serious
> > Tags: ftbfs
> >
> >
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-terser.html
> >
> > ...
> > 231 passing (47s)
> > 4 pending
> > 7 failing
> >
> > 1) bin/uglifyjs (2)
> > Should dump AST as JSON:
> > Uncaught Command failed: "/usr/bin/node" bin/uglifyjs
test/input/global_defs/simple.js -mco ast
> > ERROR: ENOENT: no such file or directory, open 'ast'
> > at Object.openSync (fs.js:443:3)
> > at Object.readFileSync (fs.js:343:35)
> > at read_file (/build/1st/node-terser-4.1.2/bin/uglifyjs:353:19)
> > at /build/1st/node-terser-4.1.2/bin/uglifyjs:176:37
> > at Array.forEach ()
> > at Object. (/build/1st/node-terser-4.1.2/bin/uglifyjs:175:28)
> > at Module._compile (internal/modules/cjs/loader.js:778:30)
> > at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
> > at Module.load (internal/modules/cjs/loader.js:653:32)
> > at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
> >
> > Error: Command failed: "/usr/bin/node" bin/uglifyjs
test/input/global_defs/simple.js -mco ast
> > ERROR: ENOENT: no such file or directory, open 'ast'
> > at Object.openSync (fs.js:443:3)
> > at Object.readFileSync (fs.js:343:35)
> > at read_file (bin/uglifyjs:353:19)
> > at /build/1st/node-terser-4.1.2/bin/uglifyjs:176:37
> > at Array.forEach ()
> > at Object. (bin/uglifyjs:175:28)
> > at Module._compile (internal/modules/cjs/loader.js:778:30)
> > at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
> > at Module.load (internal/modules/cjs/loader.js:653:32)
> > at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
> >
> > at ChildProcess.exithandler (child_process.js:294:12)
> > at maybeClose (internal/child_process.js:982:16)
> > at Process.ChildProcess._handle.onexit (internal/child_process.js:259:5)
> > ...
>
> Thanks for reporting!
>
> Tag as confirmed (corresponds with local cowbuilder build).
>
> Update bug title to disambiguate from similar but possibly different
> issue discussed in JavaScript team (not yet formally reported).

I have fixed it to build along with passing autopkgtests and there are
no lintian warnings + errors as well.
Also fixed the other bug #950733 associated with the package.(I tried
emulating your changes in node-uglify here).
I have pushed the changes to my local fork here[1].
Needs review and sponsorship.

[1]: https://salsa.debian.org/gi-boi-guest/node-terser/

Thanks and regards,
Nilesh

>
> - Jonas
>
> --
> * Jonas Smedegaard - idealist & Internet-arkitekt




signature.asc
Description: OpenPGP digital signature

Bug#946979: lists.debian.org: Have a mailing list archive for the JavaScript team.

[Nilesh Patra]

On Thu, 19 Dec 2019 00:35:18 +0530 Utkarsh Gupta
 wrote:
> Package: lists.debian.org
> Severity: wishlist
>
> Hiya,
>
> The JavaScript team is still using the old archive (that is,
> alioth-lists.debian.net) which gets very messy and noisy since there are
> a lot (hundres each month) of auto-generated emails from the FTP Masters.
> Moreover, all the other teams have switched to
> lists.debian.org/debian-.
>
> That said, I hereby request a slot for the JavaScript team, that is,
> debian...@lists.debian.org.
> Thank you :)
>
> Let me know if you require any more reasoning or anything of that sort!

I support the reasoning here, so we may have productive discussions
without noise.
The tracker can be used to check upload status anyway.
Hope this gets done soon.

>
> Best,
> Utkarsh
> ---
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers buster-fasttrack
>   APT policy: (500, 'buster-fasttrack'), (500, 'unstable'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
>

Bug#956417: ITP: parasail: Pairwise Sequence Alignment Library

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: parasail
  Version : 2.4.1
  Upstream Author : Jeff Daily
* URL : https://github.com/jeffdaily/parasail
<https://github.com/knsv/mermaid>
* License : BSD-Style
  Programming Lang: C, C++
  Description : Pairwise Sequence Alignment Library

 Parasail is a SIMD C (C99) library containing implementations of
 the Smith-Waterman, Needleman-Wunsch, and various semi-global
 pairwise sequence alignment algorithms. Parasail implements most
 known algorithms for vectorized pairwise sequence alignment,
 including diagonal, blocked, striped, and prefix scan.

I take the responsibility to maintain this package.

Bug#940359: RFA: golang-github-glycerine-go-unsnap-stream

[Nilesh Patra]

Hi,

On Sun, 5 Apr 2020, 02:37 Alexandre Viau,  wrote:

>
> On 2020-03-21 6:54 a.m., Nilesh wrote:
> > I would like maintaining the package, shall keep it updated.
>
> Great !
>
> > For Now, I have added in my name, along, that should work well.
> > If you really don't want your name in d/control ,I'll so the needful in
> the next release.
>
> Indeed, feel free to remove my name, or we can't close this bug haha.
>

Had done, :)


> >> Feel free to contact me with any questions. Also note that I always
> > willing to sponsor uploads!
> >
> > I have pushed my changed to my local fork here[1], with updated version.
> > I'm not a member of go-team yet; could you add me on salsa, or give me
> push access to the package
> > in go-team?> That would be great.
>
> I see that you are now a member of the Go Packaging Team on salsa. Are
> you able to apply your changes directly on the repository?
>

Yep.


>
> > Need review and sponsorship for this package as well.
>
> Maybe you can send a message to the go maintainers list for that
> package? I'd prefer if we keep focused on
> golang-github-glycerine-go-unsnap-stream for this thread. One thing at a
> time!


I adopted three of your packages, and Utkarsh Gupta 
sponsored an upload for all.

Many thanks for your response :-)

Regards, Nilesh

Bug#951634: Broken package in testing repository

[Nilesh Patra]

Hi Alexander,  Hugo, Graham

On Wed, 25 Mar 2020, 21:45 Alexander van der Meij, <
vandermeij.t...@gmail.com> wrote:

>
>
>
> Hi Debian Science team,
>
> As described in bug 951634
> , Debian is
> currently distributing a broken development build of the software of which
> I am the developer; gummi.
>
> Hereby my request to either bump the package to the stable (0.8.1) release
> or remove it from your repositories altogether.
>

Alexander, Thank you for your work on Gummi.
I have fixed this, and updated to new version.

Please note that there are spelling mistakes in your package which lintian
pointed out, it would be great if you could  get it fixed with the new
release. See the patch here [1]

Hugo, Graham: the package builds in a clean chroot, and looks lintian clean
too.
I have pushed my changes here [2]

Could you please sponsor an upload?
That would be great!

[1]:
https://salsa.debian.org/science-team/gummi/-/blob/master/debian/patches/0001-spellings.patch

[2]: https://salsa.debian.org/science-team/gummi

Thanks and regards
Nilesh

>

Bug#954500: Droping pyqi which seemed to be needed for qiime1 only (Was: Bug#954500: pyqi: FTBFS: dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2)

[Nilesh Patra]

Hi

On Mon, 30 Mar 2020, 17:12 Andreas Tille,  wrote:

> Hi,
>
> I fixed the actual issue in Git but got a new error:
>
>
> ...
>dh_auto_test -O--buildsystem=pybuild
> I: pybuild base:217: cd
> /build/pyqi-0.3.2+dfsg/.pybuild/cpython3_3.8/build; python3.8 -m unittest
> discover -v
> /build/pyqi-0.3.2+dfsg/.pybuild/cpython3_3.8/build/pyqi/core/interfaces/html/__init__.py:359:
> SyntaxWarning: "is not" with a literal. Did you mean "!="?
>   if full_name in postvars and i.Type is not 'upload_file':
> pyqi.core.interfaces.html (unittest.loader._FailedTest) ... ERROR
>
> ==
> ERROR: pyqi.core.interfaces.html (unittest.loader._FailedTest)
> --
> ImportError: Failed to import test module: pyqi.core.interfaces.html
> Traceback (most recent call last):
>   File "/usr/lib/python3.8/unittest/loader.py", line 470, in
> _find_test_path
> package = self._get_module_from_name(name)
>   File "/usr/lib/python3.8/unittest/loader.py", line 377, in
> _get_module_from_name
> __import__(name)
>   File
> "/build/pyqi-0.3.2+dfsg/.pybuild/cpython3_3.8/build/pyqi/core/interfaces/html/__init__.py",
> line 25, in 
> from cgi import parse_header, parse_multipart, parse_qs, FieldStorage
> ImportError: cannot import name 'parse_qs' from 'cgi'
> (/usr/lib/python3.8/cgi.py)
>

Just checked, none of the cgi imports (parse_header, parse_qs et al) are
being used anywhere in the file.
Imo, you can just delete this import line.
On doing that, build passed for me.


>
> --
> Ran 1 test in 0.000s
>
> FAILED (errors=1)
> E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1:
> cd /build/pyqi-0.3.2+dfsg/.pybuild/cpython3_3.8/build; python3.8 -m
> unittest discover -v
> dh_auto_test: error: pybuild --test -i python{version} -p 3.8 returned
> exit code 13
> ...
>
>
> Since pyqi has no rdepends any more and IMHO was only packaged
> for qiime version 1.x I'd suggest to remove this package.
>
> Am I missing something?
>

Regards, Nilesh.

Bug#958840: kmer: autopkgtest regression: No module named 'localAlignerInterface'

[Nilesh Patra]

On Mon, 18 May 2020 at 12:39, Andreas Tille  wrote:

>
> I've merged this and tried a test build including running autopkgtest in
> my pbuilder environment.  Unfortunately the latter test is now failing with
>
> ...
> autopkgtest [06:48:10]: test atac-unit-test: [---
> Rewriting
> '/tmp/autopkgtest.jgVuO6/autopkgtest_tmp/GCF_000195855.1_ASM19585v1_genomic.fna'
> to '/tmp/autopkgtest.jgVuO6/autopkgtest_tmp/meryldir/Lepr.fasta', removing
> newlines.
> Rewriting
> '/tmp/autopkgtest.jgVuO6/autopkgtest_tmp/GCF_000195955.2_ASM19595v2_genomic.fna'
> to '/tmp/autopkgtest.jgVuO6/autopkgtest_tmp/meryldir/Tuber.fasta', removing
> newlines.
>
> /usr/bin/meryl -B -C -threads 2 -m 20 -s
> /tmp/autopkgtest.jgVuO6/autopkgtest_tmp/meryldir/Lepr.fasta -o
> /tmp/autopkgtest.jgVuO6/autopkgtest_tmp/meryldir/Lepr.ms20
>
> fastaFile::constructIndex()-- magic mismatch.
> fastaFile::constructIndex()-- magic mismatch.
> bitPackedFile::bitPackedFile()-- failed to open and truncate
> '/tmp/autopkgtest.jgVuO6/autopkgtest_tmp/meryldir/Lepr.ms20.batch0.mcidx':
> No such file or directory
> Failed to count mers in Lepr
> autopkgtest [06:48:10]: test atac-unit-test: ---]
> autopkgtest [06:48:11]: test atac-unit-test:  - - - - - - - - - - results
> - - - - - - - - - -
> atac-unit-test   FAIL non-zero exit status 2
> ...
>
>
> I admit I personally have no idea why this fails.
>

Is this a false positive?
It seems to pass for me:

'''
Read checkpoint in 0 seconds.
Creating
/tmp/autopkgtest.Ri0bel/autopkgtest_tmp/meryldir/Lepr.fasta.idxStore
Creating
/tmp/autopkgtest.Ri0bel/autopkgtest_tmp/meryldir/Tuber.fasta.idxStore
We need to make the raw matches.
runName =
/tmp/autopkgtest.Ri0bel/autopkgtest_tmp/results/work/LeprvsTuber.matches.extended

Keep step=0
At step=0
Time elapsed=0.00037479400634765625
At uniqueFilter, step=1
Time elapsed=0.0003867149353027344
Running UniqueFilter
sort -T . -k 1,1 -k 2,2 -k 3n -k 4nr
 /tmp/autopkgtest.Ri0bel/autopkgtest_tmp/results/tmpxq1az43c >
/tmp/autopkgtest.Ri0bel/autopkgtest_tmp/results/tmprg6kyya8
time elapsed is  0.0026073455810546875
time elapsed is  7.796287536621094e-05
sort -T . -k 1,1 -k 2,2 -k 3n -k 4nr
 /tmp/autopkgtest.Ri0bel/autopkgtest_tmp/results/tmpco1alaqw >
/tmp/autopkgtest.Ri0bel/autopkgtest_tmp/results/tmpeja1c_zn
time elapsed is  0.0037603378295898438
time elapsed is  0.00011348724365234375
At filterByMatchLength, step=2
Time elapsed=0.1619856357574463
Running filterByMatchLength
At trimMatchOverlaps, step=3
Time elapsed=0.16259360313415527
Start trimming for bp one-to-one-ness
trimMatchOverlapsInX:
 #posgaps, #abuts, #overlaps, #contained, bp_trimmed= 0 0 0 0 0

trimMatchOverlapsInY:
 #posgaps, #abuts, #overlaps, #contained, bp_trimmed= 0 0 0 0 0

Finished trimming for bp one-to-one-ness
At formPerfectRuns, step=4
Time elapsed=0.21597981452941895
from
/tmp/autopkgtest.Ri0bel/autopkgtest_tmp/results/work/LeprvsTuber.matches.extended.uniq.t40.trim
making
/tmp/autopkgtest.Ri0bel/autopkgtest_tmp/results/work/LeprvsTuber.matches.extended.uniq.t40.trim.p6
formPerfectRuns step=0
formPerfectRuns step=1
formPerfectRuns step=2
formPerfectRuns step=3
At onlyKeepLongRuns, step=5
Time elapsed=0.32003164291381836
from
/tmp/autopkgtest.Ri0bel/autopkgtest_tmp/results/work/LeprvsTuber.matches.extended.uniq.t40.trim.p6
making
/tmp/autopkgtest.Ri0bel/autopkgtest_tmp/results/work/LeprvsTuber.matches.extended.uniq.t40.trim.p6.l100
At formPerfectRuns, step=6
Time elapsed=0.320875883102417
Heal the perfect runs
formPerfectRuns step=0
formPerfectRuns step=1
formPerfectRuns step=2
formPerfectRuns step=3
At squeezeIntraRunGaps, step=7
Time elapsed=0.3695542812347412
from /tmp/autopkgtest.Ri0bel/autopkgtest_tmp/results/work/
LeprvsTuber.matches.extended.uniq.t40.trim.p6.l100.pr to
/tmp/autopkgtest.Ri0bel/autopkgtest_tmp/results/work/LeprvsTuber.matches.extended.uniq.t40.trim.p6.l100.pr.sq
countLines 0 inter_run_gap_count 0 closed_gap_count 0 squeezed 0 x_len 0
y_len 0 x_nonACGT 0 y_nonACGT 0
theIsolatedSNPcount = 0
completefillednotXY = 0
completefilledXnotY = 0
completefilledYnotX = 0
completefilledXandY = 0
At TrimMatchOverlaps, step=8
Time elapsed=0.37032628059387207
Start trimming for bp one-to-one-ness
trimMatchOverlapsInX:
 #posgaps, #abuts, #overlaps, #contained, bp_trimmed= 0 0 0 0 0

trimMatchOverlapsInY:
 #posgaps, #abuts, #overlaps, #contained, bp_trimmed= 0 0 0 0 0

Finished trimming for bp one-to-one-ness
At RunsAsMatches, step=9
Time elapsed=0.4200100898742676
At fillIntraRunGaps, step=10
Time elapsed=0.42075562477111816
fill the intrarun gaps
begin
countLines=0
countLines 0 inter_run_gap_count 0
At TrimMatchOverlaps, step=11
Time elapsed=0.42135024070739746
trim the overlaps
trimMatchOverlapsInX:
 #posgaps, #abuts, #overlaps, #contained, bp_trimmed= 0 0 0 0 0

trimMatchOverlapsInY:
 #posgaps, #abuts, #overlaps, #contained, bp_trimmed= 0 0 0 0 0

Ran in 0 seconds.

/usr/bin/../lib/atac/bin/correctGaps  -m

Bug#954324: ITP: node-mermaid -- Javascript based diagramming and charting tool

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-mermaid
  Version : 8.4.8
  Upstream Author : Knut Sveidqvist
* URL : https://github.com/knsv/mermaid
* License : Expat
  Programming Lang: JavaScript
  Description : Javascript based diagramming and charting tool

Markdownish syntax for generating flowcharts,
sequence diagrams, class diagrams, gantt charts and git graphs.
.
It can help visualize flowcharts, diagrams, ganttcharts and git charts can
be
scripted in a markdown syntax, with a varitety of different symbols and
chart
types available. Since the diagram source is text based,
it can be part of production scipts.
.
Automates the diagram generation instead of making it manually.
.
Node.js is an event-based server-side JavaScript engine.

I take the responsibility to maintain this package.

Bug#940369: RFA: golang-github-influxdata-influxql

[Nilesh Patra]

Hi,

On Sun, 15 Sep 2019 18:02:20 -0400 Alexandre Viau  wrote:

> Package: wnpp
> Severity: normal
>
> Hello!
>
> I'd like to find new maintainers for some of my packages because I have
> had less time for Debian. I'd like to focus the small amount of time
> that I have for Debian on other things.

I would like maintaining the package, and shall keep it updated.

>
> For now, I intend to do my best to keep maintaining this package.
> However, I will probably retitle this bug with the 'O:' prefix at some
> point, indicating that I have orphaned it.
>
> Feel free to upload a new version of the package and remove me from the
> uploaders in debian/control.

For now, I have added-in my name along in d/control.
If you would really want your name to be removed, maybe we can do so
with the next release.

>
> Feel free to contact me with any questions. Also note that I always
> willing to sponsor uploads!
>
> Cheers,

I have pushed my changes here[1], with the updated version.
I'm not a member of go-team yet, would be great if you could add-me-in
on salsa.
My username is: gi-boi-guest
I would also appreciate if you could review and sponsor the package.

PS: The CI might fail on my runner, since it needs Micheal's runner as
can be seen in yml file. I'm confident
that it will pass there.

[1]: https://salsa.debian.org/gi-boi-guest/golang-github-influxdata-influxql

Thanks and regards,
Nilesh





signature.asc
Description: OpenPGP digital signature

Bug#940374: RFA: golang-github-jackpal-gateway

[Nilesh Patra]

Hi,

On Sun, 15 Sep 2019 18:08:48 -0400 Alexandre Viau  wrote:
> Package: wnpp
> Severity: normal
>
> Hello!
>
> I'd like to find new maintainers for some of my packages because I have
> had less time for Debian. I'd like to focus the small amount of time
> that I have for Debian on other things.
>

I would like maintaining the package, and shall keep it updated.

> For now, I intend to do my best to keep maintaining this package.
> However, I will probably retitle this bug with the 'O:' prefix at some
> point, indicating that I have orphaned it.
>
> Feel free to upload a new version of the package and remove me from the
> uploaders in debian/control.
>

For now, I have added-in my name along in d/control.
If you would really want your name to be removed, maybe we can do so
with the next release.

> Feel free to contact me with any questions. Also note that I always
> willing to sponsor uploads!
>
> Cheers,
>


I have pushed my changes here[1], with the updated version.
I'm not a member of go-team yet, would be great if you could add-me-in
on salsa, so I may maintain + push directly.
My username is: gi-boi-guest
I would also appreciate if you could review and sponsor the package.

PS: The CI might fail on my runner, since it needs Micheal's runner as
can be seen in yml file. I'm confident
that it will pass there, i.e. on the team-repo, as I saw with this Merge
Request too[2]. (Just for reference here)

[1]: https://salsa.debian.org/gi-boi-guest/golang-github-jackpal-gateway
[2]:
https://salsa.debian.org/go-team/packages/golang-github-karlseguin-expect/-/merge_requests/1

Thanks and regards,
Nilesh



signature.asc
Description: OpenPGP digital signature

Bug#961399: seaview: autopkgtest regression: gzip: *.gz: No such file or directory

[Nilesh Patra]

On Sun, 24 May 2020, 19:06 Andreas Tille,  wrote:

> On Sun, May 24, 2020 at 08:02:56AM +0200, Paul Gevers wrote:
> > gzip: *.gz: No such file or directory
>
> I've fixed this one but the test has changed and seems to require a
> running X server.  Either this can be changed via command line options
> or by using xvfb-run to provide some X server.
>

That's a nice idea indeed!

I tried implementing this, and modifying the tests in a way that made sense
to me.
Could you please have a look at this, and let me know if this is OK?

Kind regards
Nilesh

>

Bug#969423: ITP: h5sparse: Scipy sparse matrix in HDF5

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: h5sparse
  Version : 0.1.0-1
  Upstream Author : Appier Inc
* URL : https://github.com/appier/h5sparse
<https://github.com/knsv/mermaid>
* License : Expat
  Programming Lang: Python
  Description : Scipy sparse matrix in HDF5
 h5sparse is a Python library which helps
 create scipy sparse matrix in HDF5.

I shall maintain this package.

Bug#970157: ITP: seriation --- Finds a suitable linear order for a set of objects

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: seriation
  Version : 0.1+git20200810
  Upstream Author : Alexandre Amory
* URL : https://github.com/amamory/seriation
* License : Expat
  Programming Lang: C
  Description : Finds a suitable linear order for a set of objects
 This software is an efficient implementation of the
 seriation problem which 'finds a suitable linear
 order for a set of objects'. It has been used
 to order a network of proteins such that 'related'
 nodes are closer in the other.

I shall maintain this package.

Bug#970385: src:swissknife: Please provide autopkgtest

[Nilesh Patra]

Source: swissknife
Version: 1.75-2
Severity: wishlist
Tags: newcomer

Dear Maintainer,

Please provide autopkgtest for this package.


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Thank you for using reportbug

Bug#970404: shovill: Please provide autopkgtest

[Nilesh Patra]

Package: shovill
Severity: wishlist
X-Debbugs-Cc: npatra...@gmail.com

Dear Maintainer,

Please provide autopkgtest for this package. This also doesn't work
properly at the moment
and needs minor patching for the same.


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Thank you for using reportbug

Bug#970309: src:python-loompy: Please provide autopkgtest

[Nilesh Patra]

Source: python-loompy
Version: 3.0.6+dfsg-2
Severity: wishlist
Tags: newcomer

Dear Maintainer,

Please provide autopkgtest for this package.


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Thank you for using reportbug

Bug#970312: src:intake: Please provide autopkgtest

[Nilesh Patra]

Source: intake
Version: 0.6.0-3
Severity: wishlist
Tags: newcomer

Dear Maintainer,

Please provide autopkgtest for this package.


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Thank you for using reportbug

Bug#970301: phybin: Please provide autopkgtest

[Nilesh Patra]

Package: phybin
Severity: wishlist
X-Debbugs-Cc: npatra...@gmail.com
Tags: newcomer

Dear Maintainer,

Please provide autopkgtest for this package.


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Thank you for using reportbug

Bug#970238: ITP: survivor -- Tool set for simulating/evaluating SVs

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: survivor
  Version : 1.0.6-1
  Upstream Author : Fritz Sedlazeck
* URL : https://github.com/fritzsedlazeck/SURVIVOR
* License : Expat
  Programming Lang: C++
  Description :  Tool set for simulating/evaluating SVs
 SURVIVOR is a tool set for simulating/evaluating
 SVs, merging and comparing SVs within and among
 samples, and includes various methods to reformat
 or summarize SVs.

I shall maintain this package.

Bug#969743: ITP: svim: Structural variant caller for long sequencing reads

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: svim
  Version : 1.4.1+ds-1
  Upstream Author : David Heller
* URL : https://github.com/eldariont/svim/
<https://github.com/knsv/mermaid>
* License : GPL-3+
  Programming Lang: Python
  Description : Structural variant caller for long sequencing reads
 SVIM is a structural variant caller for long sequencing reads.
 It is able to detect, classify and genotype five different
 classes of structural variants. Unlike existing methods, SVIM
 integrates information from across the genome to precisely
 distinguish similar events, such as tandem and interspersed
 duplications and simple insertions.

I shall maintain this package.

Bug#920545: [RFS] python-intervaltree-bio

[Nilesh Patra]

Hi,
I've attempted to fix: #920545 which is about failing autopkgtests for
python-intervaltree-bio. It seems to pass on my chroot and I've pushed the
corresponding changes to the team repo here[1].
It'd be great if someone could try testing my changes once - and either
sponsor or grant me access to do so.

[1]: https://salsa.debian.org/med-team/python-intervaltree-bio

Kind regards
Nilesh

Bug#971148: umap-learn: FTBFS: unsatisfiable build-dependency: python3-llvmlite (< 0.34) but 0.34.0-1 is to be installed

[Nilesh Patra]

I suppose this FTBFS is due to numba[1] instead of umap-learn.
Hence, this would as well FTBFS.

It might be a better idea to close this bug and open a bug report
against numba instead, so that umap-learn migrates to testing after the
bug is fixed in numba,
w/o having to close this bug manually.
This will also prevent other packages depending on numba from migrating.

[1]:
https://salsa.debian.org/science-team/numba/-/blob/debian/master/debian/control#L11

Kind Regards,
Nilesh

Bug#961591: [RFS] r-bioc-graph

[Nilesh Patra]

On Wed, 27 May 2020, 23:28 Dylan Aïssi,  wrote:

> Hi Nilesh,
>
> Le mer. 27 mai 2020 à 19:36, Nilesh Patra  a écrit :
> >
> > Hi,
> > Currently r-bioc-graph has failing tests, and has RC bug - #961591 filed
> against this.
> > I have fixed this and pushed my changes to the team repo here[1].
> > Need review and sponsorship.
> >
>
> Thanks for #961591 !!!
>
> I don't understand why you moved some test-deps to deps ?


The second test (needing the library) failed on gitlab-ci, w/o adding
r-cran-xml and r-cran-runit, possible because this doesn't pick up depends
from test-depends.
This passed on my local machine though. Since I wanted to be sure, I moved
this there.

Was this incorrect to do?
Please do let me know.

Regards,
Nilesh

Bug#961591: [RFS] r-bioc-graph

[Nilesh Patra]

Hi,
Currently r-bioc-graph has failing tests, and has RC bug - #961591 filed
against this.
I have fixed this and pushed my changes to the team repo here[1].
Need review and sponsorship.

[1]: https://salsa.debian.org/r-pkg-team/r-bioc-graph


Thanks and regards
Nilesh

Bug#961591: [RFS] r-bioc-graph

[Nilesh Patra]

On Thu, 28 May 2020, 01:43 Dylan Aïssi,  wrote:

> Hi,
>
> Le mer. 27 mai 2020 à 20:04, Nilesh Patra  a écrit :
> >
> > The second test (needing the library) failed on gitlab-ci, w/o adding
> r-cran-xml and r-cran-runit, possible because this doesn't pick up depends
> from test-depends.
> > This passed on my local machine though. Since I wanted to be sure, I
> moved this there.
>
> There is probably a bug on the salsa-ci side, because both tests
> passed on my computer. Let's skip salsa-ci for now.
>

Ahh, alrighty.


> I have moved back these dependencies to test-deps and I have updated
> your patch (str_replace_all --> gsub) to not add a new dependency.
>

That's good, and makes sense. I didn't know about this, possibly because I
don't speak R :P


> You probably already noticed, the debian/test/control files for R
> packages require a lot of manual work to keep the list of test-deps
> up-to-date. Because I don't want to do this manually, I moved the code
> to tests these packages into pkg-r-autopkgtest. The list of test-deps
> is automatically generated at run time from the DESCRIPTION file
>

That's nice!

Currently, it is enabled only for bioconductor packages, if there is
> no big bug with this transition, we will be able to remove the
> debian/test/control files and to enable this for other R packages.
>

Got it, thanks for the explanation.


> Thanks again for #961591.
>

:)
And thanks a lot for letting me have this upload (i.e. my name on d/ch for
this upload)

Kind regards,
Nilesh

>

Bug#961494: bowtie2: please make the build reproducible

[Nilesh Patra]

On Mon, 25 May 2020 at 20:10, Andreas Tille  wrote:

> Hi Chris,
>
> On Mon, May 25, 2020 at 10:49:28AM +0100, Chris Lamb wrote:
> > This should have read:
> >
> >   Whilst you do patch out -fdebug-prefix-map in
> >   debian/patches/reproducible.patch, you also need to filter
> >   -ffile-prefix-map.
>
> I've tried this in Git[1] but the resulting bowtie2 package fails the
> autopkgtest in my pbuilder environment.  I remember issues with
> autopkgtest in pbuilder before and I suspect this might be the case
> here as well.  However, before I really upload I'd invite others to
> have a look.
>

I can confirm that this passes for me.

autopkgtest [20:46:44]: test binary-run: [---
autopkgtest [20:46:45]: test binary-run: ---]
autopkgtest [20:46:45]: test binary-run:  - - - - - - - - - - results - - -
- - - - - - -
binary-run   PASS
autopkgtest [20:46:45]:  summary
check-wo-arguments   PASS
indexing-ref-genome  PASS
binary-run   PASS

Just maybe, this is a false positive again, at your end.

[1]
> https://salsa.debian.org/med-team/bowtie2/-/commit/97052bc2de1b271f368dd8415cfafde5356e2fe8


Kind regards,
Nilesh

Bug#961499: [RFS] r-cran-sjplot and r-cran-sjmisc

[Nilesh Patra]

Hi

On Tue, 26 May 2020, 13:26 Andreas Tille,  wrote:

> Hi Nilesh,
>
> same as for r-cran-sjplot:  In commit d2c969cc you move a file out of
> help system to doc and I'm not convinced that this is not dangerous.
>

Ahh, righty!
I didn't realise the help system thing while moving it, and this was indeed
a careless mistake. Apologies.

I've reverted the commit and pushed for both the packages.
Please consider to upload.

Regards,
Nilesh

Bug#936798: Please port KisSplice to Python3 (Was: Bug#936798: kissplice: Python2 removal in sid/bullseye)

[Nilesh Patra]

Hi,

On Fri, 29 May 2020, 01:08 Andreas Tille,  wrote:

> Hi Moritz,
>
> On Thu, May 28, 2020 at 08:48:41PM +0200, Moritz Mühlenhoff wrote:
> >
> > JFTR, this is now fixed upstream in 2.5.0 and later:
> > http://kissplice.prabi.fr/download/:
> >
> > --
> > Kissplice Version 2.5.0 (2020-04-06)
> >
> > New features:
> >Now compatible with python3
> > --
>
> Thanks for the hint.  Unfortunately there are remaining issues
> in build time test and autopkgtest. even of version 2.5.1 .:-(
>

I've Fixed the autopkgtest

For the failing build tests: this is what I observe - this try matching
strings containing a few values with kissplice result.

For instance,  this is one of the failures:

Expected:
0a: Single SNPs, Inexact Repeats or sequencing substitution errors, 69 found

Actual:
0a: Single SNPs, Inexact Repeats or sequencing substitution errors, 22 found

There's definitely a difference between the outputs of previous kissplice
version and current kissplice version, I tried this manually as well.

Just _maybe_, the upstream data has been changed, and the correct data
hasn't been injected; or the implementation has changed in version,
2.5.1and this should output 22, but the tests haven't been changed
accordingly ; or maybe this is a bug with kissplice itself.

In either case, I'm not really about this. Maybe we should ask upstream
about it.

Thanks and regards
Nilesh

Bug#970447: ITP: pinfish -- Collection of tools to annotate genomes using long read transcriptomics data

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: pinfish
  Version : 0.1.0+ds-1
  Upstream Author : Oxford Nanopore Technologies Ltd.
* URL : https://github.com/nanoporetech/pinfish
* License : MPL-2.0
  Programming Lang: Go
  Description :  Collection of tools to annotate genomes using long
read transcriptomics data
 The toolchain is composed of the following tools:
 1. spliced_bam2gff - a tool for converting sorted BAM
 files containing spliced alignments
 into GFF2 format. Each read will be represented as a distinct
 transcript. This tool comes handy when visualizing spliced
 reads at particular loci and to provide input to the rest
 of the toolchain.
 .
 2. cluster_gff - this tool takes a sorted GFF2 file as
 input and clusters together reads having similar
 exon/intron structure and creates a rough consensus
 of the clusters by taking the median of exon
 boundaries from all transcripts in the cluster.
 .
 3. polish_clusters - this tool takes the cluster
 definitions generated by cluster_gff and for each
 cluster creates an error corrected read by mapping
 all reads on the read with the median length
 and polishing it using racon. The polished reads
 can be mapped to the genome using minimap2 or GMAP.
 .
 4. collapse_partials - this tool takes GFFs generated
 by either cluster_gff or polish_clusters and filters
 out transcripts which are likely to be based on RNA
 degradation products from the 5' end. The tool clusters
 the input transcripts into "loci" by the 3' ends and
 discards transcripts which have a compatible transcripts
 in the loci with more exons.

I shall maintain this package.

Bug#970550: [Pkg-javascript-devel] Bug#970550: replacing browserify with webpack or rollup - need help

[Nilesh Patra]

Hi,

On Sun, 20 Sep 2020 at 15:18, Pirate Praveen 
wrote:

> Control: tags -1 help
>
> On Sun, Sep 20, 2020 at 14:44, Pirate Praveen
>  wrote:
> > The warning now changes to,
> >
> > (!) Missing shims for Node.js built-ins
> > Creating a browser bundle that depends on 'path', 'url' and 'os'. You
> > might need to include
> > https://www.npmjs.com/package/rollup-plugin-node-builtins
> > (!) Unresolved dependencies
> >
> https://rollupjs.org/guide/en#warning-treating-module-as-external-dependency
> > path (imported by ../../../usr/share/nodejs/browserslist/index.js,
> > commonjs-external:path,
> > ../../../usr/share/nodejs/postcss/lib/input.js,
> > ../../../usr/share/nodejs/browserslist/node.js,
> > ../../../usr/share/nodejs/postcss/lib/map-generator.js,
> > ../../../usr/share/nodejs/postcss/lib/previous-map.js)
>
> rollup-plugin-node-builtins is not packaged in debian. So I decided to
> try webpack (code pushed to a separate branch 'webpack'),
>
> This has resulted in a situation where we need to handle Buffer
> correctyly.
>
> with Buffer: true in webpack.config.js, the build fails with error
>
> ERROR in /usr/share/nodejs/postcss/lib/map-generator.js
> Module not found: Error: Can't resolve
> './../../../../../<>/buffer' in
> '/usr/share/nodejs/postcss/lib'
>  @ /usr/share/nodejs/postcss/lib/map-generator.js 1:0-89
>  @ /usr/share/nodejs/postcss/lib/lazy-result.js
>  @ /usr/share/nodejs/postcss/lib/processor.js
>  @ /usr/share/nodejs/postcss/lib/postcss.js
>  @ ./lib/autoprefixer.js
>

I've seen these almost same buffer based errors before - with webpack
specifically - and manually creating a symlink helped. I did the same in
this case and the build passes with "Buffer: true"
I've pushed the commit to the same webpack branch
Could you take a look and let me know if it made the situation better/worse?

Thanks and Regards,
Nilesh

Bug#970462: [RFS] Bug#970462: sweed: autopkgtest arm64 failure

[Nilesh Patra]

Hi,

On Sun, 20 Sep 2020 at 20:34, Étienne Mollier 
wrote:

> Control: tags -1 pending
>
> Greetings,
>
> I tried to investigate the issue of running SweeD autopkgtests
> on arm64.  It turned out to be caused by the assumption that the
> "char" type was "signed" by default, while it is "unsigned" by
> default at least on arm64.  The patch I added makes several
> targeted changes, so that the test suite goes through without
> either crashing (segfault) or hanging (infinite loop).
>
> I also tried to ensure test results were unchanged compared to
> other CPU architectures, and as far as I could see, they the
> same on arm64 (with the patch) and on amd64 (without the patch).
>
> Changes are available on Salsa for review:
>
> https://salsa.debian.org/med-team/sweed
>
> Thanks Paul for having reported the issue, and Thanks Nilesh for
> having written the test suite that allowed to catch the bug!  :)
>

Thanks a lot! Uploaded!

Kind Regards
Nilesh

Bug#972757: ITP: golang-github-smallfish-simpleyaml -- Go package to interact with arbitrary YAML

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: golang-github-smallfish-simpleyaml
  Version : 0.0~git20170911.a320310-1
  Upstream Author : 陈小玉
* URL : https://github.com/smallfish/simpleyaml
* License : BSD-3-Clause
  Programming Lang: Golang
  Description :  Go package to interact with arbitrary YAML
 Simpleyaml is Go package to interact with arbitrary YAML
 and extracting relevant information from the YAML.

I shall maintain this package.

Bug#972759: ITP: golang-github-iafan-cwalk -- Concurrent filepath.Walk replacement

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: golang-github-iafan-cwalk
  Version : 0.0~git20191125.dd7f505-1
  Upstream Author : Igor Afanasyev
* URL : https://github.com/iafan/cwalk
* License : Expat
  Programming Lang: Golang
  Description :  Concurrent filepath.Walk replacement
 A concurrent version of filepath.Walk function that
 scans files in a directory tree and runs a callback
 for each file.
 .
 Since scanning (and callback execution) is done from within goroutines,
 this may result in a significant performance boost on multicore systems
 in cases when the bottleneck is the CPU, not the I/O.
 .
 Upstream tests showed ~3.5x average speed increase on an 8-core CPU
 and 8 workers. For measurements, upstream used provided
 bin/traversaltime.go utility that measures directory traversal time
 for both concurrent (cwalk.Walk()) and standard (filepath.Walk()) functions.

I shall maintain this package.

Bug#967051: ITP: seqkit: Cross-platform and ultrafast toolkit for FASTA/Q file manipulation

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: seqkit
  Version : 0.12.1+ds-1
  Upstream Author : 2016-2020 Wei Shen, 2019 Oxford Nanopore Technologies
<https://github.com/knsv/mermaid>
* License : MIT
  Programming Lang: Golang
  Description :cross-platform and ultrafast toolkit for FASTA/Q file
manipulation
 SeqKit describes a cross-platform ultrafast comprehensive toolkit for
 FASTA/Q processing. SeqKit provides executable binary files for all
 major operating systems, including Windows, Linux, and Mac OS X, and can
 be directly used without any dependencies or pre-configurations. SeqKit
 demonstrates competitive performance in execution time and memory usage
 compared to similar tools. The efficiency and usability of SeqKit enable
 researchers to rapidly accomplish common FASTA/Q file manipulations.

I will maintain this package.

Bug#967009: ITP: golang-github-bsipos-thist :Generates online histograms and plots them with golang

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: golang-github-bsipos-thist
  Version : 1.0.0-1
  Upstream Author : 2019 Botond Sipos
* URL : https://github.com/bsipos/thist
<https://github.com/knsv/mermaid>
* License : Expat
  Programming Lang: Golang
  Description : generating online histograms and plotting them with
golang
 Thist is a go library for calculating online histograms
 with plotting to the terminal and images.

Bug#966681: ITP: golang-gonum-v1-plot :Provides an API for building and drawing plots in Go

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: golang-gonum-v1-plot
  Version : 0.7.0-1
  Upstream Author : 2013-2019 Ethan Burns 
 Steve McCoy 
 Dan Kortschak 
 James Bell 
 Sebastien Binet 
* URL : https://github.com/gonum/plot
<https://github.com/knsv/mermaid>
* License : BSD-3-clause
  Programming Lang: Golang
  Description : repository for plotting and visualizing data (library)
 gonum/plot is the new, official fork of code.google.com/p/plotinum.
 It provides an API for building and drawing plots in Go. Note that
 this new API is still in flux and may change. See the wiki for some
 example plots.
 .
 gonum/plot is split into a few packages:
 .
  * The plot package provides simple interface for laying out a plot and
provides primitives for drawing to it.
  * The plotter package provides a standard set of Plotters which use the
primitives provided by the plot package for drawing lines, scatter
plots, box plots, error bars, etc. to a plot. You do not need to use
the plotter package to make use of gonum/plot, however: see the wiki
for a tutorial on making your own custom plotters.
  * The plotutil package contains a few routines that allow some common
plot types to be made very easily. This package is quite new so it is
not as well tested as the others and it is bound to change.
  * The vg package provides a generic vector graphics API that sits on
top of other vector graphics back-ends such as a custom EPS back-end,
draw2d, SVGo, X-Window and gopdf

Bug#963764: [Pkg-javascript-devel] Bug#963764: Bug#963764: node-node-sass: uses embedded old security-buggy libsass

[Nilesh Patra]

Hi,

On Wed, 8 Jul 2020, 19:30 Jonas Smedegaard,  wrote:

> Quoting mer...@debian.org (2020-07-08 15:13:06)
> > The upstream has updated the libsass support to 3.6.3 [1], it's just
> > not released yet. I have successfully used head of their git
> > repository to build node-node-sass without the embedded libsass copy
> > (there were a couple of failing mocha tests, however).
>

@Andrius: Thanks a lot for your work on this :-)


> Thanks for looking into this issue!
>
> Please strongly consider to not only make the package link with
> system-shared libsass, but also repackage upstream tarball with embedded
> code copy removed, to ensure not accidentally using that code (and to
> lighten the size of what gets distributed in Debian and simplify
> copyright tracking and ease security tracking).


@Jonas:
I considered the same approach after the first source-only-upload was done.
However, it might so happen that going forward the version of sass is
updated to a newer upstream, and Debian adapts to that particular release,
but the node-sass upstream might only have support for libsass 3.6.3 -
considering that upstream of node-node-sass is slower to adapt to changes.

This would cause node-node-sass to FTBFS.

Hence, I wish to keep the embedded copy of libsass if such a situation
arises.

The package built with the libsass in the archive earlier - when it started
to FTBFS,
a flag was appended  for it to build with the embedded version of libsass.
On reverting the commit[1], it'd again start building with the libsass in
the archive.

I'd wish to keep the same approach.
_Please let me know_ if this doesn't sound good to you and if you'd prefer
embedded libsass to be stripped entirely.

[1]:
https://salsa.debian.org/js-team/node-node-sass/-/commit/bb9e5ede14253ecc02140f9a5e946b580afed3d4

Kind Regards,
Nilesh

Bug#963764: [Pkg-javascript-devel] Bug#963764: Bug#963764: node-node-sass: uses embedded old security-buggy libsass

[Nilesh Patra]

On Wed, 8 Jul 2020, 20:22 Jonas Smedegaard,  wrote:

> Quoting Nilesh Patra (2020-07-08 16:26:34)
> > On Wed, 8 Jul 2020, 19:30 Jonas Smedegaard,  wrote:
> > > Please strongly consider to not only make the package link with
> > > system-shared libsass, but also repackage upstream tarball with
> > > embedded code copy removed, to ensure not accidentally using that
> > > code (and to lighten the size of what gets distributed in Debian and
> > > simplify copyright tracking and ease security tracking).
> >
> >
> > @Jonas:
> > I considered the same approach after the first source-only-upload was
> done.
> > However, it might so happen that going forward the version of sass is
> > updated to a newer upstream, and Debian adapts to that particular
> release,
> > but the node-sass upstream might only have support for libsass 3.6.3 -
> > considering that upstream of node-node-sass is slower to adapt to
> changes.
> >
> > This would cause node-node-sass to FTBFS.
>
> Yes. That is how Debian generally works.
>
> Please explain why this package needs exceptional handling.


The upstream for node-node-sass took a considerable amount of time to
switch to libsass 3.6.3, and there is still no official upstream release
yet.

The same situation may arise in future, and it might take many months for
upstream to adapt.

Hence I considered it _might_ be sensible to keep the copy.

However, I admit that your reasoning is right here - this probably doesn't
need exceptional handling.


Kind regards,
Nilesh

Bug#963764: [Pkg-javascript-devel] Bug#963764: Bug#963764: node-node-sass: uses embedded old security-buggy libsass

[Nilesh Patra]

On Wed, 8 Jul 2020, 20:38 Jonas Smedegaard,  wrote:

> Quoting Nilesh Patra (2020-07-08 17:00:01)
> > On Wed, 8 Jul 2020, 20:22 Jonas Smedegaard,  wrote:
> >
> > > Quoting Nilesh Patra (2020-07-08 16:26:34)
> > > > On Wed, 8 Jul 2020, 19:30 Jonas Smedegaard,  wrote:
> > > > > Please strongly consider to not only make the package link with
> > > > > system-shared libsass, but also repackage upstream tarball with
> > > > > embedded code copy removed, to ensure not accidentally using that
> > > > > code (and to lighten the size of what gets distributed in Debian
> and
> > > > > simplify copyright tracking and ease security tracking).
> > > >
> > > >
> > > > @Jonas:
> > > > I considered the same approach after the first source-only-upload was
> > > done.
> > > > However, it might so happen that going forward the version of sass is
> > > > updated to a newer upstream, and Debian adapts to that particular
> > > release,
> > > > but the node-sass upstream might only have support for libsass 3.6.3
> -
> > > > considering that upstream of node-node-sass is slower to adapt to
> > > changes.
> > > >
> > > > This would cause node-node-sass to FTBFS.
> > >
> > > Yes. That is how Debian generally works.
> > >
> > > Please explain why this package needs exceptional handling.
> >
> >
> > The upstream for node-node-sass took a considerable amount of time to
> > switch to libsass 3.6.3, and there is still no official upstream release
> > yet.
> >
> > The same situation may arise in future, and it might take many months for
> > upstream to adapt.
> >
> > Hence I considered it _might_ be sensible to keep the copy.
> >
> > However, I admit that your reasoning is right here - this probably
> doesn't
> > need exceptional handling.
>
> None of us can predict the future.  But we can choose to assume that
> this package will evolve badly in the future or that it will evolve
> well.
>

Correct.


> If we expect this package to evolve badly, then we should *not* keep an
> embedded copy of libsass, but instead remove this package and all its
> reverse dependencies, because libsass has been proven insecure if left
> unmaintained,


It has a few reverse dependencies - I mainly packaged this for getting
node-mermaid to Debian which is still in NEW, and hopefully will be
accepted.
I am interested in maintaining mermaid and hence do not want to remove
node-node-sass.

Maybe I'll keep nagging the upstream for evolving this properly time and
again ;-)

Kind regards,
Nilesh

Bug#964266: ITP: golang-github-brentp-irelate: Streaming relation testing of sorted files of intervals

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: golang-github-brentp-irelate
  Version : 0.0~git20180801.1bf7c8f+ds-1
  Upstream Author : Brent Pedersen
* URL : https://github.com/brentp/irelate
<https://github.com/knsv/mermaid>
* License : Expat
  Programming Lang: Golang
  Description : Streaming relation testing of sorted files of intervals

Description: Streaming relation testing of sorted files of intervals
 Helps to relate (e.g. intersect or by distance) sets of intervals.
 For example, if the nearest gene to a set of ChIP-Seq peaks needs
 to be reported, BEDTools does this extremely well, irelate is an
 attempt to provide an API so that users can write their own tools
 with little effort in go.
 .
 Performance irelate is quite fast, but use PIRelate for parallel
 intersection. It is less flexible than irelate, but skips parsing of
 database intervals for sparse regions in the query.  In addition, it
 has very good (automatic) parallelization.

I shall maintain this package.

Bug#964273: ITP: golang-github-brentp-vcfgo: Golang library to read, write, manipulate VCF format files

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: golang-github-brentp-vcfgo
  Version : 0.0~git20190824.654ed2e-1
  Upstream Author :  Brent Pedersen
* URL : https://github.com/brentp/vcfgo
<https://github.com/knsv/mermaid>
* License : Expat
  Programming Lang: Golang
  Description : Golang library to read, write, manipulate VCF format
files

 Package vcfgo implements a Reader and Writer for variant
 call format. It eases reading, filtering modifying VCF's
 even if they are not to spec.
 .
 Status: vcfgo is well-tested, but still in development.
 It tries to tolerate, but report errors; after every
 rdr.Read() call, the caller can check rdr.Error() and
 get feedback on the errors without stopping
 execution unless it is explicitly requested to do so.

I shall maintain this package.

Bug#964307: ITP: golang-github-brentp-bix: Tabix file access with golang using biogo machinery (library)

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: golang-github-brentp-bix
  Version : 0.0~git20190718.00aa7a7+ds-1
  Upstream Author : Brent Pedersen
* URL : https://github.com/brentp/bix
<https://github.com/knsv/mermaid>
* License : Expat
  Programming Lang: Golang
  Description : Tabix file access with golang using biogo machinery
(library)

 Bixis a pure go tabix reader. Tabix has a minimum resolution of 16K
 bases. So, for dense annotations like ExAC, repeated queries will have to
 re-parse the same intervals. To mitigate this, Bix caches all annotations
 for the blocks from each query and re-uses them for later queries to
 the same block.  In practice, this results in 10X-100X speedup for any
 type of data.

I shall maintain this package.

Bug#964932: ITP: golang-github-yuin-gluare: Regular expression library for the GopherLua

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: golang-github-yuin-gluare
  Version : 0.0~git20170607.d7c94f1-1
  Upstream Author : Yusuke Inuzuka
* URL : https://github.com/yuin/gluare
<https://github.com/knsv/mermaid>
* License : Expat
  Programming Lang: Golang
  Description : Regular expression library for the GopherLua
 Gluare has almost the same API as Lua pattern match.
 "re.find" , "re.gsub", "re.match", "re.gmatch"
 are available. These functions have the same API
 as Lua pattern match. gluare uses the Go regexp package,
 so you can use regular expressions that are supported
 in the Go regexp package.

I shall maintain this package.

Bug#964933: ITP: golang-github-brentp-goluaez: Easy embedding Lua in go

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: golang-github-brentp-goluaez
  Version : 0.0~git20160116.dd35d08-1
  Upstream Author : Brent Pedersen
* URL : https://github.com/brentp/goluaez
<https://github.com/knsv/mermaid>
* License : Expat
  Programming Lang: Golang
  Description : Easy embedding Lua in go

 goluaez wraps gopher-lua  and gopher-luar.
 gopher-luar does a nice job of converting
 go values to Lua. This package uses that and
 also converts Lua values to go and converts
 go slices to Lua tables.

I shall maintain this package.

Bug#963001: ITP: yanagiba: Filters low quality Oxford Nanopore reads basecalled with Albacore

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: yanagiba
  Version : 1.0.0
  Upstream Author : Adam Taranto
* URL : https://github.com/Adamtaranto/Yanagiba
<https://github.com/knsv/mermaid>
* License : Expat
  Programming Lang: Python
  Description : Filters low quality Oxford Nanopore reads basecalled
with Albacore

 Yanagiba is used to filter short or low quality
 Oxford Nanopore reads which have been basecalled
 with Albacore. It takes fastq.gz and an Albacore
 summary file as input. If no Albacore summary file
 is provided attempt to calculate mean qscore from
 directly from fastq file using NanoMath. Note:
 Calculated quality scores appear to be lower
 for reads called with Metrichor, you may need
 to lower your minqual setting in this case.

I take the responsibility to maintain this package.

Bug#963047: ITP: ngmlr: CoNvex Gap-cost alignMents for Long Reads

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: ngmlr
  Version : 0.2.7
  Upstream Author : Philipp Rescheneder
* URL : https://github.com/philres/ngmlr
<https://github.com/knsv/mermaid>
* License : Expat
  Programming Lang: C++
  Description : CoNvex Gap-cost alignMents for Long Reads

 ngmlr is a long-read mapper designed to sensitively
 align PacBilo or Oxford Nanopore to (large) reference
 genomes. It was designed to quickly and correctly
 align the reads, including those spanning (complex)
 structural variations. Ngmlr uses an SV aware k-mer
 search to find approximate mapping locations for a
 read and then a banded Smith-Waterman alignment
 algorithm to compute the final alignment. Ngmlr
 uses a convex gap cost model that penalizes gap
 extensions for longer gaps less than for shorter
 ones to compute precise alignments.

I take the responsibility to maintain this package.

Bug#963078: ITP: paryfor: Parallel_for implementation based on atomic queues

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: paryfor
  Version : 0.1
  Upstream Author : Erik Garrison
* URL : https://github.com/ekg/paryfor
<https://github.com/knsv/mermaid>
* License : Expat
  Programming Lang: C++
  Description : Parallel_for implementation based on atomic queues

 The parallel_for templates replace #pragma omp parallel for.
 This uses a callback that takes the iteration number.

NB: Dependency of mmmulti
I take the responsibility to maintain this package.

Bug#963137: ITP: ncls: Datastructure for interval overlap queries

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: ncls
  Version : 0.0.53
  Upstream Author : Endre Bakken Stovner
* URL : https://github.com/biocore-ntnu/ncls
<https://github.com/knsv/mermaid>
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Datastructure for interval overlap queries

 The Nested Containment List is a datastructure
 for interval overlap queries, like the interval
 tree. It is usually an order of magnitude faster
 than the interval tree both for building and query
 lookups. The implementation here is a revived
 version of the one used in the now defunct PyGr
 library. Its made less memory-consuming and
 has wrapper functions which allows batch-querying

NB: Dependency of pyrle
I take the responsibility to maintain this package.

Bug#963628: [Pkg-javascript-devel] Bug#963628: Bug#963628: Node-jest fails with: Error: Cannot find module 'import-local'

[Nilesh Patra]

On Sun, 28 Jun 2020, 02:45 Xavier,  wrote:

> Control: severity -i grave
>

Thanks.


> Le 24/06/2020 à 21:18, Nilesh Patra a écrit :
> > Package: node-jest
> > Severity: serious
> >
> > Dear Maintainer,
> >
> > Node-jest fails with the following on all the node-modules I've tried
> yet.
> > Sample examples on
>
> Work needed for node-jest:
>  * add babel-plugin-istanbul; proposition: add it in node-babel7
>

It's good.
Would you mind discussing this bit on the list?

 * update and fix node-jsdom
>  * add missing components
>

Noted.


> Here is the list of missing modules (mix of node-jest and node-jsdom):
>  * astral-regex
>  * babel-plugin-istanbul
>  * browser-process-hrtime
>  * data-urls
>  * domexception
>  * es-abstract
>  * fast-json-stable-stringify
>  * html-encoding-sniffer
>  * import-local
>  * is-generator-fn
>  * is-regex
>  * left-pad
>  * makeerror
>  * natural-compare
>  * nwsapi
>  * object.getownpropertydescriptors
>  * object-keys
>  * parse5
>  * p-each-series
>  * pn
>  * p-reduce
>  * realpath-native
>  * request-promise-native
>  * sane
>  * string-length
>  * symbol-tree
>  * throat
>  * tmpl
>  * tr46
>  * util.promisify
>  * w3c-hr-time
>  * walker
>  * whatwg-encoding
>  * whatwg-mimetype
>  * whatwg-url
>  * xml-name-validator
>

Would you have a rough idea as to how many of these can be simply embedded
- or do all of these need to be packaged NEW?

For all new packages needed,
I would really like helping here :-)

Kind Regards,
Nilesh

>

Bug#963628: [Pkg-javascript-devel] Bug#963628: Bug#963628: Node-jest fails with: Error: Cannot find module 'import-local'

[Nilesh Patra]

Also, as I dug in a bit, the "import-local" module has this description:

"""
Let a globally installed package use a locally installed version of itself
if available

For our use-case we would need modules only from /usr/share/* right?
So _maybe_ this has no real use here?

Let me know if this is wrong, or I'm missing out something.

Regards,
Nilesh

Bug#962941: ITP: streamz: Helps build pipelines to manage continuous streams of data

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: streamz
  Version : 0.5.3
  Upstream Author : Continuum Analytics, Inc. and contributors
* URL : https://github.com/python-streamz/streamz
<https://github.com/knsv/mermaid>
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Helps build pipelines to manage continuous streams of
data

 It is simple to use in simple cases, but also supports complex pipelines
that
 involve branching, joining, flow control, feedback, back pressure, and so
on.
 Optionally, Streamz can also work with both Pandas and cuDF dataframes,
 to provide sensible streaming operations on continuous tabular data.

I take the responsibility to maintain this package.

Bug#956694: Clarification: [RFS] spdlog

[Nilesh Patra]

> For sopt, the build fails with the logs same as what Ole sharedearlier - but 
> looking at them, it seems that spdlog is probably not responsible for the 
> failure.


By same logs, I do not mean the one in the original bug report, but the
logs which Ole got after workaround: #953855

cd /build/sopt-3.0.1/obj-x86_64-linux-gnu/cpp/tests && /usr/bin/cmake -E
cmake_link_script CMakeFiles/test_padmm.dir/link.txt --verbose=1
/usr/lib/ccache/c++  -g -O2 -fdebug-prefix-map=/build/sopt-3.0.1=.
-fstack-protector-strong -Wformat -Werror=format-security
-DSPDLOG_FMT_EXTERNAL -Wdate-time -D_FORTIFY_SOURCE=2  -std=gnu++11
-Wl,-z,relro >
/usr/bin/ld: CMakeFiles/copy_tiff.dir/copy_tiff.cc.o: in function
`fmt::v6::basic_format_context
>, char>::on_error(char const*)':
/usr/include/fmt/core.h:1169: undefined reference to
`fmt::v6::internal::error_handler::on_error(char const*)'

Here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956694#10

I suspect this is due to a missing flag like I said earlier.

Regards,
Nilesh

Bug#962947: ITP: shovill: Assemble bacterial isolate genomes from Illumina paired-end reads

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: shovill
  Version : 1.1.0
  Upstream Author : Torsten Seemann
* URL : https://github.com/tseemann/shovill
<https://github.com/knsv/mermaid>
* License : GPL-3+
  Programming Lang: Perl
  Description : Assemble bacterial isolate genomes from Illumina
paired-end reads

 Shovill is a pipeline which uses SPAdes at its core,
 but alters the steps before and after the primary
 assembly step to get similar results in less time.
 Shovill also supports other assemblers like SKESA,
 Velvet and Megahit, so you can take advantage of the
 pre- and post-processing the Shovill provides
 with those too.

I take the responsibility to maintain this package.

Bug#962965: ITP: yanosim:Read simulator nanopore DRS datasets

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: yanosim
  Version : 0.1
  Upstream Author : Matthew Parker
* URL : https://github.com/bartongroup/yanosim
<https://github.com/knsv/mermaid>
* License : Expat
  Programming Lang: Python
  Description : Read simulator nanopore DRS datasets

 It has three options:
 1 yanosim model:
 Creates an model of mismatches, insertions and deletions
 based on an alignment of nanopore DRS reads to a
 reference. Reads should be aligned to a transcriptome
 i.e. without spliced alignment, using minimap2. They
 should have the cs tag.
 .
 2 yanosim quantify:
 Quantify the number of reads mapping to each
 transcript in a reference, so that the right number
 of reads can be simulated.
 .
 3 yanosim simulate
 Given a model created using yanosim model, and
 per-transcript read counts created using yanosim
 simulate, simulate error-prone long-reads from the
 given fasta file.

I take the responsibility to maintain this package.

Bug#962888: ITP: readucks: Nanopore read de-multiplexer

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: readucks
  Version : 0.0.3
  Upstream Author : Andrew Rambaut
* URL : https://github.com/artic-network/readucks/
<https://github.com/knsv/mermaid>
* License : GPL-3+
  Programming Lang: Python
  Description : Nanopore read de-multiplexer

 This package is inspired by the demultiplexing options in
 porechop but without the adapter trimming options - it just demuxes.
 It uses the parasail library with its Python bindings to do
 pairwise alignment which provides a considerable speed up over
 the seqan library used by porechop due to its low-level use
 of vector processor instructions.


I take the responsibility to maintain this package.

Bug#963164: ITP: pyrle: Run length arithmetic in Python using Cython

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: pyrle
  Version : 0.0.31
  Upstream Author : Endre Bakken Stovner
* URL : https://github.com/pyranges/pyrle
<https://github.com/knsv/mermaid>
* License : Expat
  Programming Lang: Python
  Description : Run length arithmetic in Python using Cython

 As opposed to S4Vectors, pyrle does not
 rotate the shortest vector, but rather
 extends the shorter Rle with zeroes.
 This is likely the desired behavior in
 almost all cases

I shall maintain this package.

Bug#963465: ITP: node-natural-sort: Sorting with support for numbers, dates, unicode and more

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-natural-sort
  Version : 1.0.0-1
  Upstream Author : Studio B12 GmbH
* URL : https://github.com/studio-b12/natural-sort
<https://github.com/knsv/mermaid>
* License : Expat
  Programming Lang: Javascript
  Description : Sorting with support for numbers, dates, unicode and
more
 The package provides support for sorting
 dates, numbers, unicode, et. al.
 .
 This has the following features:
  *  Numbers are handled properly – “2” is before “10”
  *  Strings are after numbers
  *  Empty strings are after “z”
  *  “a” is before “B” (opt out via caseSensitive: true)
  *  Semver-compatible sorting of version numbers

I shall maintain this package.

Bug#963189: ITP: sorted-nearest: Cython helper library for pyranges

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: sorted-nearest
  Version : 0.0+git20200319.8204815+ds
  Upstream Author : Endre Bakken Stovner
* URL : https://github.com/pyranges/sorted_nearest
<https://github.com/knsv/mermaid>
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Cython helper library for pyranges

 Find nearest interval in linear time at C speed
 This is a pre-dependency and helper of pyranges.

I shall maintain this package.

Bug#963628: Node-jest fails with: Error: Cannot find module 'import-local'

[Nilesh Patra]

Package: node-jest
Severity: serious

Dear Maintainer,

Node-jest fails with the following on all the node-modules I've tried yet.
Sample examples on

node-compression-webpack-plugin version 2.0.0-3
and
node-proper-lockfile version 4.1.1-2

internal/modules/cjs/loader.js:800
throw err;
^

Error: Cannot find module 'import-local'
Require stack:
- /usr/share/nodejs/jest/bin/jest.js
at Function.Module._resolveFilename
(internal/modules/cjs/loader.js:797:15)
at Function.Module._load (internal/modules/cjs/loader.js:690:27)
at Module.require (internal/modules/cjs/loader.js:852:19)
at require (internal/modules/cjs/helpers.js:74:18)
at Object. (/usr/share/nodejs/jest/bin/jest.js:9:21)
at Module._compile (internal/modules/cjs/loader.js:959:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:995:10)
at Module.load (internal/modules/cjs/loader.js:815:32)
at Function.Module._load (internal/modules/cjs/loader.js:727:14)
at Function.Module.runMain (internal/modules/cjs/loader.js:1047:10) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [ '/usr/share/nodejs/jest/bin/jest.js' ]
}

Thanks!

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd

Bug#963927: predictprotein:Unusable, fails with: Assigning non-zero to $[ is no longer possible

[Nilesh Patra]

Package: predictprotein
Version: 1.1.09-2
Severity: severe

Dear Maintainer,

predictprotein uses `$[ = 1` which is no longer supported with newer
perl versions.
Way to reproduce:

Get the predictprotein source package, and cd there. Try running
examples with predictprotein:

$ cd examples
$ predictprotein --seqfile p53.fasta --output-dir test
Assigning non-zero to $[ is no longer possible at
/usr/share/librg-utils-perl//copf.pl line 11.
make: *** [/usr/share/predictprotein/MakefilePP.mk:475: query.fasta]
Error 255
make --no-builtin-rules INFILE=query.in -C /tmp/9BCtEP40vL JOBID=query
-j 1 BLASTCORES=1 LIBRGUTILS=/usr/share/librg-utils-perl/
PPROOT=/usr/share/predictprotein/ PROFNUMRESMIN=17
PROFROOT=/usr/share/profphd/prof/
BIGBLASTDB=/mnt/project/rost_db/data/blast/big
BIG80BLASTDB=/mnt/project/rost_db/data/blast/big_80
PFAM2DB=/mnt/project/rost_db/data/pfam/Pfam_ls
PFAM3DB=/mnt/project/rost_db/data/pfam/Pfam-A.hmm
PROSITEDAT=/mnt/project/rost_db/data/prosite/prosite.dat
PROSITECONVDAT=/mnt/project/rost_db/data/prosite/prosite_convert.dat
PSICEXE=/usr/share/rost-runpsic/runNewPSIC.pl
SPKEYIDX=/mnt/project/rost_db/data/swissprot/keyindex_loctree.txt
SWISSBLASTDB=/mnt/project/rost_db/data/blast/swiss --quiet -f
/usr/share/predictprotein/MakefilePP.mk all failed: 512 at
/usr/bin/predictprotein line 393.

Thanks

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd

Versions of packages predictprotein depends on:
ii  bioperl   1.7.7-1
ii  disulfinder   1.2.11-8
ii  hmmer 3.3+dfsg2-1
ii  hmmer2    2.3.2+dfsg-6
ii  librg-exception-perl  1.0.3-4
ii  librg-utils-perl  1.0.43-6
ii  make  4.2.1-1.2
ii  metastudent   2.0.1-8
ii  ncbi-blast+-legacy    2.9.0-4
ii  ncbi-seg  0.0.2620-5
ii  ncoils    2002-7
ii  norsnet   1.0.17-6
ii  norsp 1.0.6-4
ii  perl  5.30.0-10
ii  predictnls    1.0.20-6
ii  profbval  1.0.22-6
ii  profisis  1.0.11-5
ii  profphd   1.0.42-3
ii  proftmb   1.1.12-8+b1
ii  reprof    1.0.1-7

predictprotein recommends no packages.

Versions of packages predictprotein suggests:
pn  pp-cache-mgr    
ii  pp-popularity-contest   1.0.6-4+b1
pn  predictprotein-nonfree  

-- no debconf information

Bug#963927: Bug-report severity fix

[Nilesh Patra]

Control: severity -1 serious
thanks

Bug#962247: Required Configuration Files Not Found

[Nilesh Patra]

Hi,

On Fri, 5 Jun 2020 at 14:30, Andreas Tille  wrote:

> Hi Dario,
>
> thanks a lot for your bug report.  To bad that nobody reported before
> this issue which seems pretty obvious.  May be everybody is using circos
> with the --conf option (as our autopkgtest is doing it as well) and thus
> the issue was hidden.
>
> On Fri, Jun 05, 2020 at 02:00:13AM +, Dario Strbenac wrote:
> > Package: circos
> > Version: 0.69.6
> >
> > I think this software has not been correctly packaged. Running the
> circos command with no parameters results in
> >
> >   The Config::General module reported the error
> >   Config::General The file "etc/colors_fonts_patterns.conf" does not
> exist
> >   within ConfigPath:
> >
>  
> /etc/circos.circos.circos/etc./usr/bin/etc./usr/bin/../etc./usr/bin/.../usr/bin!
> >   at /usr/share/perl5/Circos/Configuration.pm line 820
> >
> > The server administrator at university investigated the c and explains
> "The issue is that it looked for file etc/colors_fonts_patterns.conf in
> various places including current directory and in /etc/circos, when that
> file was present as /etc/circos/colors_fonts_patterns.conf (while circos
> tried the name /etc/circos/etc/colors_fonts_patterns.conf with an extra or
> bogus /etc/ in the middle)."
>
> I've patched the code and moved some additional config files from
> examples to /etc/circos which helped to solve all these issues.
> Unfortunately there is a remaining one.  @Nilesh or @Pranav:  Do you
> have time to fix this one:
>
> /tmp $ circos
> debuggroup summary 0.17s welcome to circos v0.69-8 15 Jun 2019 on Perl
> 5.030002
> debuggroup summary 0.17s current working directory /tmp
> debuggroup summary 0.17s command /usr/bin/circos [no flags]
> debuggroup summary 0.17s guessing configuration file
> debuggroup summary 0.17s found conf file /usr/share/circos/etc/circos.conf
>
>   *** CIRCOS ERROR ***
>
>   cwd: /tmp
>
>   command: /usr/bin/circos
>
>   CONFIGURATION FILE ERROR
>
>   Error parsing the configuration file. You used an <>
> directive,
>   but the FILE could not be found. This FILE is interpreted relative to the
>   configuration file in which the <> directive is used. Circos
> lookd
>   for the file in these directories
>
>   /usr/share/circos/etc
>
>   /etc/circos
>
>   /usr/share/circos/etc
>
>   /usr/share/circos/etc/etc
>
>   /usr/bin/etc
>
>   /usr/bin/../etc
>
>   /usr/bin/..
>
>   /usr/bin
>
>   The Config::General module reported the error
>
>   Config::General The file "/usr/share/circos/fonts.conf" does not exist
> within
>   ConfigPath:
>
> /usr/share/circos/etc./etc/circos./usr/share/circos/etc./usr/share/circos/etc/etc./usr/bin/etc./usr/bin/../etc./usr/bin/.../usr/bin!
>   at /usr/share/perl5/Circos/Configuration.pm line 820.
>
>   If you are having trouble debugging this error, first read the best
> practices
>   tutorial for helpful tips that address many common problems
>
>
> http://www.circos.ca/documentation/tutorials/reference/best_practices
>
>   The debugging facility is helpful to figure out what's happening under
> the
>   hood
>
>   http://www.circos.ca/documentation/tutorials/configuration/debugging
>
>   If you're still stumped, get support in the Circos Google Group.
>
>   http://groups.google.com/group/circos-data-visualization
>
>   Please include this error, all your configuration, data files and the
> version
>   of Circos you're running (circos -v). Do not email me directly -- please
> use
>   the group.
>
>   Stack trace:
>  at /usr/share/perl5/Circos/Error.pm line 425.
> Circos::Error::fatal_error("configuration", "cannot_find_include",
> "/usr/share/circos/etc\x{a}/etc/circos\x{a}/usr/share/circos/etc\x{a}/usr/"...,
> "Config::General The file \"/usr/share/circos/fonts.conf\" does "...)
> called at /usr/share/perl5/Circos/Configuration.pm line 826
>
> Circos::Configuration::loadconfiguration("/usr/share/circos/etc/circos.conf")
> called at /usr/share/perl5/Circos.pm line 148
> Circos::run("Circos", "_cwd", "/tmp", "_argv", "") called at
> /usr/bin/circos line 538
>
>
> I admit I'm running out of ideas why the file
>
>   Config::General The file "/usr/share/circos/fonts.conf" does not
> exist within
>
> is seeked instead of  "/usr/share/circos/etc/fonts.conf" - may be that's
> a cause of the patches I did in debian/patches/fix_config_path.patch.
>
> Unfortunately I'm a bit running out of time to hunt this down finally.
>

This was so because the config files are full of (relative) hardcoded
paths.
I read up the documentation, only to realise that the code just works that
way i.e. with hardcoded relative paths: the only way to prevent this is to
add an absolute hard-coded path.
Hence, I replaced all the hardcoded paths with the installation paths
(which is also, in a way hard-coded). But this will likely work on all(most
of) GNU/Linux distributions and I suppose that's what we care about.
I've pushed a patch, please take a look if it looks right to you.

Kind Regards,

Bug#962085: bcalm, kissplice: both ship /usr/bin/bcalm

[Nilesh Patra]

Hi,

On Wed, 3 Jun 2020, 14:50 Andreas Tille,  wrote:

> Hi Andreas,
>
> thanks for spotting this.
>
> On Wed, Jun 03, 2020 at 09:41:12AM +0200, Andreas Beckmann wrote:
> > Package: bcalm,kissplice
> > Severity: serious
> > User: trei...@debian.org
> > Usertags: edos-file-overwrite
> > Control: found -1 bcalm/2.2.2-1.1
> > Control: found -1 kissplice/2.5.1-1
> > ...
> > Possible solution:
> >  * kissplice stops shipping /usr/bin/bcalm
> >  * bcalm adds Breaks+Replaces: kissplice (<< 2.5.1-2~) (assuming the
> >fixing upload of kissplice is 2.5.1-2)
>
> Seems since last version of kissplice it seems to include bcalm.
> @Nilesh: Would you mind sorting out with upstream which bcalm
> version is the one that will be actively supported?


When I was just drafting the mail regarding this, David replied to this
bug. I suppose they are already on this.
Thanks David!

Or is it
> just a code copy included into kissplice?  We also should remove
> the code copy of gatb-core and rather link against the Debian
> packaged lib.
>

Yep, probably we should remove gatb-core and symlink it/tweak the build
system if need be.
I simply fixed the autopkgtest and called it a day, assuming everything
else is in place.

Looks like my assumption was wrong, and I apologize for not checking rest
of the stuff, I really should have.

Kind Regards,
Nilesh

>

Bug#964610: nibabel: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.8 returned exit code 13

[Nilesh Patra]

On Tue, 21 Jul 2020 15:52:22 +0200 Andreas Tille  wrote:
> Control: tags -1 - upstream
> Control: tags -1 pending
>
> The build time test issue was solved thanks to upstream (switched from
> nose to pytest). Unfortunately there are now issues with sphinx to
> build the docs. My dirty workaroung did not worked so I simply added
> ' || true ' behind the sphinx call. This needs to be sorted out before
> uploading.
>
> Moreover autopkgtest should be switched from nose to pytest.
>
> Any help is welcome

I don't see such an error in the build log on my system. Pasting the
relevant part below:

PYTHONPATH=/<> /usr/bin/make -C doc html
SPHINXBUILD=/usr/share/sphinx/scripts/python3/sphinx-build PYTHON=python3
make[2]: Entering directory '/<>/doc'
mkdir -p ../build/html ../build/doctrees
python3 tools/build_modref_templates.py nibabel source/reference False
/usr/share/sphinx/scripts/python3/sphinx-build -b html -d
../build/doctrees   source ../build/html
/<>/doc/tools/apigen.py:210: UserWarning: The DICOM readers
are highly experimental, unstable, and only work for Siemens time-series
at the moment
Please use with caution.  We would be grateful for your help in
improving them
  mod = __import__(uri, fromlist=[uri.split('.')[-1]])
*** 3.1.1
Generating docs for nibabel:
  -> nibabel
Generating docs for nibabel._h5py_compat:
  -> nibabel._h5py_compat
WARNING: Empty - nibabel._h5py_compat
Generating docs for nibabel._version:
  -> nibabel._version
Generating docs for nibabel.affines:
  -> nibabel.affines
Generating docs for nibabel.analyze:
  -> nibabel.analyze
Generating docs for nibabel.arrayproxy:
  -> nibabel.arrayproxy
Generating docs for nibabel.arraywriters:
  -> nibabel.arraywriters
Generating docs for nibabel.batteryrunners:
  -> nibabel.batteryrunners
Generating docs for nibabel.benchmarks:
  -> nibabel.benchmarks
WARNING: Empty - nibabel.benchmarks
  -> nibabel.benchmarks.bench_array_to_file
  -> nibabel.benchmarks.bench_arrayproxy_slicing
  -> nibabel.benchmarks.bench_fileslice
  -> nibabel.benchmarks.bench_finite_range
  -> nibabel.benchmarks.bench_load_save
  -> nibabel.benchmarks.bench_streamlines
  -> nibabel.benchmarks.butils
Generating docs for nibabel.brikhead:
  -> nibabel.brikhead
Generating docs for nibabel.casting:
  -> nibabel.casting
Generating docs for nibabel.cifti2:
  -> nibabel.cifti2
WARNING: Empty - nibabel.cifti2
  -> nibabel.cifti2.cifti2
  -> nibabel.cifti2.cifti2_axes
  -> nibabel.cifti2.parse_cifti2
Generating docs for nibabel.cmdline:
  -> nibabel.cmdline
WARNING: Empty - nibabel.cmdline
  -> nibabel.cmdline.conform
  -> nibabel.cmdline.dicomfs
  -> nibabel.cmdline.diff
  -> nibabel.cmdline.ls
  -> nibabel.cmdline.nifti_dx
  -> nibabel.cmdline.parrec2nii
  -> nibabel.cmdline.tck2trk
  -> nibabel.cmdline.trk2tck
  -> nibabel.cmdline.utils
Generating docs for nibabel.data:
  -> nibabel.data
Generating docs for nibabel.dataobj_images:
  -> nibabel.dataobj_images
Generating docs for nibabel.deprecated:
  -> nibabel.deprecated
Generating docs for nibabel.deprecator:
  -> nibabel.deprecator
Generating docs for nibabel.dft:
  -> nibabel.dft
Generating docs for nibabel.ecat:
  -> nibabel.ecat
Generating docs for nibabel.environment:
  -> nibabel.environment
Generating docs for nibabel.eulerangles:
  -> nibabel.eulerangles
Generating docs for nibabel.filebasedimages:
  -> nibabel.filebasedimages
Generating docs for nibabel.fileholders:
  -> nibabel.fileholders
Generating docs for nibabel.filename_parser:
  -> nibabel.filename_parser
Generating docs for nibabel.fileslice:
  -> nibabel.fileslice
Generating docs for nibabel.fileutils:
  -> nibabel.fileutils
Generating docs for nibabel.freesurfer:
  -> nibabel.freesurfer
WARNING: Empty - nibabel.freesurfer
  -> nibabel.freesurfer.io
  -> nibabel.freesurfer.mghformat
Generating docs for nibabel.funcs:
  -> nibabel.funcs
Generating docs for nibabel.gifti:
  -> nibabel.gifti
WARNING: Empty - nibabel.gifti
  -> nibabel.gifti.gifti
  -> nibabel.gifti.giftiio
  -> nibabel.gifti.parse_gifti_fast
  -> nibabel.gifti.util
WARNING: Empty - nibabel.gifti.util
Generating docs for nibabel.imageclasses:
  -> nibabel.imageclasses
Generating docs for nibabel.imageglobals:
  -> nibabel.imageglobals
Generating docs for nibabel.keywordonly:
  -> nibabel.keywordonly
Generating docs for nibabel.loadsave:
  -> nibabel.loadsave
Generating docs for nibabel.minc1:
  -> nibabel.minc1
Generating docs for nibabel.minc2:
  -> nibabel.minc2
Generating docs for nibabel.mriutils:
  -> nibabel.mriutils
Generating docs for nibabel.nicom:
  -> nibabel.nicom
WARNING: Empty - nibabel.nicom
  -> nibabel.nicom.csareader
  -> nibabel.nicom.dicomreaders
  -> nibabel.nicom.dicomwrappers
  -> nibabel.nicom.dwiparams
  -> nibabel.nicom.structreader
  -> nibabel.nicom.utils
Generating docs for nibabel.nifti1:
  -> nibabel.nifti1
Generating docs for nibabel.nifti2:
  -> nibabel.nifti2
Generating docs for nibabel.onetime:
  -> nibabel.onetime
Generating docs for nibabel.openers:
  -> 

Bug#962863: r-cran-rdflib: autopkgtest regression

[Nilesh Patra]

On Mon, 15 Jun 2020 11:17:24 +0200 Graham Inggs  wrote:
> Source: r-cran-rdflib
> Version: 0.2.3+dfsg-1
> Severity: serious
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: regression
>
> Hi Maintainer
>
> Sometime in the last month, r-cran-rdflib started to fail its own
> autopkgtests [1].
> There's a failing migration-reference/0 test in testing on 2020-05-22
> which was before the new r-base migrated.
>
> I've copied what I hope is the relevant part of the log below.

I cannot seem to reproduce the error on my system (using a clean
chroot). Logs:

autopkgtest [17:46:54]: test pkg-r-autopkgtest: ---]
autopkgtest [17:46:54]: test pkg-r-autopkgtest:  - - - - - - - - - -
results - - - - - - - - - -
pkg-r-autopkgtest    PASS
autopkgtest [17:46:54]:  summary
run-unit-test    PASS
pkg-r-autopkgtest    PASS

In the test logs I observed that it _did_
pass on July 15 after it again started to fail yet again - weirdly
enough. Log here[1]
Is it randomly failing here, or is it error at my end?
I'm not sure, please let me know.
This is tagged for removal within a week now, and hence it'd be great if
I can get a response.

[1]:
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-rdflib/6273992/log.gz

Thanks and Regards,
Nilesh




signature.asc
Description: OpenPGP digital signature

Bug#965383: ITP: golang-github-tatsushid-go-prettytable: Builds a simple text table with a multibyte, doublewidth character support

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: golang-github-tatsushid-go-prettytable
  Version : 0.0~git20141013.ed2d14c-1
  Upstream Author : Tatsushi Demachi
* URL : https://github.com/tatsushid/go-prettytable
<https://github.com/knsv/mermaid>
* License : Expat
  Programming Lang: Golang
  Description : Builds a simple text table with a multibyte,
doublewidth character support

go-prettytable go-prettytable is a library for
 Golang to build a simple text table with a multibyte,
 doublewidth character support.

I shall maintain this package.

Bug#968045: golang-gonum-v1-plot: please make the build reproducible

[Nilesh Patra]

Hi again,

On Fri, 06 Nov 2020 09:18:34 + "Chris Lamb"  wrote:
> Chris Lamb wrote:
>
> > Source: golang-gonum-v1-plot
> > Version: 0.7.0-2
> > Tags: patch
>
> Gentle ping on the above?
>

Thanks again, but unfortunately this patch breaks the autopkgtests :/
The only way to make it reproducible and allow testing migration would
be to disable the tests.

What do you think would be better? Please let me know.
The tests currently are the default autodep8 ones - autopkgtest-pkg-go

Best Regards,
Nilesh

Bug#974178: python3-biom-format: debci tests fail: Object of type bytes is not JSON serializable

[Nilesh Patra]

Hi,

On Wed, 11 Nov 2020 11:56:10 +0800 Drew Parsons  wrote:
> Package: python3-biom-format
> Version: 2.1.9-2
> Severity: normal
>
> debci tests for python3-biom-format are show test error triggered by
> python3-h5py 3.1.0-1exp1 from experimental.
>
> The odd thing is that the error trace does not directly refer to h5py,
> it's a json problem:
>
> Traceback (most recent call last):
> File "/usr/lib/python3/dist-packages/biom/assets/exercise_api.py",
line 95, in 
> out.write(table.to_json('rc-testing'))
> File "/usr/lib/python3/dist-packages/biom/table.py", line 4720, in to_json
> dumps(samp[1]), dumps(samp[2])))
> File "/usr/lib/python3.8/json/__init__.py", line 231, in dumps
> return _default_encoder.encode(obj)
> File "/usr/lib/python3.8/json/encoder.py", line 199, in encode
> chunks = self.iterencode(o, _one_shot=True)
> File "/usr/lib/python3.8/json/encoder.py", line 257, in iterencode
> return _iterencode(o, 0)
> File "/usr/lib/python3.8/json/encoder.py", line 179, in default
> raise TypeError(f'Object of type {o.__class__.__name__} '
> TypeError: Object of type bytes is not JSON serializable
>

Thanks for this bug report!

Just uploaded a new upstream revision for python-biom-format, the
autopkgtests seem fine locally now:

autopkgtest [13:08:06]: test run-unit-test: [---

System information
==
 Platform:    linux
   Python version:    3.9.0+ (default, Oct 19 2020, 09:51:18)  [GCC 10.2.0]
Python executable:    /usr/bin/python3

Dependency versions
===
click version:    7.1.2
NumPy version:    1.19.4
SciPy version:    1.5.3
 h5py version:    3.1.0

biom-format package information
===
biom-format version:    2.1.10


The input file is a valid BIOM-formatted file.

The input file is a valid BIOM-formatted file.

The input file is a valid BIOM-formatted file.

The input file is a valid BIOM-formatted file.
+ table=examples/min_sparse_otu_table_hdf5.biom
+ obsmd=examples/obs_md.txt
+ [ ! -f examples/min_sparse_otu_table_hdf5.biom ]
+ biom show-install-info

System information
==
 Platform:    linux
   Python version:    3.9.0+ (default, Oct 19 2020, 09:51:18)  [GCC 10.2.0]
Python executable:    /usr/bin/python3

Dependency versions
===
click version:    7.1.2
NumPy version:    1.19.4
SciPy version:    1.5.3
 h5py version:    3.1.0

biom-format package information
===
biom-format version:    2.1.10

+ biom validate-table -i examples/min_sparse_otu_table_hdf5.biom

The input file is a valid BIOM-formatted file.
+ biom add-metadata -i examples/min_sparse_otu_table_hdf5.biom -o
test_add_metadata.biom --observation-metadata-fp examples/obs_md.txt
--sc-separated taxonomy
+ biom convert -i examples/min_sparse_otu_table_hdf5.biom -o
test_json.biom --to-json
+ biom convert -i examples/min_sparse_otu_table_hdf5.biom -o
test_tsv.txt --to-tsv
+ biom validate-table -i test_json.biom

The input file is a valid BIOM-formatted file.
+ biom convert -i test_json.biom -o test_hdf5.biom --to-hdf5
+ biom validate-table -i test_hdf5.biom

The input file is a valid BIOM-formatted file.
+ biom convert -i test_json.biom -o test_tsv.txt --to-tsv
+ biom convert -i test_tsv.txt -o test_hdf5.biom --to-hdf5 --table-type
OTU table
+ biom validate-table -i test_hdf5.biom

The input file is a valid BIOM-formatted file.
+ biom convert -i test_tsv.txt -o test_json.biom --to-json --table-type
OTU table
+ biom validate-table -i test_json.biom

The input file is a valid BIOM-formatted file.
+ biom head -i examples/min_sparse_otu_table_hdf5.biom
# Constructed from biom file
#OTU ID    Sample1    Sample2    Sample3    Sample4    Sample5
GG_OTU_1    0.0    0.0    1.0    0.0    0.0
GG_OTU_2    5.0    1.0    0.0    2.0    3.0
GG_OTU_3    0.0    0.0    1.0    4.0    0.0
GG_OTU_4    2.0    1.0    1.0    0.0    0.0
GG_OTU_5    0.0    1.0    1.0    0.0    0.0
+ biom table-ids -i examples/min_sparse_otu_table_hdf5.biom
Sample1
Sample2
Sample3
Sample4
Sample5
Sample6
+ biom normalize-table -i examples/min_sparse_otu_table_hdf5.biom -o
test_norm.biom -p
+ cat
+ biom subset-table -i examples/min_sparse_otu_table_hdf5.biom -o
test_subset.biom -a observation -s ids.txt
/usr/lib/python3/dist-packages/biom/table.py:4077: FutureWarning: arrays
to stack must be passed as a "sequence" type such as list or tuple.
Support for non-sequence iterables such as generators is deprecated as
of NumPy 1.16 and will raise an error in the future.
  data = np.hstack(h5_data[start:end]
/usr/lib/python3/dist-packages/biom/table.py:4079: FutureWarning: arrays
to stack must be passed as a "sequence" type such as list or tuple.
Support for non-sequence iterables such as generators is deprecated as
of NumPy 1.16 and will raise an error in the future.
  indices = np.hstack(h5_indices[start:end]
+ biom summarize-table -i examples/min_sparse_otu_table_hdf5.biom
Num samples: 6
Num observations: 5
Total count: 27
Table density 

Bug#976497: python-parasail: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13 Inbox [Imap]/Sent

[Nilesh Patra]

Control:  forwarded -1
https://github.com/jeffdaily/parasail-python/issues/56

Forwarded the issue upstream, hopefully we will have a fix soonish with
arm64 becoming more popular.

Bug#976497: python-parasail: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13

[Nilesh Patra]

Control: tags -1 help

Hi Debian Arm team,

I've no clue of where to even start debugging this. Any help/hints are welcome 
and highly appreciated.

Thanks and regards
Nilesh


On Sat, 5 Dec 2020 13:51:16 +0100 Lucas Nussbaum  wrote:
> Source: python-parasail
> Version: 1.2.1-1
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on arm64 (I don't know if it also fails on amd64).
>
> Relevant part (hopefully):
> > dpkg-buildpackage
> > -
> >
> > Command: dpkg-buildpackage -us -uc -sa -rfakeroot
> > dpkg-buildpackage: info: source package python-parasail
> > dpkg-buildpackage: info: source version 1.2.1-1
> > dpkg-buildpackage: info: source distribution unstable
> > dpkg-buildpackage: info: source changed by Nilesh Patra 
> > 
> > dpkg-source --before-build .
> > dpkg-buildpackage: info: host architecture arm64
> > debian/rules clean
> > dh clean --with python3 --buildsystem=pybuild
> > dh_auto_clean -O--buildsystem=pybuild
> > I: pybuild base:232: python3.9 setup.py clean
> > running clean
> > removing '/<>/.pybuild/cpython3_3.9/build' (and everything 
> > under it)
> > 'build/bdist.linux-arm64' does not exist -- can't clean it
> > 'build/scripts-3.9' does not exist -- can't clean it
> > dh_autoreconf_clean -O--buildsystem=pybuild
> > dh_clean -O--buildsystem=pybuild
> > dpkg-source -b .
> > dpkg-source: info: using source format '3.0 (quilt)'
> > dpkg-source: info: building python-parasail using existing 
> > ./python-parasail_1.2.1.orig.tar.gz
> > dpkg-source: info: using patch list from debian/patches/series
> > dpkg-source: info: building python-parasail in 
> > python-parasail_1.2.1-1.debian.tar.xz
> > dpkg-source: info: building python-parasail in python-parasail_1.2.1-1.dsc
> > debian/rules binary
> > dh binary --with python3 --buildsystem=pybuild
> > dh_update_autotools_config -O--buildsystem=pybuild
> > dh_autoreconf -O--buildsystem=pybuild
> > dh_auto_configure -O--buildsystem=pybuild
> > I: pybuild base:232: python3.9 setup.py config
> > running config
> > dh_auto_build -O--buildsystem=pybuild
> > I: pybuild base:232: /usr/bin/python3 setup.py build
> > running build
> > running build_py
> > creating /<>/.pybuild/cpython3_3.9/build/parasail
> > copying parasail/bindings_v2.py -> 
> > /<>/.pybuild/cpython3_3.9/build/parasail
> > copying parasail/__init__.py -> 
> > /<>/.pybuild/cpython3_3.9/build/parasail
> > copying parasail/bindings_v1.py -> 
> > /<>/.pybuild/cpython3_3.9/build/parasail
> > dh_auto_test -O--buildsystem=pybuild
> > I: pybuild base:232: cd /<>/.pybuild/cpython3_3.9/build; 
> > python3.9 -m pytest tests
> > = test session starts 
> > ==
> > platform linux -- Python 3.9.1rc1, pytest-4.6.11, py-1.9.0, pluggy-0.13.0
> > rootdir: /<>
> > collected 16 items
> > tests/test_basic.py ...Segmentation fault
>> E: pybuild pybuild:353: test: plugin distutils failed with: exit code=139: 
>> cd /<>/.pybuild/cpython3_3.9/build; python3.9 -m pytest tests 
>> >> dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 
>> 3.9 returned exit code 13





signature.asc
Description: OpenPGP digital signature

Bug#976497: python-parasail: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13

[Nilesh Patra]

Control: tags -1 help


Hi Debian Arm team,

I've no clue of where to even start debugging this. Any help/hints are welcome 
and highly appreciated.

Thanks and regards
Nilesh


On Sat, 5 Dec 2020 13:51:16 +0100 Lucas Nussbaum  wrote:
> Source: python-parasail
> Version: 1.2.1-1
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on arm64 (I don't know if it also fails on amd64).
>
> Relevant part (hopefully):
>> dpkg-buildpackage
>> -
>>
>> Command: dpkg-buildpackage -us -uc -sa -rfakeroot
>> dpkg-buildpackage: info: source package python-parasail
>> dpkg-buildpackage: info: source version 1.2.1-1
>> dpkg-buildpackage: info: source distribution unstable
>> dpkg-buildpackage: info: source changed by Nilesh Patra 
>> dpkg-source --before-build .
>> dpkg-buildpackage: info: host architecture arm64
>> debian/rules clean
>> dh clean --with python3 --buildsystem=pybuild
>> dh_auto_clean -O--buildsystem=pybuild
>> I: pybuild base:232: python3.9 setup.py clean
>> running clean
>> removing '/<>/.pybuild/cpython3_3.9/build' (and everything 
>> under it)
>> 'build/bdist.linux-arm64' does not exist -- can't clean it
>> 'build/scripts-3.9' does not exist -- can't clean it
>> dh_autoreconf_clean -O--buildsystem=pybuild
>> dh_clean -O--buildsystem=pybuild
>> dpkg-source -b .
>> dpkg-source: info: using source format '3.0 (quilt)'
>> dpkg-source: info: building python-parasail using existing 
>> ./python-parasail_1.2.1.orig.tar.gz
>> dpkg-source: info: using patch list from debian/patches/series
>> dpkg-source: info: building python-parasail in 
>> python-parasail_1.2.1-1.debian.tar.xz
>> dpkg-source: info: building python-parasail in python-parasail_1.2.1-1.dsc
>> debian/rules binary
>> dh binary --with python3 --buildsystem=pybuild
>> dh_update_autotools_config -O--buildsystem=pybuild
>> dh_autoreconf -O--buildsystem=pybuild
>> dh_auto_configure -O--buildsystem=pybuild
>> I: pybuild base:232: python3.9 setup.py config
>> running config
>> dh_auto_build -O--buildsystem=pybuild
>> I: pybuild base:232: /usr/bin/python3 setup.py build
>> running build
>> running build_py
>> creating /<>/.pybuild/cpython3_3.9/build/parasail
>> copying parasail/bindings_v2.py -> 
>> /<>/.pybuild/cpython3_3.9/build/parasail
>> copying parasail/__init__.py -> 
>> /<>/.pybuild/cpython3_3.9/build/parasail
>> copying parasail/bindings_v1.py -> 
>> /<>/.pybuild/cpython3_3.9/build/parasail
>> dh_auto_test -O--buildsystem=pybuild
>> I: pybuild base:232: cd /<>/.pybuild/cpython3_3.9/build; 
>> python3.9 -m pytest tests
>> = test session starts 
>> ==
>> platform linux -- Python 3.9.1rc1, pytest-4.6.11, py-1.9.0, pluggy-0.13.0
>> rootdir: /<>
>> collected 16 items
>> tests/test_basic.py ...Segmentation fault
>> E: pybuild pybuild:353: test: plugin distutils failed with: exit code=139: 
>> cd /<>/.pybuild/cpython3_3.9/build; python3.9 -m pytest tests 
>> >> dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 
>> 3.9 returned exit code 







signature.asc
Description: OpenPGP digital signature

Bug#976479: [Request for help] Bug: #976479 scrappie: FTBFS: scrappie_matrix.h:5:14: fatal error: immintrin.h: No such file or directory

[Nilesh Patra]

Hi Michael and others,

Scrappie looks like a candidate where we can use the simde trick.
I tried doing a patch, and it works on amd64 machine, but not on an arm64 
porter box :/ (with issues with __v4sf)

And I'm not sure how to fix this, and hence this is a humble request to please 
take a look - and any help/hints would be really great.
My patch is pushed to salsa[1]
I'm also sorry if these pings are somehow irritating, since I need help 
admittedly.

[1]: https://salsa.debian.org/med-team/scrappie

Pasting the (relevant part of) failing arm64 log:

make[1]: Entering directory '/home/nilesh/scrappie/scrappie'
mkdir build
cd build && \
cmake .. -DCMAKE_BUILD_TYPE=Release && \
make
-- The C compiler identification is GNU 10.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Performing Test HAS_OPENMP
-- Performing Test HAS_OPENMP - Success
-- Looking for hdf5.h
-- Looking for hdf5.h - not found
-- Looking for hdf5/serial/hdf5.h
-- Looking for hdf5/serial/hdf5.h - found
-- Configuring done
-- Generating done
-- Build files have been written to: /home/nilesh/scrappie/scrappie/build
make[2]: Entering directory '/home/nilesh/scrappie/scrappie/build'
make[2]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
rule.
make[3]: Entering directory '/home/nilesh/scrappie/scrappie/build'
make[4]: Entering directory '/home/nilesh/scrappie/scrappie/build'
Scanning dependencies of target scrappie_objects
make[4]: Leaving directory '/home/nilesh/scrappie/scrappie/build'
make[4]: Entering directory '/home/nilesh/scrappie/scrappie/build'
[  2%] Building C object CMakeFiles/scrappie_objects.dir/src/decode.c.o
In file included from /usr/include/simde/x86/avx.h:27,
 from /home/nilesh/scrappie/scrappie/src/scrappie_matrix.h:6,
 from /home/nilesh/scrappie/scrappie/src/decode.h:5,
 from /home/nilesh/scrappie/scrappie/src/decode.c:3:
/home/nilesh/scrappie/scrappie/src/sse_mathfun.h: In function 'log_ps':
/home/nilesh/scrappie/scrappie/src/sse_mathfun.h:106:22: warning: dereferencing 
type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
  106 |   x = _mm_max_ps(x, *(v4sf*)_ps_min_norm_pos);  /* cut off denormalized 
stuff */
  |  ^~~
In file included from /usr/include/simde/x86/avx.h:27,
 from /home/nilesh/scrappie/scrappie/src/scrappie_matrix.h:6,
 from /home/nilesh/scrappie/scrappie/src/decode.h:5,
 from /home/nilesh/scrappie/scrappie/src/decode.c:3:
/home/nilesh/scrappie/scrappie/src/sse_mathfun.h:110:22: warning: dereferencing 
type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
  110 |   x = _mm_and_ps(x, *(v4sf*)_ps_inv_mant_mask);
  |  ^~~~
In file included from /usr/include/simde/x86/sse3.h:30,
 from /usr/include/simde/x86/ssse3.h:30,
 from /usr/include/simde/x86/sse4.1.h:31,
 from /usr/include/simde/x86/sse4.2.h:31,
 from /usr/include/simde/x86/avx.h:31,
 from /home/nilesh/scrappie/scrappie/src/scrappie_matrix.h:6,
 from /home/nilesh/scrappie/scrappie/src/decode.h:5,
 from /home/nilesh/scrappie/scrappie/src/decode.c:3:
/home/nilesh/scrappie/scrappie/src/sse_mathfun.h:113:31: warning: dereferencing 
type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
  113 |   emm0 = _mm_sub_epi32(emm0, *(v4si*)_pi32_0x7f);
  |   ^
In file included from /usr/include/simde/x86/sse3.h:30,
 from /usr/include/simde/x86/ssse3.h:30,
 from /usr/include/simde/x86/sse4.1.h:31,
 from /usr/include/simde/x86/sse4.2.h:31,
 from /usr/include/simde/x86/avx.h:31,
 from /home/nilesh/scrappie/scrappie/src/scrappie_matrix.h:6,
 from /home/nilesh/scrappie/scrappie/src/decode.h:5,
 from /home/nilesh/scrappie/scrappie/src/decode.c:3:
/home/nilesh/scrappie/scrappie/src/sse_mathfun.h: In function 'exp_ps':
/home/nilesh/scrappie/scrappie/src/sse_mathfun.h:228:31: warning: dereferencing 
type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
  228 |   emm0 = _mm_add_epi32(emm0, *(v4si*)_pi32_0x7f);
  |   ^
In file included from /usr/include/simde/x86/avx.h:27,
 from /home/nilesh/scrappie/scrappie/src/scrappie_matrix.h:6,
 from /home/nilesh/scrappie/scrappie/src/decode.h:5,
 from /home/nilesh/scrappie/scrappie/src/decode.c:3:
/home/nilesh/scrappie/scrappie/src/sse_mathfun.h: In function 'sin_ps':
/home/nilesh/scrappie/scrappie/src/sse_mathfun.h:281:22: warning: dereferencing 

Bug#976479: [Request for help] Bug: #976479 scrappie: FTBFS: scrappie_matrix.h:5:14: fatal error: immintrin.h: No such file or directory

[Nilesh Patra]

Hi Michael

Thanks for the hint, I did this (not yet pushed):

-#include 
-
 /* yes I know, the top of this file is quite ugly */

+define SIMDE_ENABLE_NATIVE_ALIASES
+#include 

But I end up with the same error that I pasted earlier. Am I missing
something in the hint?
Please let me know.
(I checked the code for xmmintrin.h and indeed the typedef should be
included on the above diff simde patch - I've no idea why this doesn't.)

On Mon, 7 Dec 2020 at 16:04, Michael Crusoe 
wrote:

> Hey Nilesh,
>
> No problem for me when you ask for help!
>
> I suspect that
> https://salsa.debian.org/med-team/scrappie/-/commit/a00691d910110a460ef5e61a6c74cc2cb0e1a626#5dc91bdd30262777c0556235b73413cd5865a144_0_31
> is the issue
> You should add the regular simde includes here, so that v4sf typedef works
>
> define SIMDE_ENABLE_NATIVE_ALIASES#include 
>
>
>
> On Mon, 7 Dec 2020 at 11:28, Nilesh Patra  wrote:
>
>> Hi Michael and others,
>>
>> Scrappie looks like a candidate where we can use the simde trick.
>> I tried doing a patch, and it works on amd64 machine, but not on an arm64
>> porter box :/ (with issues with __v4sf)
>>
>> And I'm not sure how to fix this, and hence this is a humble request to
>> please take a look - and any help/hints would be really great.
>> My patch is pushed to salsa[1]
>> I'm also sorry if these pings are somehow irritating, since I need help
>> admittedly.
>>
>> [1]: https://salsa.debian.org/med-team/scrappie
>>
>> Pasting the (relevant part of) failing arm64 log:
>>
>> make[1]: Entering directory '/home/nilesh/scrappie/scrappie'
>> mkdir build
>> cd build && \
>> cmake .. -DCMAKE_BUILD_TYPE=Release && \
>> make
>> -- The C compiler identification is GNU 10.2.0
>> -- Detecting C compiler ABI info
>> -- Detecting C compiler ABI info - done
>> -- Check for working C compiler: /usr/bin/cc - skipped
>> -- Detecting C compile features
>> -- Detecting C compile features - done
>> -- Performing Test HAS_OPENMP
>> -- Performing Test HAS_OPENMP - Success
>> -- Looking for hdf5.h
>> -- Looking for hdf5.h - not found
>> -- Looking for hdf5/serial/hdf5.h
>> -- Looking for hdf5/serial/hdf5.h - found
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to: /home/nilesh/scrappie/scrappie/build
>> make[2]: Entering directory '/home/nilesh/scrappie/scrappie/build'
>> make[2]: warning: jobserver unavailable: using -j1.  Add '+' to parent
>> make rule.
>> make[3]: Entering directory '/home/nilesh/scrappie/scrappie/build'
>> make[4]: Entering directory '/home/nilesh/scrappie/scrappie/build'
>> Scanning dependencies of target scrappie_objects
>> make[4]: Leaving directory '/home/nilesh/scrappie/scrappie/build'
>> make[4]: Entering directory '/home/nilesh/scrappie/scrappie/build'
>> [  2%] Building C object CMakeFiles/scrappie_objects.dir/src/decode.c.o
>> In file included from /usr/include/simde/x86/avx.h:27,
>>  from
>> /home/nilesh/scrappie/scrappie/src/scrappie_matrix.h:6,
>>  from /home/nilesh/scrappie/scrappie/src/decode.h:5,
>>  from /home/nilesh/scrappie/scrappie/src/decode.c:3:
>> /home/nilesh/scrappie/scrappie/src/sse_mathfun.h: In function 'log_ps':
>> /home/nilesh/scrappie/scrappie/src/sse_mathfun.h:106:22: warning:
>> dereferencing type-punned pointer will break strict-aliasing rules
>> [-Wstrict-aliasing]
>>   106 |   x = _mm_max_ps(x, *(v4sf*)_ps_min_norm_pos);  /* cut off
>> denormalized stuff */
>>   |  ^~~
>> In file included from /usr/include/simde/x86/avx.h:27,
>>  from
>> /home/nilesh/scrappie/scrappie/src/scrappie_matrix.h:6,
>>  from /home/nilesh/scrappie/scrappie/src/decode.h:5,
>>  from /home/nilesh/scrappie/scrappie/src/decode.c:3:
>> /home/nilesh/scrappie/scrappie/src/sse_mathfun.h:110:22: warning:
>> dereferencing type-punned pointer will break strict-aliasing rules
>> [-Wstrict-aliasing]
>>   110 |   x = _mm_and_ps(x, *(v4sf*)_ps_inv_mant_mask);
>>   |  ^~~~
>> In file included from /usr/include/simde/x86/sse3.h:30,
>>  from /usr/include/simde/x86/ssse3.h:30,
>>  from /usr/include/simde/x86/sse4.1.h:31,
>>  from /usr/include/simde/x86/sse4.2.h:31,
>>  from /usr/include/simde/x86/avx.h:31,
>>  from
>> /home/nilesh/scrappie/scrappie/src/scrappie_matrix.h:6,
>>  from /home/n

Bug#976479: [Request for help] Bug: #976479 scrappie: FTBFS: scrappie_matrix.h:5:14: fatal error: immintrin.h: No such file or directory

[Nilesh Patra]

Hi again,

Since that didn't work, I manually added a typedef definition for it, and
it works now on both am64 machine and arm64 porter box - with passing
build-time tests.
I've pushed to salsa.

I'd be really grateful if you could take a look at my changes and let me
know if they look fine.

Also, another question: This package has a MPL-2.0 license and AFAIK, MPL
is a restrictive Free software license, so does this qualify for adding in
a "Built-Using" field?

Thanks and regards
Nilesh

On Mon, 7 Dec 2020 at 16:19, Nilesh Patra  wrote:

> Hi Michael
>
> Thanks for the hint, I did this (not yet pushed):
>
> -#include 
> -
>  /* yes I know, the top of this file is quite ugly */
>
> +define SIMDE_ENABLE_NATIVE_ALIASES
> +#include 
>
> But I end up with the same error that I pasted earlier. Am I missing
> something in the hint?
> Please let me know.
> (I checked the code for xmmintrin.h and indeed the typedef should be
> included on the above diff simde patch - I've no idea why this doesn't.)
>
> On Mon, 7 Dec 2020 at 16:04, Michael Crusoe 
> wrote:
>
>> Hey Nilesh,
>>
>> No problem for me when you ask for help!
>>
>> I suspect that
>> https://salsa.debian.org/med-team/scrappie/-/commit/a00691d910110a460ef5e61a6c74cc2cb0e1a626#5dc91bdd30262777c0556235b73413cd5865a144_0_31
>> is the issue
>> You should add the regular simde includes here, so that v4sf typedef works
>>
>> define SIMDE_ENABLE_NATIVE_ALIASES#include 
>>
>>
>>
>> On Mon, 7 Dec 2020 at 11:28, Nilesh Patra  wrote:
>>
>>> Hi Michael and others,
>>>
>>> Scrappie looks like a candidate where we can use the simde trick.
>>> I tried doing a patch, and it works on amd64 machine, but not on an
>>> arm64 porter box :/ (with issues with __v4sf)
>>>
>>> And I'm not sure how to fix this, and hence this is a humble request to
>>> please take a look - and any help/hints would be really great.
>>> My patch is pushed to salsa[1]
>>> I'm also sorry if these pings are somehow irritating, since I need help
>>> admittedly.
>>>
>>> [1]: https://salsa.debian.org/med-team/scrappie
>>>
>>> Pasting the (relevant part of) failing arm64 log:
>>>
>>> make[1]: Entering directory '/home/nilesh/scrappie/scrappie'
>>> mkdir build
>>> cd build && \
>>> cmake .. -DCMAKE_BUILD_TYPE=Release && \
>>> make
>>> -- The C compiler identification is GNU 10.2.0
>>> -- Detecting C compiler ABI info
>>> -- Detecting C compiler ABI info - done
>>> -- Check for working C compiler: /usr/bin/cc - skipped
>>> -- Detecting C compile features
>>> -- Detecting C compile features - done
>>> -- Performing Test HAS_OPENMP
>>> -- Performing Test HAS_OPENMP - Success
>>> -- Looking for hdf5.h
>>> -- Looking for hdf5.h - not found
>>> -- Looking for hdf5/serial/hdf5.h
>>> -- Looking for hdf5/serial/hdf5.h - found
>>> -- Configuring done
>>> -- Generating done
>>> -- Build files have been written to: /home/nilesh/scrappie/scrappie/build
>>> make[2]: Entering directory '/home/nilesh/scrappie/scrappie/build'
>>> make[2]: warning: jobserver unavailable: using -j1.  Add '+' to parent
>>> make rule.
>>> make[3]: Entering directory '/home/nilesh/scrappie/scrappie/build'
>>> make[4]: Entering directory '/home/nilesh/scrappie/scrappie/build'
>>> Scanning dependencies of target scrappie_objects
>>> make[4]: Leaving directory '/home/nilesh/scrappie/scrappie/build'
>>> make[4]: Entering directory '/home/nilesh/scrappie/scrappie/build'
>>> [  2%] Building C object CMakeFiles/scrappie_objects.dir/src/decode.c.o
>>> In file included from /usr/include/simde/x86/avx.h:27,
>>>  from
>>> /home/nilesh/scrappie/scrappie/src/scrappie_matrix.h:6,
>>>  from /home/nilesh/scrappie/scrappie/src/decode.h:5,
>>>  from /home/nilesh/scrappie/scrappie/src/decode.c:3:
>>> /home/nilesh/scrappie/scrappie/src/sse_mathfun.h: In function 'log_ps':
>>> /home/nilesh/scrappie/scrappie/src/sse_mathfun.h:106:22: warning:
>>> dereferencing type-punned pointer will break strict-aliasing rules
>>> [-Wstrict-aliasing]
>>>   106 |   x = _mm_max_ps(x, *(v4sf*)_ps_min_norm_pos);  /* cut off
>>> denormalized stuff */
>>>   |  ^~~
>>> In file included from /usr/include/simde/x86/avx.h:27,
>>>  from
>>> /home/nilesh/scrappie/scrappie/src/scrappie_

Bug#976479: [Request for help] Bug: #976479 scrappie: FTBFS: scrappie_matrix.h:5:14: fatal error: immintrin.h: No such file or directory

[Nilesh Patra]

Hi o/

First of all, thank you for the fixes and letting me know about
cowbuilder-dist :-)

On Mon, 7 Dec 2020 at 17:51, Michael Crusoe 
wrote:

>
> I'd be really grateful if you could take a look at my changes and let me
>> know if they look fine.
>>
>
> I'll leave comments on Salsa
>

Thanks a lot, cherry-picked + pulled the changes mentioned.


>
> Have you been sending PRs and otherwise forwarding your patches upstream?
>

Yeah, I almost always do the needed forwards. I did 2 simde fixes before
this one - for plast and ngmlr.
I forwarded the patch for plast upstream[1] and I'll forward for ngmlr in
some more days - since this seems to need more changes in the upstream
codebase (I don't exactly remember what exactly, but this is in my TODO)

[1]: https://github.com/PLAST-software/plast-library/pull/8


>
>
>>
>> Also, another question: This package has a MPL-2.0 license and AFAIK, MPL
>> is a restrictive Free software license, so does this qualify for adding in
>> a "Built-Using" field?
>>
>
> Re-reading https://wiki.debian.org/SIMDEverywhere#Approach item 6, we see
> "if the source package requires the full source code be available"
>
> Does the MPL have this requirement?
>

I skimmed through /usr/share/common-licenses/MPL-2.0 but admittedly, it is
still not very clear to me. From what I read, it looks like the answer is
yes for this question, but I'm not completely confident about it.
Do you think we should ask debian-legal? - This seems like the last blocker
for an upload now


On Mon, 7 Dec 2020 at 18:06, Michael Crusoe 
wrote:

> Don't forget step 8 of https://wiki.debian.org/SIMDEverywhere#Approach ;
> I've updated the sample scripts for multi-compiling x86 at different SIMD
> levels
>

Done and pushed. it took me quite a while to figure this out. Two questions
though:
1) We are fundamentally doing this because we want to build this for all
possible compilation flags right? - and in the dispatch script we are
trying to figure out the most efficient implementation and use the binary
for the same?
2) Could you please review the changes once? Works fine everywhere IMO

BTW I noticed that the rules file which was initially just around 10 lines
increased by approximately an order of magnitude because I had to almost
handcraft the makefile to do various stuff, and I observed a similar
phenomenon for kalign and mmseqs2 where you made similar changes.
My intent here is to say - I (vaguely)wonder can we make a tool/helper that
can _automate_ the entire process while using simde to reduce handcrafted
stuff?
Because fundamentally we seem to be making similar changes everywhere.
And ofcourse, apologies if this doesn't sound good.


> Please also update https://wiki.debian.org/SIMDEverywhere#Packages_Status
> & https://wiki.debian.org/SIMDEverywhere#Candidate_packages as you add
> SIMDe support to packages.
>

I'll definitely update this in the next couple of days.

Kind Regards,
Nilesh

Bug#976479: [Request for help] Bug: #976479 scrappie: FTBFS: scrappie_matrix.h:5:14: fatal error: immintrin.h: No such file or directory

[Nilesh Patra]

[update]

On Mon, 7 Dec 2020 at 22:27, Nilesh Patra  wrote:

>
>
>>
>>>
>>> Also, another question: This package has a MPL-2.0 license and AFAIK,
>>> MPL is a restrictive Free software license, so does this qualify for adding
>>> in a "Built-Using" field?
>>>
>>
>> Re-reading https://wiki.debian.org/SIMDEverywhere#Approach item 6, we
>> see
>> "if the source package requires the full source code be available"
>>
>> Does the MPL have this requirement?
>>
>
> I skimmed through /usr/share/common-licenses/MPL-2.0 but admittedly, it is
> still not very clear to me. From what I read, it looks like the answer is
> yes for this question, but I'm not completely confident about it.
> Do you think we should ask debian-legal? - This seems like the last
> blocker for an upload now
>

I asked around, and I got an ACK that MPL-2.0 qualifies this criterion.
But...
just a quick question - are there code copies of simde that are being
included in the target source package? Or is it _somehow_statically linked?
Since according to policy we use Built-Using only in these situations. I'm
not fully certain about it

Could you please let me know?

Thanks and regards
Nilesh

Bug#962184: [Help] Re: jellyfish FTBFS on 32bit

[Nilesh Patra]

Hi Andreas,

On Thu, 3 Dec 2020 at 03:04, Andreas Tille  wrote:

> Control: tags -1 help
>
> Hi,
>
> I guess this bug is relatively easy to fix by some explicit typing - but
> I'm lacking the C++ knowledge to find out where.
>

Attaching a patch for this, it goes past this.
However, the build-time tests fail on 32-bit arches - on exploring the test
files, it looks like (with some confidence at least) that its due to large
valued numbers in test files, which is (probably) beyond what a 32-bit arch
can digest.

Maybe it is sensible to disable tests (both build-time and autopkgtest) for
that 32-bit arch, but I leave that up to you to check and decide :-)

Kind regards
Nilesh
--- a/include/jellyfish/rectangular_binary_matrix.hpp
+++ b/include/jellyfish/rectangular_binary_matrix.hpp
@@ -118,7 +118,7 @@
   uint64_t *p = _columns;
   while(*p == 0 && p < _columns + _c)
 ++p;
-  return (p - _columns) == _c;
+  return static_cast(p - _columns) == _c;
 }
 
 // Randomize the content of the matrix
--- a/include/jellyfish/mer_dna.hpp
+++ b/include/jellyfish/mer_dna.hpp
@@ -693,7 +693,7 @@
 
   char buffer[mer.k() + 1];
   is.read(buffer, mer.k());
-  if(is.gcount() != mer.k())
+  if(static_cast(is.gcount()) != mer.k())
 goto error;
   buffer[mer.k()] = '\0';
   if(!mer.from_chars(buffer))
--- a/unit_tests/test_mer_dna.cc
+++ b/unit_tests/test_mer_dna.cc
@@ -466,7 +466,7 @@
 
 // Get bits by right-shifting
 typename TypeParam::Type cm(m);
-for(unsigned int j = 1; j < start; j += 2)
+for(unsigned long int j = 1; start>=0 && j < static_cast(start); j += 2)
   cm.shift_right(0); // Shift by 2 bits
 typename TypeParam::Type::base_type y = cm.word(0);
 if(start & 0x1)

Bug#977308: shasta: hardcoded dependencies on boost 1.71

[Nilesh Patra]

Hi Andreas,

On Fri, 18 Dec 2020 at 15:53, Andreas Tille  wrote:

> Control: tags -1 help
>
> Hi,
>
> I tried to fix the issue by making dh_shlibdeps work.  In
>
>
> https://salsa.debian.org/med-team/shasta/-/commit/366edd672be428cc553b34b99bc614aa698175d6
>
> I documented what I tried but all failed and I think the key to this bug
> is just making it work.
>
> Any idea?
>

I've no clue. The "-l" flag doesn't seem to work somehow. May I suggest
forwarding it to the list? I'm positive that Aaron (ucko) will definitely
know a good workaround for this bit.
Also another request: Could you please as well attach the failing logs in
future RFHs? This saves atleast one build for the others. Consider my best
of intentions.

Regards

Bug#976907: golang-github-boltdb-bolt: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: cd obj-powerpc64le-linux-gnu && go test -vet=off -v -p 160 -short github.com/boltdb/bolt github.co

[Nilesh Patra]

Hi Andreas,

On Sat, 12 Dec 2020 18:48:52 +0100 Andreas Henriksson  wrote:
> Hello again,
>
> So after wasting my time here I finally realized that apparently
> boltdb is archived upstream. It will not receive any fixes.
>
> Apparently golang-github-coreos-bbolt is a maintained feature-extended
> fork. We should likely encurage moving to that and get boltdb removed
> from debian.
>
> The timeout waiting for db.mmaplock that occurred in boltdb is
> apparently already fixed in bbolt, see:
> https://github.com/etcd-io/bbolt/commit/e06ec0a754bc30c2e17ad871962e71635bf94d45
>
> The pagesize issue seems to plague them both still though.
>
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976926
> for the bug report against bbolt.

Thanks a lot for investigating! The problem with removing this 'right now' is 
that there are a few (important) reverse-dependencies and reverse-build-deps 
that this package has.

$ reverse-depends golang-github-boltdb-bolt-dev  
Reverse-Depends
* golang-github-blevesearch-bleve-dev
* golang-github-hashicorp-nomad-dev
* golang-github-hashicorp-raft-boltdb-dev
* golang-github-influxdb-influxdb-dev


$ reverse-depends golang-github-boltdb-bolt-dev -b
Reverse-Testsuite-Triggers
* snapd

Reverse-Build-Depends
* docker-libkv
* etcd
* go-dep
* golang-github-blevesearch-bleve
* golang-github-hashicorp-raft-boltdb
* influxdb
* nomad
* snapd
* vuls

Can simply replacing the dependency in all of them with bbolt work?
This may also need upstream patching in the future.
Please let me know

Kind Regards,
Nilesh



signature.asc
Description: OpenPGP digital signature

Bug#977155: ITP: node-thenby: library that helps sorting arrays on multiple keys

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-thenby
  Version : 1.3.4+git20200720.0fd165a+ds-1
  Upstream Author : Teun Duynstee
* URL : https://github.com/Teun/thenBy.js
* License : Apache-2.0
  Programming Lang: Javascript
  Description : library that helps sorting arrays on multiple keys
 It allows users to use the native Array::sort()
 method of javascript, but pass in multiple
 functions to sort that are composed with
 firstBy().thenBy().thenBy() style.

This is a pre-dependency of q2-taxa
I shall maintain this package.

Bug#965114: golang-github-shenwei356-bwt: FTBFS: unsatisfiable build dependency

[Nilesh Patra]

Control: severity -1 minor


On Tue, 10 Nov 2020 21:39:40 +0530 Nilesh Patra  wrote:
> sbuild (Debian sbuild) 0.79.1 (22 April 2020) on debian
>
>
++
> | golang-github-shenwei356-bwt 0.0~git20200418.ae79c98-2 (amd64) Tue, 10
Nov 2020 15:55:30 + |
> +===�

Bug#974774: ITP: golang-github-alexflint-go-arg -- Struct-based argument parsing in Go

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: golang-github-alexflint-go-arg
  Version : 1.3.0+ds
  Upstream Author : Alex Flint
* URL : https://github.com/alexflint/go-arg
* License : BSD-2-Clause
  Programming Lang: Golang
  Description :  Struct-based argument parsing in Go
 The idea behind go-arg is that Go already has an excellent way
 to describe data structures using structs, so there is no need to
 develop additional levels of abstraction. Instead of one API to specify
 which arguments a program accepts, and then another API to get the
 values of those arguments, go-arg replaces both with a single struct.

I shall maintain this package.

Bug#926079: ITP: golang-github-alexflint-go-scalar -- Go-lang Scalar parsing library

[Nilesh Patra]

Hi,

Any update on this package? It seems that it hasn't landed in the
archive yet.
We need this to package https://github.com/alexflint which is another
chain of deps to get bcbio working.

If there's no issue at your end, this shall be uploaded to NEW. Please
let me know if there's any update regarding this.

Nilesh

Bug#974798: ITP: ggd-utils -- programs for use in ggd

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: ggd-utils
  Version : 0.0.7+ds
  Upstream Author : gogetdata
* URL : github.com/gogetdata/ggd-utils
* License : Expat
  Programming Lang: Golang
  Description :  programs for use in ggd
 Takes a genome file and (currently) a .vcf.gz or
 a .bed.gz and checks that:
 .
 * a .tbi is present
 * the VCF has ""##fileformat=VCF" as the first
 line
 * the VCF has a #CHROM header
 * the chromosome are in the order specified by
 the genome file (and present)
 * the positions are sorted
 * the positions are <= the chromosome lengths
 defined in the genome file.
 .
 As a result, any new genome going into GGD will have
 a .genome file that will dictate the sort order
 and presence or absence of the 'chr' prefix for chromosomes

I shall maintain this package.

Bug#974178: python3-biom-format: debci tests fail: Object of type bytes is not JSON serializable

[Nilesh Patra]

Hi,

debci seems happy now.

https://ci.debian.net/packages/p/python-biom-format/unstable/amd64/
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-biom-format/8336917/log.gz

Should this bug be closed now? Please let me know/do so if you feel this is
done.

(I can close it myself in a few days when there are more logs)

Nilesh

Bug#974834: ITP: gsort -- Sort genomic data

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: gsort
  Version : 0.1.4-1
  Upstream Author : Brent Pedersen
* URL : https://github.com/brentp/gsort
* License : Expat
  Programming Lang: Golang
  Description :  sort genomic data
 gsort is a tool to sort genomic files according to a genomefile.
 For example, to sort VCF to have order:
 X, Y, 2, 1, 3, ... and the header needs to be kept at the top.
 .
 As a more likely example, if a file nneds to be sorted to match GATK
 order (1 ... X, Y, MT) which is not possible with any other sorting
 tool. With gsort one can simply place MT as the last chrom in the
 ".genome" file.
 .
 It will also be useful for getting files ready for use in bedtools.

I shall maintain this package.

Bug#978760: man page for lua-busted (binary: busted)

[Nilesh Patra]

Package: lua-busted
Tags: patch

Hi,

Please consider adding the attached manpage for the binary: busted

Thanks and regards,
Nilesh

.\" DO NOT MODIFY THIS FILE!  It was generated by help2man 1.47.16.
.TH BUSTED "1" "December 2020" "busted 2.0.0" "User Commands"
.SH NAME
busted \- Lua unit testing framework focused on ease of use
.SH DESCRIPTION
busted: error: Usage: busted [OPTIONS] [\-\-] [ROOT\-1 [ROOT\-2 [...]]]
.SS "ARGUMENTS:"
.TP
ROOT
test script file/folder. Folders will be
traversed for any file that matches the
\fB\-\-pattern\fR option. (optional, default: nil)
.SS "OPTIONS:"
.TP
\fB\-\-version\fR
prints the program version and exits
.TP
\fB\-p\fR, \fB\-\-pattern\fR=\fI\,PATTERN\/\fR
only run test files matching the Lua
pattern (default: _spec)
.TP
\fB\-\-exclude\-pattern\fR=\fI\,PATTERN\/\fR do not run test files matching the 
Lua
pattern, takes precedence over \fB\-\-pattern\fR
.TP
\fB\-e\fR STATEMENT
execute statement STATEMENT
.TP
\fB\-o\fR, \fB\-\-output\fR=\fI\,LIBRARY\/\fR
output library to load (default:
plainTerminal)
.TP
\fB\-C\fR, \fB\-\-directory\fR=\fI\,DIR\/\fR
change to directory DIR before running
tests. If multiple options are specified,
each is interpreted relative to the
previous one. (default: ./)
.TP
\fB\-f\fR, \fB\-\-config\-file\fR=\fI\,FILE\/\fR
load configuration options from FILE
.TP
\fB\-t\fR, \fB\-\-tags\fR=\fI\,TAGS\/\fR
only run tests with these #tags (default:
[])
.TP
\fB\-\-exclude\-tags\fR=\fI\,TAGS\/\fR
do not run tests with these #tags, takes
precedence over \fB\-\-tags\fR (default: [])
.TP
\fB\-\-filter\fR=\fI\,PATTERN\/\fR
only run test names matching the Lua
pattern (default: [])
.TP
\fB\-\-filter\-out\fR=\fI\,PATTERN\/\fR
do not run test names matching the Lua
pattern, takes precedence over \fB\-\-filter\fR
(default: [])
.TP
\fB\-m\fR, \fB\-\-lpath\fR=\fI\,PATH\/\fR
optional path to be prefixed to the Lua
module search path (default:
\&./src/?.lua;./src/?/?.lua;./src/?/init.lua)
.TP
\fB\-\-cpath\fR=\fI\,PATH\/\fR
optional path to be prefixed to the Lua C
module search path (default:
\&./csrc/?.so;./csrc/?/?.so;)
.TP
\fB\-r\fR, \fB\-\-run\fR=\fI\,RUN\/\fR
config to run from .busted file
.TP
\fB\-\-repeat\fR=\fI\,COUNT\/\fR
run the tests repeatedly (default: 1)
.TP
\fB\-\-seed\fR=\fI\,SEED\/\fR
random seed value to use for shuffling test
order (default: \fI\,/dev/urandom\/\fP or os.time())
.TP
\fB\-\-lang\fR=\fI\,LANG\/\fR
language for error messages (default: en)
.TP
\fB\-\-loaders\fR=\fI\,NAME\/\fR
test file loaders (default: lua,moonscript)
.TP
\fB\-\-helper\fR=\fI\,PATH\/\fR
A helper script that is run before tests
.TP
\fB\-\-lua\fR=\fI\,LUA\/\fR
The path to the lua interpreter busted
should run under
.TP
\fB\-Xoutput\fR OPTION
pass `OPTION` as an option to the output
handler. If `OPTION` contains commas, it is
split into multiple options at the commas.
(default: [])
.TP
\fB\-Xhelper\fR OPTION
pass `OPTION` as an option to the helper
script. If `OPTION` contains commas, it is
split into multiple options at the commas.
(default: [])
.TP
\fB\-c\fR, \fB\-\-[no\-]coverage\fR
do code coverage analysis (requires
`LuaCov` to be installed) (default: off)
.TP
\fB\-v\fR, \fB\-\-[no\-]verbose\fR
verbose output of errors (default: off)
.TP
\fB\-s\fR, \fB\-\-[no\-]enable\-sound\fR
executes `say` command if available
(default: off)
.TP
\fB\-l\fR, \fB\-\-list\fR
list the names of all tests instead of
running them
.TP
\fB\-\-ignore\-lua\fR
Whether or not to ignore the lua directive
.TP
\fB\-\-[no\-]lazy\fR
use lazy setup/teardown as the default
(default: off)
.TP
\fB\-\-[no\-]auto\-insulate\fR
enable file insulation (default: on)
.TP
\fB\-k\fR, \fB\-\-[no\-]keep\-going\fR
continue as much as possible after an error
or failure (default: on)
.TP
\fB\-R\fR, \fB\-\-[no\-]recursive\fR
recurse into subdirectories (default: on)
.TP
\fB\-\-[no\-]shuffle\fR
randomize file and test order, takes
precedence over \fB\-\-sort\fR (\fB\-\-shuffle\-test\fR and
\fB\-\-shuffle\-files\fR) (default: off)
.TP
\fB\-\-[no\-]shuffle\-files\fR
randomize file execution order, takes
precedence over \fB\-\-sort\-files\fR (default: off)
.TP
\fB\-\-[no\-]shuffle\-tests\fR
randomize test order within a file, takes
precedence over \fB\-\-sort\-tests\fR (default: off)
.TP
\fB\-\-[no\-]sort\fR
sort file and test order (\fB\-\-sort\-tests\fR and
\fB\-\-sort\-files\fR) (default: off)
.TP
\fB\-\-[no\-]sort\-files\fR
sort file execution order (default: off)
.TP
\fB\-\-[no\-]sort\-tests\fR
sort test order within a file (default:
off)
.TP
\fB\-\-[no\-]suppress\-pending\fR
suppress `pending` test output (default:
off)
.TP
\fB\-\-[no\-]defer\-print\fR
defer print to when test suite is complete
(default: off)
.PP
; re\-run with \fB\-\-help\fR for usage.
.SH AUTHOR
 This manpage was written by Nilesh Patra for the Debian distribution and
 can be used for any other usage of the program.


signature.asc
Description: OpenPGP digital signature

Bug#978662: apertium-cy-en: autopkgtest failure

[Nilesh Patra]

Hi Tino,

On Tue, 29 Dec 2020 23:21:15 +0100 Tino Didriksen  wrote:
> This is a chicken-and-egg problem that should solve itself. New apertium
> 3.7.1 can't migrate until apertium-cy-en is fixed, but fixed apertium-cy-en
> won't build correctly with existing apertium 3.6.1.

On declaring hard dependency for apertium (>= 3.7) in d/control it will migrate 
with, or before apertium 3.7, solving the problem.
I tried to modify the autopkgtests to ignore spacing for now, since 
fundamentally the translation is correct, and opened an MR here[1]

If you could take a look and give a green signal, I'll happily upload this 
package.

[1]: https://salsa.debian.org/science-team/apertium-cy-en/-/merge_requests/1/

Thanks and Regards,

Nilesh



signature.asc
Description: OpenPGP digital signature

Bug#962717: q2-quality-control seems so uncover segfaults in bowtie2

[Nilesh Patra]

On Fri, 15 Jan, 2021, 2:12 am Andreas Tille,  wrote:

> Hi,
>
> since q2-taxa is in new I intended to upload q2-quality-control as well.
>

I don't know about the segfaults, but I don't see q2-taxa in NEW? You
probably uploaded it more than 8 hours ago from the time I'm typing this
mail, it usually appears in the queue.

It's not at the tracker and not at incoming.d.o as well. Do I miss
something?

>

Bug#962717: q2-quality-control seems so uncover segfaults in bowtie2

[Nilesh Patra]

On Fri, 15 Jan, 2021, 11:30 am Andreas Tille,  wrote:

> Hi,
>
> On Fri, Jan 15, 2021 at 10:16:45AM +0530, Nilesh Patra wrote:
> >
> > I don't know about the segfaults, but I don't see q2-taxa in NEW? You
> > probably uploaded it more than 8 hours ago from the time I'm typing this
> > mail, it usually appears in the queue.
>
> Argh, its good we talked about it.  Seems my first attempt had failed.
> Its uploaded now.
>

Thanks, can you push to salsa as well?

>

Bug#976735: spyder needs source upload for Python 3.9 transition

[Nilesh Patra]

Hi Julian

I read through the rest of the thread.

On Mon, 1 Feb, 2021, 6:31 pm Julian Gilbey,  wrote:

> I have a package of Spyder 4 waiting to upload, but it requires five
> packages to be accepted into unstable from NEW first (pyls-server,
> pyls-black, pyls-spyder, abydos, textdistance); once that happens, the
> rest of the packages are almost ready to

go.


I requested on IRC (probably again after you) to process these ASAP,
however I don't see pyls-server in NEW or at the archive yet.

Has this been rejected, or am I missing something?

Nilesh

>
>

Bug#976735: spyder needs source upload for Python 3.9 transition

[Nilesh Patra]

Hi Julian,

On Sun, 13 Dec 2020 06:58:29 + Julian Gilbey  wrote:
> On Mon, Dec 07, 2020 at 05:38:26PM +0200, Adrian Bunk wrote:
> > Package: spyder
> > Version: 3.3.6+dfsg1-5
> > Severity: serious
> >
> > Since binNMUs are not possible for binary-all packages,
> > a source upload is needed for the Python 3.9 transition.
> >
> > In a more general note, does /usr/bin/spyder3 have to use
> > the versioned interpreter instead of python3?
>
> The versioned interpreter can be avoided by removing '{interpreter} '
> from the definition of PYBUILD_AFTER_INSTALL in debian/rules.

Please consider to apply the fix if it works, also for #976966
Since freeze is near, it would be unfortunate to loose spyder and spyder-* 
packages in bullseye.

Nilesh

Bug#976735: spyder needs source upload for Python 3.9 transition

[Nilesh Patra]

Hi Julian,

On Sun, 13 Dec 2020 06:58:29 + Julian Gilbey  wrote:
> On Mon, Dec 07, 2020 at 05:38:26PM +0200, Adrian Bunk wrote:
> > Package: spyder
> > Version: 3.3.6+dfsg1-5
> > Severity: serious
> >
> > Since binNMUs are not possible for binary-all packages,
> > a source upload is needed for the Python 3.9 transition.
> >
> > In a more general note, does /usr/bin/spyder3 have to use
> > the versioned interpreter instead of python3?
>
> The versioned interpreter can be avoided by removing '{interpreter} '
> from the definition of PYBUILD_AFTER_INSTALL in debian/rules.

Please consider to apply the fix if it works, also for #976966
Since freeze is near, it would be unfortunate to loose spyder and spyder-* 
packages in bullseye.

Nilesh