Bug#1052835: marked as pending in utf8proc

2023-09-30 Thread Mo Zhou 
Control: tag -1 pending

Hello,

Bug #1052835 in utf8proc reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/julia-team/utf8proc/-/commit/ba942e99629cb82bf92805c10e407826ac22bf24


Patch to support unicode-data 15.1.0 (Closes: #1052835)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1052835

Bug#993029: ranger: No preview for mp(e)g files (mime-type: image/x-tga) and fs saturation with .pam files

2021-11-11 Thread Mo Zhou 
Control: reassign -1 imagemagick-6.q16 8:6.9.11.60+dfsg-1.3
Control: severity -1 important

Hi,

This bug does not belong to ranger. ranger called `identify` from
imagemagick on
the given video, and identify ends up creating a bulky magick-*.pam file
under /tmp
and exiting with error.

I can reproduce this problem on stable with some of my local video
files:

lumin ~/Videos> identify xxx.mp4
identify-im6.q16: delegate failed `'ffmpeg' -nostdin -v -1 -i '%i'
-vframes %S -vcodec pam -an -f rawvideo -y '%u.pam' 2> '%u'' @
error/delegate.c/InvokeDelegate/1966.

It only quit when there is no space in /tmp anymore.

Bug#969477: zfs-dkms fails to compile with 5.7.0-3 kernel blocking kernel upgrade

2020-09-29 Thread Mo Zhou 
Control: severity -1 important
Control: tag -1 +moreinfo

I cannot reproduce this with either linux 5.7 or linux 5.8 on sid.

Bug#961725: libopenblas-dev: On some cpus, openmp and pthread dead-lock

2020-05-28 Thread Mo Zhou 
Control: severity -1 important
Control: tags -1 +moreinfo
Clarification: possibly a Ubuntu bug

Hello guys,

The way to reproduce with docker + ubuntu devel (20.10)

1. docker image pull ubuntu:devel
2. docker run -ti ubuntu:devel
3. apt update -y ; apt upgrade -y
4. apt install -y r-base-core
5. Rscript -e "example(solve)"  # good with netlib
6. apt install -y libopenblas-dev
7. Rscript -e "example(solve)"  # hang

The way to reproduce with nspawn/chroot + ubuntu focal (20.04)
if you don't have docker

1. mkdir Focal
2. debootstrap focal Focal/
3. systemd-nspawn -D Focal
4. apt update -y; apt upgrade -y
5. apt install -y r-base-core
6. Rscript -e "example(solve)"  # good with netlib
7. apt install -y libopenblas-dev
8. Rscript -e "example(solve)"  # hang

The way to reproduce with *. + debian

1. Not yet reproducible.

Bug#950545: FTBFS against opencv 4.2.0

2020-02-03 Thread Mo Zhou 
Source: eviacam
Version: 2.1.4-1
Severity: serious

Dear maintainer,

eviacam FTBFS against the latest version of OpenCV:
https://buildd.debian.org/status/package.php?p=eviacam&suite=sid
https://buildd.debian.org/status/fetch.php?pkg=eviacam&arch=amd64&ver=2.1.4-1%2Bb1&stamp=1580642132&raw=0

which looks due an API change at the first glance.


crvnormroi.cpp:449:35: error: cannot convert ‘cv::Size’ {aka ‘cv::Size_’} 
to ‘const CvSize&’
  449 |  SetP1ResizeInteger (pImg->GetSize(), x, y);
  |  ~^~
  |   |
  |   cv::Size {aka cv::Size_}
crvnormroi.cpp:359:50: note:   initializing argument 1 of ‘void 
CNormROI::SetP1ResizeInteger(const CvSize&, int, int)’
  359 | void CNormROI::SetP1ResizeInteger (const CvSize& size, const int x, 
const int y)
  |~~^~~~
crvnormroi.cpp: In member function ‘void CNormROI::SetP1MoveImg(const 
CIplImage*, int, int)’:
crvnormroi.cpp:457:33: error: cannot convert ‘cv::Size’ {aka ‘cv::Size_’} 
to ‘const CvSize&’
  457 |  SetP1MoveInteger (pImg->GetSize(), x, y);
  |~^~
  | |
  | cv::Size {aka cv::Size_}
crvnormroi.cpp:369:48: note:   initializing argument 1 of ‘void 
CNormROI::SetP1MoveInteger(const CvSize&, int, int)’
  369 | void CNormROI::SetP1MoveInteger (const CvSize& size, const int x, const 
int y)
  |  ~~^~~~
crvnormroi.cpp: In member function ‘void CNormROI::SetP2ResizeImg(const 
CIplImage*, int, int)’:
crvnormroi.cpp:465:35: error: cannot convert ‘cv::Size’ {aka ‘cv::Size_’} 
to ‘const CvSize&’
  465 |  SetP2ResizeInteger (pImg->GetSize(), x, y);
  |  ~^~
  |   |
  |   cv::Size {aka cv::Size_}
crvnormroi.cpp:379:50: note:   initializing argument 1 of ‘void 
CNormROI::SetP2ResizeInteger(const CvSize&, int, int)’
  379 | void CNormROI::SetP2ResizeInteger (const CvSize& size, const int x, 
const int y)
  |~~^~~~
crvnormroi.cpp: In member function ‘void CNormROI::SetCenterImg(const 
CIplImage*, int, int)’:
crvnormroi.cpp:473:33: error: cannot convert ‘cv::Size’ {aka ‘cv::Size_’} 
to ‘const CvSize&’
  473 |  SetCenterInteger (pImg->GetSize(), x, y);
  |~^~
  | |
  | cv::Size {aka cv::Size_}
crvnormroi.cpp:389:48: note:   initializing argument 1 of ‘void 
CNormROI::SetCenterInteger(const CvSize&, int, int)’
  389 | void CNormROI::SetCenterInteger (const CvSize& size, const int x, const 
int y)
  |  ~~^~~~
crvnormroi.cpp: In member function ‘void CNormROI::GetCenterImg(const 
CIplImage*, int&, int&)’:
crvnormroi.cpp:481:33: error: cannot convert ‘cv::Size’ {aka ‘cv::Size_’} 
to ‘const CvSize&’
  481 |  GetCenterInteger (pImg->GetSize(), x, y);
  |~^~
  | |
  | cv::Size {aka cv::Size_}
crvnormroi.cpp:398:48: note:   initializing argument 1 of ‘void 
CNormROI::GetCenterInteger(const CvSize&, int&, int&)’
  398 | void CNormROI::GetCenterInteger (const CvSize& size, int& x, int& y)
  |  ~~^~~~
crvnormroi.cpp: In member function ‘void CNormROI::SetSizeImg(const CIplImage*, 
int, int)’:
crvnormroi.cpp:489:31: error: cannot convert ‘cv::Size’ {aka ‘cv::Size_’} 
to ‘const CvSize&’
  489 |  SetSizeInteger (pImg->GetSize(), width, height);
  |  ~^~
  |   |
  |   cv::Size {aka cv::Size_}
crvnormroi.cpp:408:46: note:   initializing argument 1 of ‘void 
CNormROI::SetSizeInteger(const CvSize&, int, int)’
  408 | void CNormROI::SetSizeInteger (const CvSize& size, const int width, 
const int height)
  |~~^~~~
crvnormroi.cpp: In member function ‘void CNormROI::GetBoxImg(const CIplImage*, 
int&, int&, int&, int&)’:
crvnormroi.cpp:497:53: error: no matching function for call to 
‘CNormROI::GetBoxInteger(cv::Size, int&, int&, int&, int&)’
  497 |  GetBoxInteger (pImg->GetSize(), x, y, width, height);
  | ^
crvnormroi.cpp:418:6: note: candidate: ‘void CNormROI::GetBoxInteger(const 
CvSize&, int&, int&, int&, int&)’
  418 | void CNormROI::GetBoxInteger (const CvSize& size, int& x, int& y, int& 
width, int& height)
  |  ^~~~
crvnormroi.cpp:418:45: note:   no known conversion for argument 1 from 
‘cv::Size’ {aka ‘cv::Size_’} to ‘const CvSize&’
  418 | void CNormROI::GetBoxInteger (const CvSize& size, int& x, int& y, int&

Bug#936609: cblas / gsl hint needed (Was: Bug#936609: Ported ghmm to Python3 but issues with clapack)

2020-01-05 Thread Mo Zhou 
GSL provides a set of CBLAS API/ABI, delivered with shared object
"libgslcblas.so" and header "gsl_cblas.h".  That subset becomes
redundant once you include the headers of any standard/compatible
(C)BLAS library. That's what the compilation error means.

Make sure that the code only use one CBLAS implementation. In the
context of debian, I'd recommend you use the CBLAS ABI from libblas-dev,
and avoid linking against -lcblas. Link against -lblas instead.

On Sun, Jan 05, 2020 at 07:55:05AM +0100, Andreas Tille wrote:
> Control: tags -1 help
> 
> Hi,
> 
> I was asking upstream about this issue[1] and an issue about gsl usage
> is suspected.  Any hint how this can be fixed?
> 
> > Finally I have a question about building with lapack.  I get:
> > 
> > ...
> > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I.. -Wdate-time 
> > -D_FORTIFY_SOURCE=2 -DDTD_LOC=\"/usr/share/ghmm/ghmm.dtd.1.0\" -g -O2 
> > "-fdebug-prefix-map=/build/ghmm-0.9~rc3=." -fstack-protector-strong -  
> > Wformat -Werror=format-security -I/usr/include 
> > -I/usr/include/x86_64-linux-gnu -I/usr/include/libxml2 -c rng.c  -fPIC 
> > -DPIC -o .libs/rng.o
> > In file included from /usr/include/x86_64-linux-gnu/clapack.h:4,
> >  from matrixop.c:48:
> > /usr/include/x86_64-linux-gnu/cblas.h:5:9: error: nested redefinition of 
> > 'enum CBLAS_ORDER'
> > 5 |enum CBLAS_ORDER {CblasRowMajor=101, CblasColMajor=102 };
> >   | ^~~
> > /usr/include/x86_64-linux-gnu/cblas.h:5:9: error: redeclaration of 'enum 
> > CBLAS_ORDER'
> > In file included from /usr/include/gsl/gsl_blas_types.h:28,
> >  from /usr/include/gsl/gsl_blas.h:29,
> >  from /usr/include/gsl/gsl_linalg.h:30,
> >  from matrixop.c:44:
> > /usr/include/gsl/gsl_cblas.h:46:6: note: originally defined here
> >46 | enum CBLAS_ORDER {CblasRowMajor=101, CblasColMajor=102};
> >   |  ^~~
> > In file included from /usr/include/x86_64-linux-gnu/clapack.h:4,
> >  from matrixop.c:48:
> > /usr/include/x86_64-linux-gnu/cblas.h:5:22: error: redeclaration of 
> > enumerator 'CblasRowMajor'
> > 5 |enum CBLAS_ORDER {CblasRowMajor=101, CblasColMajor=102 };
> >   |  ^
> > In file included from /usr/include/gsl/gsl_blas_types.h:28,
> >  from /usr/include/gsl/gsl_blas.h:29,
> >  from /usr/include/gsl/gsl_linalg.h:30,
> >  from matrixop.c:44:
> > /usr/include/gsl/gsl_cblas.h:46:19: note: previous definition of 
> > 'CblasRowMajor' was here
> >46 | enum CBLAS_ORDER {CblasRowMajor=101, CblasColMajor=102};
> >   |   ^
> > In file included from /usr/include/x86_64-linux-gnu/clapack.h:4,
> >  from matrixop.c:48:
> > /usr/include/x86_64-linux-gnu/cblas.h:5:41: error: redeclaration of 
> > enumerator 'CblasColMajor'
> > 5 |enum CBLAS_ORDER {CblasRowMajor=101, CblasColMajor=102 };
> >   | ^
> > 
> > 
> 
> Kind regards
> 
>  Andreas.
> 
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936609#19
> 
> -- 
> http://fam-tille.de
>

Bug#936924: Moving libsvm to Debian Science team

2019-12-21 Thread Mo Zhou 
I second this proposal, and the same for src:liblinear.

These are high popcon packages, dependencies for a number of other
packages. They should be team maintained to unblock important fixes.

On Sat, Dec 21, 2019 at 08:35:28AM +0100, Andreas Tille wrote:
> Hi Chen-Tse,
> 
> I'm maintaining a package that depends from libsvm.  Due to bug #936924
> that did not received any response since August it is in danger to be
> removed from testing so I'm interested that this bug will be fixed.
> When looking at the package I realised that while it would fit into
> Debian Science team scope it is not team maintained nor is there any
> repository in Salsa.  That's why I have the following suggestion:
> 
>   1. I create a repository on Salsa
>   2. Move the package to Debian Science team maintenance
>  and add you as Uploader
>   3. Drop Python2 package and close bug #936924
>   4. May be migrate packaging from cdbs to dh
> 
> If I do not hear from you until Monday I assume you agree with this
> plan and will do so.
> 
> Kind regards
> 
>  Andreas.
> 
> PS: @Christian: I noticed that you and Chen-Tse are maintaining
> liblinear.  I have just removed Python2 package and reassigned
> #936889 to ftp.debian.org to make sure python-liblinear will be
> removed.  Thus libsvm can be dealt as suggested.
> 
> -- 
> http://fam-tille.de
>

Bug#945218: moar segfaults during nqp build on mipsel

2019-11-21 Thread Mo Zhou 
Control: forwarded -1 https://github.com/MoarVM/MoarVM/issues/1194

On Thu, Nov 21, 2019 at 12:25:13PM +0100, Paul Gevers wrote:
> Source: moarav
> Version: 2019.07.1+dfsg-2
> Severity: serious
> Tags: ftbfs
> Justification: ftbfs
> Control: affects -1 nqp
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Dear maintainers,
> 
> The last upload of nqp failed to build on mipsel due to a segmentation fault 
> in
> /usr/bin/moar. Please investigate. This is holding back the migration of 
> moarvm
> to testing.
> 
> Paul
> 
> https://buildd.debian.org/status/package.php?p=nqp
> 
> make[1]: Entering directory '/<>'
> dh_auto_build
>   make -j1
> make[2]: Entering directory '/<>'
> mkdir -p -- 'gen/moar/stage1/gen'
> '/usr/bin/perl' '/<>/tools/build/gen-cat.pl' moar stage1 
> src/how/Archetypes.nqp src/how/RoleToRoleApplier.nqp 
> src/how/NQPConcreteRoleHOW.nqp src/how/RoleToClassApplier.nqp 
> src/how/NQPCurriedRoleHOW.nqp src/how/NQPParametricRoleHOW.nqp 
> src/how/NQPClassHOW.nqp src/how/NQPNativeHOW.nqp src/how/NQPAttribute.nqp 
> src/how/NQPModuleHOW.nqp src/how/EXPORTHOW.nqp  > 'gen/moar/stage1/nqpmo.nqp'
> '/usr/bin/moar' --libpath=src/vm/moar/stage0 src/vm/moar/stage0/nqp.moarvm 
> --bootstrap --setting=NULL --no-regex-lib --target=mbc --stable-sc=stage1 \
> --output='gen/moar/stage1/nqpmo.moarvm' 'gen/moar/stage1/nqpmo.nqp'
> Segmentation fault
> make[2]: *** [Makefile:281: gen/moar/stage1/nqpmo.moarvm] Error 139
> make[2]: Leaving directory '/<>'
> dh_auto_build: make -j1 returned exit code 2
> make[1]: *** [debian/rules:18: override_dh_auto_build] Error 255
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:8: build-arch] Error 2
> 
> - -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'testing-debug')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.2.0-3-amd64 (SMP w/2 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> -BEGIN PGP SIGNATURE-
> 
> iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAl3WdBkACgkQnFyZ6wW9
> dQrPLQgAwtvzw6J0t5+bkiGIJpECWAFn0qUJp6Fjk/xGZsxU3yKTrRLBMuXC1p2B
> 6gVK6lDH8Rs8SjCLgvko6ZuY7O7f40mIvazGIGYBGAqC0c3xxOnvabWMXmfoSRHo
> w/I+YgQ5so7GYC3s94H6vs/UfZH2cmzJ7cASWk/sOQEDjjavLu7hcgTpHhUBmWPA
> BdosodsYwiVqRkLsYtHRwFtep3MBl/l84Du5avHM/K4Jys+6MJt7Nsym+JRZeqTr
> TlFxxGUKui8o6JcG9JnaaWnAZ8ZF4QT+vZvrmj5VWEbqWr+hjjtSxvPS8c/ZM7VO
> b2KDSOIwN+Hy4NkarQiUm4+KzE9m7Q==
> =NgCy
> -END PGP SIGNATURE-
> 
> ___
> Pkg-rakudo-devel mailing list
> pkg-rakudo-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rakudo-devel

Bug#942561: mips{,64}el ISA baseline violation

2019-10-18 Thread Mo Zhou 
Source: opencv
Version: 4.1.2+dfsg-3
Severity: serious

Opencv's cmake files unconditionally use the MSA
ISA baseline once detected MIPS architecture.
It resulted in mips64el sigill and caffe (rdep
of opencv) ftbfs on mips64el. mipsel should have
been affected too.

Bug#942364: [patch] perl6-* (vendored) packages out of the reach of perl6 path

2019-10-17 Thread Mo Zhou 
Great. I'll prepare the -8 revision for unstable.
When it landed onto the archive, all remaining usability issues
of perl6 should be gone.

After that I'll update the perl6-zef package.

On 2019-10-17 12:09, Dominique Dumont wrote:
> On Wednesday, 16 October 2019 16:34:20 CEST gregor herrmann wrote:
>> Ideally someone would try to update directly from -4 in unstable to
>> -7 …
> 
> I was at -5, I've downgraded to -4 without much problems.
> 
> Then I've upgrade to -7 without problem and zef is working fine.
> 
> That's good news :-)
> 
> All the best
> 
> Dod
> 
> ___
> Pkg-rakudo-devel mailing list
> pkg-rakudo-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rakudo-devel

Bug#942364: [patch] perl6-* (vendored) packages out of the reach of perl6 path

2019-10-16 Thread Mo Zhou 
Hi

2019.07.1-7 in experimental should be able to address all the remaining
issues. If the upgrading process didn't automatically trigger the
reinstallation of vendored modules (fixed in master branch), the manual
invokation of rakudo-helper.pl -R should be able to address the
problems.

Could you please verify it? :-)

On 2019-10-15 16:44, gregor herrmann wrote:
> On Tue, 15 Oct 2019 02:17:24 -0700, Mo Zhou wrote:
> 
>> Could you please double check the -6 revision? If it looks good,
>> I'll continue and upload it to unstable and close this bug.
> 
> After upgrading rakudo from 2019.07.1-4 to 2019.07.1-6:
> 
> % zef
> ===SORRY!===
> Could not find Zef::CLI at line 3 in:
> inst#/home/gregoa/.perl6
> inst#/usr/share/perl6/site
> inst#/usr/share/perl6/vendor
> inst#/usr/share/perl6/core
> ap#
> nqp#
> perl5#
> 
> (i.e. same as before)
> 
> /usr/lib/perl6 doesn't exist anymore; /usr/share/perl6 has lots of
> stuff with zef:
> 
> /usr/share/perl6/debian-sources/perl6-zef
> /usr/share/perl6/debian-sources/perl6-zef/resources
> /usr/share/perl6/debian-sources/perl6-zef/resources/scripts
> /usr/share/perl6/debian-sources/perl6-zef/resources/scripts/perl5tar.pl
> /usr/share/perl6/debian-sources/perl6-zef/resources/scripts/win32http.ps1
> /usr/share/perl6/debian-sources/perl6-zef/resources/scripts/win32unzip.ps1
> /usr/share/perl6/debian-sources/perl6-zef/resources/config.json
> /usr/share/perl6/debian-sources/perl6-zef/lib
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Extract.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Repository
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Repository/LocalCache.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Repository/Ecosystems.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Repository/MetaCPAN.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Utils
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Utils/URI.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Utils/FileSystem.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Utils/SystemInfo.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Utils/SystemQuery.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Config.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Repository.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Install.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Fetch.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/CLI.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Client.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Report.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/InstallPM6.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/P6CReporter.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/FetchPath.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/git.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/prove.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/PowerShell
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/PowerShell/download.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/PowerShell/unzip.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/LegacyBuild.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/curl.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/tar.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/p5tar.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/PowerShell.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/wget.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/DistributionBuilder.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/unzip.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/Test.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/TAP.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Distribution
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Distribution/DependencySpecification.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Distribution/Local.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Identity.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Test.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Build.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Distribution.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef.pm6
> /usr

Bug#942364: [patch] perl6-* (vendored) packages out of the reach of perl6 path

2019-10-15 Thread Mo Zhou 
Hi Gregor,

Thanks for the feedback. What you encountered is an old hidden
but in rakudo-helper's reinstall-all function. When none of the
packages has a dependency, the dependency graph would be empty
hence reinstall-all triggers nothing.

The bug is fixed here:
https://salsa.debian.org/perl6-team/rakudo/commit/7b510778df1c10163eab07741d25099066efd80b

And I've also changed the usr/{lib->share} transition method
in the latest maintainer scripts. I will upload the -7 release
once implemented a graceful /usr/lib/perl6 purge in preinst.

/usr/lib/perl6 should not appear again after the transition.

On 2019-10-15 16:44, gregor herrmann wrote:
> On Tue, 15 Oct 2019 02:17:24 -0700, Mo Zhou wrote:
> 
>> Could you please double check the -6 revision? If it looks good,
>> I'll continue and upload it to unstable and close this bug.
> 
> After upgrading rakudo from 2019.07.1-4 to 2019.07.1-6:
> 
> % zef
> ===SORRY!===
> Could not find Zef::CLI at line 3 in:
> inst#/home/gregoa/.perl6
> inst#/usr/share/perl6/site
> inst#/usr/share/perl6/vendor
> inst#/usr/share/perl6/core
> ap#
> nqp#
> perl5#
> 
> (i.e. same as before)
> 
> /usr/lib/perl6 doesn't exist anymore; /usr/share/perl6 has lots of
> stuff with zef:
> 
> /usr/share/perl6/debian-sources/perl6-zef
> /usr/share/perl6/debian-sources/perl6-zef/resources
> /usr/share/perl6/debian-sources/perl6-zef/resources/scripts
> /usr/share/perl6/debian-sources/perl6-zef/resources/scripts/perl5tar.pl
> /usr/share/perl6/debian-sources/perl6-zef/resources/scripts/win32http.ps1
> /usr/share/perl6/debian-sources/perl6-zef/resources/scripts/win32unzip.ps1
> /usr/share/perl6/debian-sources/perl6-zef/resources/config.json
> /usr/share/perl6/debian-sources/perl6-zef/lib
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Extract.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Repository
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Repository/LocalCache.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Repository/Ecosystems.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Repository/MetaCPAN.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Utils
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Utils/URI.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Utils/FileSystem.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Utils/SystemInfo.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Utils/SystemQuery.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Config.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Repository.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Install.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Fetch.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/CLI.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Client.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Report.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/InstallPM6.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/P6CReporter.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/FetchPath.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/git.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/prove.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/PowerShell
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/PowerShell/download.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/PowerShell/unzip.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/LegacyBuild.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/curl.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/tar.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/p5tar.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/PowerShell.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/wget.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/DistributionBuilder.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/unzip.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/Shell/Test.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Service/TAP.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Distribution
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Distribution/DependencySpecification.pm6
> /usr/share/perl6/debian-sources/perl6-zef/lib/Zef/Distribution/Local.pm6
> /usr/share/perl6/debian-sources/perl6-ze

Bug#942364: [patch] perl6-* (vendored) packages out of the reach of perl6 path

2019-10-15 Thread Mo Zhou 
Package: rakudo
Version: 2019.07.1-4
Severity: serious
Clarification: causes FTBFS of rdeps, can causes usability issue
X-Debbugs-CC: rober...@semistable.com, d...@debian.org

Hi co-maintainers,

After installing 2019.07.1-4 and perl6-zef, user would confront
the following issue:

~/D/p/rakudo ❯❯❯ zef
===SORRY!===
Could not find Zef::CLI at line 3 in:
inst#/home/lumin/.perl6
inst#/usr/share/perl6/site
inst#/usr/share/perl6/vendor
inst#/usr/share/perl6/core
ap#
nqp#
perl5#

Because the required files are put to /usr/lib/perl6/vendor,
a path that is inconsistent with upstream.

I've fixed this bug in the -6 revision and just uploaded it to
experimental. The perl6-* package products will be moved from
/usr/lib/perl6/vendor to /usr/share/perl6/vendor following the
upstream default. I modified the maintainer scripts to smooth
the upgrading process.

Could you please double check the -6 revision? If it looks good,
I'll continue and upload it to unstable and close this bug.

Bug#935290: moar digging

2019-09-18 Thread Mo Zhou 
Fresh installation is fine. /usr/share/perl6 should be a
symlink pointing to /usr/lib/perl6 in the latest version.
When directly upgrading rakudo to the expeirmental version,
this is not handled by dpkg.

I've fixed the upgrade issue in rakduo 2019.07.1-2 (experimental).
Later when the binary is avaialble in mirrors, I'll test
rakudo with the following dockerfile. If anything looks fine,
I'll start uploading 2019.07 to unstable.

--

fromdebian:sid
workdir /tmp
run echo "deb http://ftp2.cn.debian.org/debian sid main contrib
non-free" > /etc/apt/sources.list
run echo "deb http://ftp2.cn.debian.org/debian experimental main
contrib non-free" >> /etc/apt/sources.list
run apt update -y
run apt dist-upgrade -y
run apt autoremove -y

# fresh install [OK]
#runapt install -t experimental rakudo -y
#runperl6 -e '"Hello Perl6!".say'

# sid->experimental upgrade [unverified]
run apt install -t sid rakudo -y
run perl6 -e '"Hello Perl6!".say'
run apt install -t experimental rakudo -y
run perl6 -e '"Hello Perl6!".say'


On 2019-09-16 10:58, Dominique Dumont wrote:
> On Saturday, 14 September 2019 02:37:41 CEST Mo Zhou wrote:
>> Could you please verify the {moarvm,nqp,rakudo}-2019.07.1 in
>> experimental? Shall I proceed and upload it to unstable?
> 
> Looks like there's an issue with /usr/share/perl6 link:
> 
> $ perl6 -e 'say "hello"'
> Unhandled exception: While looking for '/usr/share/perl6/runtime/
> perl6.moarvm': no such file or directory
> 
> /usr/share/perl6 is not a link on my machine:
> 
> $ ll /usr/share/perl6
> total 8
> drwxr-xr-x 5 root root 4096 Aug 31 19:28 debian-sources
> -rw-r--r-- 1 root root   41 Jun 22  2018 previous-compiler-id
> 
> May be because /usr/share/perl6 existed before rakudo 2019-07 installation.
> 
> All the best
> 
> Dod

Bug#935290: moar digging

2019-09-13 Thread Mo Zhou 
Hi Dominique and Robert,

Could you please verify the {moarvm,nqp,rakudo}-2019.07.1 in
experimental? Shall I proceed and upload it to unstable?

On 2019-09-13 14:44, M. Zhou wrote:
> Hi Dominique,
> 
> Will do it later. BTW, the *.moarvm not found error is related to this:
> https://github.com/rakudo/rakudo/issues/3093
> 
> We can temporarily symlink several directories to wordaround this.
> 
> 
> On Fri, 13 Sep 2019 at 12:24, Dominique Dumont  wrote:
>>
>> On Thursday, 12 September 2019 08:33:00 CEST Niels Thykier wrote:
>> > Does rakudo build with "Rules-Requires-Root: no"[1]?  If it does, then
>> > you can work around the bug / issue in fakeroot for sid, testing and
>> > stable for now by using it.
>>
>> Yes ! I can now build rakudo on my laptop. Thanks for the help :-)
>>
>> Mo Zhou, can you follow-up and, if possible, release rakudo on unstable ?
>>
>> All the best
>>
>>
>>
>>

Bug#939505: bumblebee fails to disable discrete graphics card after upgrade nvidia driver to 430.40-2

2019-09-07 Thread Mo Zhou 
same here.
reflink:
https://devtalk.nvidia.com/default/topic/1050786/linux/nvidia-drivers-430-09-causes-xorg-segfault-at-start-

Bug#929929: Being unable to build with >= 4.19.38 is an RC

2019-06-03 Thread Mo Zhou 
control: close -1

I made a big mistake. It's the ***LTS KERNEL UPDATE***
that breaks ZFS 0.7.12-2. It's not a ZFS bug at all!

An LTS KERNEL UPDATE that breaks stuff is where the
grave RC lies.

Bug#929929: Being unable to build with >= 4.19.38 is an RC

2019-06-03 Thread Mo Zhou 
Source: zfs-linux
Version: 0.7.12-2
Severity: grave
Clarification: a foreseeable stable RC is grave enough.

Buster will be released with 4.19.37 kernel. That's fine
and it doesn't break ZFS. However, the changes introduced
in 4.19.38 and linux 5.0 break ZFS. That means the current
0.7.12-2 will fail to build everywhere after the first
Buster point release (with kernel version bump).
RC in stable is terrible enough.

We have two choices:
1. just unblock 0.7.13-1 .
2. revert diff(0.7.12-2,0.7.12-5), then cherry-pick
   the commits that fix the build issue, then go
   through t-p-u for 0.7.12-6 .

I dislike the second one but the first one seems hard
to achieve. Sigh.

Bug#928454: perl6-zef's p6c mirror URLs are outdated

2019-05-04 Thread Mo Zhou 
Package: perl6-zef
Version: 0.6.2-1
Severity: serious
Clarification: renders zef nearly unusable

Dear maintainer,

The URL list for p6c mirrors has already outdated:

 53 "short-name" : "p6c",
 54 "enabled" : 1,
 55 "module" : "Zef::Repository::Ecosystems",
 56 "options" : {
 57 "name" : "p6c",
 58 "auto-update" : 1,
 59 "mirrors" : [
 60 "http://ecosystem-api.p6c.org/projects1.json";,
 61 "http://ecosystem-api.p6c.org/projects.json";,
 62 "git://github.com/ugexe/Perl6-ecosystems.git",
 63 
"https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/p6c1.json";

The outdated URL list makes zef fail twice on update. It only starts to
work with the 3rd URL. In order to make zef package easier to use, we
should update the p6c mirror URLs in resources/config.json to

  "https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/p6c1.json";,
  "git://github.com/ugexe/Perl6-ecosystems.git",
  "http://ecosystem-api.p6c.org/projects1.json";

https://github.com/ugexe/zef/blob/master/resources/config.json#L60-L62

in #perl6 channel, zef upstream said these URLs are not likely to be
changed recently:

 ugexe: How likely will zef change it's mirror URL again in the next one 
or two years? I'm going to update the zef package for Debian Buster
 i don't plan on changing it. someone whined about it not being hosted 
by p6c once before so i changed it back, but i guess thats what i get for being 
a push over

Bug#926386: free(): double free detected in tcache 2

2019-04-04 Thread Mo Zhou 
Package: peek
Version: 1.3.1-5
Severity: grave
Clarification: renders software totally unusable

On my Debian sid system it crashes every time.

~ ❯❯❯ peek
Using screen recorder backend gnome-shell
Recording to file /home/lumin/.cache/peek/peekJ0BLZZ.webm
free(): double free detected in tcache 2
fish: “peek” terminated by signal SIGABRT (Abort)
~ ❯❯❯ gdb peek
GNU gdb (Debian 8.2.1-2) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from peek...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/bin/peek
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x74a72700 (LWP 18733)]
[New Thread 0x7fffe700 (LWP 18734)]
[New Thread 0x7fffef5f5700 (LWP 18735)]
Using screen recorder backend gnome-shell
Recording to file /home/lumin/.cache/peek/peekAN9KZZ.webm
[Detaching after fork from child process 18745]
[Detaching after fork from child process 18746]
[New Thread 0x7fffe6582700 (LWP 18748)]
[New Thread 0x7fffe5d81700 (LWP 18762)]
[Detaching after fork from child process 18763]
[New Thread 0x7fffe5580700 (LWP 18764)]
free(): double free detected in tcache 2

Thread 1 "peek" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x76f548bb in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x76f3f535 in __GI_abort () at abort.c:79
#2  0x76f96778 in __libc_message
(action=action@entry=do_abort, fmt=fmt@entry=0x770a128d "%s\n")
at ../sysdeps/posix/libc_fatal.c:181
#3  0x76f9ce6a in malloc_printerr
(str=str@entry=0x770a2f58 "free(): double free detected in tcache 2")
at malloc.c:5341
#4  0x76f9e94d in _int_free
(av=0x770d8c40 , p=0x55a30ab0, have_lock=) at malloc.c:4193
#5  0x5557482e in  ()
#6  0x55572912 in  ()
#7  0x774f9719 in  () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#8  0x774fa196 in  () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#9  0x55572bc4 in  ()
#10 0x774f9719 in  () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#11 0x774f9759 in  () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#12 0x7732fdd8 in g_main_context_dispatch ()
at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x773301c8 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x773304c2 in g_main_loop_run ()
--Type  for more, q to quit, c to continue without paging--
at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x77a20583 in gtk_dialog_run ()
at /lib/x86_64-linux-gnu/libgtk-3.so.0
#16 0x5557f7df in  ()
#17 0x77413c7d in g_closure_invoke ()
at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#18 0x77427345 in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#19 0x7743025e in g_signal_emit_valist ()
at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#20 0x77430df4 in g_signal_emit_by_name ()
at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#21 0x5557903b in 
peek_recording_base_screen_recorder_finalize_recording ()
#22 0x5557b423 in  ()
#23 0x77330863 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#24 0x7732fdd8 in g_main_context_dispatch ()
at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#25 0x773301c8 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#26 0x7733025c in g_main_context_iteration ()
at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#27 0x7752499d in g_application_run ()
at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#28 0x55564be6 in _vala_main ()
--Type  for more, q to quit, c to continue without paging--
#29 0x76f4109b in __libc_start_main (main=
0x55564a60 , argc=1, argv=0x7fffe5e8, init=, 
fini=, rtld_fini=, stack_end=0x7fffe5d8)
at ../csu/libc-start.c:308
#30 0x55564aaa in _start ()
(gdb)
(gdb)
(gdb) stop
(gdb) quit
A debugging session is active.

Inferior 1 [process 18697] will be killed.

Quit anyway? (y or n) y

Bug#883619: Bug#868355: Any reason not to simply upload ceres-solver with adjusted version of libeigen3-dev

2019-02-26 Thread Mo Zhou 
On Tue, Feb 26, 2019 at 11:25:49AM +0100, Andreas Tille wrote:
> > The eigen3 maintainer and I are happy to simply rebuild affected
> > packages after every eigen3 update, but Emilio considers it an upstream bug.
> > Unfortunately I could not find anybody able to shed more light on the
> > eigen3 topic.
> 
> I agree that the topic seems to be more complex in general but for the
> moment we need a fix for Buster and that fix is very simple - so I do
> not see any reason to not fix it.  You might like to reopen the relevant
> bugs (I mean #868355 - I just asked for closing which was done and
> #883619) with lower severity to keep on discussing for Buster+1.

Similar to packages built against static libraries, eigen3 as a
header-only library gives us no chance except for binNMU all the rdeps.

There are a lot of header only packages in my packaging radar, and
the transition problem really brings me headache. Fortunately they
won't have to much rdeps at the beginning.

Bug#921207: Octave GEMM error on large matrix due to openmp thread race condition

2019-02-03 Thread Mo Zhou 
control: severity -1 important

Hi Sébastien and Sylvestre,

On Sun, Feb 03, 2019 at 10:16:05AM +0100, Sébastien Villemot wrote:
> Control: tags -1 unreproducible
> 
> Dear Lumin,
> 
> I've tried to reproduce the problem with Netlib BLAS, OpenBLAS and
> BLIS, but without success (I did not try with MKL since I don't want
> such a large binary blob on my system).

I tried to reproduce this issue in a docker container. It seems that
the problem only occurs after the installation of libmkl-rt. I feel
very strange and tried to do some further research:

root@6c3d05276fb0:~/x# cat x.sh
for i in $(seq 10); do octave -q --no-gui a.m ; done

root@6c3d05276fb0:~/x# OMP_NUM_THREADS=2 MKL_THREADING_LAYER=intel 
MKL_NUM_THREADS=1 sh x.sh
   385   385   385   385
   385   385   385   385
   385   385   385   385
   385   385   385   385
   385   385   385   385
   385   385   385   385
   385   385   385   385
   385   385   385   385
   385   385   385   385
   385   385   385   385

root@6c3d05276fb0:~/x# OMP_NUM_THREADS=2 MKL_THREADING_LAYER=intel 
MKL_NUM_THREADS=2 sh x.sh
   641731270638496   641731270638496   641348657394560   641348657394560
   484510470256176   484510470256176   485846751162000   485846751162000
   640975146516736   640975146516736   641915530512672   641915530512672
   646390298635168   646390298635168   646390298635168   646390298635168
   541379330715152   541379330715152   546317613096592   546317613096592
   495137794802960   495137794802960   497281139942736   497281139942736
   418469161038160   418469161038160   417908282300720   417908282300720
   550962358819680   550962358819680   12823424000   12823424000
   447356352104528   447356352104528   452646448263472   452646448263472
   401738136831792   401738136831792   405814754050064   405814754050064

root@6c3d05276fb0:~/x# ln -sr /usr/lib/llvm-7/lib/libgomp.so 
/usr/lib/llvm-7/lib/libgomp.so.1

root@6c3d05276fb0:~/x# OMP_NUM_THREADS=2 MKL_THREADING_LAYER=intel 
MKL_NUM_THREADS=2 LD_LIBRARY_PATH=/usr/lib/llvm-7/lib/ sh x.sh
   385   385   385   385
   385   385   385   385
   385   385   385   385
   385   385   385   385
   385   385   385   385
   385   385   385   385
   385   385   385   385
   385   385   385   385
   385   385   385   385
   385   385   385   385

It turns out that the incorrect matrix product is a result of
gomp + iomp library clash: octave is linked against the GNU OMP,
while libmkl-rt.so invokes Intel(LLVM) OMP by default.

@Sylvestre Do you have any idea about measures to avoid gomp/iomp clash?
Although people should keep in mind to avoid mixing the usage of gomp
and iomp together, the matrix product error just happend silently
without any notice...

> Basically you're suggesting that Octave's basic matrix multiplication
> functionality is utterly broken, without anybody else noticing. This is
> highly unlikely.
>
> Did you try to reproduce the problem on a pristine sid chroot, or
> another system?

I think any BLAS implementation using iomp would end up with such error.
And unfortunately there is only MKL doing that.
 
I confirm that this problem is reproducible, as long as you make
gomp and iomp clash.

OpenBLAS/Netlib/BLIS are innocent even if I encountered error with
them, because LAPACK still points to libmkl-rt, which eventually
leads to gomp-iomp clash again. (I finally found the answer)

So ... How do I fix such gomp-iomp clashing issue?
(I guess it's not fixable)

Bug#921207: Octave GEMM error on large matrix due to openmp thread race condition

2019-02-02 Thread Mo Zhou 
Package: octave
Version: 4.4.1-4
Severity: grave
X-Debbugs-CC: debian-scie...@lists.debian.org, ido...@neto.net.il

Dear octave maintainer,

I received an astonishing bug report[1] saying that MKL returns wrong
result for matrix multiplication. However, my further investigation
suggests that the problem is very likely a threading bug of octave.
OpenMP is highly suspected according to my following experimental
results.

===

Please reproduce the problem with the following octave script:

921193.m

```
x=1:10; y=[x;x]*[x;x]';
disp(reshape(y, 1, 4))
```

The correct result is
   385   385   385   385

However sometimes octave yields random results, which is possibly
a symptom of race condition between threads or alike.

 MKL --

libblas.so, libblas.so.3 = libmkl_rt.so

$ octave 921193.m
   1.1033e+15   1.1033e+15   1.1038e+15   1.1038e+15

$ MKL_NUM_THREADS=1 octave 921193.m
   385   385   385   385

$ MKL_NUM_THREADS=2 octave 921193.m 
   642428448891136   642428448891136   642428448891136   642428448891136

$ MKL_NUM_THREADS=2 MKL_THREADING_LAYER=intel octave 921193.m 
   489859913436624   489859913436624   488279025495504   488279025495504

$ MKL_NUM_THREADS=2 MKL_THREADING_LAYER=gnu octave 921193.m 
   385   385   385   385

$ MKL_NUM_THREADS=2 MKL_THREADING_LAYER=tbb octave 921193.m 
   385   385   385   385

$ MKL_NUM_THREADS=2 MKL_THREADING_LAYER=sequential octave 921193.m 
   385   385   385   385

The default threading model used by libmkl_rt is the "intel" threading
aka. libiomp5 . It seems that Octave isn't happy with libiomp5 .
In contrast, gomp (gnu), tbb, serial/sequential threading users
are not affected.

--- Netlib --

libblas.so, libblas.so.3 = netlib blas

$ octave 921193.m
   824104476280848   824104476280848   828286951663952   828286951663952
$ octave 921193.m
   385   385   385   385
$ OMP_NUM_THREADS=1 octave 921193.m
   385   385   385   385

Netlib blas has no multi-thread implementation. This result indicates
that octave's multi-threading functionality is questionable.

-- BLIS (openmp) 

libblas.so, libblas.so.3 = blis (openmp). Please note that BLIS use
single thread by default even if it's compiled with openmp/pthread
threading model.

$ octave 921193.m
   757875851200128   757875851200128   796692912410048   796692912410048

$ BLIS_NUM_THREADS=1 octave 921193.m
   531523819460688   531523819460688   543945552290544   543945552290544

$ OMP_NUM_THREADS=1 octave 921193.m
   385   385   385   385

Again, octave's multi-threading functionality is questionable.

--- OpenBLAS ---

libblas.so, libblas.so.3 = openblas

$ octave 921193.m
   907773323384928   907773323384928   925793789579664   925793789579664

$ octave 921193.m
   385   385   385   385

$ OPENBLAS_NUM_THREADS=1 octave 921193.m
   737565604371072   737565604371072   741382086552384   741382086552384

$ OMP_NUM_THREADS=1 octave 921193.m
   385   385   385   385

=

According to the above experimental results, I think BLAS libraries
are innocent.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921193

Bug#919362: lua5.3 ftbfs in unstable

2019-02-02 Thread Mo Zhou 
control: severity -1 important
control: tags -1 +moreinfo

I cannot reproduce this issue with sbuild.

Bug#919363: lua5.2 ftbfs in unstable

2019-02-02 Thread Mo Zhou 
control: severity -1 important
control: tags -1 +moreinfo

I cannot reproduce this failure with sbuild.

Bug#919364: lua5.1 ftbfs in unstable

2019-02-02 Thread Mo Zhou 
control: severity -1 important
control: tags -1 +moreinfo

I cannot reproduce the failure with sbuild.

Bug#915886: zfs-dkms: module FTBFS for 4.18.0-3-amd64: NR_FILE_PAGES in either node_stat_item or zone_stat_item: NOT FOUND

2019-01-05 Thread Mo Zhou 
Hi anbe,

Do you still have any idea about the way to reproduce this failure?

I've added an autopkgtest script to zfs to test the dkms build
against linux-headers-$(dpkg --print-architecture), and it seems
that I cannot reproduce this issue in a clean and minimal chroot.

http://debomatic-amd64.debian.net/distribution#unstable/zfs-linux/0.7.12-2/autopkgtest

Bug#918000: openmpi postinst failure due to missing space in script

2019-01-01 Thread Mo Zhou 
Package: libopenmpi3
Version: 3.1.3-7
Severity: serious

Dear maintainer,

You missed a space in the script, which resulted in


The following packages will be upgraded:
  libopenmpi3 openmpi-common
2 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
210 not fully installed or removed.
Need to get 0 B/2338 kB of archives.
After this operation, 16.4 kB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 168982 files and directories currently installed.)
Preparing to unpack .../libopenmpi3_3.1.3-7_amd64.deb ...
Unpacking libopenmpi3:amd64 (3.1.3-7) over (3.1.3-5) ...
rm: cannot remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran-8#': No such file 
or directory
rm: cannot remove 'End': No such file or directory
rm: cannot remove 'automatically': No such file or directory
rm: cannot remove 'added': No such file or directory
rm: cannot remove 'section': No such file or directory
dpkg: warning: old libopenmpi3:amd64 package post-removal script subprocess 
returned error exit status 1
dpkg: trying script from the new package instead ...
dpkg: error processing archive 
/var/cache/apt/archives/libopenmpi3_3.1.3-7_amd64.deb (--unpack):
 there is no script in the new version of the package - giving up
Preparing to unpack .../openmpi-common_3.1.3-7_all.deb ...
Unpacking openmpi-common (3.1.3-7) over (3.1.3-5) ...
rm: cannot remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran-8#': No such file 
or directory
rm: cannot remove 'End': No such file or directory
rm: cannot remove 'automatically': No such file or directory
rm: cannot remove 'added': No such file or directory
rm: cannot remove 'section': No such file or directory
dpkg: warning: old openmpi-common package post-removal script subprocess 
returned error exit status 1
dpkg: trying script from the new package instead ...
dpkg: error processing archive 
/var/cache/apt/archives/openmpi-common_3.1.3-7_all.deb (--unpack):


 cat /var/lib/dpkg/info/libopenmpi3:amd64.postrm | tail -n1
[ -d /usr/lib/$multiarch/fortran/$base ] && rm 
/usr/lib/$multiarch/fortran/$cmplr# End automatically added section

 ^missing space here

Bug#915831: Fwd:Re: zfsutils-linux: Upgrading to 0.7.12 breaks during dpkg --configure]

2018-12-31 Thread Mo Zhou 
- Forwarded message -

Hi Rich,

I investigated into this issue a bit and it looks like a result of
messy system where systemd-sysv and insserv are co-installed.
In insserv/sid, the postinst process will nolonger fail even if the
same error occurs. The error will disappear if you remove insserv.
And in your initial bug report, meta infomation told me that you
use systemd. So please don't co-install systemd-sysv and insserv.

>From zfs's side we can do mostly nothing to prevent user from
co-installing systemd-sysv and insserv, except for a simple
suggestion.

Does the issue you reported persist even after removing insserv?



I tried to install zfs tens of times in different virtual machines
setup in differrent settings. And my conclusion is simply don't
co-install them.

- End forwarded message -

Bug#916957: Bug #916957 in julia marked as pending

2018-12-20 Thread Mo Zhou 
Control: tag -1 pending

Hello,

Bug #916957 in julia reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/julia-team/julia/commit/abfae3d3e5c9c4962a97b0f8747c1a7b7eab5764


DFSG: Exclude contrib/windows/7zS.sfx (Closes: #916957)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/916957

Bug#911946: rc-status: double free or corruption (!prev)

2018-10-26 Thread Mo Zhou 
Package: openrc
Version: 0.38-2
Severity: serious

On my amd64 virtual machine rc-status failes every time I run it.
Some times it just reports

  double free or corruption (!prev)

And sometimes it reports

  malloc(): smallbin double linked list corrupted

I think this is 100% reproducible by just simply $ rc-status

Bug#911830: FTBFS on multiple architectures

2018-10-25 Thread Mo Zhou 
Package: python3-sklearn
Version: 0.20.0+dfsg-1
Severity: serious

https://buildd.debian.org/status/package.php?p=scikit-learn