Bug#888220: ignition-math4: FTBFS on mips(el) and hppa: UNIT_Helpers_TEST fails badly

2018-03-30 Thread Emilio Pozuelo Monfort
On Tue, 13 Feb 2018 15:15:22 -0800 Jose Luis Rivero 
wrote:
> Thanks very much James for the research and the patch.
> 
> I've sent it upstream:
> https://bitbucket.org/ignitionrobotics/ign-math/pull-requests/232/bug-in-pairing-function-insde-helperscc/diff

Can this be applied now? It's blocking sdformat builds on mips(el), which is in
turn blocking some transitions.

Thanks,
Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#885450: apertium-all-dev: depends on libhfst49-dev which is no more

2017-12-27 Thread Emilio Pozuelo Monfort
Package: apertium-all-dev
Version: 3.4.2~r68466-2
Severity: serious

Hi,

libhfst49-dev has been renamed to libhfst-dev. Please update your dependency.

Since the package name is now unversioned, this should prevent more RC bugs
due to this in the future.

Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#879052: v-sim: please drop unused python-gobject-dev build-dependency

2017-10-18 Thread Emilio Pozuelo Monfort
Source: v-sim
Version: 3.7.2-2
Severity: important

Hi,

v-sim is using gobject introspection for the python bindings, thus the
old python-gobject-dev build-dependency is not needed. The python-gi-dev
package provides the gobject introspection python support.

Please drop python-gobject-dev from build-depends. It's obsolete and a
transitional package and I will remove it soon.

Thanks,
Emilio

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), (500, 
'unstable-debug'), (500, 'testing-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), 
LANGUAGE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#866044: caffe-contrib: needs a rebuild against libgflags2.2

2017-06-26 Thread Emilio Pozuelo Monfort
Source: caffe-contrib
Version: 1.0.0~rc4-1
Severity: serious

Hi,

gflags changed the SONAME, so caffe-contrib needs a rebuild to pick up the
new package name. A binNMU isn't possible given caffe-contrib is in contrib.

Severity serious as the package will be removed from testing if this doesn't
happen.

Cheers,
Emilio

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), (500, 
'unstable-debug'), (500, 'testing-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), 
LANGUAGE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#846919: yade: enable parallel builds

2016-12-04 Thread Emilio Pozuelo Monfort
Source: yade
Version: 2016.06a-6
Severity: wishlist

Hi,

I see parallel builds were disabled because it caused build failures
in some cases (#805032). Usually the problem is lack of dependencies
in the makefiles. It'd be good to either fix that and re-enable
parallel builds, or to disable parallelisation in specific directories
(with GNU make you would do that with .NOPARALLEL in a Makefile, dunno
how to do it with cmake).

Maybe just forward this upstream so they eventually fix it and we can
re-enable it in Debian.

My motivation to report this is the long build time in mips64el, which
should be reduced by a parallel build.

Thanks,
Emilio

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), (500, 
'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#846520: pcl: enable parallel builds on 32 bit arches

2016-12-01 Thread Emilio Pozuelo Monfort
On 01/12/16 23:25, Jochen Sprickerhof wrote:
> Hi Emilio,
> 
> * Emilio Pozuelo Monfort <po...@debian.org> [2016-12-01 22:24]:
>> Why was this disabled? Do the builds run out of memory often? It'd be good
>> to re-enable this, the speedup is huge and it would avoid taking one buildd
>> for a day and a half on some architectures.
> 
> Exactly because it was running out of memory. Quoting from the buildd:
> 
> | cc1plus: out of memory allocating 903468 bytes after a total of 19152896 
> bytes
> 
> I asked in #debian-buildd back then and the consensus was to remove the
> --parallel. Is there any reason to revert this now?

We have more powerful buildds, at least in some architectures. Not sure about
RAM/swap. Also there was one bad build back then, but several good builds. I'm
not sure if this is such an issue, but I think it's worth re-trying. Doesn't
need to happen right now just for the sake of it, it can be uploaded when there
are other worthwhile changes.

If parallel support is re-enabled and some builds fail, we can evaluate whether
it's best to disable parallel support on specific architectures, blacklist pcl
in specific buildds, lower the parallelism without disabling it entirely, or
disabling it altogether in 32-bits architectures again.

Cc'ing debian-wb-team@ to see if anybody disagrees.

Thanks,
Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#846520: pcl: enable parallel builds on 32 bit arches

2016-12-01 Thread Emilio Pozuelo Monfort
Source: pcl
Version: 1.8.0+dfsg1-3
Severity: wishlist

Hi,

In your changelog, I see:

pcl (1.7.2-6) unstable; urgency=medium

  [ Jochen Sprickerhof ]
  * Remove --parallel from dh to fix build on i386 buildd.

 -- Leopold Palomo-Avellaneda   Tue, 02 Dec 2014 08:29:43 
+0100

My guess is that happened because of the build failure on 2014-11-30 in:
https://buildd.debian.org/status/logs.php?pkg=pcl=i386

Note how the builds on i386 take ~5 hours, while on amd64 they take ~1h,
because of the parallel builds. For e.g. mipsel it's at 22h or 1d15h vs.
8h on mips64el.

Why was this disabled? Do the builds run out of memory often? It'd be good
to re-enable this, the speedup is huge and it would avoid taking one buildd
for a day and a half on some architectures.

Thanks,
Emilio

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), (500, 
'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#815725: trilinos: FTBFS on non-amd64

2016-11-22 Thread Emilio Pozuelo Monfort
Control: severity -1 serious

On Thu, 25 Aug 2016 10:22:28 -0400 u...@debian.org (Aaron M. Ucko) wrote:
> notfixed 815725 12.6.3-4
> found 815725 12.6.3-4
> thanks
> 
> Graham Inggs  writes:
> 
> >* Only enable Kokkos assembly functions on amd64 (Closes: #815725)
> 
> Alas, builds for 32-bit architectures such as i386 are still failing:
> 
>   
> /«PKGBUILDDIR»/packages/kokkos/core/src/impl/Kokkos_Atomic_Generic.hpp:144:49:
>  error: no matching function for call to 'atomic_compare_exchange(long long 
> unsigned int*, long long unsigned int&, long long unsigned int&)'
>   [...]
>   
> /«PKGBUILDDIR»/packages/kokkos/core/src/impl/Kokkos_Atomic_Compare_Exchange_Strong.hpp:143:3:
>  error: invalid use of incomplete type 'struct Kokkos::Impl::enable_if const long long unsigned int&>'
>   [...]
>   
> /«PKGBUILDDIR»/packages/kokkos/core/src/impl/Kokkos_Atomic_Compare_Exchange_Strong.hpp:165:3:
>  error: invalid use of incomplete type 'struct Kokkos::Impl::enable_if const long long unsigned int&>'
>   [...]
>   
> /«PKGBUILDDIR»/packages/kokkos/core/src/impl/Kokkos_Atomic_Compare_Exchange_Strong.hpp:207:3:
>  error: invalid use of incomplete type 'struct Kokkos::Impl::enable_if const long long unsigned int>'
> 
> Could you please take another look?

There are outdated binaries on i386/armhf/mips64el, so this is RC.

Cheers,
Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#843728: pytango: enable parallel builds

2016-11-09 Thread Emilio Pozuelo Monfort
Source: pytango
Version: 9.2.0-2
Severity: wishlist

Hi,

Your package takes some time to build, yet it doesn't enable
parallel builds. It would be nice if you could enable that (just
add --parallel to the dh call, or bump the debhelper compat to 10),
provided that that works fine with your package.

Thanks,
Emilio

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), (500, 
'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#843223: petsc: FTBFS: error: 'struct superlu_options_t' has no member named 'ILU_DropTol'

2016-11-05 Thread Emilio Pozuelo Monfort
Source: petsc
Version: 3.7.4+dfsg1-3
Severity: serious

Your package failed to build with:

/«BUILDDIR»/petsc-3.7.4+dfsg1/src/mat/impls/aij/seq/superlu/superlu.c: In 
function 'PetscErrorCode MatFactorInfo_SuperLU(Mat, PetscViewer)':
/«BUILDDIR»/petsc-3.7.4+dfsg1/src/mat/impls/aij/seq/superlu/superlu.c:99:72: 
error: 'struct superlu_options_t' has no member named 'ILU_DropTol'
 ierr = PetscViewerASCIIPrintf(viewer,"  ILU_DropTol: 
%g\n",options.ILU_DropTol);CHKERRQ(ierr);

See logs at: https://buildd.debian.org/status/package.php?p=petsc

Emilio

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), (500, 
'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#833667: freemat: FTBFS with LLVM 3.8

2016-10-05 Thread Emilio Pozuelo Monfort
Control: severity -1 serious

On Sun, 7 Aug 2016 18:39:29 +0200 Graham Inggs  wrote:
> Source: freemat
> Version: 4.2+dfsg1-1
> Severity: wishlist
> Tags: patch
> 
> 
> Hi Maintainer
> 
> Freemat currently FTBFS with LLVM 3.8, although LLVM 3.8 is not yet
> the default in Sid.
> I made the following minor changes:
> 
> In libs/libMatC/CJitFuncClang.cpp, include llvm/Config/llvm-config.h
> instead of llvm/Config/config.h and remove the second include of
> llvm/Config/config.h.
> 
> In CMakeLists.txt, link with clangTidyReadabilityModule instead of
> clangTidyReadability.
> 
> I attempted to produce a patch against
> debian/patches/12_update_clang_deps.patch but the result was not very
> clear and the differing line endings made it difficult.  Attached is a
> patch that should be applied after applying
> debian/patches/12_update_clang_deps.patch.
> 
> Not being familiar with freemat, I was not able to do extensive
> testing, but the package built and installed and I was able to open
> the freemat gui and perform some basic operations.
> 
> LLVM 3.8 is already the default in Ubuntu and I would like to apply
> this patch there, but I would appreciate it if you would please review
> it first.

LLVM 3.8 is now the default in Debian too. Your package failed to build, see:

https://buildd.debian.org/status/package.php?p=freemat

Cheers,
Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#827199: hfst: FTBFS: twolc test fails on big-endian systems

2016-10-01 Thread Emilio Pozuelo Monfort
On Wed, 15 Jun 2016 17:03:20 +0200 Tino Didriksen  wrote:
> On 13 June 2016 at 18:00, Aaron M. Ucko  wrote:
> 
> > Justification: fails to build from source (but built successfully in the
> > past)
> >
> > Thanks for taking care of the twolc errors I reported in #826659.  The
> > twolc test now succeeds on little-endian systems, and no longer hangs
> > anywhere, but still fails on big-endian architectures (mips, powerpc,
> > s390x, and several non-release architectures).  I don't have further
> > details, but perhaps you can reproduce the problem on a porterbox.
> > Could you please take a look?
> 
> 
> Can reproduce. Looking into it upstream:
> https://github.com/hfst/hfst/issues/328
> 
> While it did successfully build in the past, that was only because the test
> suite was disabled until recently. The tests revealed the unsigned char
> issue which was easy to fix, and now the endian issue which will not be as
> easy.

Hi,

Any progress on this?

Thanks,
Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#836599: shark: FTBFS on mips/mipsel: test errors

2016-09-04 Thread Emilio Pozuelo Monfort
Source: shark
Version: 3.1.3+ds1-1
Severity: serious

Your package failed to build on mips/mipsel:

95% tests passed, 8 tests failed out of 163

Logs at
https://buildd.debian.org/status/package.php?p=shark=unstable

Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#836448: fcl: out of date binaries on armel/armhf

2016-09-03 Thread Emilio Pozuelo Monfort
Source: fcl
Version: 0.5.0-2
Severity: serious

Your package no longer builds on armel/armhf because it build-depends
on liboctomap-dev, which is unavailable there. You should either get
it built there somehow (e.g. by disabling that b-d there if possible)
or by getting your package removed from those architectures by filing
a bug against ftp.debian.org.

Emilio

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), (500, 
'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#826307: liggghts: FTBFS on powerpc: test suite hangs

2016-06-04 Thread Emilio Pozuelo Monfort
Source: liggghts
Version: 3.3.1+repack1-1
Severity: serious

Your package fails to build on powerpc, where the test suite is
hanging:

insertion: proc 1 at 100 %
INFO: Particle insertion ins: inserted 891 particle templates (mass 1.910893) 
at step 1
 - a total of 891 particle templates (mass 1.910893) inserted so far.
   1  891  0.08606047705732.6777   0.0015 
Loop time of 0.0217927 on 2 procs for 1 steps with 891 atoms

Pair  time (%) = 1.26362e-05 (0.0579837)
Neigh time (%) = 0.000283122 (1.29916)
Comm  time (%) = 8.14199e-05 (0.373612)
Outpt time (%) = 3.05176e-05 (0.140036)
Other time (%) = 0.021385 (98.1292)

Nlocal:445.5 ave 446 max 445 min
Histogram: 1 0 0 0 0 0 0 0 0 1
Nghost:50 ave 52 max 48 min
Histogram: 1 0 0 0 0 0 0 0 0 1
Neighs:707.5 ave 721 max 694 min
Histogram: 1 0 0 0 0 0 0 0 0 1

Total # of neighbors = 1415
Ave neighs/atom = 1.5881
Neighbor list builds = 1
Dangerous builds = 0
Setting up run ...
Memory usage per processor = 8.00555 Mbytes
Step Atoms KinEng rke heattran Volume 
   1  891  0.08606047705732.6777   0.0015 
make: *** wait: No child processes.  Stop.
make: *** Waiting for unfinished jobs
make: *** wait: No child processes.  Stop.
debian/rules:15: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Terminated
Build killed with signal TERM after 150 minutes of inactivity

Full logs at:
https://buildd.debian.org/status/logs.php?pkg=liggghts=3.3.1%2Brepack1-1%2Bb2=powerpc

This may be related to this openmpi bug: #814183. If so, you may want
to disable the relevant tests on powerpc or force mpi to just use
one processor there.

Cheers,
Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#825096: dolfin: FTBFS: No rule to make target '/usr/lib/libgl2ps.so', needed by 'dolfin/libdolfin.so.1.6.0'

2016-05-23 Thread Emilio Pozuelo Monfort
Source: dolfin
Version: 1.6.0-4
Severity: serious

On a rebuild against petsc 3.6.4, your package failed to build:

make[4]: *** No rule to make target '/usr/lib/libgl2ps.so', needed by 
'dolfin/libdolfin.so.1.6.0'.  Stop.
make[4]: Leaving directory '/«PKGBUILDDIR»/debian/build-python2.7'
CMakeFiles/Makefile2:186: recipe for target 'dolfin/CMakeFiles/dolfin.dir/all' 
failed
make[3]: *** [dolfin/CMakeFiles/dolfin.dir/all] Error 2

Full logs at https://buildd.debian.org/status/package.php?p=dolfin

Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#817017: libopencv-highgui-dev: Should not depend on libgtk2.0-dev

2016-04-25 Thread Emilio Pozuelo Monfort
Control: tags -1 moreinfo

On Mon, 07 Mar 2016 08:53:03 +0100 Eric Valette  wrote:
> Package: libopencv-highgui-dev
> Version: 3.0.0+dfsg-1~exp2+b1
> Severity: important
> 
> LANG=C; apt-get -t experimental install libopencv-dev
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  libopencv-dev : Depends: libopencv-objdetect-dev (= 3.0.0+dfsg-1~exp2+b1) 
> but it is not going to be installed
>  Depends: libopencv-highgui-dev (= 3.0.0+dfsg-1~exp2+b1) but 
> it is not going to be installed
>  Depends: libopencv-calib3d-dev (= 3.0.0+dfsg-1~exp2+b1) but 
> it is not going to be installed
>  Depends: libopencv-features2d-dev (= 3.0.0+dfsg-1~exp2+b1) 
> but it is not going to be installed
>  Depends: libopencv-videostab-dev (= 3.0.0+dfsg-1~exp2+b1) 
> but it is not going to be installed
>  Depends: libopencv-stitching-dev (= 3.0.0+dfsg-1~exp2+b1) 
> but it is not going to be installed
> E: Unable to correct problems, you have held broken packages.
> tri-yann4:/home/valette# LANG=C; apt-get -t experimental install 
> libopencv-highgui-dev
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  libopencv-highgui-dev : Depends: libgtk2.0-dev but it is not going to be 
> installed
> E: Unable to correct problems, you have held broken packages.

So why was / is libgtk2.0-dev uninstallable?

That it was temporarily uninstallable, or that apt failed at installing it
(possibly because of the experimental priorities) doesn't mean that
libopencv-highgui-dev shouldn't depend on it.

Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#822607: opencv: please build highgui with gtk3 support

2016-04-25 Thread Emilio Pozuelo Monfort
Source: opencv
Version: 3.0.0+dfsg-1~exp2
Severity: normal

Hi,

Currently libopencv-highgui2.4v5 / libopencv-highgui3.0 depend
on libgtk2.0-0. It'd be great if you could build highgui with
GTK+ 3 support - it looks like opencv 3.x already supports that.

Thanks,
Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#820498: tachyon: FTBFS with libpng16 on mipsel

2016-04-09 Thread Emilio Pozuelo Monfort
On Sat, 09 Apr 2016 09:26:58 +0200 Tobias Frost  wrote:
> Source: tachyon
> Severity: serious
> Justification: FTBFS but did in the past
> 
> Dear maintainer,
> 
> the package FTBFS with libpng 1.6 on mipsel (release arch) and others
> non-release archs (mips64el and sh4) (it built on mipsel in the past, so it is
> RC)
> 
> Note that hppa also shows a very similar error, which was not binNMUed. So it
> might be that the problem is not related to the library tansition.
> 
> Buildlog for mips: 
> 
> https://buildd.debian.org/status/fetch.php?pkg=tachyon=mipsel=0.99~b6%2Bdsx-4%2Bb1=1460116130
> 
> Buildd page:
> https://buildd.debian.org/status/package.php?p=tachyon
> 
> snippet: 
> dh_install: Cannot find (any matches for) 
> "usr/lib/mipsel-linux-gnu/libtachyon-openmpi-thr.so.0.0.0" (tried in "." and 
> "debian/tmp")
> dh_install: libtachyon-openmpi-0 missing files: 
> usr/lib/mipsel-linux-gnu/libtachyon-openmpi-thr.so.0.0.0
> dh_install: Cannot find (any matches for) 
> "usr/lib/mipsel-linux-gnu/libtachyon-openmpi.so.0" (tried in "." and 
> "debian/tmp")
> dh_install: libtachyon-openmpi-0 missing files: 
> usr/lib/mipsel-linux-gnu/libtachyon-openmpi.so.0
> dh_install: Cannot find (any matches for) 
> "usr/lib/mipsel-linux-gnu/libtachyon-openmpi.so.0.0.0" (tried in "." and 
> "debian/tmp")
> dh_install: libtachyon-openmpi-0 missing files: 
> usr/lib/mipsel-linux-gnu/libtachyon-openmpi.so.0.0.0
> dh_install: Cannot find (any matches for) 
> "usr/lib/mipsel-linux-gnu/libtachyon-openmpi-openmp.so" (tried in "." and 
> "debian/tmp")
> dh_install: libtachyon-openmpi-0-dev missing files: 
> usr/lib/mipsel-linux-gnu/libtachyon-openmpi-openmp.so
> dh_install: Cannot find (any matches for) 
> "usr/lib/mipsel-linux-gnu/libtachyon-openmpi-thr.so" (tried in "." and 
> "debian/tmp")
> dh_install: libtachyon-openmpi-0-dev missing files: 
> usr/lib/mipsel-linux-gnu/libtachyon-openmpi-thr.so
> dh_install: Cannot find (any matches for) 
> "usr/lib/mipsel-linux-gnu/libtachyon-openmpi.so" (tried in "." and 
> "debian/tmp")
> dh_install: libtachyon-openmpi-0-dev missing files: 
> usr/lib/mipsel-linux-gnu/libtachyon-openmpi.so
> dh_install: missing files, aborting
> debian/rules:59: recipe for target 'binary-arch' failed
> make: *** [binary-arch] Error 2

This is caused by #818909, which has just been fixed in chrpath. The necessary
rebuilds will be scheduled soon.

Cheers,
Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#820429: libvigraimpex: FTBFS on kfreebsd-i386 and hurd-i386: Assertion failed: Sequence items differ at index 5

2016-04-08 Thread Emilio Pozuelo Monfort
Source: libvigraimpex
Version: 1.10.0+git20160211.167be93+dfsg-1
Severity: important

Your package failed to build on hurd and kfreebsd-i386:

Entering test suite GraphAlgorithmTestSuite

Failure in GraphAlgorithmTest::testEdgeWeightComputation()
Assertion failed: Sequence items differ at index 5 [4.24264 != 4.24264] 
(/«BUILDDIR»/libvigraimpex-1.10.0+git20160211.167be93+dfsg/test/graph_algorithm/test.cxx:543)

1 of 6 tests failed in test suite GraphAlgorithmTestSuite
Leaving test suite GraphAlgorithmTestSuite

Cc'ing the porters in case they have any insights.

Cheers,
Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#818715: ros-image-common: FTBFS on several architectures: relocation R_X86_64_PC32 against symbol `_ZTVN7testing8internal17TestEventRepeaterE' can not be used when making a shared object; recompil

2016-03-19 Thread Emilio Pozuelo Monfort
Source: ros-image-common
Version: 1.11.10-4
Severity: serious

Your package failed to build on several architectures:

/usr/bin/ld: CMakeFiles/gtest.dir/src/gtest-all.cc.o: relocation R_X86_64_PC32 
against symbol `_ZTVN7testing8internal17TestEventRepeaterE' can not be used 
when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

It looks as if that file was compiled with -fPIC though:

cd /«PKGBUILDDIR»/obj-x86_64-linux-gnu/gtest && /usr/bin/c++   
-DGTEST_CREATE_SHARED_LIBRARY=1 -Dgtest_EXPORTS -I/usr/src/gtest/include 
-I/usr/src/gtest  -g -O2 -fPIE -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -fPIC   -g -O2 -fPIE 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2  -Wall -Wshadow -DGTEST_HAS_PTHREAD=1 -fexceptions -Wextra 
-Wno-unused-parameter -Wno-missing-field-initializers -o 
CMakeFiles/gtest.dir/src/gtest-all.cc.o -c /usr/src/gtest/src/gtest-all.cc

On ppc64el the error is a bit different, but it also points to -fPIC so the
problem is likely the same:

/usr/bin/c++  -fPIC -g -O2 -fPIE -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2   -fPIE -pie 
-Wl,-z,relro -Wl,-z,now -shared -Wl,-soname,libgtest.so -o libgtest.so 
CMakeFiles/gtest.dir/src/gtest-all.cc.o  
-L/«PKGBUILDDIR»/obj-powerpc64le-linux-gnu/gtest/src -lpthread 
-Wl,-rpath,/«PKGBUILDDIR»/obj-powerpc64le-linux-gnu/gtest/src 
/usr/bin/ld: CMakeFiles/gtest.dir/src/gtest-all.cc.o: In function 
`testing::internal::FormatCxxExceptionMessage(char const*, char const*)':
/usr/src/gtest/src/gtest.cc:2030:(.text.unlikely+0x80): call to 
`testing::Message::Message()' lacks nop, can't restore toc; recompile with -fPIC
/usr/bin/ld: CMakeFiles/gtest.dir/src/gtest-all.cc.o: In function 
`testing::Message::GetString[abi:cxx11]() const':
/usr/src/gtest/src/gtest.cc:947:(.text.unlikely+0x150): call to 
`testing::internal::StringStreamToString(std::__cxx11::basic_stringstream*)' lacks nop, can't restore toc; 
recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

Full logs at:
https://buildd.debian.org/status/logs.php?pkg=ros-image-common=1.11.10-4

Cheers,
Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#816101: petsc: FTBFS on mipsel - try rebuild again

2016-03-13 Thread Emilio Pozuelo Monfort

[Adding debian-wb-team back to Cc]

On 13/03/16 17:56, Drew Parsons wrote:

On Sun, 2016-03-13 at 17:35 +0100, Emilio Pozuelo Monfort wrote:

On 13/03/16 16:34, Drew Parsons wrote:


Source: petsc
Followup-For: Bug #816101

The petsc build failure on mipsel appears to be a transient problem
on
the build machine. Please try the mipsel build again.

Why? It has failed twice already.


What would make mipsel different to other architectures or from the
earlier successful mipsel build?  It's the same petsc.


petsc may be at the same version, but the environment has changed. It may be a 
bug in another package (e.g. an rdep) or a bug in petsc that was latent until now.



Have you checked if it builds fine on a porterbox?


I tried but sbuild wouldn't work inside the schroot environment on
etler.


Did you read the MOTD? See https://dsa.debian.org/doc/schroot/

Anyway given the build queue is currently empty on mipsel, I've given it back. 
Let's see if the problem is fixed now...


Emilio

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#816101: petsc: FTBFS on mipsel - try rebuild again

2016-03-13 Thread Emilio Pozuelo Monfort

On 13/03/16 16:34, Drew Parsons wrote:

Source: petsc
Followup-For: Bug #816101

The petsc build failure on mipsel appears to be a transient problem on
the build machine. Please try the mipsel build again.


Why? It has failed twice already. Have you checked if it builds fine on a 
porterbox?

Emilio

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#816719: chealpix: FTBFS on mips: timed out

2016-03-04 Thread Emilio Pozuelo Monfort
Source: chealpix
Version: 3.11.4-2
Severity: serious

Your package failed to build on mips after 720 minutes of inactivity:

Log at

https://buildd.debian.org/status/fetch.php?pkg=chealpix=mips=3.11.4-2%2Bb1=1456747053

Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#816423: ros-simulators{,-dev}: update dependency to gazebo7

2016-03-01 Thread Emilio Pozuelo Monfort
Source: ros-metapackages
Version: 1.4
Severity: serious

gazebo6 is gone. Please update your dependencies on
ros-simulators / ros-simulators-dev to
gazebo7 / libgazebo7-dev.

Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#815814: urdfdom: FTBFS on several architectures

2016-02-24 Thread Emilio Pozuelo Monfort
Source: urdfdom
Version: 0.4.1-1
Severity: serious

Your package failed to build on several architectures with:

CMake Error at CMakeLists.txt:41 (find_package):
  Could not find a configuration file for package "urdfdom_headers" that is
  compatible with requested version "0.4".

  The following configuration files were considered but not accepted:

/usr/share/urdfdom_headers/cmake/urdfdom_headers-config.cmake, version: 
0.4.0 (64bit)

Logs at:

https://buildd.debian.org/status/logs.php?pkg=urdfdom=0.4.1-1

Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Re: Bug#807666: nmu: mpich_3.1-6

2015-12-11 Thread Emilio Pozuelo Monfort
Control: reassign -1 src:mpich
Control: severity -1 serious
Control: retitle -1 mpich: overly restrictive GCC check

On 11/12/15 14:50, Samuel Thibault wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> Hello,
> 
> Compiling c++ programs against mpich currently fails in sid:
> 
> In file included from /usr/include/mpich/mpi.h:2175:0,
>  from test.c:1:
> /usr/include/mpich/mpicxx.h:22:4: error: #error 'Please use the same version 
> of GCC and g++ for compiling MPICH and user MPI programs'
>  #  error 'Please use the same version of GCC and g++ for compiling MPICH and 
> user MPI programs'
> 
> Apparently mpich got built with 5.2, and sid currently has 5.3, thus the
> failure.  Rebuilding mpich with current gcc 5.3 should be fixing it.
> 
> Samuel
> 
> nmu mpich_3.1-6 . ANY . unstable . -m "Rebuild against g++ 5.3"

This sounds like a too restrictive check, especially now that a 5.2 -> 5.3 GCC
bump is similar to a 4.9.2 -> 4.9.3 one (i.e. a "micro" or bugfix update). I'm
reassigning so this gets fixed in mpich.

Cheers,
Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#796716: urdfdom: library transition needed with GCC 5 as default

2015-10-30 Thread Emilio Pozuelo Monfort
This is a friendly ping wrt the libstdc++ ABI transition. Your package is listed
as needing a transition but has seen no action. It'd be good to get things going
so we can finish the transition soon.

Cheers,
Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#791024: dolfin: library transition may be needed when GCC 5 is the default

2015-10-30 Thread Emilio Pozuelo Monfort
This is a friendly ping wrt the libstdc++ ABI transition. Your package is listed
as needing a transition but has seen no action. It'd be good to get things going
so we can finish the transition soon.

Cheers,
Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#791274: scilab: library transition may be needed when GCC 5 is the default

2015-10-30 Thread Emilio Pozuelo Monfort
This is a friendly ping wrt the libstdc++ ABI transition. Your package is listed
as needing a transition but has seen no action. It'd be good to get things going
so we can finish the transition soon.

Cheers,
Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#801060: scilab: FTBFS on ppc64el

2015-10-05 Thread Emilio Pozuelo Monfort
Source: scilab
Version: 5.5.2-1.1
Severity: serious
Control: block 798256 with -1

Your package failed to build on ppc64el

Excerpt from the build log:

checking if jni.h can be included... yes
Looking for JNI libs with ppc64 as machine hardware name
Looking for /usr/lib/jvm/java-7-openjdk-ppc64el/jre/lib/ppc64/libjava.so
Looking for /usr/lib/jvm/java-7-openjdk-ppc64el/jre/lib/amd64/libjava.so
Looking for /usr/lib/jvm/java-7-openjdk-ppc64el/jre/lib/i386/client/libjvm.so
Looking for /usr/lib/jvm/java-7-openjdk-ppc64el/jre/bin/classic/libjvm.so
Looking for /usr/lib/jvm/java-7-openjdk-ppc64el/lib/jvm.lib
Looking for /usr/lib/jvm/java-7-openjdk-ppc64el/jre/lib/mipsel/libjava.so
configure: error: Could not detect the location of the Java
shared library. You will need to update java.m4
to add support for this JVM configuration.
/usr/share/cdbs/1/class/autotools.mk:42: recipe for target
'debian/stamp-autotools' failed

Full build log at
https://buildd.debian.org/status/fetch.php?pkg=scilab=ppc64el=5.5.2-1.1=1444066243

Cheers,
Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#800466: FTBFS: 4 failed tests with ValueError: could not broadcast input array

2015-10-02 Thread Emilio Pozuelo Monfort
On Wed, 30 Sep 2015 18:56:35 +0200 Emilio Pozuelo Monfort <po...@debian.org> 
wrote:
> On Tue, 29 Sep 2015 21:28:07 +0200 Gilles Filippini <p...@debian.org> wrote:
> > On Tue, 29 Sep 2015 20:46:42 +0200 Gilles Filippini <p...@debian.org> wrote:
> > > Source: pytables
> > > Version: 3.2.1-1
> > > Severity: serious
> > > Justification: FTBFS
> > > 
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > > 
> > > Hi,
> > > 
> > > pytables FTBFS on a clean amd64 sid chroot. 4 tests fail with similar
> > > error messages:
> > > ==
> > > ERROR: None (tables.tests.test_tables.RecArrayRangeTestCase)
> > > - --
> > > Traceback (most recent call last):
> > >   File 
> > > "/tmp/buildd/pytables-3.2.1/build/lib.linux-x86_64-2.7/tables/tests/test_tables.py",
> > >  line 2169, in test01a_range
> > > self.check_range()
> > >   File 
> > > "/tmp/buildd/pytables-3.2.1/build/lib.linux-x86_64-2.7/tables/tests/test_tables.py",
> > >  line 2042, in check_range
> > > recarray = table.read(self.start, self.stop, self.step)
> > >   File 
> > > "/tmp/buildd/pytables-3.2.1/build/lib.linux-x86_64-2.7/tables/table.py", 
> > > line 1965, in read
> > > arr = self._read(start, stop, step, field, out)
> > >   File 
> > > "/tmp/buildd/pytables-3.2.1/build/lib.linux-x86_64-2.7/tables/table.py", 
> > > line 1887, in _read
> > > self.row._fill_col(result, start, stop, step, field)
> > >   File "tables/tableextension.pyx", line 1272, in 
> > > tables.tableextension.Row._fill_col (tables/tableextension.c:15021)
> > > ValueError: could not broadcast input array from shape (2) into shape (0)
> > 
> > This is upstream issue #481 [1] which was fixed by commit 44dba04 [2].
> > 
> > [1] <https://github.com/PyTables/PyTables/issues/481>
> > [2] 
> > <https://github.com/PyTables/PyTables/commit/44dba04d7d72f150a91553f4eb455684dfef0913.patch>
> > 
> > I've successfully tested this patch, but then a python3.5 related error 
> > occurs:
> > 
> > Ran 5734 tests in 147.360s
> > 
> > OK (skipped=42)
> > + cd /tmp/buildd/pytables-3.2.1/build/lib.linux-x86_64-3.5
> > + env PYTHONPATH=. LOCPATH=/tmp/buildd/pytables-3.2.1/tmp-locales 
> > LC_ALL=en_US.UTF-8 python3.5 tables/tests/test_all.py -vvv
> > Traceback (most recent call last):
> >   File "tables/tests/test_all.py", line 10, in 
> > import tables
> >   File 
> > "/tmp/buildd/pytables-3.2.1/build/lib.linux-x86_64-3.5/tables/__init__.py", 
> > line 123, in 
> > from tables.file import File, open_file, copy_file, openFile, copyFile
> >   File 
> > "/tmp/buildd/pytables-3.2.1/build/lib.linux-x86_64-3.5/tables/file.py", 
> > line 31, in 
> > import numexpr
> >   File "/usr/lib/python3/dist-packages/numexpr/__init__.py", line 40, in 
> > 
> > from numexpr.expressions import E
> >   File "/usr/lib/python3/dist-packages/numexpr/expressions.py", line 45, in 
> > 
> > from numexpr import interpreter
> > ImportError: cannot import name 'interpreter'
> > debian/rules:58: recipe for target 'override_dh_install' failed
> > make[1]: *** [override_dh_install] Error 1
> > make[1]: Leaving directory '/tmp/buildd/pytables-3.2.1'
> > debian/rules:26: recipe for target 'binary' failed
> > make: *** [binary] Error 2
> 
> That's just because numexpr hasn't been rebuilt for the python 3.5 transition

That's happened now, so this shouldn't fail at that stage.

Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#800632: scilab: FTBFS:

2015-10-01 Thread Emilio Pozuelo Monfort
Source: scilab
Version: 5.5.2-1
Severity: serious

Your package fails to build with:

[javac]
/«PKGBUILDDIR»/modules/graphic_export/src/java/org/scilab/modules/graphic_export/Export.java:883:
error: method processShape in class PSGraphics2D cannot be applied to given 
types;

See
https://buildd.debian.org/status/fetch.php?pkg=scilab=amd64=5.5.2-1%2Bb1=1443633918

You should also take a look at bug #791274.

Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#791238: petsc: library transition may be needed when GCC 5 is the default

2015-09-30 Thread Emilio Pozuelo Monfort
Control: user release.debian@packages.debian.org
Control: usertag -1 - transition

On Wed, 5 Aug 2015 16:17:54 +0200 Martin Pitt  wrote:
> tag 791238 patch
> user release.debian@packages.debian.org
> usertag 791238 + transition
> block 791238 by 790756
> 
> Hello,
> 
> this is a debdiff which we uploaded to Ubuntu (aside from some formal
> debian/changelog differences). As debian/rules is really complex and I
> don't have a good way of testing this, I'd appreciate a second look
> before uploading this.

>From a RT POV, feel free to go ahead with this.

I'm removing the transition tag for now, feel free to add that (and reassign)
once this is uploaded.

[ Note that I haven't actually reviewed the debdiff. ]

Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#800466: FTBFS: 4 failed tests with ValueError: could not broadcast input array

2015-09-30 Thread Emilio Pozuelo Monfort
On Tue, 29 Sep 2015 21:28:07 +0200 Gilles Filippini  wrote:
> On Tue, 29 Sep 2015 20:46:42 +0200 Gilles Filippini  wrote:
> > Source: pytables
> > Version: 3.2.1-1
> > Severity: serious
> > Justification: FTBFS
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > Hi,
> > 
> > pytables FTBFS on a clean amd64 sid chroot. 4 tests fail with similar
> > error messages:
> > ==
> > ERROR: None (tables.tests.test_tables.RecArrayRangeTestCase)
> > - --
> > Traceback (most recent call last):
> >   File 
> > "/tmp/buildd/pytables-3.2.1/build/lib.linux-x86_64-2.7/tables/tests/test_tables.py",
> >  line 2169, in test01a_range
> > self.check_range()
> >   File 
> > "/tmp/buildd/pytables-3.2.1/build/lib.linux-x86_64-2.7/tables/tests/test_tables.py",
> >  line 2042, in check_range
> > recarray = table.read(self.start, self.stop, self.step)
> >   File 
> > "/tmp/buildd/pytables-3.2.1/build/lib.linux-x86_64-2.7/tables/table.py", 
> > line 1965, in read
> > arr = self._read(start, stop, step, field, out)
> >   File 
> > "/tmp/buildd/pytables-3.2.1/build/lib.linux-x86_64-2.7/tables/table.py", 
> > line 1887, in _read
> > self.row._fill_col(result, start, stop, step, field)
> >   File "tables/tableextension.pyx", line 1272, in 
> > tables.tableextension.Row._fill_col (tables/tableextension.c:15021)
> > ValueError: could not broadcast input array from shape (2) into shape (0)
> 
> This is upstream issue #481 [1] which was fixed by commit 44dba04 [2].
> 
> [1] 
> [2] 
> 
> 
> I've successfully tested this patch, but then a python3.5 related error 
> occurs:
> 
> Ran 5734 tests in 147.360s
> 
> OK (skipped=42)
> + cd /tmp/buildd/pytables-3.2.1/build/lib.linux-x86_64-3.5
> + env PYTHONPATH=. LOCPATH=/tmp/buildd/pytables-3.2.1/tmp-locales 
> LC_ALL=en_US.UTF-8 python3.5 tables/tests/test_all.py -vvv
> Traceback (most recent call last):
>   File "tables/tests/test_all.py", line 10, in 
> import tables
>   File 
> "/tmp/buildd/pytables-3.2.1/build/lib.linux-x86_64-3.5/tables/__init__.py", 
> line 123, in 
> from tables.file import File, open_file, copy_file, openFile, copyFile
>   File 
> "/tmp/buildd/pytables-3.2.1/build/lib.linux-x86_64-3.5/tables/file.py", line 
> 31, in 
> import numexpr
>   File "/usr/lib/python3/dist-packages/numexpr/__init__.py", line 40, in 
> 
> from numexpr.expressions import E
>   File "/usr/lib/python3/dist-packages/numexpr/expressions.py", line 45, in 
> 
> from numexpr import interpreter
> ImportError: cannot import name 'interpreter'
> debian/rules:58: recipe for target 'override_dh_install' failed
> make[1]: *** [override_dh_install] Error 1
> make[1]: Leaving directory '/tmp/buildd/pytables-3.2.1'
> debian/rules:26: recipe for target 'binary' failed
> make: *** [binary] Error 2

That's just because numexpr hasn't been rebuilt for the python 3.5 transition
yet, see:

https://release.debian.org/transitions/html/python3.5.html

It should work once that's done.

Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#793621: transition: vtk6

2015-07-25 Thread Emilio Pozuelo Monfort
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: block -1 with 792883 793604 793605 793607

There is an uncoordinated, ongoing transition for vtk6.

vtk6 failed to build on armel/armhf. Also some of the rdeps (gammaray,
liggghts, nifti2dicom) currently fail to build.

Anton, as a library maintainer I would have expected you to

- coordinate the transition with the RT
- test-build the rdeps to check for FTBFS bugs
- file bugs for the rdeps, prepare patches, offer to NMU...
- not break vtk6 on some arches in the middle of the transition

Please help fix the remaining issues as this is blocking other
transitions.

Also it'd be good if you gave a status update on the vtk5 - vtk6
transition.

Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#793304: vtk6: FTBFS on arm*: qt4 not found

2015-07-22 Thread Emilio Pozuelo Monfort
Source: vtk6
Version: 6.2.0+dfsg1-1
Severity: serious

The latest vtk6 upload fails to build on arm*. That seems to be because
d/rules contains:

qt4_archs = armel armhf
ifeq (,$(filter $(DEB_HOST_ARCH),$(qt4_archs)))
extra_flags += -DVTK_QT_VERSION=5
else
extra_flags += -DVTK_QT_VERSION=4
endif

Reason:

vtk6 (6.1.0+dfsg2-2) unstable; urgency=medium

  * [463aa5a] Use Qt4 on armel and armhf instead of Qt5. (Closes: #763763)

However the last upload contained this change:

  * [880e68d] Remove Qt4 dependencies. (Closes: #784557, #765491)


So I guess vtk6 should build with qt5 on arm* again.

Please fix this ASAP as it's blocking the ongoing vtk6 transition and the
ffmpeg one, and it will get tangled with the libstdc++ one when that starts.

Emilio

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers