Bug#911937: FTBFS on architecture=all

[Lumin]

Package: zfsutils-linux
Version: 0.7.11-2
Severity: serious
Owner: !

https://buildd.debian.org/status/package.php?p=zfs-linux

   dh_python3 -i -O--parallel
E: dh_python3 dh_python3:176: no package to act on (python3-foo or one with 
${python3:Depends} in Depends)
   dh_systemd_enable -i -O--parallel
   debian/rules override_dh_installinit
make[1]: Entering directory '/<>'
dh_installinit -r --no-start --name zfs-import
dh_installinit -r --no-start --name zfs-mount
dh_installinit -r --no-start --name zfs-share
dh_installinit -R --no-start --name zfs-zed
ln -sr /dev/null \
debian/zfsutils-linux/lib/systemd/system/zfs-import.service
ln: failed to create symbolic link 
'debian/zfsutils-linux/lib/systemd/system/zfs-import.service': No such file or 
directory
make[1]: *** [debian/rules:161: override_dh_installinit] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:35: binary-indep] Error 2

Bug#906932: kmer FTBFS in clean unstable chroot

[Lumin]

Yes, I'm doing parallel build with -j4

On Wed, Aug 22, 2018 at 23:34 Adrian Bunk  wrote:

> On Wed, Aug 22, 2018 at 01:58:15PM +0000, Lumin wrote:
> > Package: kmer
> > Version: 0~20150903+r2013-4
> > Severity: serious
> > Justification: FTBFS in clean chroot
> >
> > I cannot build kmer under both Debian experimental,
> > and the debian unstable docker.
> >
> > ```
>^
> > In file included from atac-driver/alignOverlap/overlap.H:45,
> >  from atac-driver/alignOverlap/overlap-sort.C:19:
> > atac-driver/alignOverlap/overlap-stats.H:64:29: warning: invalid suffix
> on literal; C++11 requires a space between literal and string macro
> [-Wliteral-suffix]
> >fprintf(out, uint32FMT" "uint32FMT"\n", i, hist[i]);
> >  ^
> > ln -f
> /root/kmer-0~20150903+r2013/atac-driver/alignOverlap/overlap-process.C
> /root/kmer-0~20150903+r2013/atac-driver/alignOverlap/overlap-process1.C
> > ln -f
> /root/kmer-0~20150903+r2013/atac-driver/alignOverlap/overlap-process.C
> /root/kmer-0~20150903+r2013/atac-driver/alignOverlap/overlap-process2.C
> > make[2]: *** No rule to make target
> '/root/kmer-0~20150903+r2013/atac-driver/libatac/libatac.a', needed by
> 'atac-driver/alignOverlap/overlap'.  Stop.
> > make[2]: *** Waiting for unfinished jobs
> > make[2]: Leaving directory '/root/kmer-0~20150903+r2013'
> > make[1]: *** [debian/rules:27: override_dh_auto_build] Error 2
> > make[1]: Leaving directory '/root/kmer-0~20150903+r2013'
> > make: *** [debian/rules:21: build] Error 2
> > dpkg-buildpackage: error: debian/rules build subprocess returned exit
> status 2
> > ```
>
> Are you using something like "dpkg-buildpackage -j" or "sbuild -j"?
>
> cu
> Adrian
>
> --
>
>"Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
>"Only a promise," Lao Er said.
>Pearl S. Buck - Dragon Seed
>
> --
Best,

Bug#906932: kmer FTBFS in clean unstable chroot

[Lumin]

Package: kmer
Version: 0~20150903+r2013-4
Severity: serious
Justification: FTBFS in clean chroot

I cannot build kmer under both Debian experimental,
and the debian unstable docker.

``` ^
In file included from atac-driver/alignOverlap/overlap.H:45,
 from atac-driver/alignOverlap/overlap-sort.C:19:
atac-driver/alignOverlap/overlap-stats.H:64:29: warning: invalid suffix on 
literal; C++11 requires a space between literal and string macro 
[-Wliteral-suffix]
   fprintf(out, uint32FMT" "uint32FMT"\n", i, hist[i]);
 ^
ln -f /root/kmer-0~20150903+r2013/atac-driver/alignOverlap/overlap-process.C 
/root/kmer-0~20150903+r2013/atac-driver/alignOverlap/overlap-process1.C
ln -f /root/kmer-0~20150903+r2013/atac-driver/alignOverlap/overlap-process.C 
/root/kmer-0~20150903+r2013/atac-driver/alignOverlap/overlap-process2.C
make[2]: *** No rule to make target 
'/root/kmer-0~20150903+r2013/atac-driver/libatac/libatac.a', needed by 
'atac-driver/alignOverlap/overlap'.  Stop.
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory '/root/kmer-0~20150903+r2013'
make[1]: *** [debian/rules:27: override_dh_auto_build] Error 2
make[1]: Leaving directory '/root/kmer-0~20150903+r2013'
make: *** [debian/rules:21: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
```

Bug#906708: Bug#906753: Acknowledgement (GCC's -O2 optimization breaks floating point precision or something else)

[Lumin]

This is the minimal code for repro #906753:

OK with -O0, FAIL with -O2 on i386, ppc64el, ...

masssq1 and masssq2 are computed from the same vector [1.1, 2.2, 3.3, 4.4],
but the results are different!

==

#include 
#include // for swap
#include 

namespace HepMC {
class FourVector {
public:
  double m_x, m_y, m_z, m_t;
  FourVector( double xin, double yin, double zin, double tin=0) : m_x(xin), 
m_y(yin), m_z(zin), m_t(tin) {}
  inline double m2() const {
return m_t*m_t - (m_x*m_x + m_y*m_y + m_z*m_z);
  }
  inline double m() const {
double mm = m2();
return mm < 0.0 ? -std::sqrt(-mm) : std::sqrt(mm);
  }
};
} // HepMC

int main()
{
  double eps = 1.e-15; // allowed differnce between doubles

  // FourVector
  HepMC::FourVector vector(1.1,2.2,3.3,4.4);
  HepMC::FourVector v4(1.1,2.2,3.3,4.4);

  //vector = v4;

  double masssq1 = v4.m2();
  double mass1 = v4.m();
  double masssq2 = vector.m2();
  double mass2 = vector.m();

  if( fabs( masssq1 - masssq2 ) > eps ) {
 std::cout << "different mass sq values: " << masssq1 << " " << masssq2 << 
std::endl;
 std::cout << "difference is : " << ( masssq1 - masssq2 ) << std::endl;
  }

  return 0;
}

Bug#906753: GCC's -O2 optimization breaks floating point precision or something else

[Lumin]

Package: g++-8
Version: 8.2.0-4
Severity: serious
Justification: -O2 results in different double precision number result.
Affects: 906708

This bug is found in package src:hepmc, which currently FTBFS on
i386, arm64, ppc64el and s390x.

https://buildd.debian.org/status/package.php?p=hepmc
 - arm64:
   difference is : 3.55271e-15
 - i386:
   difference is : 1.77636e-15
 - ppc64el:
   difference is : 3.55271e-15
 - s390x:
   difference is : 3.55271e-15

Data Matrix:

 * amd64 architecture
   + GCC-8:
 -O2 : OK
 -O0 : OK
   + Clang-6.0
 -O2 : OK
 -O0 : OK

 * ppc64el architecture
   + GCC-8:
 -O2 : FTBFS because floating point precision beyond tolerance
 -O0 : OK
   + Clang-6.0:
 -O2 : OK
 -O0 : OK

   + GCC-7:
 -O2 : FTBFS

   + GCC-6:
 -O2 : FTBFS

   + GCC-5:
 -O2 : FTBFS

 * i386, arm64, s390x not tested.

 * In testSimpleVector.cc, the expected result of
   v4.m2() and vector.m2() are both 2.4253 .

 * -O2 and -O0 can be specified in DEB_CXXFLAGS_MAINT_APPEND
 * default compiler can be switched by simply e.g.
   export CC=clang
   export CXX=clang++
   in debian/rules
   
I wanted to trace into testSimpleVector.cc with gdb to find out
what's going wrong. However this bug only occurs with -O2 option
with which gdb cannot trace the C++ code line by line.

Clang-6 doesn't FTBFS with the same compiler flags, so I
consider this bug is an RC bug of GCC.

I totally forgot how to dump the detail about gcc's -O2 option.
Hence I'm not sure if gcc -O2 used something like -ffast-math .

Bug#906708: hepmc: FTBFS on i386 / arm64 / ppc64el / s390x

[Lumin]

control: tags -1 +patch +confirmed

> Fix attached.

> -  double eps = 1.e-15; // allowed differnce between doubles
> +  double eps = 4.e-15; // allowed difference between doubles

No no no, please DON'T do this!

This precision issue is triggered by a GCC optimization bug,
and simply bumping floating point tolerance for scientific software
especially physics software is bad

The fix of this RC is to simply change the default compiler to Clang.
Or disable -O2 optimization with -O0

the real patch:

debian/rules:
export CC=clang
export CXX=clang++

Bug#906645: FTBFS due to "Dunno about this gcc"

[Lumin]

Source: insighttoolkit4
Version: 4.13.0-dfsg1
Severity: serious
Justification: FTBFS in sid/experimental.

[ 14%] Building CXX object 
Modules/ThirdParty/VNL/src/vxl/vcl/CMakeFiles/itkvcl.dir/vcl_deprecated.cxx.o
cd 
/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/BUILD/Modules/ThirdParty/VNL/src/vxl/vcl
 && /usr/bin/c++  -DVXL_LEGACY_ERROR_REPORTING -DVXL_WARN_DEPRECATED 
-DVXL_WARN_DEPRECATED_ONCE -Ditkvcl_EXPORTS 
-I/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/Modules/ThirdParty/VNL/src/vxl/v3p/netlib
 
-I/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/Modules/ThirdParty/VNL/src/vxl/vcl
 
-I/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/Modules/ThirdParty/VNL/src/vxl/core
 
-I/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/BUILD/Modules/ThirdParty/VNL/src/vxl/v3p/netlib
 
-I/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/BUILD/Modules/ThirdParty/VNL/src/vxl/vcl
 
-I/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/BUILD/Modules/ThirdParty/VNL/src/vxl/core
  -g -O2 -fdebug-prefix-map=/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -I/usr/include/nifti  -Wall -Wcast-align 
-Wdisabled-optimization -Wextra -Wformat=2 -Winvalid-pch -Wno-format-nonliteral 
-Wpointer-arith -Wshadow -Wunused -Wwrite-strings -funit-at-a-time 
-Wno-strict-overflow -Wno-deprecated -Wno-invalid-offsetof -Woverloaded-virtual 
-Wstrict-null-sentinel  -w  -fPIC   -o 
CMakeFiles/itkvcl.dir/vcl_deprecated.cxx.o -c 
/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/Modules/ThirdParty/VNL/src/vxl/vcl/vcl_deprecated.cxx
In file included from 
/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/Modules/ThirdParty/VNL/src/vxl/vcl/vcl_iostream.h:5,
 from 
/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/Modules/ThirdParty/VNL/src/vxl/vcl/vcl_deprecated.cxx:4:
/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/Modules/ThirdParty/VNL/src/vxl/vcl/vcl_compiler.h:90:4:
 error: #error "Dunno about this gcc"
 #  error "Dunno about this gcc"
^
make[2]: *** 
[Modules/ThirdParty/VNL/src/vxl/vcl/CMakeFiles/itkvcl.dir/build.make:66: 
Modules/ThirdParty/VNL/src/vxl/vcl/CMakeFiles/itkvcl.dir/vcl_deprecated.cxx.o] 
Error 1
make[2]: Leaving directory 
'/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/BUILD'
make[1]: *** [CMakeFiles/Makefile2:1636: 
Modules/ThirdParty/VNL/src/vxl/vcl/CMakeFiles/itkvcl.dir/all] Error 2
make[1]: Leaving directory 
'/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/BUILD'
make: *** [Makefile:166: all] Error 2

Bug#897767: closed by Mo Zhou (Bug#897767: fixed in highwayhash 0~20180209-g14dedec-5)

[Lumin]

control: retitle -1 non-x86 symbols out of date
control: severity -1 normal

This non-x86 arches are not my priorities currently. It doesn't deserve
another RFS bug to the mentors list, and it can be easily fixed by me when
I get my Debian Developer account.

On Mon, Aug 6, 2018 at 00:45 Adrian Bunk  wrote:

> Control: reopen -1
>
> On Mon, Jul 23, 2018 at 01:54:03AM +, Debian Bug Tracking System wrote:
> >...
> >  highwayhash (0~20180209-g14dedec-5) unstable; urgency=medium
> >  .
> >* Refresh symbols to avoid FTBFS with GCC-8 (Closes: #897767)
> >...
>
> unfortunately this fixed it only for amd64, the package still FTBFS
> on arm64/ppc64el/x32:
> https://buildd.debian.org/status/package.php?p=highwayhash
>
> cu
> Adrian
>
> --
>
>"Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
>"Only a promise," Lao Er said.
>Pearl S. Buck - Dragon Seed
>
-- 
Best,

Bug#904781: closing because h5py 2.8.0 has been uploaded

[Lumin]

control: close -1

closing because 0.2.8 has been uploaded.
I forgot to close this bug.

Bug#905439: su from util-linux breaks autopkgtest

[Lumin]

control: close -1

Hi Antonio,

The log is available here and the autopkgtest version used is 5.4.1~bpo9+2
http://debomatic-amd64.debian.net/distribution#unstable/h5py/2.8.0-1/autopkgtest

So I think it would be fixed when the backported backage is updated.
Sorry for the noise.

On Sat, Aug 04, 2018 at 01:31:27PM -0300, Antonio Terceiro wrote:
> Control: tag -1 + moreinfo unreproducible
> 
> On Sat, Aug 04, 2018 at 03:11:17PM +0000, Lumin wrote:
> > Package: autopkgtest
> > Version: 5.4.2
> > Severity: serious
> > 
> > the "su" command from util-linux breaks autopkgtest. The previous
> > working one comes from shadow.
> > 
> > python-h5py-dbg is already the newest version (2.8.0-1).
> > python-h5py-dbg set to manually installed.
> > python-h5py is already the newest version (2.8.0-1).
> > python-h5py set to manually installed.
> > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> > (Reading database ... 13709 files and directories currently installed.)
> > Removing autopkgtest-satdep (0) ...
> > autopkgtest [16:38:33]: test command1: set -e ; for py in $(pyversions -r 
> > 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c 
> > "import h5py; h5py.run_tests()" ; echo "Testing with $py-dbg:" ; $py-dbg -c 
> > "import h5py; h5py.run_tests()" ; done
> > autopkgtest [16:38:33]: test command1: [---
> > su: user  does not exist
> > autopkgtest [16:38:33]: test command1: ---]
> > Unexpected error:
> > Traceback (most recent call last):
> >   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop
> > command()
> >   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 646, in command
> > r = f(c, ce)
> >   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 584, in cmd_copyup
> > copyupdown(c, ce, True)
> >   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 469, in copyupdown
> > copyupdown_internal(ce[0], c[1:], upp)
> >   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 494, in 
> > copyupdown_internal
> > copyup_shareddir(sd[0], sd[1], dirsp, downtmp_host)
> >   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 408, in 
> > copyup_shareddir
> > shutil.copy(tb, host)
> >   File "/usr/lib/python3.5/shutil.py", line 241, in copy
> > copyfile(src, dst, follow_symlinks=follow_symlinks)
> >   File "/usr/lib/python3.5/shutil.py", line 120, in copyfile
> > with open(src, 'rb') as fsrc:
> > FileNotFoundError: [Errno 2] No such file or directory: 
> > '/var/run/schroot/mount/unstable-amd64-debomatic-98e10886-4014-46ea-a35e-37ffe71bdcf3/tmp/autopkgtest.mZ5fp7/command1-stdout'
> > autopkgtest [16:38:34]: ERROR: testbed failure: unexpected eof from the 
> > testbed
> 
> Are you sure you saw this with autopkgtest 5.4.2? This bug was present
> 5.4.1, but explicitly fixed in 5.4.2.
> 
> See the attached log for an attempt I just made at reproducing this. The
> tests fail but autopkgtest itself works as expected.

> autopkgtest [13:26:52]: version 5.4.2
> autopkgtest [13:26:52]: host lemur; command line: /usr/bin/autopkgtest 
> --apt-upgrade --log-file /tmp/log -B h5py -- lxc --sudo 
> autopkgtest-unstable-amd64
> autopkgtest: WARNING: running as root in testbed, because no normal user 
> could be determined
> autopkgtest [13:27:04]:  test bed setup
> Get:1 http://deb.debian.org/debian unstable InRelease [233 kB]
> Get:2 http://deb.debian.org/debian unstable/non-free Sources.diff/Index [27.8 
> kB]
> Get:3 http://deb.debian.org/debian unstable/main Sources.diff/Index [27.9 kB]
> Get:4 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index 
> [27.9 kB]
> Get:5 http://deb.debian.org/debian unstable/contrib amd64 Packages.diff/Index 
> [27.8 kB]
> Get:6 http://deb.debian.org/debian unstable/non-free Sources 
> 2018-08-03-2013.11.pdiff [1,306 B]
> Get:7 http://deb.debian.org/debian unstable/non-free Sources 
> 2018-08-04-0814.44.pdiff [665 B]
> Get:8 http://deb.debian.org/debian unstable/main Sources 
> 2018-08-02-1416.04.pdiff [5,521 B]
> Get:7 http://deb.debian.org/debian unstable/non-free Sources 
> 2018-08-04-0814.44.pdiff [665 B]
> Get:9 http://deb.debian.org/debian unstable/main Sources 
> 2018-08-02-2015.39.pdiff [10.3 kB]
> Get:10 http://deb.debian.org/debian unstable/main Sources 
> 2018-08-03-0208.52.pdiff [3,145 B]
> Get:11 http://deb.debian.org/debian unstable/main Sources 
> 2018-08-03-0811.08.pdiff [15.6 kB]
> 

Bug#905439: su from util-linux breaks autopkgtest

[Lumin]

Package: autopkgtest
Version: 5.4.2
Severity: serious

the "su" command from util-linux breaks autopkgtest. The previous
working one comes from shadow.

python-h5py-dbg is already the newest version (2.8.0-1).
python-h5py-dbg set to manually installed.
python-h5py is already the newest version (2.8.0-1).
python-h5py set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
(Reading database ... 13709 files and directories currently installed.)
Removing autopkgtest-satdep (0) ...
autopkgtest [16:38:33]: test command1: set -e ; for py in $(pyversions -r 
2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c 
"import h5py; h5py.run_tests()" ; echo "Testing with $py-dbg:" ; $py-dbg -c 
"import h5py; h5py.run_tests()" ; done
autopkgtest [16:38:33]: test command1: [---
su: user  does not exist
autopkgtest [16:38:33]: test command1: ---]
Unexpected error:
Traceback (most recent call last):
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop
command()
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 646, in command
r = f(c, ce)
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 584, in cmd_copyup
copyupdown(c, ce, True)
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 469, in copyupdown
copyupdown_internal(ce[0], c[1:], upp)
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 494, in 
copyupdown_internal
copyup_shareddir(sd[0], sd[1], dirsp, downtmp_host)
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 408, in 
copyup_shareddir
shutil.copy(tb, host)
  File "/usr/lib/python3.5/shutil.py", line 241, in copy
copyfile(src, dst, follow_symlinks=follow_symlinks)
  File "/usr/lib/python3.5/shutil.py", line 120, in copyfile
with open(src, 'rb') as fsrc:
FileNotFoundError: [Errno 2] No such file or directory: 
'/var/run/schroot/mount/unstable-amd64-debomatic-98e10886-4014-46ea-a35e-37ffe71bdcf3/tmp/autopkgtest.mZ5fp7/command1-stdout'
autopkgtest [16:38:34]: ERROR: testbed failure: unexpected eof from the testbed

Bug#905101: not working with python3

[Lumin]

Package: pius
Version: 2.2.6-1
Severity: serious
Justification: totally unusable with python3.


~ ❯❯❯ pius -A -s  -r ~/.gnupg/pubring.kbx  -m 
Welcome to PIUS, the PGP Individual UID Signer.

Traceback (most recent call last):
  File "/usr/bin/pius", line 328, in 
main()
  File "/usr/bin/pius", line 261, in main
options.mail_host
  File "/usr/lib/python3/dist-packages/libpius/signer.py", line 88, in __init__
self.gpg2 = self._is_gpg2()
  File "/usr/lib/python3/dist-packages/libpius/signer.py", line 120, in _is_gpg2
m = re.match(r'^gpg \(GnuPG.*\) ([0-9\.]+)$', line)
  File "/usr/lib/python3.6/re.py", line 172, in match
return _compile(pattern, flags).match(string)
TypeError: cannot use a string pattern on a bytes-like object

https://github.com/jaymzh/pius/issues/98

Bug#904434: intel-mkl: FTBFS in C locale

[Lumin]

control: tags -1 +pending

fixed in master branch.

Bug#904319: FTBFS when building binary-packages only

[Lumin]

Thanks for the full log, very helpful!

I can reproduce the failure with

  LC_ALL=POSIX python3 ...

and it could be avoided by

  LC_ALL=C.UTF-8 python3 ...

On Mon, Jul 23, 2018 at 02:43:41PM +0200, Santiago Vila wrote:
> On Mon, Jul 23, 2018 at 12:16:45PM +0000, Lumin wrote:
> 
> > Thanks for the report, but could you please provider a more verbose
> > failure report?
> 
> Sure. I've put the full build log here:
> 
> https://people.debian.org/~sanvila/build-logs/intel-mkl/
> 
> This was a binary-indep only build, i.e. "dpkg-buildpackage -A".
> 
> Assuming "dpkg-buildpackage -A" is not the issue here, you would get full
> build logs here as well:
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/intel-mkl.html
> 
> but only when the page finally exists.
> 
> > And could you please test this patch:
> > 
> > LC_ALL=C.UTF-8 python3 debian/control.py
> 
> Sorry, I can't test modified packages easily in my autobuilder setup.
> 
> You should be able to reproduce this using either sbuild or pbuilder.
> By looking at the proposed patch I bet that this could be reproduced
> with a simple chroot as well, setting LC_ALL=C before dpkg-buildpackage,
> but I don't really know.
> 
> Thanks.

Bug#904319: FTBFS when building binary-packages only

[Lumin]

Hi Santiago,

Thanks for the report, but could you please provider a more verbose
failure report?

And could you please test this patch:

LC_ALL=C.UTF-8 python3 debian/control.py

```
diff --git a/debian/rules b/debian/rules
index 212c9aa..8d21adc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -39,7 +39,7 @@ autogen: extract-rpms $(AUTOGEN_FILES)
chmod +x debian/libmkl-dev.postinst debian/libmkl-dev.prerm  
debian/libmkl-dev.config

 override_dh_auto_configure: autogen
-   python3 debian/control.py  # Generate install files and lintian 
overrides
+   LC_ALL=C.UTF-8 python3 debian/control.py  # Generate install files and 
lintian overrides

# deal with embedded libjs-jquery
$(RM) 
opt/intel/documentation_2018/ja/mkl/ps2018/resources/jquery-1.11.1.min.js
```

Bug#903659: OpenBLAS 0.3.1 gives incorrect SVD result

[Lumin]

Package: libopenblas-base
Version: 0.3.1+ds-1
Severity: serious

https://github.com/JuliaLang/julia/pull/28002
https://github.com/JuliaLang/julia/issues/27960
https://github.com/xianyi/OpenBLAS/issues/1666

Bug#873408: lowering severity

[Lumin]

Control: severity -1 important

julia_0.6.3-5 was just uploaded to unstable, it depends on llvm-4.0 .

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

[Lumin]

X-Debbugs-CC: gin...@debian.org, stef...@berkeley.edu, deb...@onerussian.com
control: owner -1 !

I'm working on this. It would take days for me to finish it
due to my final terms... But I think it doesn't matter because
we still have a month until AUTORM.

https://salsa.debian.org/lumin-guest/skimage/commits/master

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

[Lumin]

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

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

[Lumin]

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

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

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

[Lumin]

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

Bug#863511: [numba/ppc64el] segfault

[Lumin]

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

still exists in 0.37.0

Bug#863512: numba/x390x: segfault

[Lumin]

numba 0.37.0-1 

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

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


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

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

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

[Lumin]

Dear skimage maintainer,

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

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

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


signature.asc
Description: PGP signature

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

[Lumin]

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

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

Bug#901383: whalebuilder is broken after the ruby upgrade

[Lumin]

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

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



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

Bug#896295: Tensorflow is missing

[Lumin]

Hello Debian-Science folks,

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

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

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

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

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

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

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

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

farmhash
gemmlowp
highwayhash

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

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

[Lumin]

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

// Encoding: UTF-8, Simplified Chinese

致 Debian 中文团队：

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

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

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

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

非常感谢。

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


signature.asc
Description: PGP signature

Bug#899513: Invalid maintainer address chinese-develop...@lists.alioth.debian.org

[Lumin]

Dear Debian Chinese Team,

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

As suggested by Boyuan, we can either

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

Which one to choose?

Regards,
lumin

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




signature.asc
Description: PGP signature

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

[Lumin]

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


signature.asc
Description: PGP signature

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

[Lumin]

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

Dear Numpy maintainers,

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

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

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

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

Output:

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

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

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


signature.asc
Description: PGP signature

Bug#899133: FTBFS on Architecture:all

[Lumin]

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

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

Bug#898483: Acknowledgement (failed creating configuration directroy: unsupported)

[Lumin]

control: tag -1 +patch

I think the problem lays in main.cpp :

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

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

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

Not verified. Hope it helps.


signature.asc
Description: PGP signature

Bug#898483: failed creating configuration directroy: unsupported

[Lumin]

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

Dear lincity-ng maintainer,

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

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

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

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

Best,

Bug#897506: Cannot reproduce

[Lumin]

control: severity -1 important
Hi,

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

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

Bug#889539: pandas FTBFS: test failures

[Lumin]

Yaroslav has just uploaded pandas 0.22.0, let's see if this problem
still exists.

On 7 February 2018 at 14:57, Andreas Tille <andr...@an3as.eu> wrote:
> On Tue, Feb 06, 2018 at 03:51:27PM +0000, Lumin wrote:
>> Apart from that, the pandas packaging needs a patch [2] to reduce
>> autopkgtest failures.
>
> As always:  Please push your patches. :-)
> You and I are in the same position: We are team members of the maintainer
> team.  I even have the strong impression, that you are the more competent
> team member than me in terms of pandas.  So please do not be shy. ;-)
>
> Thanks a lot and feel to keep on pushing promising patches
>
> Andreas.
>
>> [2]
>> diff --git a/debian/tests/control b/debian/tests/control
>> index 38521c8..ab54101 100644
>> --- a/debian/tests/control
>> +++ b/debian/tests/control
>> @@ -15,6 +15,7 @@ Depends: python-all,
>>   python-xlwt,
>>   python-bs4,
>>   python-html5lib,
>> + python-pytest,
>>   xauth,
>>   xvfb
>>
>> @@ -29,5 +30,6 @@ Depends: python3-all,
>>   python3-tk,
>>   python3-tz,
>>   python3-bs4,
>> + python3-pytest,
>>   xauth,
>>   xvfb
>
> --
> http://fam-tille.de



-- 
Best,

Bug#877130: highwayhash: FTBFS with GCC 7: symbols files need to be updated

[Lumin]

On 7 February 2018 at 00:27, Andreas Beckmann  wrote:
> The new upstream snapshot probably cuased further symbol changes:

Indeed and thanks. I was just waiting for an upstream build fix for ppc64el.



-- 
Best,

Bug#889539: pandas FTBFS: test failures

[Lumin]

Hi Andreas,

On 6 February 2018 at 11:10, Andreas Tille  wrote:

> you did a really good job on latest pandas issues.  Do you think you can
> have a look at this problem as well?

I found no related upsteam issue about the failed tests. However there are
some links that might be useful:

https://stackoverflow.com/questions/40659212/futurewarning-elementwise-comparison-failed-returning-scalar-but-in-the-futur
https://stackoverflow.com/questions/15777951/how-to-suppress-pandas-future-warning

I noticed these lines [1] in the test log. The failures seem to be
numpy issues again
according to the stackoverflow answers.

Apart from that, the pandas packaging needs a patch [2] to reduce
autopkgtest failures.


> BTW, to upgrade pandas to the latest upstream version python-moto is
> needed.  I prepared the packaging (#777089) and may be there is only a
> minor issue to finalise this (see [1]).  It might be a sensible strategy
> To upgrade to latest pandas upstream to not spent to much time on the
> old code - however, I have no idea about compatibility issues of all of
> its rdepends.

I checked and tried to build that package. Feedbacks were sent in
another mail. I think the 0.20.3-12 upload is not necessary as long as
we manage to build the new pandas before the removal, because
there is no obvious bug in pandas itself -- the patch for -12 will be
workarounds to those external problems.


[1] 
debian/tmp/usr/lib/python2.7/dist-packages/pandas/tests/dtypes/test_missing.py::test_array_equivalent_compat
  /usr/lib/python2.7/dist-packages/numpy/core/numeric.py:2604:
FutureWarning: elementwise == comparison failed and returning scalar
instead; this will raise an error or perform elementwise comparison in
the future.
return bool(asarray(a1 == a2).all())

debian/tmp/usr/lib/python2.7/dist-packages/pandas/tests/frame/test_analytics.py::TestDataFrameAnalytics::()::test_corr_int_and_boolean
  /usr/lib/python2.7/dist-packages/scipy/stats/stats.py:3577:
RuntimeWarning: invalid value encountered in double_scalars
size * (size - 1) * (size - 2))

debian/tmp/usr/lib/python2.7/dist-packages/pandas/tests/plotting/test_boxplot_method.py::TestDataFramePlots::()::test_boxplot_legacy
  /usr/lib/python2.7/dist-packages/numpy/core/fromnumeric.py:57:
FutureWarning: reshape is deprecated and will raise in a subsequent
release. Please use .values.reshape(...) instead
return getattr(obj, method)(*args, **kwds)
  /usr/lib/python2.7/dist-packages/numpy/core/fromnumeric.py:57:
FutureWarning: reshape is deprecated and will raise in a subsequent
release. Please use .values.reshape(...) instead
return getattr(obj, method)(*args, **kwds)
  /usr/lib/python2.7/dist-packages/numpy/core/fromnumeric.py:57:
FutureWarning: reshape is deprecated and will raise in a subsequent
release. Please use .values.reshape(...) instead
return getattr(obj, method)(*args, **kwds)
  /usr/lib/python2.7/dist-packages/numpy/core/fromnumeric.py:57:
FutureWarning: reshape is deprecated and will raise in a subsequent
release. Please use .values.reshape(...) instead
return getattr(obj, method)(*args, **kwds)
  /usr/lib/python2.7/dist-packages/numpy/core/fromnumeric.py:57:
FutureWarning: reshape is deprecated and will raise in a subsequent
release. Please use .values.reshape(...) instead
return getattr(obj, method)(*args, **kwds)
  /usr/lib/python2.7/dist-packages/numpy/core/fromnumeric.py:57:
FutureWarning: reshape is deprecated and will raise in a subsequent
release. Please use .values.reshape(...) instead
return getattr(obj, method)(*args, **kwds)
  /usr/lib/python2.7/dist-packages/numpy/core/fromnumeric.py:57:
FutureWarning: reshape is deprecated and will raise in a subsequent
release. Please use .values.reshape(...) instead
return getattr(obj, method)(*args, **kwds)
  /usr/lib/python2.7/dist-packages/numpy/core/fromnumeric.py:57:
FutureWarning: reshape is deprecated and will raise in a subsequent
release. Please use .values.reshape(...) instead
return getattr(obj, method)(*args, **kwds)

debian/tmp/usr/lib/python2.7/dist-packages/pandas/tests/plotting/test_boxplot_method.py::TestDataFramePlots::()::test_boxplot_axis_limits
  /usr/lib/python2.7/dist-packages/numpy/core/fromnumeric.py:57:
FutureWarning: reshape is deprecated and will raise in a subsequent
release. Please use .values.reshape(...) instead
return getattr(obj, method)(*args, **kwds)

debian/tmp/usr/lib/python2.7/dist-packages/pandas/tests/plotting/test_datetimelike.py::TestTSPlot::()::test_irreg_hf
  /usr/lib/python2.7/dist-packages/matplotlib/cbook/deprecation.py:106:
MatplotlibDeprecationWarning: Adding an axes using the same arguments
as a previous axes currently reuses the earlier instance.  In a future
version, a new instance will always be created and returned.
Meanwhile, this warning can be suppressed, and the future behavior
ensured, by passing a unique label to each axes instance.
warnings.warn(message, mplDeprecation, stacklevel=1)
  

Bug#884294: Patch for pandas RC 884294, someone to sponsor?

[Lumin]

> I'd volunteer to upload once it is pushed.  Please ping me after pushing
> since there is not commit mailing list and I'm not sure whether the
> tracker solution is implemented yet.

Done.
https://salsa.debian.org/science-team/pandas/commits/debian

-- 
Best,

Bug#884294: Patch for pandas RC 884294, someone to sponsor?

[Lumin]

Control: tags -1 +patch

Pandas FTBFS on amd64 due to test failure:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884294
I reproduced this FTBFS on my machine (sid/amd64).

This test failure was due to a numpy problem. Upstream workaround
(bypass) is available:
* 
https://github.com/pandas-dev/pandas/commit/5f2b96bb637f6ddeec169c5ef8ad20013a03c853

Another test failure arose (not related to #884924). The new failure
could be solved by referencing:
* https://github.com/pandas-dev/pandas/issues/17046
* https://github.com/pandas-dev/pandas/pull/17051

For details about more test failures arose when I'm writing this email please
check the patches.

debomatic-amd64 build was successful:
http://debomatic-amd64.debian.net/distribution#unstable/pandas/0.20.3-11/buildlog

git-formatted patches are attached. I can push the commits to salsa if
the fix is fine.
Can someone review and sponsor the Team upload?
Thanks.

pandas (0.20.3-11) unstable; urgency=medium

  * Team upload.
  * Cherry-pick upstream commit 5f2b96bb637f6ddeec169c5ef8ad20013a03c853
to workaround a numpy bug. (Closes: #884294)
+ patches/up_tst_dont_assert_that_a_bug_exists_in_numpy
  * Cherry-pick upstream commits to fix test failure caused by test_argsort().
+ patches/up_tst_np_argsort_comparison2
  * Workaround test failure of test_basic_indexing() in file
pandas/tests/series/test_indexing.py .
+ patches/deb_fix_test_failure_test_basic_indexing



-- 
Best,
From 23745eb17f921b42e1b3ee574c2aef0f05d4252f Mon Sep 17 00:00:00 2001
From: Mo Zhou 
Date: Sat, 20 Jan 2018 09:02:43 +
Subject: [PATCH 1/7] Cherry-pick upstream commit
 5f2b96bb637f6ddeec169c5ef8ad20013a03c853 to workaround a numpy bug. (Closes:
 #884294)

---
 debian/patches/series  |  1 +
 .../up_tst_dont_assert_that_a_bug_exists_in_numpy  | 33 ++
 2 files changed, 34 insertions(+)
 create mode 100644 debian/patches/up_tst_dont_assert_that_a_bug_exists_in_numpy

diff --git a/debian/patches/series b/debian/patches/series
index b0c042d..209965f 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -9,6 +9,7 @@ deb_skip_sequencelike_on_armel
 # 858260.patch
 up_print_versions
 up_network_seaborn
+up_tst_dont_assert_that_a_bug_exists_in_numpy
 dateutil-2.6.1-fixed-ambiguous-tz-dst-be.patch
 mark_tests_working_on_intel.patch
 mark_tests_working_on_intel_s390x.patch
diff --git a/debian/patches/up_tst_dont_assert_that_a_bug_exists_in_numpy b/debian/patches/up_tst_dont_assert_that_a_bug_exists_in_numpy
new file mode 100644
index 000..4242da7
--- /dev/null
+++ b/debian/patches/up_tst_dont_assert_that_a_bug_exists_in_numpy
@@ -0,0 +1,33 @@
+From 5f2b96bb637f6ddeec169c5ef8ad20013a03c853 Mon Sep 17 00:00:00 2001
+From: Eric Wieser 
+Date: Sat, 15 Jul 2017 13:30:03 +0100
+Subject: [PATCH] TST: Don't assert that a bug exists in numpy (#16940)
+
+Better to ignore the warning from the bug, rather than assert the bug is still there
+
+After this change, numpy/numpy#9412 _could_ be backported to fix the bug
+---
+ pandas/tests/test_algos.py | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/pandas/tests/test_algos.py b/pandas/tests/test_algos.py
+index 9504d2a9426..993dcc4f527 100644
+--- a/pandas/tests/test_algos.py
 b/pandas/tests/test_algos.py
+@@ -2,6 +2,7 @@
+ 
+ import numpy as np
+ import pytest
++import warnings
+ 
+ from numpy.random import RandomState
+ from numpy import nan
+@@ -127,7 +128,7 @@ def test_unsortable(self):
+ arr = np.array([1, 2, datetime.now(), 0, 3], dtype=object)
+ if compat.PY2 and not pd._np_version_under1p10:
+ # RuntimeWarning: tp_compare didn't return -1 or -2 for exception
+-with tm.assert_produces_warning(RuntimeWarning):
++with warnings.catch_warnings():
+ pytest.raises(TypeError, algos.safe_sort, arr)
+ else:
+ pytest.raises(TypeError, algos.safe_sort, arr)
-- 
2.15.1

From b92f86abb26073326ec80dffaa017c1e3f77eab5 Mon Sep 17 00:00:00 2001
From: Mo Zhou 
Date: Sat, 20 Jan 2018 09:04:32 +
Subject: [PATCH 2/7] dch: finalize, upload to unstable

---
 debian/changelog | 8 
 1 file changed, 8 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index bed979e..53b0deb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+pandas (0.20.3-11) unstable; urgency=medium
+
+  * Team upload.
+  * Cherry-pick upstream commit 5f2b96bb637f6ddeec169c5ef8ad20013a03c853
+to workaround a numpy bug. (Closes: #884294)
+
+ -- Mo Zhou   Sat, 20 Jan 2018 09:00:31 +
+
 pandas (0.20.3-10) unstable; urgency=medium
 
   * Team upload.
-- 
2.15.1

From c37cee1b4a9c44522c6bf3d74bceb8f0b20364cd Mon Sep 17 00:00:00 2001
From: Mo Zhou 
Date: Sat, 20 Jan 2018 10:12:15 +
Subject: [PATCH 3/7] Cherry-pick upstream commit to fix test failure caused by

Bug#870029: Missing new dependency "moses"

[Lumin]

Package: lua-torch-nn
Version: 0~20170726-gf613412+dfsg-1
Severity: serious

Recently the upstream added a new package "moses"
as its runtime dependency, which is not packaged
for Debian.

The missing of 'moses' package renders 'lua-torch-nn'
unusable.

Bug#861878: fixed in nvidia-cuda-toolkit 8.0.44-4

[Lumin]

> try: grep-excuses nvidia-cuda-toolkit
> :-)


I find it's already unblocked, and get a new tool :-)
Thanks.

Bug#861878: fixed in nvidia-cuda-toolkit 8.0.44-4

[Lumin]

Hi,

We should either lower the severity of this bug or request for an unblock for
this package to prevent it and its r-deps from autoremoval.

Bug#861878: nvidia-cuda-toolkit: nvcc needs to pass -fpie to compiler

[lumin]

Control: tags -1 +patch

This patch simply discussed about the way getting NVCC
working with the compiler in README.Debian.

Please review.From a9c1cc803ddc531c06e0f51c50c8b2f2eba22510 Mon Sep 17 00:00:00 2001
From: Zhou Mo 
Date: Mon, 22 May 2017 07:53:07 +
Subject: [PATCH] README.Debian: discuss about getting NVCC working with
 compiler

This is what we can do from the CUDA packaging side in order to
Close #861878.
---
 nvidia-cuda-toolkit.README.Debian | 54 +++
 1 file changed, 54 insertions(+)

diff --git a/nvidia-cuda-toolkit.README.Debian b/nvidia-cuda-toolkit.README.Debian
index d6e7a3a..b702963 100644
--- a/nvidia-cuda-toolkit.README.Debian
+++ b/nvidia-cuda-toolkit.README.Debian
@@ -1,5 +1,59 @@
 nvidia-cuda-toolkit for Debian
 --
+Contents:
+  1. Getting NVCC Working with the Compiler
+  2. Installing the CUDA Code Samples
+
+Getting NVCC Working with the Compiler
+==
+
+It is worth noting that not all compilers can be used together with NVCC.
+Here is a list of possible combinations:
+
+```
+CXX compiler |  CUDA 7.5  |  CUDA 8.0  |  CUDA 9.0  |
+-++++
+GCC-8| ?  | ?  | ?  |
+GCC-7| ?  | ?  | ?  |
+GCC-6| X  | X  | OK |
+GCC-5| OK[1]  | OK | OK |
+-++++
+CLANG-4.0| ?  | ?  | ?  |
+CLANG-3.9| X  | X  | OK |
+CLANG-3.8| ?  | OK | OK |
+```
+
+In the above table, '?' means 'not tested', 'X' means 'never work',
+'OK' means 'should work'.
+
+CUDA 8.0 Specific
+-
+
+The recommended way, as declared in NEWS, to compile your CUDA application
+with CUDA 8.0 is to globally use clang-3.8/clang++-3.8 as the C/CXX compiler
+for your project. Example:
+
+  CC=clang-3.8 make
+
+However, when you have to mix the use of GCC and CLANG, things differ.
+Due to the difference on the default options of the two compilers, you
+may have to add flags such as -fPIC/-fPIE or alike to CLANG's argument
+list, to avoid the linkage failure as reported in BUG #861878 [2].
+See [3] for detail about these compiler options. Example:
+
+  nvcc -ccbin clang-3.8 --compiler-options -fPIC ...
+
+Sidenotes
+-
+
+Debian Stretch ships CUDA 8.0, and the same time its default GCC is
+GCC-6. So we changed the default compiler to clang-3.8 for the CUDA 8.0
+package because Stretch ships no GCC-5.
+
+[1] CUDA 7.5 works with GCC-5 after begin patched.
+[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861878
+[3] https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html
+
 
 Installing the CUDA Code Samples
 =
-- 
2.11.0

Bug#861878: nvidia-cuda-toolkit: nvcc needs to pass -fpie to compiler

[Lumin]

>> That means, the "build your whole application with clang-3.8"
>> advise is temporary and specific to CUDA 8.0. Before uploading
>> CUDA 9.0 to unstable/experimental, we can change the default
>> compiler back to GCC. And backporting CUDA 9.0 to stretch
>> will eliminate the compiler trouble.
>
> It would be interesting to know how GCC 7 plays along with CUDA 9.0

NVIDIA didn't say anything about CUDA 9.0's support on GCC-7.
This is to be tested.

Bug#861878: nvidia-cuda-toolkit: nvcc needs to pass -fpie to compiler

[Lumin]

@doko GCC-5 may be removed from unstable when CUDA 9.0
is uploaded. See below.
(Maybe doko is already in some of these lists.)

> The problem is the move of some parts of the toolchain to pie by
> default, without updating the whole toolchain. Whenever not using only
> gcc for building object files, the issue shows up. nvcc is only an
> example of this.

Yes, toolchain problem. Due to the difference on the default option,
the mixed use of GCC and CLANG may end up with a failure as shown
in previous examples. This issue is not related to CUDA so I think
another bug against clang should be submitted.

>> And what can we do from the CUDA packaging side except for a new
>> NEWS/README.Debian section?
>>
> That's probably a reasonable thing to do on that side, yes.

The good news is that, the upcoming CUDA 9.0 supports GCC-6
and CLANG-3.9, as reported here

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

That means, the "build your whole application with clang-3.8"
advise is temporary and specific to CUDA 8.0. Before uploading
CUDA 9.0 to unstable/experimental, we can change the default
compiler back to GCC. And backporting CUDA 9.0 to stretch
will eliminate the compiler trouble.

Bug#861878: nvidia-cuda-toolkit: nvcc needs to pass -fpie to compiler

[Lumin]

Hi,

> This was documented in NEWS.Debian.gz. Having to use "--compiler-options
> -fPIC" was however not documented in NEW.Debian.gz, at least that should
> be done.
>
> Ok, but that's still something difficult to the user to work out, while
> it is needed for basically any use of nvcc. Currently NEWS.Debian.gz
> only advises to use -ccbin clang-3.8.
>
> Well, AIUI it's not considered a bug to require PIE, but a toolchain
> goal...
>
> Sure, but application Makefiles are not ready for that, we had to
> tinker them to use clang-3.8, and NEWS.Debian.gz only talks about the
> invokation of nvcc, not the eventual linking issue.

Well, what do you think we can to to deal with this bug?

And what can we do from the CUDA packaging side except for a new
NEWS/README.Debian section?

I plan to point out these in the new NEWS/README.Debian section:
(1) Try to compile the whole CUDA application with clang-3.8
(2) Append the PIE/PIC flags to compiler arguments, reference: [1]

[1] http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html

Bug#861878: nvidia-cuda-toolkit: nvcc needs to pass -fpie to compiler

[Lumin]

Hi Samuel,

I'm not sure whether this bug should be marked as serious. Since your test
cases are mixing the default cc (GCC-6) and clang-3.8 together.

I reproduced the failure you reported, but there is a simpler solution
to the issue
as shown below.

test$ CC=clang-3.8 make
clang-3.8-c -o test.o test.c
nvcc -ccbin clang-3.8 -c test-cuda.cu -o test-cuda.o
nvcc warning : The 'compute_20', 'sm_20', and 'sm_21' architectures are deprecat
ed, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to s
uppress warning).
clang-3.8   test.o test-cuda.o  -lcudart -o test

test2$ CC=clang-3.8 make
clang-3.8-c -o test.o test.c
clang-3.8  -c test-clang.c -o test-clang.o
clang-3.8   test.o test-clang.o   -o test

Maybe this is a bug about GCC's linking process on a set of GCC-6 and
clang-3.8 produced objects. I did further test on your test2.tgz,
swapping GCC-6 and clang-3.8:

test2$ cat Makefile
CLANG=cc
[...]
test2$ CC=clang-3.8 make
clang-3.8-c -o test.o test.c
cc  -c test-clang.c -o test-clang.o
clang-3.8   test.o test-clang.o   -o test

Clang-3.8 is able to link a set of mixed object files while GCC-6
fails to do so. I guess
this bug is a GCC-6 bug and not related to CUDA?

On the other hand, for instance, cuda application package
"caffe-contrib" was thoroughly
and finely compiled by clang-3.8 .

Best,

Bug#851578: add nmu patch for this bug, however encountered FTBFS due to testsuite failure

[lumin]

Control: tags -1 +patch

Here is an NMU patch for this package. I intended to file an
RFS but the debomatic build failure stopped me to do so.

The build failure was caused by testsuite failure:
http://debomatic-amd64.debian.net/distribution#experimental/numba/0.30.0-2.1/buildlog

diff -Nru numba-0.30.0/debian/changelog numba-0.30.0/debian/changelog
--- numba-0.30.0/debian/changelog	2016-12-29 18:50:40.0 +
+++ numba-0.30.0/debian/changelog	2017-02-17 12:27:37.0 +
@@ -1,3 +1,12 @@
+numba (0.30.0-2.1) experimental; urgency=medium
+
+  * Non-maintainer / Team upload.
+  * Remove unwanted file "annotation_usecases.py" for the python2 package.
+(Closes: #851578)
+  * Add basic autopkgtest support.
+
+ -- Zhou Mo   Fri, 17 Feb 2017 12:27:37 +
+
 numba (0.30.0-2) experimental; urgency=medium
 
   * deb/control:
diff -Nru numba-0.30.0/debian/rules numba-0.30.0/debian/rules
--- numba-0.30.0/debian/rules	2016-12-29 18:16:39.0 +
+++ numba-0.30.0/debian/rules	2017-02-17 12:22:23.0 +
@@ -7,6 +7,11 @@
 %:
 	dh $@ --with python2,python3,sphinxdoc --buildsystem=pybuild
 
+override_dh_auto_install:
+	dh_auto_install
+	# remove the unwanted file for python2 package
+	find debian/python-numba -type f -name annotation_usecases.py -delete
+
 override_dh_auto_test:
 	PYBUILD_SYSTEM=custom PYBUILD_TEST_ARGS="cd {build_dir} && {interpreter} -Wd -m pytest numba/tests -v -rs" dh_auto_test
 
diff -Nru numba-0.30.0/debian/tests/control numba-0.30.0/debian/tests/control
--- numba-0.30.0/debian/tests/control	1970-01-01 00:00:00.0 +
+++ numba-0.30.0/debian/tests/control	2017-02-17 12:24:02.0 +
@@ -0,0 +1,3 @@
+Tests: simpletest.py2.sh
+
+Tests: simpletest.py3.sh
diff -Nru numba-0.30.0/debian/tests/simpletest.py2.sh numba-0.30.0/debian/tests/simpletest.py2.sh
--- numba-0.30.0/debian/tests/simpletest.py2.sh	1970-01-01 00:00:00.0 +
+++ numba-0.30.0/debian/tests/simpletest.py2.sh	2017-02-17 12:25:58.0 +
@@ -0,0 +1,22 @@
+#!/bin/sh
+set -e
+
+# example taken from http://numba.pydata.org/
+python2 -c "
+from numba import jit
+from numpy import arange
+
+# jit decorator tells Numba to compile this function.
+# The argument types will be inferred by Numba when function is called.
+@jit
+def sum2d(arr):
+M, N = arr.shape
+result = 0.0
+for i in range(M):
+for j in range(N):
+result += arr[i,j]
+return result
+
+a = arange(9).reshape(3,3)
+print(sum2d(a))
+"
diff -Nru numba-0.30.0/debian/tests/simpletest.py3.sh numba-0.30.0/debian/tests/simpletest.py3.sh
--- numba-0.30.0/debian/tests/simpletest.py3.sh	1970-01-01 00:00:00.0 +
+++ numba-0.30.0/debian/tests/simpletest.py3.sh	2017-02-17 12:26:07.0 +
@@ -0,0 +1,22 @@
+#!/bin/sh
+set -e
+
+# example taken from http://numba.pydata.org/
+python3 -c "
+from numba import jit
+from numpy import arange
+
+# jit decorator tells Numba to compile this function.
+# The argument types will be inferred by Numba when function is called.
+@jit
+def sum2d(arr):
+M, N = arr.shape
+result = 0.0
+for i in range(M):
+for j in range(N):
+result += arr[i,j]
+return result
+
+a = arange(9).reshape(3,3)
+print(sum2d(a))
+"

Bug#835940: Bug#851871: RM: remove gcc-5 from stretch

[lumin]

Control: tags 835940 +patch

On Fri, 20 Jan 2017 14:50:43 +0100 Sylvestre Ledru  wrote:
> >> What is the final decision regarding LLVM versions in stretch?
> > 
> > We are shipping with 3.7 (for ghc), 3.8 and 3.9.
> > 
> And 3.8 has the default.
> 
> Sylvestre

Thank you LLVM guys. We have chance to rescue the CUDA package.

Proposed fix for CUDA is attached. Not carefully tested yet.
CUDA 8.0 supports Clang up to 3.8 (clang <= 3.8). [1]

caffe-contrib's default compiler has been changed to
clang-3.8 several weeks ago. I don't know whether
the other CUDA applications compile with Clang.

[1] conclusion made from caffe-contrib compiling experiments.From 7cf970e7fd91198c237a6509b6e44bc22dd5cbe5 Mon Sep 17 00:00:00 2001
From: Zhou Mo 
Date: Fri, 20 Jan 2017 14:48:17 +
Subject: [PATCH] preview

---
 NEWS  | 7 +++
 changelog | 6 ++
 control   | 4 ++--
 3 files changed, 15 insertions(+), 2 deletions(-)
 create mode 100644 NEWS

diff --git a/NEWS b/NEWS
new file mode 100644
index 000..8282b5d
--- /dev/null
+++ b/NEWS
@@ -0,0 +1,7 @@
+nvidia-cuda-toolkit (8.0.44-3) UNRELEASED; urgency=medium
+
+  The recommended compiler for CUDA 8.0 has been changed from GCC-5 to
+  Clang (<= 3.8). Please try to compile your CUDA application with Clang
+  when CUDA 8.0 failed to work with GCC-6.
+
+ -- Zhou Mo   Fri, 20 Jan 2017 14:40:47 +
diff --git a/changelog b/changelog
index 80b1339..dd1eb82 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,9 @@
+nvidia-cuda-toolkit (8.0.44-3) UNRELEASED; urgency=medium
+
+  * Build with clang <= 3.8 . (Closes: #835940)
+
+ -- Zhou Mo   Fri, 20 Jan 2017 14:14:01 +
+
 nvidia-cuda-toolkit (8.0.44-2) unstable; urgency=medium
 
   * Overhaul installation of examples.
diff --git a/control b/control
index cab6772..2d721e0 100644
--- a/control
+++ b/control
@@ -26,8 +26,8 @@ Depends:
  nvidia-profiler (= ${binary:Version}),
  nvidia-cuda-dev (= ${binary:Version}),
  nvidia-opencl-dev (= ${binary:Version}) | opencl-dev,
- gcc-5 | gcc-4.9 | gcc-4.8,
- g++-5 | g++-4.9 | g++-4.8,
+ clang-3.8 | clang (<= 3.8) | gcc-5 | gcc-4.9 | gcc-4.8,
+ clang-3.8 | clang (<= 3.8) | g++-5 | g++-4.9 | g++-4.8,
  ${shlibs:Depends}, ${misc:Depends},
 Recommends:
  nvidia-cuda-doc (= ${source:Version}),
-- 
2.11.0

Bug#840589: skimage: any update?

[lumin]

Hello,

Is there any update on this bug?
python3-skimage is the only problem for one of my
packages to enter testing.

Bug#842082: torch-core-free: uninstallable on architectures without lua-torch-image

[lumin]

Hi,

Thank you for pointing this out, I noticed it.

Actually I plan to add all of its runtime dependencies
to its B-D list and add autopkgtest support for this
package. In this way the installation failure issue
on any architecture will be eliminated.

Will fix it in 1~exp2 .

Bug#838789: Fwd: caffe-contrib: FTBFS: libcaffe.so.1.0.0-rc3: undefined reference to `H5LTget_dataset_ndims'

[lumin]

Control: affects -1 caffe

On Sat, 2016-09-24 at 22:51 +0200, Andreas Beckmann wrote:
> This is Bug#838789, but for some reason the BTS considers this as an
> unknown package, so you didn't get this forwarded ...

Thank you for forwarding. :-)

> Oh, you did a source-only upload. That does not work in this case, since
> you have Build-Depends in non-free. You'll always have to do
> source+binary uploads (for *all* architectures you want). And having a
> source package without binaries for some time seems to have made the
> package "partially disappear" from the archive.

Several weeks ago I posted a question on mentors, asking why buildd
doesn't build caffe-contrib and saying "cuda" is missing. Now I know
buildd won't pull non-free stuff and source-only upload may cause
"partial missing" package.

> caffe-contrib FTBFS in experimental:
> ../../../lib/libcaffe.so.1.0.0-rc3: undefined reference to
> `H5LTread_dataset_string'

I noticed this FTBTS some time ago in package caffe (another
version, free of cuda). However I didn't look into the reason of build failure
because at that time there was an hdf5 transition.

╰─>$ find /var/lib/dpkg/info/ -name '*.symbols' | grep hdf5 | xargs ack 
H5LTread_dataset_string

/var/lib/dpkg/info/libhdf5-openmpi-10:amd64.symbols
3734: H5LTread_dataset_string@HDF5_MPI_1.8.7 1.8.13
/var/lib/dpkg/info/libhdf5-10:amd64.symbols
3707: H5LTread_dataset_string@HDF5_SERIAL_1.8.7 1.8.13

╰─>$ apt list libhdf5-10 libhdf5-openmpi-10
Listing... Done
libhdf5-10/unstable,now 1.8.16+docs-8+b1 amd64 [installed,automatic]
libhdf5-openmpi-10/unstable,now 1.8.16+docs-8+b1 amd64 [installed]

Well, confusing.

> I'm *not* attaching the 160 MB build log. But I could look for details
> if needed.
> 
> In case it does matter:
> This was built against hdf5 1.8.16 from sid, not against 1.10 from
> experimental.

I used to test it against hdf5/sid. caffe* were uploaded to experimental
because runtime-dep python3-protobuf is still missing.

> IIRC some time ago apt changed how Build-Depends are resolved for
> packages in experimental, preferring packages from unstable unless
> a versioned constraint actually requires something from experimental.

But this reminds to to test whether it compiles against hdf5/experimental.

> I remember vaguely to have seen symbol changes during previous rebuilds,
> but I don't have the old longs any longer.

That's ok, I'll handle the changes if any, as long as I can pass the build.

> 
> Andreas

Bug#771387: siliconmotion graphic card driver segfault and unusable.

[lumin]

Package: xserver-xorg-video-siliconmotion
Source: xserver-xorg-video-siliconmotion (1:1.7.7-2)
Version: 1:1.7.7-2+b2
Severity: serious
Tags: moreinfo

Hi,

The xserver-xorg-video-siliconmotion segfaults right away once I started
X, and then the X is totally unuseable on my machine (mipsel,
loongson-2f).

```
(==) Log file: /var/log/Xorg.0.log, Time: Sat Nov 29 11:07:18 2014
(==) Using config file: /etc/X11/xorg.conf
(==) Using system config directory /usr/share/X11/xorg.conf.d
(EE) 
(EE) Backtrace:
(EE) 0: X (xorg_backtrace+0x84) [0x77e2ede4]
(EE) 
(EE) Segmentation fault at address 0x3c4
(EE) 
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE) 
(EE) 
```

I have read http://x.debian.net/howto/use-gdb.html and
http://x.debian.net/howto/report-bugs.html
but I feel hard to generate coredump/backtrace,
as I'm not familiar with gdb.

This issue also affects debian wheezy (even the save segfault addr).
And another useful information is,
someone fixed this problem and put that fixed version (1.7.6-1loongson)
onto a forum, it works indeed. I can send that fix privately.[1]

And then, what moreinfo should I exactly offer?
P.S. the /var/log/Xorg.0.log seems doesn't help, so not attached.

thanks:)

[1] I tried to apply that fix for jessie, but ABI's not happy.
-- 
Regards,
  C.D.Luminate


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org