Bug#877419: pandas FTBFS on !x86/ppc64el: test failures
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
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
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
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
-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
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
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 ...
Hi Pierre (cc-ing Andreas in case he is not subscribed) On 12 December 2017 at 15:13, Pierre Saramitowrote: > 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
Hi Frédéric On 7 December 2017 at 19:00, Frédéric Bonnardwrote: > 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
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
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
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
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
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
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 Gladkywrote: > 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
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
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)
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
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
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
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
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
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
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
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
On 23 July 2017 at 18:07, Nico Schlömerwrote: > 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
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
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
On 16 July 2017 at 20:40, Nico Schlömerwrote: > 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
On 16 July 2017 at 13:12, Drew Parsonswrote: > 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
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
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
On 8 June 2017 at 19:53, Michael Hudson-Doylewrote: > 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()
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()
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
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
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
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
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
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 ?
On 19 May 2017 at 14:55, Theodore Lytraswrote: > 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
Control: severity -1 wishlist On 19 April 2017 at 09:14, Lucas Nussbaumwrote: >> 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
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
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?)
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
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)
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)
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)
On 5 January 2017 at 13:46, Ansgar Burchardtwrote: > 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)
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
Hi Arto On 23 December 2016 at 14:59, Arto Jantunenwrote: > 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
On 9 December 2016 at 09:49, Nico Schlömerwrote: > 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
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
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)
On 29 November 2016 at 00:29, Breno Leitaowrote: > 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
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
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
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
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
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
On 25 October 2016 at 17:32, Anton Gladkywrote: > 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
On 24 October 2016 at 21:46, Anton Gladkywrote: > 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
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
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
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. Uckowrote: > 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
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
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
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
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
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
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/
Hi Peter On 2 September 2016 at 23:15, Peter Greenwrote: > 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
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
On 29 August 2016 at 21:55, Nico Schlömerwrote: > 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
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
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
On 18 July 2016 at 18:53, Nico Schlömerwrote: > @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
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
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
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 CurtinLast-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
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
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
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
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
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
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
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
Hi Hans-Christoph On 8 February 2016 at 21:25, Hans-Christoph Steinerwrote: > 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
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)'
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
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
Hi Peter On 13 December 2015 at 01:17, peter greenwrote: > 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
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
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
On 22 November 2015 at 07:04, Jerome BENOITwrote: > 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
On 20 November 2015 at 14:06, Jerome BENOITwrote: > 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
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
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)
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
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