Bug#877419: pandas FTBFS on !x86/ppc64el: test failures

2018-04-12 Thread Graham Inggs

Hi

I refreshed and re-enabled Andreas' mark_tests_working_on_intel.patch 
[1] which was disabled in 0.22.0-1.
I additionally marked test_sum_nanops_timedelta and 
test_timedelta_ops_with_missing_values with pytest.mark.intel which were 
failing at least on arm64.


To address a new failure on big-endian architectures, I added a patch 
[2] and forwarded it upstream.


I uploaded 0.22.0-3 including these changes, and as of this writing, 
builds have succeeded on s390x, ppc64el, amd64 and i386.


Regards
Graham


[1] 
https://salsa.debian.org/science-team/pandas/commit/2971b1a4336d54def88857853e24274503b9cf55
[2] 
https://salsa.debian.org/science-team/pandas/commit/27e71d47e891547e3e492b1e25494bf2b4504a49


--
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#892199: r-cran-knitr: autopkgtest failure

2018-03-06 Thread Graham Inggs

Source: r-cran-knitr
Version: 1.20-1
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic autopkgtest

Hi Andreas

Since the upload of 1.20-1, r-cran-knitr's autopkgtests have been
failing [1].  There are new tests that require r-cran-tinytex which is
not yet packaged in Debian.

Regards
Graham


[1] https://ci.debian.net/packages/r/r-cran-knitr/unstable/amd64/

--
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#891246: ros-metapackages: please adjust dependencies for libgazebo9

2018-02-23 Thread Graham Inggs
Source: ros-metapackages
Version: 1.8
Tags: patch

Hi Maintainer

9.0.0+dfsg5-2 was recently uploaded to unstable.  Please update the
dependencies of ros-simulators and ros-simulators-dev for the new
gazebo9 packages.  I believe the patch below is what is required.

Regards
Graham


@@ -448,7 +448,7 @@
 Package: ros-simulators
 Architecture: all
 Depends: ros-robot,
- gazebo7,
+ gazebo9,
  ${misc:Depends}
 Description: Python Robot OS simulators metapackage
  This package is part of Robot OS (ROS). It is a metapackage which
@@ -462,7 +462,7 @@
 Architecture: all
 Depends: ros-simulators,
  ros-robot-dev,
- libgazebo7-dev,
+ libgazebo9-dev,
  ${misc:Depends}
 Recommends: ros-simulators-python-dev,
 ros-simulators-lisp-dev
graham@azureus:~/debian-packages/debian-science/ro

-- 
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#890987: sdformat: autopkgtest failure

2018-02-21 Thread Graham Inggs

Source: sdformat
Version: 6.0.0+dfsg-3
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic autopkgtest

Hi Maintainer

With the upload of 6.0.0+dfsg-3, sdformat's autopkgtest failed [1] with 
the following error:


autopkgtest [22:16:52]: test build: [---
Package ignition-math4 was not found in the pkg-config search path.
Perhaps you should add the directory containing `ignition-math4.pc'
to the PKG_CONFIG_PATH environment variable
Package 'ignition-math4', required by 'sdformat', not found
sdformattest.c:1:10: fatal error: sdf/sdf.hh: No such file or directory
 #include 
  ^~~~
compilation terminated.
autopkgtest [22:16:52]: test build: ---]
autopkgtest [22:16:52]: test build:  - - - - - - - - - - results - - - - 
- - - - - -

buildFAIL non-zero exit status 1

Regards
Graham


[1] https://ci.debian.net/packages/s/sdformat/unstable/amd64/

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


Accepted artha 1.0.3-3 (source) into unstable

2018-02-18 Thread Graham Inggs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 19 Feb 2018 07:14:44 +
Source: artha
Binary: artha
Architecture: source
Version: 1.0.3-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Team 
<debian-science-maintainers@lists.alioth.debian.org>
Changed-By: Graham Inggs <gin...@debian.org>
Description:
 artha  - Handy off-line thesaurus based on WordNet
Closes: 729458
Changes:
 artha (1.0.3-3) unstable; urgency=medium
 .
   * Team upload
   * Recommend libnotify4 instead of libnotify1 (Closes: #729458)
   * Fix Vcs-* URIs for move to salsa.debian.org
   * Remove trailing whitespace from debian/changelog and debian/control
Checksums-Sha1:
 acd5ec4d7ac386487054b4574d86b8b48fbd26bb 1932 artha_1.0.3-3.dsc
 509ba7b06f37fae905db092250444b7ffc3881f2 3460 artha_1.0.3-3.debian.tar.xz
Checksums-Sha256:
 d234ecd6774df2265bbc2b86bdb6cbb6153b96f01ccd6422fc02d8a0bc87d86f 1932 
artha_1.0.3-3.dsc
 bd443dc067f6e5091e0d2460349d6325eb5b559bf2e9843ce19f0d14288468e8 3460 
artha_1.0.3-3.debian.tar.xz
Files:
 14f87943512b82ac30421af405b0ea8e 1932 utils optional artha_1.0.3-3.dsc
 664b930a0ca33b44b80a52c7c55b7830 3460 utils optional 
artha_1.0.3-3.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJainrQAAoJEK/P7I5mnOHCuP8QALrRWvwa7ttyeND6SFlfT2ks
MHZX7oT0KdcNrJUDEYtrb8HOL4sMbd7OcjX4wpSHEBGihi/I1BiFUh1vuOEGu+m+
ddpw5f+xs75rHJMf/H/PVxDtA7BoYeL3QvGHiKQb0ocBCWWqEKf9lNUN+C06W1Sq
+IfTIyjMXpW6Er8rRIVV8XSOpkpXEwO79d3G9DzILCITFMa0MwGse+1Lpjuq03RS
3ECkeIz1v6H68W/RZyMWs7QpL/3RAA4XUDto+m5TxuYKgJmtWuJteCbDcUnu4/BP
Xxelx1TfmfWu04JO28YgR4Bmz5n/dwZFe+t6FYdcFtfRrCetnDx7UDzSaloSccnG
5/XYfPnMV8BurTtY3qjijrdAmMzDSEYsViWoi8s9LGLSPWJZ8XVlrwScQWLjydV1
wds/9kcHYvLsymj6mKQ2muAHTPsj8gXqYchyeH1MD/I1bpg6W3g/MHVxyvHxbeJG
Y3/mGA9nhTvLGGCLJW8k9YjkBcsFz8gos1TMXZUiUIdAP4kOJ/oc69Sz8HTbcXaR
TUuKjE9h05cxuugONHh4w1wsVrrV7fsw7AbhLoXbHl/oL6f9Ltdnd+Y+zyiFQo+S
LDM2mdT5NRTlaJsuKwEZnNvm03n3CRfLIgzW24f1eNCtyt1PP0dF4CZkcCmaJjfs
vMg2VYjL5oMDBsG96WDP
=FWQ4
-END PGP SIGNATURE-


-- 
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#885569: suitesparse: libgraphblasdemo underlinked

2017-12-27 Thread Graham Inggs
Source: suitesparse
Version: 1:5.1.0-1
Tags: patch

Hi Sébastien

Suitesparse fails to build in Ubuntu where everything is linked with
-Wl,--as-needed by default.

[ 50%] Linking C executable simple_demo
/usr/bin/cmake -E cmake_link_script
CMakeFiles/simple_demo.dir/link.txt --verbose=1
/usr/bin/cc -std=c11 -lm -fopenmp -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
-Wl,-Bsymbolic-functions -Wl,-z,relro -L/<>/lib -rdynamic
CMakeFiles/simple_demo.dir/Demo/Program/simple_demo.c.o  -o
simple_demo -Wl,-rpath,"/<>/GraphBLAS/build"
libgraphblasdemo.so libgraphblas.so.1.1.2
libgraphblasdemo.so: undefined reference to `cabs'
libgraphblasdemo.so: undefined reference to `atan2'
collect2: error: ld returned 1 exit status

The attached patch links libgraphblasdemo with libm and fixes the
build in Ubuntu.
Please consider applying it, it should be a no-op in Debian.

Also, consider adding the following line to debian/rules:

export DEB_LDFLAGS_MAINT_APPEND=-Wl,--as-needed

It should  eliminate all the "package could avoid a useless
dependency" warnings from dpkg-shlibdeps.

Regards
Graham


as-needed.debdiff
Description: Binary data
-- 
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#884349: primesieve: autopkgtest failure

2017-12-14 Thread Graham Inggs

Source: primesieve
Version: 6.2+ds-1
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic autopkgtest

Hi Jerome

Since the upload of 6.2+ds-1, primesieve's autopkgtests have been
failing [1].  Upstream removed the option to run 'primesieve --test' in 
version 6.0.


Regards
Graham


[1] https://ci.debian.net/packages/p/primesieve/unstable/amd64/

--
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#883987: rheolef: FTBFS error: partial specialization ... after instantiation ...

2017-12-12 Thread Graham Inggs
Hi Pierre

(cc-ing Andreas in case he is not subscribed)

On 12 December 2017 at 15:13, Pierre Saramito  wrote:
> Hi Andreas,
>
> This problem do neither comes from Rheolef-6.7 nor from CGAL-4.11:
> it comes from Boost-1.62 combined with g++ 7.2 in Debian sid and testing.
>
> The bug has already be identified in the upstream version of Boost :
>   https://svn.boost.org/trac10/ticket/12534
> and it is now fixed in the upstream version Boost-1.65:
>   
> https://github.com/boostorg/container/commit/5e4a107e82ab3281688311d22d2bfc2fddcf84a3
> but this version is not yet available in Debian.
>
> I've just send a bug report to the Boost package, together with a patch for 
> Boost-1.62
> and later, until we will get Boost-1.65 in Debian.
>
> See also in attachment for a small test "pair_tst.cc" and the corresponding 
> Boost patch "pair_tst.patch"
>
> I hope it will be fixed soon.
>
> Best regards,
>
> Pierre
> --
> pierre.saram...@imag.fr
> Directeur de Recherche CNRS
> Laboratoire Jean Kuntzmann, Grenoble, France
> http://ljk.imag.fr/membres/Pierre.Saramito

Would you please quote the bug number?  I failed to find your bug report.

I think the thing to do here is reassign this bug to src:boost1.62 and
mark that it affects src:rheolef.

Regards
Graham

-- 
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#836983: Patch

2017-12-08 Thread Graham Inggs
Hi Frédéric

On 7 December 2017 at 19:00, Frédéric Bonnard  wrote:
> Graham, here is patch attached for the issue.
> By default some architectures have "char" being unsigned such as the ones
> listed here and others ( https://wiki.debian.org/ArchitectureSpecificsMemo ).
> I just forced the sign-ness of pow()'s argument.

Thanks for the patch!  I uploaded it to Ubuntu, and the autopkgtests
were successful everywhere that freecad builds [1].

> Sorry for the delay.

There is no need for an apology.

Do you intend to send this upstream, or shall I do it?

Regards
Graham


[1] http://autopkgtest.ubuntu.com/packages/freecad

-- 
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#836983: freecad: autopkgtests fail on arm64, ppc64el, s390x

2017-12-07 Thread Graham Inggs

Control: retitle -1 freecad: autopkgtests fail on arm64, ppc64el, s390x

Ubuntu have recently enabled autopkgtests on arm64 [1] which confirms 
the same "Unit overflow in pow()" failure on arm64.



[1] http://autopkgtest.ubuntu.com/packages/f/freecad/bionic/arm64

--
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#883002: r-cran-zelig: autopkgtest failure

2017-11-28 Thread Graham Inggs
Source: r-cran-zelig
Version: 5.1.5-1
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic autopkgtest

Hi Maintainer

Since the upload of 5.1.5-1, r-cran-zelig's autopkgtests have been
failing [1].  Previous tests failed due to r-cran-zelig not being
installable, but otherwise would have passed.

The tests now require r-cran-zeligverse which is not yet packaged.
As an interim measure, simply preventing zeligverse from loading is
sufficient to make the tests pass, as the patch that follows.

--- a/tests/testthat.R
+++ b/tests/testthat.R
@@ -3,7 +3,6 @@
 library(geepack)
 library(survey)
 library(testthat)
-library(zeligverse)

 set.seed(123)
 test_check("Zelig")

Regards
Graham


[1] https://ci.debian.net/packages/r/r-cran-zelig/unstable/amd64/

-- 
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#882865: r-cran-coin: autopkgtest failure

2017-11-27 Thread Graham Inggs
Source: r-cran-coin
Version: 1.2-1-1
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic autopkgtest

Hi Maintainer

Since the upload of 1.2-1-1, r-cran-coin's autopkgtests have been
failing [1].  There is a new test that requires r-cran-libcoin which is
not yet packaged.

Regards
Graham


[1] https://ci.debian.net/packages/r/r-cran-coin/unstable/amd64/

-- 
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#836983: arm64 too

2017-11-20 Thread Graham Inggs
Hi Frederic

> Just for the record, this bug also happens on arm64.
> This seems to be a regression. I'm trying to bisect that.

Did you ever make any progress with this?

Regards
Graham

-- 
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#881318: dh-r: Please provide a means to update or check Build-Depends

2017-11-10 Thread Graham Inggs
Package: dh-r
Severity: wishlist

Hi

It would be great if there was a way to update or check Build-Depends
when updating a package to a new upstream version.

Regards
Graham

-- 
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#876509: deal.ii FTBFS with lapack

2017-09-26 Thread Graham Inggs
Control: reassign -1 src:trilinos 12.10.1-4
Control: affects -1 src:deal.ii
Control: block -1 by 876958

Hi Anton

On 23 September 2017 at 01:23, Anton Gladky  wrote:
> deal.ii FTBFS in the sid. Probably due to the new upload of lapack.

Yes indeed, thanks for picking this up.  Trilinos needs a rebuild, I
have requested a binNMU (#876958)

Regards
Graham

-- 
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#876958: nmu: trilinos_12.10.1-4

2017-09-26 Thread Graham Inggs
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: debian-science-maintainers@lists.alioth.debian.org

Dear Release Team

Lapack recently switched to multiarch and Trilinos needs to be rebuilt
in order to pick up the new locations of liblapack.so and libblas.so.
This causes deal.ii (its only reverse-dependency) to FTBFS (see
#876509).  Please schedule the following binNMU:

nmu trilinos_12.10.1-4 . ANY . -m 'Rebuild against multiarch lapack'

Regards
Graham

-- 
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#876411: admesh: autopkgtests fail since 0.98.3-1 upload

2017-09-21 Thread Graham Inggs
Source: admesh
Version: 0.98.3-1
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful autopkgtest

Hi Anton

ADMesh's autopkgtests have been failing since the 0.98.3-1 upload [1].
Output of the 'regression' test changed because it includes the
version.

If you are happy with the attached patch, I can do a team upload.

Regards
Graham


[1] https://ci.debian.net/packages/a/admesh/unstable/amd64/
--- a/debian/tests/regression
+++ b/debian/tests/regression
@@ -98,7 +98,6 @@
 EOF
 
 cat < regression_test_output_etalon
-ADMesh version 0.98.2, Copyright (C) 1995, 1996 Anthony D. Martin
 ADMesh comes with NO WARRANTY.  This is free software, and you are welcome to
 redistribute it under certain conditions.  See the file COPYING for details.
 Opening block.stl
@@ -111,7 +110,6 @@
 Calculating volume...
 Verifying neighbors...
 
-= Results produced by ADMesh version 0.98.2 
 Input file : block.stl
 File type  : ASCII STL file
 Header : SOLID  Untitled1
@@ -137,6 +135,8 @@
 EOF
 
 admesh block.stl > regression_test_output_current
+# delete lines containing the ADMesh version
+sed -i '/version/d' regression_test_output_current
 DIFFRESULT=`diff regression_test_output_current regression_test_output_etalon`
 if [ "$DIFFRESULT" != "" ]; then
   rm regression_test_output_current
-- 
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#875618: closed by Sébastien Villemot <sebast...@debian.org> (Bug#875618: fixed in openblas 0.2.20+ds-4)

2017-09-19 Thread Graham Inggs
Thanks Sébastien!  I'm sorry it turned out not to be as simple as I 
originally thought.


--
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#875618: openblas: please enable build on s390x

2017-09-12 Thread Graham Inggs
Source: openblas
Version: 0.2.20+ds-1
Severity: wishlist

Hi Sébastien


From Changelog.txt in OpenBLAS 0.2.20:

IBM Z: * New target z13 with BLAS3 optimizations

I have just checked, and openblas/0.2.20-3 builds successfully on
zelenka.debian.org.
Please enable building on s390x.

Regards
Graham

-- 
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#868922: r-cran-randomfieldsutils: FTBFS: init_RandomFieldsUtils.cc:62:10: error: 'R_NativeArgStyle' does not name a type

2017-09-05 Thread Graham Inggs

Control: tags -1 - buster

r-cran-randomfieldsutils 0.3.15-1 builds fine in testing

--
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#850965: freecad: GNOME Software catalog entry missing

2017-08-22 Thread Graham Inggs
On 8 July 2017 at 00:52,   wrote:
> The issue is still present although the icons and desktop file seems to be
> correct. Any ideas?

Probably this:
https://wiki.debian.org/AppStream/Guidelines#No_symbolic_links

Since the AppStream Generator relies on packages' md5sums file to
determine the contents of a package, symbolic links are not
recognized. So please do not symlink .desktop files or icons from
other places into /usr/share/pixmaps or the /usr/share/icons/hicolor
subdirectories, because the generator will not see these files then.
Relying on symbolic links in icon-theme packages is fine though.

-- 
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#856055: NetCDF import broken on amd64

2017-08-11 Thread Graham Inggs

Control: tags -1 + pending

Hi Timo

Thanks for the bug report, test case and patch!

I have confirmed the reported behaviour on amd64 and verified that the 
patch doesn't break i386.  I've committed your patch to git [1], 
slightly reformatted to minimize the diff.


Regards
Graham


[1] 
https://anonscm.debian.org/cgit/debian-science/packages/dx.git/commit/?id=597ea9b0ccd18dcc75541d0b6793c94e28bddd8f


--
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#870128: libgpuarray: broken autopkgtests

2017-07-30 Thread Graham Inggs
Hi Ghislain

Can you test your package with mesa-opencl-icd instead of pocl-opencl-icd?
This will allow the test suite to run on more architectures than only
amd64 and i386.

Regards
Graham

-- 
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#868523: FTBFS: test failed 617 ML_MLP_NonSym_MPI_4, 668 Phalanx_dag_manager_MPI_1

2017-07-24 Thread Graham Inggs

On 24/07/2017 10:40, Nico Schlömer wrote:

Sounds more like a gAM bug then. Can this be closed?


I intentionally didn't close this bug because the tests still fail if 
they are enabled.


If the problem is caused by another package, then this bug should be 
reassigned to that package and marked that it affects trilinos.


--
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#868873: dependence on libmumps-4.10.0 _AND_ libmumps-5.1.1 breaks make

2017-07-24 Thread Graham Inggs

On 24/07/2017 10:39, Nico Schlömer wrote:

Thanks, Graham, for the analysis.


You are welcome.  It seems the Stretch freeze was so long that we've 
forgotten how transitions work. :)


Some helpful references:

https://wiki.debian.org/Teams/ReleaseTeam/Transitions

https://wiki.debian.org/TransitionBestPractices


It appears that with 12.10.1-4 we're on top of things, so I guess this can
be closed.


Agreed.

--
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#868873: dependence on libmumps-4.10.0 _AND_ libmumps-5.1.1 breaks make

2017-07-23 Thread Graham Inggs
On 23 July 2017 at 18:07, Nico Schlömer  wrote:
> Hm, funny! I don't get how libtrilinos-amesos12 should depend on
> libmumps-4.10.0 when 5.1.1 is available.

libtrilinos-amesos12/12.10.1-3 depends on libmumps-4.10.0 because
libtrilinos_amesos.so.12 is linked to libdmumps-4.10.0.so and
libmumps_common-4.10.0.so

As per debian/control, libtrilinos-amesos-dev depends on any version
of libmumps-dev.

The new version of MUMPS changed ABI in a backward-incompatible way,
requiring a transition in Debian and every package that was built
against libmumps-4.10.0 needed to be rebuilt against libmumps-5.1.1 to
pick up the new dependencies.  See the transition bug #864650 for more
details.

The binNMU of trilinos 12.10.1-3+b1, which was supposed to pick up the
new dependencies, failed to build from source, see:
https://buildd.debian.org/status/logs.php?pkg=trilinos=amd64
and also bug #868523.

> We've recently uploaded 12.10.1-4, perhaps this rebuild will solve your
> problem.

Trilinos 12.10.1-4 was built against libmumps-5.1.1 and migrated to
testing on 2017-07-22, see:
https://packages.qa.debian.org/t/trilinos/news/20170722T043921Z.html

-- 
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#868873: dependence on libmumps-4.10.0 _AND_ libmumps-5.1.1 breaks make

2017-07-19 Thread Graham Inggs

On 19/07/2017 13:32, Joachim Wuttke wrote:
Since the recent update of Debian/testing from libmumps-4.10.0 to 
libmumps-5.1.1,

trilinos-all depends on both of them. This breaks my build:

make[2]: *** No rule to make target '/usr/lib/libsmumps.so', needed by 



after providing an ad-hoc link /usr/lib/libsmumps.so -> 
/usr/lib/libsmumps-4.10.0.so,

the next error comes up:

make[2]: *** No rule to make target '/usr/lib/libdmumps.so', needed by 



I don't think it is possible for trilinos to depend on both versions.

Trilinos 12.10.1-3 was built against libmumps-4.10.0 and is currently in 
testing.


Trilinos 12.10.1-4 was built against libmumps-5.1.1 and is currently in 
unstable.  It should migrate to testing in a couple of days.


Note that libmumps-5.1.1 now ships files in the multiarch directories, 
so your application my need to be changed to link against 
/usr/lib/x86_64-linux-gnu/libsmumps.so (or the equivalent for your 
architecture).


--
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#868523: FTBFS: test failed 617 ML_MLP_NonSym_MPI_4, 668 Phalanx_dag_manager_MPI_1

2017-07-16 Thread Graham Inggs
Uploaded, please downgrade the severity of this bug once the builds
are successful.

-- 
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#868523: FTBFS: test failed 617 ML_MLP_NonSym_MPI_4, 668 Phalanx_dag_manager_MPI_1

2017-07-16 Thread Graham Inggs
On 16 July 2017 at 20:40, Nico Schlömer  wrote:
> I've disabled the phalanx tests in master, and also fixed two other things.
> Perhaps it's time for an upload?

Doing a test build now, will upload if successful.

-- 
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#868523: FTBFS: test failed 617 ML_MLP_NonSym_MPI_4, 668 Phalanx_dag_manager_MPI_1

2017-07-16 Thread Graham Inggs
On 16 July 2017 at 13:12, Drew Parsons  wrote:
> Testing trilinos build on a porterbox for the mumps 5.1.1 transition.
>
> The following tests FAILED:
> 617 - ML_MLP_NonSym_MPI_4 (Failed)
> 668 - Phalanx_dag_manager_MPI_1 (Failed)
>
> Not sure if it's the new mumps, new openmpi 2.1.1 or something else.
> Full build log attached.

Reproducible build history shows FTBFS since 2017-07-02:
https://tests.reproducible-builds.org/debian/history/amd64/trilinos.html

Although with only one test failure:

The following tests FAILED:
668 - Phalanx_dag_manager_MPI_1 (Failed)

-- 
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#864443: pytables: ftbfs on armhf

2017-07-05 Thread Graham Inggs
This package subsequently built in Ubuntu and I have just confirmed that 
it now builds on harris.d.o.  There is already a binNMU pending for 
armhf, so if that is successful, this bug may be closed.


--
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#593231: freemat: window created, but input ignored

2017-06-08 Thread Graham Inggs
Hi Julian

On 08/16/2010 03:58 PM, Julian Andres Klode wrote:
> You can start freemat and the window appears, but is empty. Entering
> something into it has no effect.

Are you able to reproduce this behaviour with freemat 4.2+dfsg1-4 in Stretch?

Regards
Graham

-- 
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#864443: pytables: ftbfs on armhf

2017-06-08 Thread Graham Inggs
On 8 June 2017 at 19:53, Michael Hudson-Doyle  wrote:
> pytables currently ftbfs on armhf Ubuntu, and it turns out it ftbfs on armhf
> Debian too -- attaching the tail of a build log from a Debian porter box.  It
> started failing on Ubuntu in late January according to autopkgtest runs with
> the only package change between passing and failing being a trivial bzip2
> change -- so this is all a bit of a mystery to me.

I think this may be related:
http://www.pytables.org/latest/cookbook/threading.html

-- 
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#864364: freemat: toolbox missing diff() and run_tests()

2017-06-07 Thread Graham Inggs
Control: tags -1 + pending

These files are not very big, so instead of generating a new tarball,
we can restore them with a patch until the next upstream release.  I
have pushed this to git [1], as well updating Files-Excluded, and
enabling the diff() and hist() tests.
Please let me know if you have any objections to this approach.

[1] 
https://anonscm.debian.org/cgit/debian-science/packages/freemat.git/commit/?id=0b8cf010e3f58afe222a36b644c896d77ed945e6

-- 
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#864364: freemat: toolbox missing diff() and run_tests()

2017-06-07 Thread Graham Inggs
Source: freemat
Version: debian/4.2+dfsg1-1_exp1

Hi Maintainer

The diff() and run_tests() functions are missing from the freemat toolbox.
The missing diff() function also causes the hist() function to fail.
The run_tests() function provides a convenient way for a user to run
the freemat tests after the binary packages are installed

The files toolbox/general/diff.m and toolbox/tests/run_tests/m are
present in upstream's tarball, but are missing from the DFSG tarball
due to the Files-Excluded field in debian/copyright.
I didn't see anything in these files that would make them non-free.
Please consider including them again.

Regards
Graham

-- 
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#863793: freemat: please enable build-time and autopkgtest tests

2017-06-05 Thread Graham Inggs
I have this mostly working in Ubuntu, except s390x segfaults often. 
I'll push to git soon.


--
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#863794: freemat: please re-enable LLVM support

2017-06-05 Thread Graham Inggs

How to verify that JIT is functioning correctly.

Check whether JIT is enabled:

--> jitcontrol
ans =
on

Enable it if needed:

--> jitcontrol('on')

Run something that can be JIT compiled:

--> A=0; for j=1:100; A=A+j; end

Debug window in bottom-left should show 'Block JIT compiled at line 1 of 
"docli"', or similar.  If freemat was started from a terminal, you 
should see CLANG output, and no errors indicated.


Running the same commands subsequent times should be faster.

The value of the 'jitstat' variable should increment after every run.

--> jitstat
ans =
 0

JIT tests from the freemat test suite can be run as follows:

--> wrap_jit_test('tjit1',0,true)
Speedup base 1.293000 target 0.00 up 1.286000
Jit succeeded 0
Issame 1

Tests from 'tjit1' to 'tjit27' are available.
The line 'Jit succeeded 0' above indicates that 'jitstat' did not 
increment and JIT was not successful.


--
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#850150: freemat ftbfs with LLVM 3.9

2017-06-05 Thread Graham Inggs

The attached patch fixes the build with LLVM 4.0.
However, JIT still needs to be re-enabled and properly tested, see #863794.
Description: Fix build failure with default LLVM 4.0
Author: Graham Inggs <gin...@debian.org>
Last-Update: 2017-06-03
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -258,7 +258,7 @@
   link_directories(${LLVM_LIBRARY_DIRS})
   llvm_map_components_to_libnames(REQ_LLVM_LIBRARIES executionengine option IRReader lto interpreter nativecodegen asmparser bitreader bitwriter codegen ipo linker selectiondag instrumentation)
   
-  set(OPTIONAL_LIBS ${OPTIONAL_LIBS} ${CLANG_LIBRARIES};clang;clangAnalysis;clangApplyReplacements;clangARCMigrate;clangAST;clangASTMatchers;clangBasic;clangCodeGen;clangDriver;clangDynamicASTMatchers;clangEdit;clangFormat;clangFrontend;clangFrontendTool;clangIndex;clangLex;clangParse;clangQuery;clangRename;clangRewrite;clangRewriteFrontend;clangSema;clangSerialization;clangStaticAnalyzerCheckers;clangStaticAnalyzerCore;clangStaticAnalyzerFrontend;clangTidy;clangTidyGoogleModule;clangTidyLLVMModule;clangTidyMiscModule;clangTidyReadability;clangTidyUtils;clang ${CLANG_LIBS} ${REQ_LLVM_LIBRARIES})
+  set(OPTIONAL_LIBS ${OPTIONAL_LIBS} ${CLANG_LIBRARIES};clang;clangAnalysis;clangApplyReplacements;clangARCMigrate;clangAST;clangASTMatchers;clangBasic;clangCodeGen;LLVMCoverage;LLVMCoroutines;clangDriver;clangDynamicASTMatchers;clangEdit;clangFormat;clangFrontend;clangFrontendTool;clangIndex;clangLex;clangParse;clangQuery;clangRename;clangRewrite;clangRewriteFrontend;clangSema;clangSerialization;clangStaticAnalyzerCheckers;clangStaticAnalyzerCore;clangStaticAnalyzerFrontend;clangTidy;clangTidyGoogleModule;clangTidyLLVMModule;clangTidyMiscModule;clangTidyReadabilityModule;clangTidyUtils;clang ${CLANG_LIBS} ${REQ_LLVM_LIBRARIES})
 ENDIF()
 
 ##
--- a/libs/libMatC/CJitFuncClang.cpp
+++ b/libs/libMatC/CJitFuncClang.cpp
@@ -17,9 +17,8 @@
 
 #include "llvm/IR/LLVMContext.h"
 #include "llvm/IR/Module.h"
-#include "llvm/Config/config.h"
+#include "llvm/Config/llvm-config.h"
 #include "llvm/ADT/SmallString.h"
-#include "llvm/Config/config.h"
 #include "llvm/ExecutionEngine/ExecutionEngine.h"
 #include "llvm/ExecutionEngine/GenericValue.h"
 #include "llvm/Support/ManagedStatic.h"
@@ -110,7 +109,7 @@
   // FIXME: This is copied from cc1_main.cpp; simplify and eliminate.
   // Create a compiler instance to handle the actual work.
   comp = new clang::CompilerInstance;
-  comp->setInvocation(CI.get());
+  comp->setInvocation(std::move(CI));
   // Create the compilers actual diagnostics engine.
   DiagnosticConsumer ClientDia;
   comp->createDiagnostics();
-- 
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#863795: freemat: fails to start if ~/Private exists

2017-05-31 Thread Graham Inggs

Source: freemat
Version: 4.0-2
Severity: normal
Forwarded: https://sourceforge.net/p/freemat/bugs/489/

As reported to Ubuntu [1]:

Freemat does not start if there is a file or a directory named Private 
in the user's home directory.


This still affects freemat 4.2.


[1] https://bugs.launchpad.net/ubuntu/+source/freemat/+bug/893742

--
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#863686: freemat: fails to start with llvm error

2017-05-30 Thread Graham Inggs

On 30/05/2017 06:45, Stuart Prescott wrote:


Starting a fresh installation of freemat fails:

$ freemat
: CommandLine Error: Option 'x86-machine-combiner' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options


I see the same here.

A no-change rebuild with llvm-3.8 has no effect.

Applying the patch from #850150 and rebuilding with llvm-3.9 has no 
effect either.


--
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#862969: r-cran-sp needs recompilation for R 3.4.0 ?

2017-05-19 Thread Graham Inggs
On 19 May 2017 at 14:55, Theodore Lytras  wrote:
> It was working until recently, i.e. before the upgrade from R 3.3 to 3.4.

r-base in testing is 3.3.3-1
r-base in unstable is 3.4.0-1 and is blocked from migration due to #861333

> If I uninstall the debian package and compile the R source package from CRAN,
> it works. So probably the debian package needs recompilation.

r-cran-sp (and many packages) will need to recompiled for R 3.4.0
I guess this will only take place after the release of Stretch, which
includes R 3.3.3

-- 
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#860697: deal.ii: FTBFS on i386: build-dependency not installable: trilinos-all-dev

2017-04-19 Thread Graham Inggs
Control: severity -1 wishlist

On 19 April 2017 at 09:14, Lucas Nussbaum  wrote:
>> The following packages have unmet dependencies:
>>  sbuild-build-depends-deal.ii-dummy : Depends: trilinos-all-dev but it is 
>> not installable
>> E: Unable to correct problems, you have held broken packages.
>> apt-get failed.

Trilinos currently does not build on 32-bit architectures, see #835406.
Deal.ii 32-bit binaries were removed on 2016-12-08, see #847430.

-- 
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#859871: r-cran-sp: autopkgtests depend on non-existent r-cran-rgeos

2017-04-08 Thread Graham Inggs
Source: r-cran-sp
Version: 1:1.2-4-1

Hi Maintainer

Autopkgtests of r-cran-sp have been failing since the upload of
1:1.2-4-1 [1] with the error:

badpkg: Test dependencies are unsatisfiable. A common reason is that
your testbed is out of date with respect to the archive, and you need
to use a current testbed or run apt-get update or use -U.
adt-run [11:11:21]: ERROR: erroneous package: Test dependencies are
unsatisfiable. A common reason is that your testbed is out of date
with respect to the archive, and you need to use a current testbed

debian/tests/control contains the following [2]:

Tests: run-unit-test
Depends: @, r-cran-runit, r-cran-rgeos
Restrictions: allow-stderr

But r-cran-geos is not in the archive.

Regards
Graham


[1] https://ci.debian.net/packages/r/r-cran-sp/unstable/amd64/
[2] https://sources.debian.net/src/r-cran-sp/1:1.2-4-1/debian/tests/control/#L2

-- 
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#850965: freecad: GNOME Software catalog entry missing

2017-01-24 Thread Graham Inggs

On 24/01/2017 00:00, asciiw...@seznam.cz wrote:

The issue seems to be still present.


Please re-open the bug and state what is still needed.

--
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#852296: yade FTBFS on arm64: compiler processes terminated (machine runs out of RAM?)

2017-01-23 Thread Graham Inggs

On 23/01/2017 14:08, Adrian Bunk wrote:

This buildd has 6 CPUs, but it has only 8 GB of RAM.


From the last changelog entry:

  * [d763fbf] Set compat level to 10.

The switch to debhelper 10 enabled parallel builds.

Yade 2017.01a-1 FTBFS on most architectures in Ubuntu.
The following changed helped there:

--- a/debian/rules
+++ b/debian/rules
@@ -4,7 +4,7 @@
 tmpDirMatplotLib = $(CURDIR)/debian/matplotlib

 %:
-   dh $@ --builddirectory=$(BUILDDIR) --with python2
+   dh $@ --builddirectory=$(BUILDDIR) --with python2 --max-parallel=1

 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed,-no-keep-memory

--
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#852283: libopenblas-dev: missing on mips64el

2017-01-22 Thread Graham Inggs
Source: openblas
Version: 0.2.19-1
Severity: serious

Hi Maintainer

Architecture: mips64el was added to libopenblas-base but not libopenblas-dev.
Was this an oversight?

Regards
Graham

-- 
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#851726: liggghts: FTBFS on single-CPU machines (not enough slots available)

2017-01-18 Thread Graham Inggs
See #850229.

-- 
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#851320: trilinos: FTBFS on single-CPU machines (not enough slots available)

2017-01-14 Thread Graham Inggs
One solution here is to add '--oversubscribe' to all the mpirun
commands, however it has been pointed out that this will fail if the
user tries to use an alternate MPI implementation.

See #850229.

-- 
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#850229: dune-grid: FTBFS (not enough slots available)

2017-01-10 Thread Graham Inggs
On 5 January 2017 at 13:46, Ansgar Burchardt  wrote:
> On my laptop with 4 cores + HT (so 8 threads), I see `mpirun` complain
> once I start more than 4 processes, i.e. more processes than real
> cores.  Did you count threads or cores when you tried?

I haven't been able to duplicate that behaviour ('not enough slots
available' with more than enough CPUs available) on any real hardware.
I think I must have seen that message on the Ubuntu autopkgtest
runners which are single core cloud instances, not quad core machines
like their buildds, and been confused.

-- 
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#850229: dune-grid: FTBFS (not enough slots available)

2017-01-05 Thread Graham Inggs

Hi

On 05/01/2017 12:05, Santiago Vila wrote:

Status:FAILED
Output:
   
--
   There are not enough slots available in the system to satisfy the 2 
slots
   that were requested by the application:
 test-yaspgrid-yaspfactory-1d

   Either request fewer slots for your application, or make more slots 
available
   for use.
   
--


I started seeing similar errors in other MPI applications since the 
upload of openmpi 2.0.2~ to unstable.


The solution was to add --oversubscribe to the mpirun command line, e.g. 
[1].



The bug should be reproducible with sbuild on a single CPU virtual machine.
It always fail for me (I tried 10 times in different autobuilders).


If I understand correctly, --oversubscribe should be needed in your case 
where you have fewer CPUs than the number of processes requested, but I 
was seeing the errors even when there were more than enough CPUs available.


Regards
Graham


[1] 
https://anonscm.debian.org/cgit/debian-science/packages/lammps.git/commit/?id=64c465da9036114cec9220ebe58bd264b974b694


--
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#811986: qwtplot3d: diff for NMU version 0.2.7+svn191-10.1

2016-12-25 Thread Graham Inggs
Hi Arto

On 23 December 2016 at 14:59, Arto Jantunen  wrote:
> I've prepared an NMU for qwtplot3d (versioned as 0.2.7+svn191-10.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.

Thanks for the upload.  I'm not the maintainer, but I suggest you
remove the delay otherwise qwtplot3d won't migrate to testing before
the freeze.

BTW, the bug was RC and there had been no maintainer activity for more
than 7 days, so I think a DELAYED/0 would have been appropriate.

Regards
Graham

-- 
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#835406: trilinos: FTBFS on 32-bit architectures

2016-12-09 Thread Graham Inggs
On 9 December 2016 at 09:49, Nico Schlömer  wrote:
> The patch looks really simple. Great! Do you think it'd be worthwhile
> updating the PR [1] (or opening a new one)? Perhaps the kokkos devs can
> figure out why the remaining tests are failing.

No harm in trying, I guess. :)
Please update the PR, but I suggest leaving out the static_asserts,
i.e. don't include the changes to Kokkos_Core_fwd.hpp and
Kokkos_TaskQueue.hpp.
Also, I think the changes to Kokkos_Macros.hpp from
kokkos-disable-asm.patch should go in a separate PR.  Hopefully they
can merge that right away.

-- 
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#835406: trilinos: FTBFS on 32-bit architectures

2016-12-08 Thread Graham Inggs
Attached is an updated version of kokkos-32-bit.patch against upstream 12.10.1.
It turns out that once the templates were fixed, the overloaded
function declarations were not needed.

Builds and test of Kokkos-only and all Trilinos packages on 64-bit
architectures are not affected.

On 32-bit architectures that have an 8-byte compare-and-swap
implementation (e.g. armhf and i386), a Kokkos-only build is
successful, but 1 out of the 21 unit tests,
KokkosCore_UnitTest_Serial_MPI_1, fails.
KokkosCore_UnitTest_Serial_MPI_1 includes 60 tests and of these only 4
fail with errors like:

Value of: result[i].value[j]
  Actual: 5.5e+09
Expected: (ScalarType) correct
Which is: 7.05083e+08

A build of all Trilinos packages fails with a few errors similar to
the following:

packages/tpetra/core/test/Distributor/createfromsendsandrecvs.cpp:315:61:
error: conversion from ‘Teuchos::ArrayView’ to
non-scalar type ‘Teuchos::ArrayView’
requested
   ArrayView c = dist.getLengthsFrom();


For a Kokkos-only build, which saves a huge amount of time (thanks
Nico!), make the following changes to debian/rules:

--- a/debian/rules
+++ b/debian/rules
@@ -93,8 +93,9 @@
-DTrilinos_INSTALL_INCLUDE_DIR:PATH=include/trilinos/ \
-DTrilinos_USE_GNUINSTALLDIRS:BOOL=ON \
-DTrilinos_ENABLE_DEVELOPMENT_MODE:BOOL=OFF \
-   -DTrilinos_ENABLE_ALL_PACKAGES:BOOL=ON \
-   -DTrilinos_ENABLE_SECONDARY_TESTED_CODE:BOOL=ON \
+   -DTrilinos_ENABLE_ALL_PACKAGES:BOOL=OFF \
+   -DTrilinos_ENABLE_SECONDARY_TESTED_CODE:BOOL=OFF \
+   -DTrilinos_ENABLE_Kokkos:BOOL=ON \
-DTrilinos_ASSERT_MISSING_PACKAGES:BOOL=OFF \
-DTrilinos_ENABLE_EXPLICIT_INSTANTIATION:BOOL=ON \
-DTrilinos_ENABLE_CTrilinos:BOOL=OFF \


kokkos-32-bit.patch
Description: application/empty
-- 
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#835406: trilinos: FTBFS on 32-bit architectures

2016-12-07 Thread Graham Inggs
Control: tags -1 patch
Control: merge -1 836130

I've had another look at this after uploading 12.10.1.
Upstream have added the following in
packages/kokkos/core/src/Kokkos_Core_fwd.hpp:

//
// Have assumed a 64bit build (8byte pointers) throughout the code base.

static_assert( sizeof(void*) == 8
 , "Kokkos assumes 64-bit build; i.e., 8-byte pointers" );

//

They have also added more code that assumes long and long long are the
same size, e.g. in
packages/kokkos/core/src/impl/Kokkos_Atomic_Decrement.hpp

Nico and I discussed building Trilinos without the Kokkos package on
32-bit architectures (and even tested this) however we also lose the
Amesos2, Ifpack2, Phalanx, Stokhos, Teko, Tpetra and Zoltan2 packages
which depend on Kokkos.  Nico felt that half of a Trilinos package on
32-bit architectures would not be useful.

I'll leave this open as a wishlist bug in case any of the i386 porters
can help. ;)

-- 
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#845082: (no subject)

2016-11-28 Thread Graham Inggs
On 29 November 2016 at 00:29, Breno Leitao  wrote:
> We just created a pull request to have this fixed upstream.

Thanks!

> Should we create a Debian patch also?

This bug is tagged 'pending' and there's already a patch in the
packaging git [1].
I did notice the patch uses round() while your PR uses llround().
Antonio, should that be changed?


[1] 
https://anonscm.debian.org/cgit/debian-science/packages/numexpr.git/commit/?id=5c1edd14c6cf8f1258514faca2010380be75bb37

-- 
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#811986: qwtplot3d: FTBFS with GCC 6: symbol changes

2016-11-27 Thread Graham Inggs
Control: tags - 1 patch

Hi Maintainer

The attached patch works for me.

Regards
Graham
--- a/debian/libqwtplot3d-qt4-0v5.symbols
+++ b/debian/libqwtplot3d-qt4-0v5.symbols
@@ -243,10 +243,10 @@
  _ZN5Qwt3D4Axis9setMajorsEi@Base 0.2.7
  _ZN5Qwt3D4Axis9setMinorsEi@Base 0.2.7
  _ZN5Qwt3D4AxisC1ENS_6TripleES1_@Base 0.2.7
- _ZN5Qwt3D4AxisC1ERKS0_@Base 0.2.7
+ (optional=templinst)_ZN5Qwt3D4AxisC1ERKS0_@Base 0.2.7
  _ZN5Qwt3D4AxisC1Ev@Base 0.2.7
  _ZN5Qwt3D4AxisC2ENS_6TripleES1_@Base 0.2.7
- _ZN5Qwt3D4AxisC2ERKS0_@Base 0.2.7
+ (optional=templinst)_ZN5Qwt3D4AxisC2ERKS0_@Base 0.2.7
  _ZN5Qwt3D4AxisC2Ev@Base 0.2.7
  _ZN5Qwt3D4AxisD0Ev@Base 0.2.7
  _ZN5Qwt3D4AxisD1Ev@Base 0.2.7
@@ -268,7 +268,7 @@
  _ZN5Qwt3D5ArrowD0Ev@Base 0.2.7
  _ZN5Qwt3D5ArrowD1Ev@Base 0.2.7
  _ZN5Qwt3D5ArrowD2Ev@Base 0.2.7
- _ZN5Qwt3D5Color12createVectorERSt6vectorINS_4RGBAESaIS2_EE@Base 0.2.7
+ 
(optional=templinst)_ZN5Qwt3D5Color12createVectorERSt6vectorINS_4RGBAESaIS2_EE@Base
 0.2.7
  _ZN5Qwt3D5GL2QtEddd@Base 0.2.7
  _ZN5Qwt3D5Label11setPositionENS_6TripleENS_6ANCHORE@Base 0.2.7
  _ZN5Qwt3D5Label12devicefonts_E@Base 0.2.7
@@ -380,9 +380,9 @@
  _ZN5Qwt3D6Plot3DD0Ev@Base 0.2.7
  _ZN5Qwt3D6Plot3DD1Ev@Base 0.2.7
  _ZN5Qwt3D6Plot3DD2Ev@Base 0.2.7
- _ZN5Qwt3D7MappingD0Ev@Base 0.2.7
- _ZN5Qwt3D7MappingD1Ev@Base 0.2.7
- _ZN5Qwt3D7MappingD2Ev@Base 0.2.7
+ (optional=templinst)_ZN5Qwt3D7MappingD0Ev@Base 0.2.7
+ (optional=templinst)_ZN5Qwt3D7MappingD1Ev@Base 0.2.7
+ (optional=templinst)_ZN5Qwt3D7MappingD2Ev@Base 0.2.7
  _ZN5Qwt3D8CellData5clearEv@Base 0.2.7
  _ZN5Qwt3D8CellDataD0Ev@Base 0.2.7
  _ZN5Qwt3D8CellDataD1Ev@Base 0.2.7
@@ -475,6 +475,7 @@
  _ZNK5Qwt3D8LogScale8ticLabelEj@Base 0.2.7
  _ZNK5Qwt3D9CrossHair5cloneEv@Base 0.2.7
  
(optional=templinst)_ZNSt6vectorIN5Qwt3D2IO5EntryESaIS2_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS2_S4_EERKS2_@Base
 0.2.7
+ 
(optional=templinst)_ZNSt6vectorIN5Qwt3D2IO5EntryESaIS2_EE19_M_emplace_back_auxIJRKS2_EEEvDpOT_@Base
 0.2.7
  (optional=templinst)_ZNSt6vectorIN5Qwt3D2IO5EntryESaIS2_EED1Ev@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIN5Qwt3D2IO5EntryESaIS2_EED2Ev@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIN5Qwt3D4AxisESaIS1_EED1Ev@Base 0.2.7
@@ -482,11 +483,14 @@
  (optional=templinst)_ZNSt6vectorIN5Qwt3D4AxisESaIS1_EEaSERKS3_@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIN5Qwt3D4RGBAESaIS1_EEaSERKS3_@Base 0.2.7
  
(optional=templinst)_ZNSt6vectorIN5Qwt3D5LabelESaIS1_EE14_M_fill_insertEN9__gnu_cxx17__normal_iteratorIPS1_S3_EEmRKS1_@Base
 0.2.7
+ 
(optional=templinst)_ZNSt6vectorIN5Qwt3D5LabelESaIS1_EE17_M_default_appendEm@Base
 0.2.7
  (optional=templinst)_ZNSt6vectorIN5Qwt3D5LabelESaIS1_EED1Ev@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIN5Qwt3D5LabelESaIS1_EED2Ev@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIN5Qwt3D5LabelESaIS1_EEaSERKS3_@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIN5Qwt3D6Plot3D5LightESaIS2_EEaSERKS4_@Base 
0.2.7
+ 
(optional=templinst)_ZNSt6vectorIN5Qwt3D6TripleESaIS1_EE12emplace_backIJS1_EEEvDpOT_@Base
 0.2.7
  
(optional=templinst)_ZNSt6vectorIN5Qwt3D6TripleESaIS1_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS1_S3_EERKS1_@Base
 0.2.7
+ 
(optional=templinst)_ZNSt6vectorIN5Qwt3D6TripleESaIS1_EE19_M_emplace_back_auxIJS1_EEEvDpOT_@Base
 0.2.7
  (optional=templinst)_ZNSt6vectorIN5Qwt3D6TripleESaIS1_EEaSERKS3_@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIPdSaIS0_EEaSERKS2_@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIS_IPdSaIS0_EESaIS2_EED1Ev@Base 0.2.7
@@ -496,9 +500,12 @@
  (optional=templinst)_ZNSt6vectorIS_IjSaIjEESaIS1_EED2Ev@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIS_IjSaIjEESaIS1_EEaSERKS3_@Base 0.2.7
  
(optional=templinst)_ZNSt6vectorIdSaIdEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPdS1_EERKd@Base
 0.2.7
+ 
(optional=templinst)_ZNSt6vectorIdSaIdEE19_M_emplace_back_auxIJRKdEEEvDpOT_@Base
 0.2.7
  (optional=templinst)_ZNSt6vectorIdSaIdEEaSERKS1_@Base 0.2.7
  
(optional=templinst)_ZNSt6vectorIjSaIjEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPjS1_EERKj@Base
 0.2.7
  
(optional=templinst)_ZNSt6vectorIjSaIjEE14_M_fill_insertEN9__gnu_cxx17__normal_iteratorIPjS1_EEmRKj@Base
 0.2.7
+ (optional=templinst)_ZNSt6vectorIjSaIjEE17_M_default_appendEm@Base 0.2.7
+ 
(optional=templinst)_ZNSt6vectorIjSaIjEE19_M_emplace_back_auxIJjEEEvDpOT_@Base 
0.2.7
  (optional=templinst)_ZNSt6vectorIjSaIjEEaSERKS1_@Base 0.2.7
  
(optional=templinst)_ZNSt7__cxx114listIPN5Qwt3D8DrawableESaIS3_EEaSERKS5_@Base 
0.2.7
  
(optional=templinst)_ZSt9__find_ifIN9__gnu_cxx17__normal_iteratorIPN5Qwt3D2IO5EntryESt6vectorIS4_SaIS4_NS0_5__ops10_Iter_predINS3_13FormatCompareT_SE_SE_T0_St26random_access_iterator_tag@Base
 0.2.7
--- a/debian/libqwtplot3d-qt5-0.symbols
+++ b/debian/libqwtplot3d-qt5-0.symbols
@@ -248,10 +248,10 @@
  _ZN5Qwt3D4Axis9setMajorsEi@Base 0.2.7
  _ZN5Qwt3D4Axis9setMinorsEi@Base 0.2.7
  _ZN5Qwt3D4AxisC1ENS_6TripleES1_@Base 0.2.7
- _ZN5Qwt3D4AxisC1ERKS0_@Base 0.2.7
+ (optional=templinst)_ZN5Qwt3D4AxisC1ERKS0_@Base 0.2.7
  _ZN5Qwt3D4AxisC1Ev@Base 0.2.7
  

meshlab: FTBFS with GCC 6: cannot convert x to y

2016-11-17 Thread Graham Inggs
In addition to Gert Wollny's patch, the attached patch fixes narrowing
conversions with GCC 6 on architectures where char is unsigned by
default.

Copying to debian-science-maintainers list in case someone is
interested in rescuing this package.


narrowing-conversion.patch
Description: application/empty
-- 
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#836844: eigen3: autopkgtests fail on ppc64el

2016-11-13 Thread Graham Inggs
Control: reopen -1

I've just checked eigen3 3.3.0-1 on plummer.debian.org, and it still outputs

forceMatrix*axisMatrix: -1  0  0
 0 -2  0
 0  0 -3

-- 
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#842946: rheolef: please build everywhere

2016-11-02 Thread Graham Inggs

Source: rheolef
Version: 6.7-1
Severity: wishlist

Hi Maintainer

Please consider making librheolef1 Architecture: any.
In Ubuntu, rheolef builds additionally on arm64 and s390x.

It is not a problem if not all architectures build on the buildds 
(unless they built previously).


Regards
Graham

--
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#841885: gerris: autopkgtests fail with openmpi2

2016-10-26 Thread Graham Inggs
The problem on Ubuntu's s390x autopkgtest runner was solved by putting back:

export OMPI_MCA_plm_rsh_agent=/bin/false

I have committed the change to git.

-- 
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#841885: gerris: autopkgtests fail with openmpi2

2016-10-25 Thread Graham Inggs
On 25 October 2016 at 17:32, Anton Gladky  wrote:
> feel free to commit directly to git.

Thanks, I will do!

When I looked previously, I thought the git hadn't been updated since
2014-03-23:
https://anonscm.debian.org/cgit/debian-science/packages/gerris.git

But now I see that is the debian-unstable branch, not the master branch.

-- 
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#841885: gerris: autopkgtests fail with openmpi2

2016-10-25 Thread Graham Inggs
On 24 October 2016 at 21:46, Anton Gladky  wrote:
> thanks for your fix. I have committed it and it will be fixed by the next
> upload.

Thanks! There's no hurry for the next upload.
In Ubuntu, I'm still seeing autopkgtests fail, but only on s390x, with
the following message:

The value of the MCA parameter "plm_rsh_agent" was set to a path
that could not be found:

  plm_rsh_agent: ssh : rsh

We might need to put back:

export OMPI_MCA_plm_rsh_agent=/bin/false

But I will investigate further and reply to this bug.

-- 
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#841885: gerris: autopkgtests fail with openmpi2

2016-10-24 Thread Graham Inggs
Source: gerris
Version: 20131206+dfsg-9

Hi Maintainer

Since the transition to openmpi2, gerris' autopkgtests have been
failing with the following error:

orte_ess_init failed
--> Returned value A system-required executable either could not be
found or was not executable by this user (-126) instead of
ORTE_SUCCESS

I solved this by adding mpi-default-bin to debian/tests/control as follows:

--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,2 +1,2 @@
 Tests: testHydro testKinetic testPlate testQuadr
-Depends: gerris, libgfs-dev, build-essential, pkg-config, mpi-default-dev
+Depends: gerris, libgfs-dev, build-essential, pkg-config,
mpi-default-dev, mpi-default-bin

However, if the dependencies libgfs-dev, build-essential, pkg-config,
mpi-default-dev and mpi-default-bin are actually needed for normal
usage of gerris, then maybe they should rather be added to the gerris
package's Depends in debian/control.

Regards
Graham

-- 
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#837915: package builds crashing under fakeroot

2016-10-04 Thread Graham Inggs

Control: tags 837915 help

Hi!

On 25/09/2016 13:21, Michael Banck wrote:

as I just diagnosed this for a different package: the problem appears to
be that mpirun is run during binary-arch, i.e. under fakeroot. Latest
openmpi does not like that apparenlty and crashes.

Not sure how to fix it for aster as apparently building the elements
catalog is part of the upstream install run.  Maybe the upstream build
system can be modified to build that catalog during build, not install?


I'm not really familiar with aster's build system.  I happened to upload 
the last NMU in order to fix a build with PETSc.


Any help would be appreciated.

Regards
Graham

--
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#836130: trilinos: FTBFS without __sync_val_compare_and_swap_8

2016-09-16 Thread Graham Inggs
severity 836130 wishlist
retitle 836130 trilinos: FTBFS without __sync_val_compare_and_swap_8
thanks


Hi Aaron

On 30 August 2016 at 20:18, Aaron M. Ucko  wrote:
> Source: trilinos
> Version: 12.6.4-1
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)

I'm dropping this bug's severity to wishlist as Trilinos last built on
32-bit architectures in 2010 [1], before the Kokkos package was
introduced.  These binaries are not in testing and therefore should
not prevent Trilinos from migrating.

> Thanks for looking into #835406!  trilinos now successfully builds on
> i386 and x32, and the builds for other 32-bit architectures don't fail
> as quickly as they used to, but they nevertheless remain broken (at
> least on mips, mipsel, and powerpc -- builds for other architectures
> are still in progress):

The build was also successful on armhf, but still fails on
architectures without '__sync_val_compare_and_swap_8'.  There's a GCC
bug [2] requesting an implementation, however it has been closed
WONTFIX.  Before you reassign this bug to gcc in Debian, there seems
to be a workaround mentioned in that bug which I intend investigating
when I have some time to spend on a porterbox, probably after the
openmpi transition.

We have opened a PR [3] with upstream, in the hopes that we can work
together on a solution.

Regards
Graham

PS: If you are happy with the outcome of #815725, please close it.


[1] https://buildd.debian.org/status/logs.php?pkg=trilinos=powerpc
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368
[3] https://github.com/kokkos/kokkos/pull/410

-- 
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#837121: gazebo: please restrict libkido-dev (build-)dependency to architectures where it is available

2016-09-14 Thread Graham Inggs
Control: reopen -1


Hi Maintainer

I see you updated gazebo's build-dependencies in 7.3.0+dfsg-5.
Please do the same for libgazebo7-dev's binary dependencies, i.e.


--- a/debian/control
+++ b/debian/control
@@ -137,7 +138,7 @@
  libignition-math2-dev,
  libbullet-dev,
  libsimbody-dev,
- libkido-dev [amd64 arm64 i386 powerpc alpha],
+ libkido-dev [amd64 arm64 i386 ppc64el alpha mipsel],
  libgazebo7 (= ${binary:Version}),
  gazebo7-common (= ${source:Version}),
  gazebo7-plugin-base (= ${binary:Version}),


Regards
Graham

-- 
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#837058: p4est: FTBFS due to test failures

2016-09-10 Thread Graham Inggs
Control: notfixed -1 1.1-3
Control: found -1 1.1-3


There are still two tests that fail intermittently:

FAIL: test/p4est_test_loadsave
FAIL: test/p8est_test_loadsave

I believe upstream are aware of issues with openmpi 2.

-- 
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#836983: freecad: autopkgtests fail on ppc64el and s390x

2016-09-07 Thread Graham Inggs
Source: freecad
Version: 0.16+dfsg2-1
Severity: wishlist


Hi Maintainer

In Ubuntu, freecad 0.16+dfsg2-1 has been failing autopkgtests on
ppc64el and 390x with the following error:

==
ERROR: testConversions (UnitTests.UnitBasicCases)
--
Traceback (most recent call last):
  File "/usr/lib/freecad/Mod/Test/UnitTests.py", line 27, in testConversions
self.failUnless(compare(tu('m^2*kg*s^-3*A^-2'), 100.0))
  File "/usr/lib/freecad/Mod/Test/UnitTests.py", line 9, in tu
return FreeCAD.Units.Quantity(str).Value
ValueError: Unit overflow in pow()

==
ERROR: testUnits (TestSpreadsheet.SpreadsheetCases)
Units -- test unit calculations.
--
Traceback (most recent call last):
  File "/usr/lib/freecad/Mod/Spreadsheet/TestSpreadsheet.py", line
307, in testUnits
self.assertEqual(sheet.A9, Quantity('5 K^-1'))
ValueError: Unit overflow in pow()

I verified the behaviour on plummer.debian.org, a ppc64el porterbox.
It seems to be a problem with raising a unit to a negative power on
these architectures.

Regards
Graham

-- 
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#836844: eigen3: autopkgtests fail on ppc64el

2016-09-07 Thread Graham Inggs
Control: tags -1 patch


Hi Anton

> I think this can be ignored. But the question is interesting,
> if it is platform-dependent.

I saw the same behaviour on plummer.debian.org, a ppc64el porterbox.

For the record, I applied the patch below in Ubuntu and eigen3 migrated.

Regards
Graham


--- a/debian/tests/build1
+++ b/debian/tests/build1
@@ -73,8 +73,6 @@

   std::cout<<"forceMatrix: "<

Bug#836844: eigen3: autopkgtests fail on ppc64el

2016-09-06 Thread Graham Inggs

Source: eigen3
Version: 3.3~beta2-1
Severity: wishlist


Hi Maintainer

Since eigen3 3.3~beta2-1, its autopkgtests fail on ppc64el in Ubuntu [1].
Tests on other architectures remain successful [2].

I compared passing and failing test results and the only difference I 
can see is the passing test has:


forceMatrix*axisMatrix: -1 -0 -0
-0 -2 -0
-0 -0 -3

while the failing test has:

forceMatrix*axisMatrix: -1  0  0
 0 -2  0
 0  0 -3

This currently prevents the latest versions of eigen3 from migrating to 
Ubuntu Yakkety.

Any ideas, please?  Is it safe to ignore these differences?

Regards
Graham


[1] http://autopkgtest.ubuntu.com/packages/e/eigen3/yakkety/ppc64el
[2] http://autopkgtest.ubuntu.com/packages/e/eigen3

--
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#835411: opensurgsim: FTBFS with eigen3 3.3~beta2-1

2016-09-03 Thread Graham Inggs
With eigen3 including upstream's patch mentioned by Philipp [1],
opensurgsim now builds and passes all 12 tests on ppc64el, but fails 1
test on amd64 and 3 tests on arm64.  I don't know if more work is
needed in the eigen3 patch or in opensurgsim.


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

-- 
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#835427: s/XML_NO_ERROR/XML_SUCCESS/

2016-09-02 Thread Graham Inggs
Hi Peter

On 2 September 2016 at 23:15, Peter Green  wrote:
> Unfortunately while that patch fixed the FTBFS in raspbian stretch at the
> time the package is now failing for us for a different reason. While I saw
> this in raspbian I have no reason to belive it is raspbian specific.
>
>
> In file included from /usr/include/spnav.h:33:0,
>  from
> /<>/gazebo-7.3.0+dfsg/gazebo/gui/SpaceNav.cc:27:
> /usr/include/google/protobuf/stubs/logging.h:66:7: error: expected
> identifier before 'int'
>  class Status;
>^
> /usr/include/google/protobuf/stubs/logging.h:66:7: error: multiple types in
> one declaration

This comes from protobuf 3.  I found it has already been fixed in git
[1], although the patch description is incorrect.

Regards
Graham


[1] 
https://anonscm.debian.org/cgit/debian-science/packages/gazebo.git/commit/?id=d033bbf3218580638e35b8df13565099a5c7c8db

-- 
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#836420: python-getfem++: please depend on python-scipy for autopkgtests

2016-09-02 Thread Graham Inggs
Package: python-getfem++
Version: 5.0+dfsg1-1
Severity: wishlist


Hi Anton

Please add a dependency to python-getfem++ on python-scipy.
It is required by the autopkgtests and probably for proper operation
of python-getfem++ as well.

--- a/debian/control
+++ b/debian/control
@@ -77,6 +78,7 @@
  python (<< 2.8),
  python,
  python-numpy,
+ python-scipy,
  ${misc:Depends},
  ${python:Depends},
  ${shlibs:Depends}

Regards
Graham

-- 
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#835406: trilinos: FTBFS on 32-bit architectures

2016-08-29 Thread Graham Inggs
On 29 August 2016 at 21:55, Nico Schlömer  wrote:
> When uploading, we could perhaps also include the point release 12.6.4.
> (Current Debian is 12.6.3.)

Sure, let's do that.

Do you have time now to prepare 12.6.4 for upload?  I can rebase and
test my patches against that version.
Otherwise, if you think it will be straightforward, I can just do it.

-- 
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#835406: trilinos: FTBFS on 32-bit architectures

2016-08-29 Thread Graham Inggs

Control: -1 patch


Hi Aaron

I cloned bug #815725 as a wishlist bug for 32-bit architectures, since 
upstream only want to support 64-bit.  I was able to fix the use of x86 
assembly on other 64-bit architectures and closed the original bug.  New 
builds were successful on arm64, mips64el, alpha and sparc64.  Trilinos 
also built on s390x in Ubuntu where they have a working libtbb for s390x.


I did some further experimentation and came up with a patch (attached) 
to build Kokkos (and thus a complete Trilinos as well) on 32-bit 
architectures.
I have successfully built trilinos on i386 and armhf, and builds on 
amd64, arm64 and ppc64el remained successful.  Ithen successfully built 
deal.II against the new Trilinos packages on all of the aforementioned 
architectures, although the deal.II tests eventually timed out on armhf.


If there are no objections, I will upload Trilinos including this patch 
within this week.


Regards
Graham

Description: Allow Kokkos to build on 32-bit and 64-bit architectures
 On 32-bit architectures, long ints are four bytes in size and
 long long ints are eight bytes in size.  On 64-bit architectures,
 both long ints and long long ints are eight bytes in size.
 This patch changes long to long long in some places (no change for
 64-bit architectures), and adds function declarations needed for
 building on 32-bit architectures.
Bug-Debian: https://bugs.debian.org/835406
Author: Graham Inggs <gin...@debian.org>
Last-Update: 2016-08-28
--- a/packages/kokkos/core/src/impl/Kokkos_Atomic_Compare_Exchange_Strong.hpp
+++ b/packages/kokkos/core/src/impl/Kokkos_Atomic_Compare_Exchange_Strong.hpp
@@ -136,6 +136,24 @@
const unsigned long val )
 { return __sync_val_compare_and_swap(dest,compare,val); }
 
+KOKKOS_INLINE_FUNCTION
+unsigned long long atomic_compare_exchange( volatile unsigned long long * const dest ,
+   const unsigned long long compare ,
+   const unsigned long long val )
+{ return __sync_val_compare_and_swap(dest,compare,val); }
+
+KOKKOS_INLINE_FUNCTION
+double atomic_compare_exchange( volatile double * const dest ,
+   const double compare ,
+   const double val )
+{ return atomic_compare_exchange(dest,compare,val); }
+
+KOKKOS_INLINE_FUNCTION
+long long atomic_compare_exchange( volatile long long * const dest ,
+   const long long compare ,
+   const long long val )
+{ return __sync_val_compare_and_swap(dest,compare,val); }
+
 #endif
 
 template < typename T >
--- a/packages/kokkos/core/src/impl/Kokkos_Atomic_Fetch_Add.hpp
+++ b/packages/kokkos/core/src/impl/Kokkos_Atomic_Fetch_Add.hpp
@@ -172,6 +172,18 @@
 unsigned long int atomic_fetch_add( volatile unsigned long int * const dest , const unsigned long int val )
 { return __sync_fetch_and_add(dest,val); }
 
+KOKKOS_INLINE_FUNCTION
+double atomic_fetch_add( volatile double * const dest , const double val )
+{ return atomic_fetch_add(dest,val); }
+
+KOKKOS_INLINE_FUNCTION
+unsigned long long int atomic_fetch_add( volatile unsigned long long int * const dest , const unsigned long long int val )
+{ return __sync_fetch_and_add(dest,val); }
+
+KOKKOS_INLINE_FUNCTION
+long long int atomic_fetch_add( volatile long long int * const dest , const long long int val )
+{ return __sync_fetch_and_add(dest,val); }
+
 #endif
 
 template < typename T >
--- a/packages/kokkos/core/src/impl/Kokkos_Atomic_Exchange.hpp
+++ b/packages/kokkos/core/src/impl/Kokkos_Atomic_Exchange.hpp
@@ -157,10 +157,10 @@
 template< typename T >
 KOKKOS_INLINE_FUNCTION
 T atomic_exchange( volatile T * const dest ,
-  typename Kokkos::Impl::enable_if< sizeof(T) == sizeof(int) || sizeof(T) == sizeof(long)
+  typename Kokkos::Impl::enable_if< sizeof(T) == sizeof(int) || sizeof(T) == sizeof(long long)
   , const T & >::type val )
 {
-  typedef typename Kokkos::Impl::if_c< sizeof(T) == sizeof(int) , int , long >::type type ;
+  typedef typename Kokkos::Impl::if_c< sizeof(T) == sizeof(int) , int , long long >::type type ;
 
   const type v = *((type*)); // Extract to be sure the value doesn't change
 
@@ -237,10 +237,10 @@
 template< typename T >
 KOKKOS_INLINE_FUNCTION
 void atomic_assign( volatile T * const dest ,
-  typename Kokkos::Impl::enable_if< sizeof(T) == sizeof(int) || sizeof(T) == sizeof(long)
+  typename Kokkos::Impl::enable_if< sizeof(T) == sizeof(int) || sizeof(T) == sizeof(long long)
   , const T & >::type val )
 {
-  typedef typename Kokkos::Impl::if_c< sizeof(T) == sizeof(int) , int , long >::type type ;
+  typedef typename Kokkos::Impl::if_c< sizeof(T) == sizeof(int) , int , long long >::type type ;
 
   const type v = *((type*)); // Extract to be su

Bug#260511: inventor: ivview/SoXtExaminerViewer popup menu only comes up once

2016-07-22 Thread Graham Inggs
Hi Maintainer

This problem should have gone away in 2.1.5-10-17 when we switched
from lesstif2 to motif.

Regards
Graham

-- 
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#830681: trilinos-all-dev: Updating binutils breaks trilinos

2016-07-18 Thread Graham Inggs
On 18 July 2016 at 18:53, Nico Schlömer  wrote:
> @Graham, would you like to upload?

Sure, will do tomorrow.

-- 
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#820450: yade: FTBFS with glibc 2.23: 'isnan' was not declared in this scope

2016-05-22 Thread Graham Inggs
Control: reopen -1
Control: notfixed -1 1.20.0-9

Hi Anton

It seems Gert's patch was included in 1.20.0-9, but with my name on it.

1.20.0-9 FTBFS on the Ubuntu buildds with the following error:

In file included from
/«PKGBUILDDIR»/lib/triangulation/FlowBoundingSphere.hpp:170:0,
 from
/«PKGBUILDDIR»/debian/build/pkg/pfv/FlowEngine_FlowEngineT.hpp:39,
 from /«PKGBUILDDIR»/pkg/dem/TriaxialStressController.cpp:22:
/«PKGBUILDDIR»/lib/triangulation/FlowBoundingSphere.ipp: In member
function ‘virtual void
CGT::FlowBoundingSphere<_Tesselation>::gaussSeidel(CGT::Real)’:
/«PKGBUILDDIR»/lib/triangulation/FlowBoundingSphere.ipp:898:20: error:
there are no arguments to ‘isinf’ that depend on a template parameter,
so a declaration of ‘isinf’ must be available [-fpermissive]
if ( isinf(m) && j<10 ) cout << "(cell->info().kNorm())[j2] =
" << (cell->info().kNorm())[j2] << " cell->neighbor(j2)->info().p() =
" << cell->neighbor(j2)->info().p() << endl;
^

Reverting to the patch I uploaded with 1.20.0-8ubuntu1, and the same
as I attached to this bug, fixed the build.

Regards
Graham

-- 
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#824541: gmsh: please enable MPI again for architectures where possible

2016-05-17 Thread Graham Inggs

Source: gmsh
Version: 2.12.0+dfsg1-2
Severity: wishlist

Hi Maintainer

In gmsh 2.5.1~beta2~svn12143~dfsg-2, MPI was disabled for certain 
architectures with the following line in debian/changelog:


  * [97cda71] Disable MPI on armel, armhf, kfreebsd-amd64, kfreebsd-i386,
  mips and mipsel. Hopefully will fix FTBFS on those platforms.

In Ubuntu, MPI was enabled again in 2.8.3+dfsg-4ubuntu1 on December 23, 
2013 and they have been carrying the delta ever since.
A recent gmsh armfh build log from Ubuntu can be found here [1]. Please 
consider enabling MPI again, at least for armhf, but possibly for the 
other architectures as well.


Another wishlist item, which I don't feel is worth a separate bug 
report; 'OMPI_MCA_orte_rsh_agent' has been deprecated and should be 
changed to 'OMPI_MCA_plm_rsh_agent' in debian/rules.


Regards
Graham


[1] 
https://launchpad.net/ubuntu/+source/gmsh/2.12.0+dfsg1-2ubuntu1/+build/9747324


--
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#818814: mlpack: FTBFS with libc 2.23: there are no arguments to 'isnan' that depend on a template parameter

2016-05-10 Thread Graham Inggs

Control: tags -1 patch

Hi Maintainer

Please find a patch for this issue, as applied in Ubuntu.

Regards
Graham

Description: Fix build with glibc 2.23
Bug: https://github.com/mlpack/mlpack/issues/522
Bug-Debian: https://bugs.debian.org/818814
Origin: upstream, https://github.com/mlpack/mlpack/commit/c751e61c8e37360c93b664597c189fb984f32de2
Author: Ryan Curtin 
Last-Update: 2016-02-16
--- a/src/mlpack/methods/kmeans/kmeans_impl.hpp
+++ b/src/mlpack/methods/kmeans/kmeans_impl.hpp
@@ -175,7 +175,7 @@
 iteration++;
 Log::Info << "KMeans::Cluster(): iteration " << iteration << ", residual "
 << cNorm << ".\n";
-if (isnan(cNorm) || isinf(cNorm))
+if (std::isnan(cNorm) || std::isinf(cNorm))
   cNorm = 1e-4; // Keep iterating.
 
   } while (cNorm > 1e-5 && iteration != maxIterations);
-- 
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#823839: oce: please rebuild against freeimage 3.17.0

2016-05-09 Thread Graham Inggs

Source: oce
Version: 0.17.1-1
Severity: serious


Hi Maintainer

OCE needs to be rebuilt against the current version of freeimage in 
order to pick up the correct library paths in shipped CMake files.
For example, 
/usr/lib/x86_64-linux-gnu/oce-0.16/OCE04_VisualizationTargets-relwithdebinfo.cmake 
contains /usr/lib/libfreeimage.s instead of 
/usr/lib/x86_64-linux-gnu/libfreeimage.so.  Please refer to Ubuntu bug 
LP: #1556680 [1].  This causes at least FreeCAD to FTBFS.


In addition, the Build-Depends on libfreeimage-dev needs to be changed 
to libfreeimageplus-dev, otherwise OCE builds without freeimage 
support.  This can be confirmed by searching for '-DHAVE_FREEIMAGE' in 
the build logs.  If it is not present, freeimage support is missing.


Lastly, some files are shipped in /usr/lib/*/oce-0.16 and some in 
/usr/lib/*/oce-0.17.

Is this correct?  Please refer to Ubuntu bug LP: #1556685 [2].

Regards
Graham


[1] https://bugs.launchpad.net/bugs/1556680
[2] https://bugs.launchpad.net/bugs/1556685

--
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#823816: freecad: New upstream version available

2016-05-09 Thread Graham Inggs

Source: freecad
Version: 0.15.4671+dfsg1-4
Severity: wishlist

Hi Maintainer

A new upstream version 0.16 of FreeCAD is now available [1].
FreeCAD's page on sourceforge now displays the following:

WARNING: FreeCAD has moved!

FreeCAD code and release files are now hosted on github at 
https://github.com/FreeCAD/FreeCAD


Only older files and code are available here.


Regards
Graham


[1] https://github.com/FreeCAD/FreeCAD/releases

--
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 - broken openmpi breaks petsc build

2016-04-22 Thread Graham Inggs
On 21 April 2016 at 17:19, Graham Inggs <gin...@debian.org> wrote:
> This sounds a lot like the problem we have with powerpc, see bug #814183.  I
> think you may just have been very lucky in which powerpc buildds petsc has
> landed on lately.

Your luck ran out, the build failed on powerpc [1].
It stopped responding just after:
C/C++ example src/snes/examples/tutorials/ex19 run successfully with 1
MPI process
...and was terminated after 150 minutes of inactivity.


[1] 
https://buildd.debian.org/status/fetch.php?pkg=petsc=powerpc=3.6.3.dfsg2-4.1=1461340655

-- 
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#820450: yade: FTBFS with glibc 2.23: 'isnan' was not declared in this scope

2016-04-08 Thread Graham Inggs

Source: yade
Version: 1.20.0-7

Hi Maintainer

Yade FTBFS with glibc 2.23 available in Experimental and Ubuntu Xenial.
I was able to get yade to build in Ubuntu with the attached patch.

There are other occurrences of 'isnan' and 'isinf' inside #ifdefs that I 
did not replace.
I don't know if it would be better to just search & replace inside all 
files, or whether there is a simpler way to fix this.


Regards
Graham


[1] 
https://launchpad.net/ubuntu/+archive/test-rebuild-20160401/+build/9526535/+files/buildlog_ubuntu-xenial-amd64.yade_1.20.0-7_BUILDING.txt.gz


--- a/gui/qt5/GLViewer.cpp
+++ b/gui/qt5/GLViewer.cpp
@@ -350,7 +350,7 @@
 	if(not(rb->bound)){ rb->updateBound();}
 	
 	min=rb->bound->min; max=rb->bound->max;
-	bool hasNan=(isnan(min[0])||isnan(min[1])||isnan(min[2])||isnan(max[0])||isnan(max[1])||isnan(max[2]));
+	bool hasNan=(std::isnan(min[0])||std::isnan(min[1])||std::isnan(min[2])||std::isnan(max[0])||std::isnan(max[1])||std::isnan(max[2]));
 	Real minDim=std::min(max[0]-min[0],std::min(max[1]-min[1],max[2]-min[2]));
 	if(minDim<=0 || hasNan){
 		// Aabb is not yet calculated...
@@ -362,7 +362,7 @@
 			max=max.cwiseMax(b->state->pos);
 			min=min.cwiseMin(b->state->pos);
 		}
-		if(isinf(min[0])||isinf(min[1])||isinf(min[2])||isinf(max[0])||isinf(max[1])||isinf(max[2])){ LOG_DEBUG("No min/max computed from bodies either, setting cube (-1,-1,-1)×(1,1,1)"); min=-Vector3r::Ones(); max=Vector3r::Ones(); }
+		if(std::isinf(min[0])||std::isinf(min[1])||std::isinf(min[2])||std::isinf(max[0])||std::isinf(max[1])||std::isinf(max[2])){ LOG_DEBUG("No min/max computed from bodies either, setting cube (-1,-1,-1)×(1,1,1)"); min=-Vector3r::Ones(); max=Vector3r::Ones(); }
 	} else {LOG_DEBUG("Using scene's Aabb");}
 
 	LOG_DEBUG("Got scene box min="<0) return;
 radiusScale=weakScale;
--- a/pkg/common/InsertionSortCollider.cpp
+++ b/pkg/common/InsertionSortCollider.cpp
@@ -241,9 +241,9 @@
 if(!s) continue;
 minR=min(s->radius,minR);
 			}
-			if (isinf(minR)) LOG_ERROR("verletDist is set to 0 because no spheres were found. It will result in suboptimal performances, consider setting a positive verletDist in your script.");
+			if (std::isinf(minR)) LOG_ERROR("verletDist is set to 0 because no spheres were 

Bug#820448: paraview-dev not installable

2016-04-08 Thread Graham Inggs

Source: paraview
Version: 5.0.1+dfsg1-2

Hi Maintainer

I found a typo in the dependencies of paraview-dev that make it not 
installable.

Please see attached patch.

Regards
Graham

diff -Nru paraview-5.0.1+dfsg1/debian/changelog paraview-5.0.1+dfsg1/debian/changelog
--- paraview-5.0.1+dfsg1/debian/control	2016-04-07 15:10:45.0 +0200
+++ paraview-5.0.1+dfsg1/debian/control	2016-04-08 17:06:05.0 +0200
@@ -98,7 +98,7 @@
 Package: paraview-dev
 Architecture: any
 Section: libdevel
-Depends: qtbase5-dev-tool,
+Depends: qtbase5-dev-tools,
  ${shlibs:Depends},
  ${misc:Depends},
  paraview (= ${binary:Version}),
-- 
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#811731: dx: FTBFS with GCC 6: narrowing conversion

2016-02-20 Thread Graham Inggs
Control: tags -1 pending

Fixed in git [1].


[1] 
https://anonscm.debian.org/cgit/debian-science/packages/dx.git/commit/?id=299356490270bd744f16b9cea66251bbcb32969f

-- 
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#813248: libdx4-dev: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

2016-02-19 Thread Graham Inggs
Control: tags -1 pending

Fixed in git [1].


[1] 
https://anonscm.debian.org/cgit/debian-science/packages/dx.git/commit/?id=b15ad29a500f254fe2638347c9802bae4c9e434a

-- 
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#814149: add alternative for /usr/bin/dx

2016-02-10 Thread Graham Inggs
Hi Hans-Christoph

On 8 February 2016 at 21:25, Hans-Christoph Steiner  wrote:
> We have just packaged the "Dalvik Explorer" aka android-platform-dalvik
> which is always used as the command util 'dx'.

Always?  IBM's DX has been around since 1991. :)

> This conflicts with
> OpenDX's /usr/bin/dx, so I propose that OpenDX support /usr/bin/dx using
> the 'alternatives' system.

I don't believe the 'alternatives' system is the way to solve this.

From:
"The Debian alternatives system creates a way for several programs
that fulfill the same or similar functions to be listed as alternative
implementations that are installed simultaneously but with one
particular implementation designated as the default."

Clearly Dalvik Explorer's /usr/bin/dx and OpenDX's /usr/bin/dx do not
fulfil the same or similar functions.

I'm CC-ing the Debian Science list as I am sure similar situations
have been resolved in the past, and hopefully someone will suggest
possible solutions.

Regards
Graham


[1] http://www.opendx.org/about.html
[2] https://wiki.debian.org/DebianAlternatives

-- 
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#767338: vtk6: autopkgtest fails on unexpected warning

2016-02-06 Thread Graham Inggs
Hi Anton

What happened to this fix?

I've just merged vtk6 6.2.0+dfsg1-7 into Ubuntu and had to add it again.

Regards
Graham

-- 
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#811223: FTBFS: perl texi2html: Can't use 'defined(@array)'

2016-02-05 Thread Graham Inggs
Control: tags -1 patch

The attached patch was applied in Ubuntu.
Description: Fix texi2html for Perl 5.22
 Fixes FTBFS for arch:all - Can't use 'defined(@array)'
Bug-Debian: https://bugs.debian.org/811223
Author: Graham Inggs <ginggs@debian.org>
Last-Update: 2016-02-05
--- a/doc/texi2html
+++ b/doc/texi2html
@@ -1526,7 +1526,7 @@
 $level--; # here we start at 0
 if ($name =~ /^appendix/) {
 	# appendix style
-	if (defined(@appendix_sec_num)) {
+	if (@appendix_sec_num) {
 	_sec_num($level, @appendix_sec_num);
 	} else {
 	@appendix_sec_num = ('A', 0, 0, 0);
@@ -1534,7 +1534,7 @@
 	return(join('.', @appendix_sec_num[0..$level]));
 } else {
 	# normal style
-	if (defined(@normal_sec_num)) {
+	if (@normal_sec_num) {
 	_sec_num($level, @normal_sec_num);
 	} else {
 	@normal_sec_num = (1, 0, 0, 0);
-- 
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#805193: aster: FTBFS: Fatal Error: finclude/petscsys.h: No such file or directory

2016-01-29 Thread Graham Inggs

Control: tags -1 pending

I've committed the fix to git and will upload once libopenmpi1.10 is 
available (see #813042).


--
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#805193: aster: FTBFS: Fatal Error: finclude/petscsys.h: No such file or directory

2016-01-24 Thread Graham Inggs
Hi Peter

On 13 December 2015 at 01:17, peter green  wrote:
> On 12/12/15 19:01, peter green wrote:
>>
>>
>> New debdiff attatched, still no intent to NMU.
>
> Sorry, debdiff at
> http://debdiffs.raspbian.org/main/a/aster/aster_11.5.0%2bdfsg2-3%2brpi1.debdiff

Thanks for your work on this!

If there are no objections, I'll do a team upload in a couple of days.

Regards
Graham

-- 
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#809708: suitesparse: please lower libatlas-doc recommends to suggests

2016-01-03 Thread Graham Inggs
Source: suitesparse
Version: 1:4.4.5-2
Severity: wishlist
Tags: patch

Hi Maintainer

Please consider lowering libsuitesparse-doc's Recommends on
libatlas-doc to a Suggests, as per the attached patch.

This will allow the suitesparse package to automatically synchronize
into Ubuntu in future.

The reason for this delta in Ubuntu's suitesparse package is that it
is in Ubuntu's 'main' component and libatlas-doc is in Ubuntu's
'universe' component, and packages in 'main' cannot depend on or
recommend packages in 'universe'.

Regards
Graham


suitesparse_libatlas-doc.patch
Description: application/empty
-- 
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#806469: Parallel build FTBFS on amd64 in Ubuntu

2015-11-27 Thread Graham Inggs
Source: eigen3
Version: 3.3~alpha1-2
Severity: wishlist
Tags: patch

Hi Maintainer

Similar to #805032 [1], I've had to disable parallel builds in order
to get eigen3 to build on amd64 in Ubuntu.

Please consider including the following patch along with your next
upload so that eigen3 may be automatically sync'd in future.


Regards
Graham


[1] https://bugs.debian.org/805032
--- a/debian/rules
+++ b/debian/rules
@@ -2,15 +2,10 @@
 BUILDDIR = $(CURDIR)/debian/build
 
 %:
-   dh $@ --buildsystem=cmake --builddirectory=$(BUILDDIR) --parallel
+   dh $@ --buildsystem=cmake --builddirectory=$(BUILDDIR)
 
 export DEB_BUILD_MAINT_OPTIONS := hardening=+all
 
-ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
-   NUMJOBS = $(patsubst parallel=%,%,$(filter 
parallel=%,$(DEB_BUILD_OPTIONS)))
-   MAKEFLAGS += -j$(NUMJOBS)
-endif
-
 sse_archs = amd64 i386 kfreebsd-amd64 kfreebsd-i386
 
 extra_flags += -DDART_TESTING_TIMEOUT=300
-- 
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: normaliz_3.0.0+ds-2_amd64.changes REJECTED

2015-11-21 Thread Graham Inggs
On 22 November 2015 at 07:04, Jerome BENOIT  wrote:
> I have just done the dirty manoeuvre and some checks:
> it should be ok now.

It looks OK to me.  Shall I go ahead and upload?

-- 
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: normaliz_3.0.0+ds-2_amd64.changes REJECTED

2015-11-21 Thread Graham Inggs
On 20 November 2015 at 14:06, Jerome BENOIT  wrote:
> It appears that the faulty one is the one in the archive, if it makes sense 
> to say so.
> For a least two reasons:
> 1] ` ./debian/rules get-orig-source ' gives the one in the git;
> 2] the one in the archive is certainly derive from the git itself.
>
> Do I miss something here ?
> What is the best way to fix this ?

I've just run your get-orig-source rule and ended up with a 3rd
version of the orig.tar.xz.
I guess re-compressing with uscan is not reproducible (yet?).

So yes, the faulty one is in the archive.  The uploader of your
package should have used 'pristine-tar checkout' instead of running
the get-orig-source rule.

Unless there is something wrong with the version in the archive (have
you compared the files?), I suggest deleting
normaliz_3.0.0+ds.orig.tar.xz.id and
normaliz_3.0.0+ds.orig.tar.xz.delta from the pristine-tar branch and
running 'gbp import-orig' on the version that in the archive.

-- 
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#805032: Parallel builds FTBFS on amd64 and ppc64el in Ubuntu

2015-11-13 Thread Graham Inggs

Source: yade
Version: 1.20.0-5
Severity: wishlist
Tags: patch


Hi Maintainer

I disabled parallel builds of yade for all architectures in Ubuntu, as 
per the attached patch.

It has fixed the FTBFS on amd64 and ppc64el there.

Please consider doing the same so that yade may be sync'd automatically 
in future.


Regards
Graham

--- yade-1.20.0/debian/rules	2015-10-26 16:57:35.0 +
+++ yade-1.20.0/debian/rules	2015-11-12 14:50:20.0 +
@@ -3,13 +3,8 @@
 tmpInstall = $(CURDIR)/debian/tmp
 tmpDirMatplotLib = $(CURDIR)/debian/matplotlib
 
-ifneq (,$(filter $(DEB_HOST_ARCH), arm64))
 %:
 	dh $@ --builddirectory=$(BUILDDIR) --with python2
-else
-%:
-	dh $@ --builddirectory=$(BUILDDIR) --with python2 --parallel
-endif
 
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed,-no-keep-memory
 
-- 
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#801117: 4ti2: libzsolve.so is underlinked

2015-10-06 Thread Graham Inggs

Source: 4ti2
Version: 1.6.2+ds1-1
Tags: patch


Hi Maintainer

While investigating a FTBFS in Ubuntu [1], I found the following lines 
in the build logs of 4ti2:


dpkg-shlibdeps: warning: 
debian/4ti2/usr/lib/i386-linux-gnu/4ti2/lib/libzsolve.so contains an 
unresolvable reference to symbol __gmpz_init_set_ui: it's probably a plugin
dpkg-shlibdeps: warning: 22 other similar warnings have been skipped 
(use -v to see them all)


The attached patch links libzsolve.so with libgmpxx and libgmp and 
allowed 4ti2 to build on all architectures in Ubuntu [2].


Regards
Graham


[1] https://launchpad.net/ubuntu/+source/4ti2/1.6.2+ds1-1
[2] https://launchpad.net/ubuntu/+source/4ti2/1.6.2+ds1-1ubuntu1

Description: fix underlinking of libzsolve.so
 This fixes a FTBFS in Ubuntu with the following errors:
 ../../../src/zsolve/.libs/libzsolve.so: undefined reference to
 `operator<<(std::ostream&, __mpz_struct const*)'
 ../../../src/zsolve/.libs/libzsolve.so: undefined reference to
 `operator>>(std::istream&, __mpz_struct*)'
Author: Graham Inggs <gra...@nerve.org.za>
Last-Update: 2015-10-05
--- a/src/zsolve/Makefile.am
+++ b/src/zsolve/Makefile.am
@@ -91,7 +91,7 @@
 # Link in the "common" 4ti2 functions.
 # -no-undefined declares that no undefined symbols will remain after linking all these libraries.
 # (This is necessary to build shared libraries on Cygwin.)
-libzsolve_la_LDFLAGS = -L../4ti2 -R$(pkgliblibdir) -l4ti2common -no-undefined -avoid-version
+libzsolve_la_LDFLAGS = -L../4ti2 -R$(pkgliblibdir) -l4ti2common -lgmpxx -lgmp -no-undefined -avoid-version
 
 bin_SCRIPTS = 4ti2-hilbert 4ti2-graver
 DISTCLEANFILES = $(bin_SCRIPTS)
-- 
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#790196: [Debichem-devel] Please help porting rasmol to latest vte (Was: Bug#790196: rasmol: depends on vte which is deprecated)

2015-07-04 Thread Graham Inggs
Hi Andreas

I'll have a look when I get a chance, possibly at debcamp next month.

On 3 July 2015 at 21:24, Andreas Tille andr...@an3as.eu wrote:
 I had a look into the said issue but failed with

 ...
 No package 'vte' found
 Package vte was not found in the pkg-config search path.
 Perhaps you should add the directory containing `vte.pc'
 to the PKG_CONFIG_PATH environment variable
 No package 'vte' found

I had a look at the file listings of the -dev packages [1][2], and
vte.pc is now named vte-2.91.pc.

Regards
Graham

[1] https://packages.debian.org/sid/amd64/libvte-dev/filelist
[2] https://packages.debian.org/sid/amd64/libvte-2.91-dev/filelist

-- 
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#763909: Bug#767919: unblock: viewmol/2.4.1-21

2014-11-05 Thread Graham Inggs

On 05/11/2014 11:40, Andreas Tille wrote:

To bad that we stumbled to late about this problem to block the way more
simple solution sith source format and debhelper. :-)


Yeah, that would have been simpler.
Running configure in the build-arch target instead of the build target 
seems to have done the trick.


I attach a debdiff against 2.4.1-21 which pre-applies 
debian/patches/150-getmachine_multiarch.patch and modifies the 
build-arch target in debian/rules.
It also includes the minor changes from 
git://anonscm.debian.org/debian-science/packages/viewmol.git.
Please feel free to modify the changelog as you see fit (or anything 
else, for that matter).


diff -u viewmol-2.4.1/debian/changelog viewmol-2.4.1/debian/changelog
--- viewmol-2.4.1/debian/changelog
+++ viewmol-2.4.1/debian/changelog
@@ -1,3 +1,17 @@
+viewmol (2.4.1-22) unstable; urgency=medium
+
+  [ Andreas Tille ]
+  * Team upload.
+  * Add debian/gbp.conf
+  * Add Homepage and Vcs fields
+
+  [ Graham Inggs ]
+  * Pre-apply debian/patches/150-getmachine_multiarch.patch.
+  * Update debian/rules: configure during the build-arch target.
+Closes: #763909
+
+ -- Graham Inggs gra...@nerve.org.za  Wed, 05 Nov 2014 11:59:03 +0200
+
 viewmol (2.4.1-21) unstable; urgency=medium
 
   * Team upload.
diff -u viewmol-2.4.1/debian/control viewmol-2.4.1/debian/control
--- viewmol-2.4.1/debian/control
+++ viewmol-2.4.1/debian/control
@@ -5,6 +5,9 @@
 Uploaders: Drew Parsons dpars...@debian.org
 Build-Depends: debhelper (= 5.0.37.2), quilt, libtiff5-dev, libpng-dev, 
zlib1g-dev, libglu1-mesa-dev | libglu-dev, libgl1-mesa-dev | libgl-dev, 
libmotif-dev, libxmu-dev, libxi-dev, libxext-dev, libxt-dev, libx11-dev, 
python-dev, python-support (= 0.3)
 Standards-Version: 3.9.4
+Homepage: http://viewmol.sourceforge.net/
+Vcs-Browser: 
https://anonscm.debian.org/cgit/debian-science/packages/viewmol.git
+Vcs-Git: git://anonscm.debian.org/debian-science/packages/viewmol.git
 
 Package: viewmol
 Architecture: any
diff -u viewmol-2.4.1/debian/patches/series viewmol-2.4.1/debian/patches/series
--- viewmol-2.4.1/debian/patches/series
+++ viewmol-2.4.1/debian/patches/series
@@ -8 +8 @@
-150-getmachine_multiarch.patch
+#150-getmachine_multiarch.patch  # already applied pre-quilt
diff -u viewmol-2.4.1/debian/rules viewmol-2.4.1/debian/rules
--- viewmol-2.4.1/debian/rules
+++ viewmol-2.4.1/debian/rules
@@ -19,8 +19,8 @@
# Add here commands to configure the package.
touch configure-stamp
 
-build: configure build-arch build-indep
-build-arch: build-stamp
+build: build-arch build-indep
+build-arch: configure build-stamp
 build-indep: build-stamp
 build-stamp:
dh_testdir
diff -u viewmol-2.4.1/source/getmachine viewmol-2.4.1/source/getmachine
--- viewmol-2.4.1/source/getmachine
+++ viewmol-2.4.1/source/getmachine
@@ -84,9 +84,9 @@
   hint=1
 
   # TIFF library
-  if [ -f /usr/lib/libtiff.a ]
+  if [ -f /usr/lib/$DEB_HOST_MULTIARCH/libtiff.a ]
   then
-libtiff=-L/usr/lib
+libtiff=-L/usr/lib/$DEB_HOST_MULTIARCH
   elif [ -f /usr/local/lib/libtiff.a ]
   then
 libtiff=-L/usr/local/lib
@@ -102,12 +102,12 @@
   echo LIBTIFF = ${libtiff}  .config.$os
 
   # TIFF include file
-  if [ -f /usr/include/tiff.h ]
+  if [ -f /usr/include/$DEB_HOST_MULTIARCH/tiff.h ]
   then
 case $os in
   CYGWIN*) tiffinclude=.
;;
-  *)   tiffinclude=/usr/include
+  *)   tiffinclude=/usr/include/$DEB_HOST_MULTIARCH
;;
 esac
   elif [ -f /usr/local/include/tiff.h ]
@@ -121,9 +121,9 @@
   echo TIFFINCLUDE = $tiffinclude  .config.$os
 
   # PNG library
-  if [ -f /usr/lib/libpng.a -o -f /usr/lib/libpng12.a ]
+  if [ -f /usr/lib/$DEB_HOST_MULTIARCH/libpng.a -o -f 
/usr/lib/$DEB_HOST_MULTIARCH/libpng12.a ]
   then
-libpng=-L/usr/lib
+libpng=-L/usr/lib/$DEB_HOST_MULTIARCH
   elif [ -f /usr/local/lib/libpng.a ]
   then
 libpng=-L/usr/local/lib
only in patch2:
unchanged:
--- viewmol-2.4.1.orig/debian/gbp.conf
+++ viewmol-2.4.1/debian/gbp.conf
@@ -0,0 +1,3 @@
+[DEFAULT]
+upstream-branch = upstream
+debian-branch = debian-unstable
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

  1   2   >