Bug#895419: Acknowledgement (python3-dolfin: JIT compilation fails as python3-instant tries to includes petsc4py from python2)
I've had that issue in the past, but never bothered looking into it. Me, I'll hold out for 2018.1 (which kills Python 2 support) to fix these kind of bugs. Cheers, Nico On Fri, Apr 13, 2018 at 4:54 PM Fabrice Silvawrote: > Additional information from Johannes Ring (fenics dev) on > https://groups.google.com/d/topic/fenics-support/mfJdWYwq0-w/discussion > >The problem is that the path to petsc4py is included in >/usr/share/dolfin/cmake/DOLFINConfig.cmake and >/usr/share/dolfin/cmake/DOLFINTargets.cmake, while it should only >have been included in /usr/share/dolfin/cmake/DOLFINPython27.cmake >and /usr/share/dolfin/cmake/DOLFINPython36.cmake. > >The quick fix would be to either install python-petsc4py (the >petsc4py include files are the same for python2 and python3) or to >remove the path to petsc4py from DOLFINConfig.cmake and >DOLFINTargets.cmake. > > These recommendations solve the trouble (even if other errors are still > raised in the overly-simplified script). > > -- 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: vtk7_7.1.1+dfsg1-1~exp1_amd64.changes REJECTED
Whoop whoop! Thanks everyone! [1] https://packages.debian.org/experimental/libvtk7-dev On Tue, Apr 3, 2018 at 11:55 PM Chris Lambwrote: > Hi Gert et al., > > Thanks again for re-uploading; I have just ACCEPTed it. > > > [I] replicated here what I did, kind of to acknowledge the review and > > the changes it required (a habit from scinetific paper reviews, nothing > > more) > > Thanks! I was mostly making sure for next time; it is a good habit > to be applauded. > > > Best wishes, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org / chris-lamb.co.uk >`- > -- 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: vtk7_7.1.1+dfsg1-1~exp1_amd64.changes REJECTED
Wait, VTK7 is no longer in NEW [1]. Does anyone know what happened? Cheers, Nico [1] https://ftp-master.debian.org/new.html On Wed, Mar 7, 2018 at 1:28 PM Gert Wollny <gw.foss...@gmail.com> wrote: > Am Dienstag, den 06.03.2018, 21:37 + schrieb Nico Schlömer: > > Perhaps it's time to bring this up again. At six months in the queue, > > VTK7 has been the leader in the NEW queue for a while now. It'd be > > great if we could work on this again, particularly since VTK8 is > > already out there. > > I guess we will just skip vtk8 and move to vtk9 when it comes out :/ > > Best, > Gert > > -- 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: vtk7_7.1.1+dfsg1-1~exp1_amd64.changes REJECTED
Perhaps it's time to bring this up again. At six months in the queue, VTK7 has been the leader in the NEW queue for a while now. It'd be great if we could work on this again, particularly since VTK8 is already out there. Cheers, Nico On Thu, Nov 9, 2017 at 10:56 AM Gert Wollnywrote: > Hello Luca, > > since you did the initial review of the VTK7 package (and it is a > really big one), would you consider to have another look at the updated > version soon, I ask because we would like to start porting dependent > packages. > > All the issuses you raised should be addressed by now (although what > upstream provides there is really a mess). Specifially the for last one > with no clear copyright (not even upstream knows) we removed the files > since they are not needed anyway. > > many thanks, > Gert > > Am Freitag, den 01.09.2017, 23:00 + schrieb Luca Falavigna: > > Hi, > > > > * Accelerators/Dax/* have different copyright terms than the one > > mentioned in d/copyright > > * Please mention license of the font under > > Charts/Core/Testing/Data/Fonts > > * Common/Core/CaseFolding.txt is licensed under http://www.unicode.or > > g/copyright.html > > * Examples/GUI/QT/* are copyright Sandia Corp. and have different > > licensing terms > > * Same as above applies for > > Examples/Infovis/Cxx/{CustomLinkView,EasyView,StatsView} > > * Same as above applies for Examples/Statistics/* > > * Same as above applies for > > Infovis/Layout/{vtkCosmicTreeLayoutStrategy.h,vtkTreeOrbitLayoutStrat > > egy.h} > > * Rendering/VolumeOpenGL/vtkHAVSVolumeMapper* are copyright > > University of Utah > > > > Cheers, > > Luca > > > > > > > > === > > > > Please feel free to respond to this email if you don't understand why > > your files were rejected, or if you upload new files which address > > our > > concerns. > > > -- 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#890364:
I depend on this as well. As a stop-gap measure, I've set of a PPA [1]. Cheers, Nico [1] https://launchpad.net/~nschloe/+archive/ubuntu/pybind11-backports/ -- 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 trilinos 12.12.1-5 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 05 Feb 2018 16:01:51 +0100 Source: trilinos Binary: trilinos-all-dev trilinos-dev libtrilinos-amesos12 libtrilinos-amesos-dev libtrilinos-amesos2-12 libtrilinos-amesos2-dev libtrilinos-anasazi12 libtrilinos-anasazi-dev libtrilinos-aztecoo12 libtrilinos-aztecoo-dev libtrilinos-belos12 libtrilinos-belos-dev libtrilinos-epetra12 libtrilinos-epetra-dev libtrilinos-epetraext12 libtrilinos-epetraext-dev libtrilinos-galeri12 libtrilinos-galeri-dev libtrilinos-globipack12 libtrilinos-globipack-dev libtrilinos-ifpack12 libtrilinos-ifpack-dev libtrilinos-ifpack2-12 libtrilinos-ifpack2-dev libtrilinos-intrepid12 libtrilinos-intrepid-dev libtrilinos-isorropia12 libtrilinos-isorropia-dev libtrilinos-kokkos12 libtrilinos-kokkos-dev libtrilinos-kokkos-kernels12 libtrilinos-kokkos-kernels-dev libtrilinos-komplex12 libtrilinos-komplex-dev libtrilinos-ml12 libtrilinos-ml-dev libtrilinos-moertel12 libtrilinos-moertel-dev libtrilinos-muelu12 libtrilinos-muelu-dev libtrilinos-nox12 libtrilinos-nox-dev libtrilinos-optipack12 libtrilinos-optipack-dev libtrilinos-pamgen12 libtrilinos-pamgen-dev libtrilinos-phalanx12 libtrilinos-phalanx-dev libtrilinos-pike12 libtrilinos-pike-dev libtrilinos-piro12 libtrilinos-piro-dev libtrilinos-pliris12 libtrilinos-pliris-dev libtrilinos-rol12 libtrilinos-rol-dev libtrilinos-rtop12 libtrilinos-rtop-dev libtrilinos-rythmos12 libtrilinos-rythmos-dev libtrilinos-sacado12 libtrilinos-sacado-dev libtrilinos-shards12 libtrilinos-shards-dev libtrilinos-shylu12 libtrilinos-shylu-dev libtrilinos-trilinosss12 libtrilinos-trilinosss-dev libtrilinos-stokhos12 libtrilinos-stokhos-dev libtrilinos-stratimikos12 libtrilinos-stratimikos-dev libtrilinos-teko12 libtrilinos-teko-dev libtrilinos-teuchos12 libtrilinos-teuchos-dev libtrilinos-thyra12 libtrilinos-thyra-dev libtrilinos-tpetra12 libtrilinos-tpetra-dev libtrilinos-trilinoscouplings12 libtrilinos-trilinoscouplings-dev libtrilinos-triutils12 libtrilinos-triutils-dev libtrilinos-xpetra12 libtrilinos-xpetra-dev libtrilinos-zoltan12 libtrilinos-zoltan-dev libtrilinos-zoltan2-12 libtrilinos-zoltan2-dev trilinos-doc Architecture: source Version: 12.12.1-5 Distribution: unstable Urgency: medium Maintainer: Debian Science Maintainers <debian-science-maintainers@lists.alioth.debian.org> Changed-By: Nico Schlömer <nico.schloe...@gmail.com> Description: libtrilinos-amesos-dev - direct sparse solver package - development files libtrilinos-amesos12 - direct sparse solver package - runtime files libtrilinos-amesos2-12 - next generation direct sparse solver package - runtime files libtrilinos-amesos2-dev - next generation direct sparse solver package - development files libtrilinos-anasazi-dev - large-scale eigenvalue algorithms - development files libtrilinos-anasazi12 - large-scale eigenvalue algorithms - runtime files libtrilinos-aztecoo-dev - object-oriented interface to the Aztec solver - development files libtrilinos-aztecoo12 - object-oriented interface to the Aztec solver - runtime files libtrilinos-belos-dev - iterative linear solvers - development files libtrilinos-belos12 - iterative linear solvers - runtime files libtrilinos-epetra-dev - basis package for linear algebra - development files libtrilinos-epetra12 - basis package for linear algebra - runtime files libtrilinos-epetraext-dev - extensions to the Epetra toolkit - development files libtrilinos-epetraext12 - extensions to the Epetra toolkit - runtime files libtrilinos-galeri-dev - generation of distributed linear systems - development files libtrilinos-galeri12 - generation of distributed linear systems - runtime files libtrilinos-globipack-dev - 1D globalization capabilities - development files libtrilinos-globipack12 - 1D globalization capabilities - runtime files libtrilinos-ifpack-dev - algebraic preconditioners - development files libtrilinos-ifpack12 - algebraic preconditioners - runtime files libtrilinos-ifpack2-12 - next generation algebraic preconditioners - runtime files libtrilinos-ifpack2-dev - next generation algebraic preconditioners - development files libtrilinos-intrepid-dev - compatible discretizations of PDEs - development files libtrilinos-intrepid12 - compatible discretizations of PDEs - runtime files libtrilinos-isorropia-dev - partitioning, load balancing, coloring of sparse matrices - devel libtrilinos-isorropia12 - partitioning, load balancing, coloring of sparse matrices - runti libtrilinos-kokkos-dev - Trilinos Kokkos programming model - development files libtrilinos-kokkos-kernels-dev - Kokkos local computational kernels - development files libtrilinos-kokkos-kernels12 - Kokkos local computational kernels - runtime files libtrilinos-kokkos12 - Trilinos Kokkos programming model - runtime files libtrilinos-komplex-dev - complex linear solver package - development files libtrilinos-komplex12 - complex linear so
Bug#881881: libtrilinos-kokkos-kernels-dev: fails to upgrade from 'testing' - trying to overwrite /usr/include/trilinos/Kokkos_ArithTraits.hpp
Ah, yes, these files seem to have moved from Tpetra to Kokkos. These two upstream packages are tightly related, so no surprise there. I'll see if I can get this fixed. Cheers, Nico On Thu, Nov 16, 2017 at 2:15 AM Andreas Beckmannwrote: > Package: libtrilinos-kokkos-kernels-dev > Version: 12.12.1-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package fails to upgrade from > 'testing'. > It installed fine in 'testing', then the upgrade to 'sid' fails > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation. > > See policy 7.6 at > https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces > > From the attached log (scroll to the bottom...): > > Selecting previously unselected package > libtrilinos-kokkos-kernels-dev:amd64. > Preparing to unpack > .../libtrilinos-kokkos-kernels-dev_12.12.1-1_amd64.deb ... > Unpacking libtrilinos-kokkos-kernels-dev:amd64 (12.12.1-1) ... > dpkg: error processing archive > /var/cache/apt/archives/libtrilinos-kokkos-kernels-dev_12.12.1-1_amd64.deb > (--unpack): >trying to overwrite '/usr/include/trilinos/Kokkos_ArithTraits.hpp', > which is also in package libtrilinos-tpetra-dev 12.10.1-4+b1 > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) > Errors were encountered while processing: > > /var/cache/apt/archives/libtrilinos-kokkos-kernels-dev_12.12.1-1_amd64.deb > > > cheers, > > Andreas > -- 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#881873: trilinos: FTBFS on sparc64: Bus errors in 11 tests
Chances are slim for to ever be resolved. Upstream only supports amd64, and PRs to fix building for other architectures are rejected. (See, e.g., [1].) I'd say we'll have to live with trilinos not running on sparc64. Cheers, Nico [1] https://github.com/kokkos/kokkos/pull/576 On Thu, Nov 16, 2017 at 1:21 AM Aaron M. Uckowrote: > Source: trilinos > Version: 12.10.1-4+b1 > Severity: important > Tags: upstream > Justification: fails to build from source (but built successfully in the > past) > User: debian-sp...@lists.debian.org > Usertags: sparc64 > > Builds of trilinos for sparc64 (admittedly not a release architecture) > have been failing lately with bus errors (indicating attempts to use > underaligned pointers, about which sparc64 is notoriously strict), per > the below excerpts from > > https://buildd.debian.org/status/fetch.php?pkg=trilinos=sparc64=12.12.1-1=1510746436=0 > . > > Could you please take a look? > > Thanks! > > > > [...] > 521/871 Test #521: EpetraExt_Transpose_test_LL_MPI_4 > ..***Failed2.31 sec > Epetra::MpiComm::Processor 0 of 4 total processors. > EpetraExt in Trilinos 12.12.1 > > Epetra::MpiComm::Processor 1 of 4 total processors. > Epetra::MpiComm::Processor 2 of 4 total processors. > Epetra::MpiComm::Processor 3 of 4 total processors. > [landau:24458] *** Process received signal *** > [landau:24458] Signal: Bus error (10) > [landau:24458] Signal code: Invalid address alignment (1) > [landau:24458] Failing at address: 0x15ef4bc > [landau:24459] *** Process received signal *** > [landau:24459] Signal: Bus error (10) > [landau:24459] Signal code: Invalid address alignment (1) > [landau:24459] Failing at address: 0x15eca7c > [landau:24458] *** End of error message *** > [landau:24459] *** End of error message *** > [landau:24456] *** Process received signal *** > [landau:24456] Signal: Bus error (10) > [landau:24456] Signal code: Invalid address alignment (1) > [landau:24456] Failing at address: 0x160a96c > [landau:24457] *** Process received signal *** > [landau:24457] Signal: Bus error (10) > [landau:24457] Signal code: Invalid address alignment (1) > [landau:24457] Failing at address: 0x15ef4dc > [landau:24456] *** End of error message *** > [landau:24457] *** End of error message *** > -- > mpiexec noticed that process rank 1 with PID 0 on node landau exited on > signal 10 (Bus error). > -- > [...] > The following tests FAILED: > 517 - EpetraExt_Permutation_test_LL_MPI_4 (Failed) > 521 - EpetraExt_Transpose_test_LL_MPI_4 (Failed) > 523 - EpetraExt_inout_test_LL_MPI_4 (Failed) > 525 - EpetraExt_MatrixMatrix_test_LL_MPI_4 (Failed) > 621 - AztecOO_AztecOO_test_LL_MPI_4 (Failed) > 633 - ML_AztecSimple_MPI_4 (Failed) > 636 - ML_MatrixFree_MPI_4 (Failed) > 638 - ML_ML_Operator2Epetra_RowMatrix_MPI_4 (Failed) > 639 - ML_MLP_Maxwell_MPI_4 (Failed) > 640 - ML_MLP_NonSym_MPI_4 (Failed) > 648 - Komplex_simple_MPI_4 (Failed) > Errors while running CTest > > -- > Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) > http://www.mit.edu/~amu/ | > http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu > > -- 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: gmsh update
Good job! On Thu, Oct 26, 2017 at 5:25 PM Anton Gladky <gl...@debian.org> wrote: > Hi Nico, > > I have managed to build gmsh succesfully (in experimental). Also I have > uploaded > into unstable, but we need to get an OK from FTP masters because I have > changed > the libname to libgmsh3. > > Cheers > > Anton > > > 2017-10-26 14:07 GMT+02:00 Nico Schlömer <nico.schloe...@gmail.com>: > > Hi Anton, > > > > Just returning from holidays here. I trust you managed to work around the > > issue? > > > > Btw, the next gmsh release will contain a bunch of fixes for Debian, > > hopefully we should be able to come clean in d/patches then. [1] > > > > Cheers, > > Nico > > > > [1] https://gitlab.onelab.info/nschloe > > > > On Wed, Oct 18, 2017 at 9:48 PM Anton Gladky <gl...@debian.org> wrote: > >> > >> Hi Nico, > >> > >> I have done some changes on the package. It is almost ready for the > >> upload. > >> But there is a problem with the auto_test: > >> > >> == > >> ... > >> ompi_mpi_init: ompi_rte_init failed > >> --> Returned "Unreachable" (-12) instead of "Success" (0) > >> > -- > >> *** An error occurred in MPI_Init > >> *** on a NULL communicator > >> *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort, > >> ... > >> == > >> > >> There are some more errors. I think we had some similar problems with > MPI, > >> running under the fakeroot. But I am not able to find a quick solution > >> for this issue now. > >> > >> Best regards > >> > >> Anton > >> > >> > >> 2017-09-22 19:19 GMT+02:00 Nico Schlömer <nico.schloe...@gmail.com>: > >> > Alright, thanks for the swift reply! > >> > > >> > I'll keep an eye on oce and once this is out, there's not much more to > >> > do > >> > for gmsh to be released. > >> > > >> > Cheers, > >> > Nico > >> > > >> > On Fri, Sep 22, 2017 at 7:05 PM Anton Gladky <gl...@debian.org> > wrote: > >> >> > >> >> Hi Nico, > >> >> > >> >> Yes, I know, because I am maintaining both oce and gmsh. > >> >> Oce is in experimental and requires transition process, which > >> >> is not started because not all reverse dependencies can be > >> >> built against 0.18. Hopefully will be fixed soon. > >> >> > >> >> Cheers > >> >> > >> >> Anton > >> >> > >> >> > >> >> 2017-09-22 18:50 GMT+02:00 Nico Schlömer <nico.schloe...@gmail.com>: > >> >> > Hi everyone, > >> >> > > >> >> > I did some work on Gmsh 3.* which should hopefully soon be ready > for > >> >> > prime > >> >> > time. One thing I've had to disable for now is OpenCascade support; > >> >> > Gmsh > >> >> > requires 6.9.1 which is wrapped in OCE 0.18, but the latter is > still > >> >> > only in > >> >> > experimental [1] (and has the ~exp extension, whatever that means). > >> >> > > >> >> > Does anyone know the status of oce? > >> >> > > >> >> > Cheers, > >> >> > Nico > >> >> > > >> >> > [1] https://tracker.debian.org/pkg/oce > >> >> > > >> >> > -- > >> >> > debian-science-maintainers mailing list > >> >> > debian-science-maintainers@lists.alioth.debian.org > >> >> > > >> >> > > >> >> > > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers > -- 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: gmsh update
Hi Anton, Just returning from holidays here. I trust you managed to work around the issue? Btw, the next gmsh release will contain a bunch of fixes for Debian, hopefully we should be able to come clean in d/patches then. [1] Cheers, Nico [1] https://gitlab.onelab.info/nschloe On Wed, Oct 18, 2017 at 9:48 PM Anton Gladky <gl...@debian.org> wrote: > Hi Nico, > > I have done some changes on the package. It is almost ready for the upload. > But there is a problem with the auto_test: > > == > ... > ompi_mpi_init: ompi_rte_init failed > --> Returned "Unreachable" (-12) instead of "Success" (0) > -- > *** An error occurred in MPI_Init > *** on a NULL communicator > *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort, > ... > == > > There are some more errors. I think we had some similar problems with MPI, > running under the fakeroot. But I am not able to find a quick solution > for this issue now. > > Best regards > > Anton > > > 2017-09-22 19:19 GMT+02:00 Nico Schlömer <nico.schloe...@gmail.com>: > > Alright, thanks for the swift reply! > > > > I'll keep an eye on oce and once this is out, there's not much more to do > > for gmsh to be released. > > > > Cheers, > > Nico > > > > On Fri, Sep 22, 2017 at 7:05 PM Anton Gladky <gl...@debian.org> wrote: > >> > >> Hi Nico, > >> > >> Yes, I know, because I am maintaining both oce and gmsh. > >> Oce is in experimental and requires transition process, which > >> is not started because not all reverse dependencies can be > >> built against 0.18. Hopefully will be fixed soon. > >> > >> Cheers > >> > >> Anton > >> > >> > >> 2017-09-22 18:50 GMT+02:00 Nico Schlömer <nico.schloe...@gmail.com>: > >> > Hi everyone, > >> > > >> > I did some work on Gmsh 3.* which should hopefully soon be ready for > >> > prime > >> > time. One thing I've had to disable for now is OpenCascade support; > Gmsh > >> > requires 6.9.1 which is wrapped in OCE 0.18, but the latter is still > >> > only in > >> > experimental [1] (and has the ~exp extension, whatever that means). > >> > > >> > Does anyone know the status of oce? > >> > > >> > Cheers, > >> > Nico > >> > > >> > [1] https://tracker.debian.org/pkg/oce > >> > > >> > -- > >> > debian-science-maintainers mailing list > >> > debian-science-maintainers@lists.alioth.debian.org > >> > > >> > > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers > -- 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: gmsh update
Alright, thanks for the swift reply! I'll keep an eye on oce and once this is out, there's not much more to do for gmsh to be released. Cheers, Nico On Fri, Sep 22, 2017 at 7:05 PM Anton Gladky <gl...@debian.org> wrote: > Hi Nico, > > Yes, I know, because I am maintaining both oce and gmsh. > Oce is in experimental and requires transition process, which > is not started because not all reverse dependencies can be > built against 0.18. Hopefully will be fixed soon. > > Cheers > > Anton > > > 2017-09-22 18:50 GMT+02:00 Nico Schlömer <nico.schloe...@gmail.com>: > > Hi everyone, > > > > I did some work on Gmsh 3.* which should hopefully soon be ready for > prime > > time. One thing I've had to disable for now is OpenCascade support; Gmsh > > requires 6.9.1 which is wrapped in OCE 0.18, but the latter is still > only in > > experimental [1] (and has the ~exp extension, whatever that means). > > > > Does anyone know the status of oce? > > > > Cheers, > > Nico > > > > [1] https://tracker.debian.org/pkg/oce > > > > -- > > debian-science-maintainers mailing list > > debian-science-maintainers@lists.alioth.debian.org > > > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers > -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
gmsh update
Hi everyone, I did some work on Gmsh 3.* which should hopefully soon be ready for prime time. One thing I've had to disable for now is OpenCascade support; Gmsh requires 6.9.1 which is wrapped in OCE 0.18, but the latter is still only in experimental [1] (and has the ~exp extension, whatever that means). Does anyone know the status of oce? Cheers, Nico [1] https://tracker.debian.org/pkg/oce -- 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
> I intentionally didn't close this bug because the tests still fail if they are enabled. Right. Well, I've reported the bug upstream [1] and at this point there's not much more than we can do. Unfortunately, Trilinos has a history of failing tests, the list of subpackages for which we have to disable them is long: ``` -DAmesos2_ENABLE_TESTS:BOOL=OFF \ -DAnasazi_ENABLE_TESTS:BOOL=OFF \ -DBelos_ENABLE_TESTS:BOOL=OFF \ -DDomi_ENABLE_TESTS:BOOL=OFF \ -DEpetra_ENABLE_TESTS:BOOL=OFF \ -DIfpack_ENABLE_TESTS:BOOL=OFF \ -DIsorropia_ENABLE_TESTS:BOOL=OFF \ -DMueLu_ENABLE_TESTS:BOOL=OFF \ -DNOX_ENABLE_TESTS:BOOL=OFF \ -DPhalanx_ENABLE_TESTS:BOOL=OFF \ -DPiro_ENABLE_TESTS:BOOL=OFF \ -DShyLU_ENABLE_TESTS:BOOL=OFF \ -DShyLUCore_ENABLE_TESTS:BOOL=OFF \ -DStratimikos_ENABLE_TESTS:BOOL=OFF \ -DTeko_ENABLE_TESTS:BOOL=OFF \ -DTeuchos_ENABLE_TESTS:BOOL=OFF \ -DTeuchosComm_ENABLE_TESTS:BOOL=OFF \ -DTeuchosCore_ENABLE_TESTS:BOOL=OFF \ -DXpetra_ENABLE_TESTS:BOOL=OFF \ -DZoltan_ENABLE_TESTS:BOOL=OFF \ -DZoltan2_ENABLE_TESTS:BOOL=OFF \ ``` Not all of those disables are associated with upstream bugs, unfortunately, but then again it's probably a Sisyphean task to do so. As usual for those bugs, either they are fixed immediately or never. Cheers, Nico [1] https://github.com/trilinos/Trilinos/issues/1332 On Mon, Jul 24, 2017 at 10:53 AM Graham Inggs <gin...@debian.org> wrote: > 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
Thanks, Graham, for the analysis. It appears that with 12.10.1-4 we're on top of things, so I guess this can be closed. Cheers, Nico On Sun, Jul 23, 2017 at 9:51 PM Graham Inggs <gin...@debian.org> wrote: > On 23 July 2017 at 18:07, Nico Schlömer <nico.schloe...@gmail.com> wrote: > > Hm, funny! I don't get how libtrilinos-amesos12 should depend on > > libmumps-4.10.0 when 5.1.1 is available. > > libtrilinos-amesos12/12.10.1-3 depends on libmumps-4.10.0 because > libtrilinos_amesos.so.12 is linked to libdmumps-4.10.0.so and > libmumps_common-4.10.0.so > > As per debian/control, libtrilinos-amesos-dev depends on any version > of libmumps-dev. > > The new version of MUMPS changed ABI in a backward-incompatible way, > requiring a transition in Debian and every package that was built > against libmumps-4.10.0 needed to be rebuilt against libmumps-5.1.1 to > pick up the new dependencies. See the transition bug #864650 for more > details. > > The binNMU of trilinos 12.10.1-3+b1, which was supposed to pick up the > new dependencies, failed to build from source, see: > https://buildd.debian.org/status/logs.php?pkg=trilinos=amd64 > and also bug #868523. > > > We've recently uploaded 12.10.1-4, perhaps this rebuild will solve your > > problem. > > Trilinos 12.10.1-4 was built against libmumps-5.1.1 and migrated to > testing on 2017-07-22, see: > https://packages.qa.debian.org/t/trilinos/news/20170722T043921Z.html > -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#868523: FTBFS: test failed 617 ML_MLP_NonSym_MPI_4, 668 Phalanx_dag_manager_MPI_1
> Still comes out corrupted in the gnome Archive Manager, but extracts fine on the command line. Sounds more like a gAM bug then. Can this be closed? Cheers, Nico On Mon, Jul 17, 2017 at 4:33 AM Drew Parsonswrote: > On Mon, 17 Jul 2017 10:21:03 +0800 Drew Parsons > wrote: > > > > For whatever reason, the build does not fail on the buildd (odd, my > > test ran 842 tests, buildd only runs 830). > > Ah I see, you uploaded -4 while we were testing :) > The bugserver didn't send me the bug traffic. > > > Adding my build log again, the first attachment appears corrupted. > > Still comes out corrupted in the gnome Archive Manager, but extracts > fine on the command line. > > -- 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
Hm, funny! I don't get how libtrilinos-amesos12 should depend on libmumps-4.10.0 when 5.1.1 is available. I've rebuild this on ubuntu artsy [1] and it selects all the right versions. Perhaps this got corrupted in the transition somehow? We've recently uploaded 12.10.1-4, perhaps this rebuild will solve your problem. Cheers, Nico [1] https://launchpadlibrarian.net/329863686/buildlog_ubuntu-artful-amd64.trilinos_12.11~git20170720-31a5b251-1artful1_BUILDING.txt.gz [2] https://packages.debian.org/buster/trilinos-all-dev On Sun, Jul 23, 2017 at 1:12 PM Joachim Wuttkewrote: > > I don't think it is possible for trilinos to depend on both versions. > > Of course it should not. > But it does. > > $ apt-cache show libtrilinos-amesos-dev > Package: libtrilinos-amesos-dev > Source: trilinos > Version: 12.10.1-3 > .. > Depends: libmumps-dev, libtrilinos-amesos12 (= 12.10.1-3), trilinos-dev > > $ apt-cache show libmumps-dev > Package: libmumps-dev > Source: mumps > Version: 5.1.1-2 > .. > Depends: libmumps-5.1.1 (= 5.1.1-2), libscalapack-mpi-dev, mpi-default-dev > > $ apt-cache show libtrilinos-amesos12 > Package: libtrilinos-amesos12 > Source: trilinos > Version: 12.10.1-3 > .. > Depends: libc6 (>= 2.14), libgcc1 (>= 1:3.0), libmumps-4.10.0, > libopenmpi2, libstdc++6 (>= 5.2), libtrilinos-epetra12, > libtrilinos-epetraext12, libtrilinos-teuchos12 > > -- 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#868894: find_package option COMPONENTS ineffective because of hard-coded includes in TrilinosConfig.cmake
Thanks, Joachim, for the report! This definitely sounds like an upstream bug. Would you mind reporting it on [1]? Together with the Trilinos devs, we'll be able to take it from there. That being said, at first glance the inclusion of the subpackage configs doesn't seem to override anything. I'd be interested to improve the cmake export config though. Cheers, Nico [1] https://github.com/trilinos/trilinos/issues On Sun, Jul 23, 2017 at 1:36 PM Joachim Wuttkewrote: > Package: trilinos-dev > Version: 12.10.1-3 > > CMake's find_package takes an option COMPONENTS. > Usage with Trilinos seems to be documented nowhere, > but TrilinosConfig.cmake clearly is intended to > support e.g. > find_package(Trilinos REQUIRED COMPONENTS Epetra Belos Ifpack) > > However, at the bottom of TrilinosConfig.cmake there > is a long list that includes all Trilinos subproject > CMake files. This overwrites the component selection, > and makes it ineffective: the client application will > depend on _all_ of Trilinois, not just on the selected > components. > > -- 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
I've disabled the phalanx tests in master, and also fixed two other things. Perhaps it's time for an upload? Cheers, Nico On Sun, Jul 16, 2017 at 2:16 PM Nico Schlömer <nico.schloe...@gmail.com> wrote: > The issue was reported to upstream in May [1]. I think until we get a fix, > it's best to disable that specific test. > > Cheers, > Nico > > > [1] https://github.com/trilinos/Trilinos/issues/1332 > > On Sun, Jul 16, 2017 at 1:51 PM Graham Inggs <gin...@debian.org> wrote: > >> On 16 July 2017 at 13:12, Drew Parsons <dpars...@debian.org> wrote: >> > Testing trilinos build on a porterbox for the mumps 5.1.1 transition. >> > >> > The following tests FAILED: >> > 617 - ML_MLP_NonSym_MPI_4 (Failed) >> > 668 - Phalanx_dag_manager_MPI_1 (Failed) >> > >> > Not sure if it's the new mumps, new openmpi 2.1.1 or something else. >> > Full build log attached. >> >> Reproducible build history shows FTBFS since 2017-07-02: >> https://tests.reproducible-builds.org/debian/history/amd64/trilinos.html >> >> Although with only one test failure: >> >> The following tests FAILED: >> 668 - Phalanx_dag_manager_MPI_1 (Failed) >> >> -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#868523: FTBFS: test failed 617 ML_MLP_NonSym_MPI_4, 668 Phalanx_dag_manager_MPI_1
The issue was reported to upstream in May [1]. I think until we get a fix, it's best to disable that specific test. Cheers, Nico [1] https://github.com/trilinos/Trilinos/issues/1332 On Sun, Jul 16, 2017 at 1:51 PM Graham Inggswrote: > On 16 July 2017 at 13:12, Drew Parsons wrote: > > Testing trilinos build on a porterbox for the mumps 5.1.1 transition. > > > > The following tests FAILED: > > 617 - ML_MLP_NonSym_MPI_4 (Failed) > > 668 - Phalanx_dag_manager_MPI_1 (Failed) > > > > Not sure if it's the new mumps, new openmpi 2.1.1 or something else. > > Full build log attached. > > Reproducible build history shows FTBFS since 2017-07-02: > https://tests.reproducible-builds.org/debian/history/amd64/trilinos.html > > Although with only one test failure: > > The following tests FAILED: > 668 - Phalanx_dag_manager_MPI_1 (Failed) > > -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#864779: Epetra doc missing
Let me add also that Epetra isn't that important anymore. Trilinos devs try to get people to switch over to Tpetra, and in fact Epetra hasn't seen substantial development in many years now. Cheers, Nico On Thu, Jun 15, 2017 at 5:22 PM Nico Schlömer <nico.schloe...@gmail.com> wrote: > Thanks Joachim for report. > > This is more of an upstream issue, see [1]. Once that is done, the package > will have the Epetra documentation shipped. > > Cheers, > Nico > > [1] https://github.com/trilinos/Trilinos/issues/1431 > > On Wed, Jun 14, 2017 at 6:42 PM Joachim Wuttke <j.wut...@fz-juelich.de> > wrote: > >> Package: trilinos-doc >> Version: 12.10.1-3 >> >> Documentation of the important Trilinos component Epetra >> is missing in /usr/share/doc/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#864779: Epetra doc missing
Thanks Joachim for report. This is more of an upstream issue, see [1]. Once that is done, the package will have the Epetra documentation shipped. Cheers, Nico [1] https://github.com/trilinos/Trilinos/issues/1431 On Wed, Jun 14, 2017 at 6:42 PM Joachim Wuttkewrote: > Package: trilinos-doc > Version: 12.10.1-3 > > Documentation of the important Trilinos component Epetra > is missing in /usr/share/doc/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#862111: python-slepc4py: Python 3 support
Package: python-slepc4py Version: 3.7.0-2build3 Severity: wishlist slepc4py is compatible with Python 3.2 and up (see [1]), and it'd be nice to this reflected in the package. [1] https://bitbucket.org/slepc/slepc4py -- System Information: Debian Release: stretch/sid APT prefers zesty-updates APT policy: (500, 'zesty-updates'), (500, 'zesty-security'), (500, 'zesty') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.10.0-20-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-slepc4py depends on: ii libc6 2.24-9ubuntu2 ii libgcc1 1:6.3.0-12ubuntu2 ii libopenmpi2 2.0.2-2 ii libpetsc3.7.5 [libpetsc3.7] 3.7.5+dfsg1-4build1 ii libslepc3.7.3 [libslepc3.7] 3.7.3+dfsg1-5build1 ii libstdc++66.3.0-12ubuntu2 ii python2.7.13-2 ii python-numpy [python-numpy-abi9] 1:1.12.1-1ubuntu1 ii python-petsc4py 3.7.0-2build1 pn python:any python-slepc4py recommends no packages. python-slepc4py suggests no packages. -- no debconf information -- 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#862110: python-petsc4py: Python 3 support
Package: python-petsc4py Version: 3.7.0-2build1 Severity: wishlist petsc4py is compatible with Python 3.2 and up (see [1]) and it'd be nice to see this reflected in the package. [1] https://bitbucket.org/petsc/petsc4py -- System Information: Debian Release: stretch/sid APT prefers zesty-updates APT policy: (500, 'zesty-updates'), (500, 'zesty-security'), (500, 'zesty') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.10.0-20-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-petsc4py depends on: ii libc6 2.24-9ubuntu2 ii libgcc1 1:6.3.0-12ubuntu2 ii libopenmpi2 2.0.2-2 ii libpetsc3.7.5 [libpetsc3.7] 3.7.5+dfsg1-4build1 ii libstdc++66.3.0-12ubuntu2 ii python2.7.13-2 ii python-numpy [python-numpy-abi9] 1:1.12.1-1ubuntu1 pn python:any python-petsc4py recommends no packages. python-petsc4py suggests no packages. -- no debconf information -- 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#810254:
Hi everyone, I did some work on this in the last few days and I got to something. As requested, it's all committed to the vtk6 repo (and also available from [1]). As far as I can tell, it's all in good order. I'm already running a bunch of applications against it with no nasty surprises so far. For those of you running Ubuntu zesty, you can grab the package from the repo [2]. (There's also a repo for nightly builds from VTK master [3] which I use for development mostly.) Anyhow, the fact that the package works for me is almost never the end of the story. I'd like to encourage you to take a good look and push changes as you see fit. Hopefully we can this out to experimental sometime soon. Cheers, Nico [1] https://github.com/nschloe/debian-vtk7 [2] https://launchpad.net/~nschloe/+archive/ubuntu/vtk7 [3] https://launchpad.net/~nschloe/+archive/ubuntu/vtk7-nightly -- 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#854624: fenics: vcs information incorrect
Package: fenics Version: 1:2016.2.0.1~ppa1~yakkety Severity: minor Tags: newcomer Dear Maintainer, on [1], the VCS is still listed as SVN and has a dysfunctional link. This should be updated to the new Git repo (in debian/control). Cheers, Nico [1] https://tracker.debian.org/pkg/fenics -- System Information: Debian Release: stretch/sid APT prefers yakkety-updates APT policy: (500, 'yakkety-updates'), (500, 'yakkety-security'), (500, 'yakkety'), (100, 'yakkety-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-37-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fenics depends on: ii dolfin-bin 2016.2.0-1~ppa3~yakkety1 ii dolfin-doc 2016.2.0-1~ppa3~yakkety1 ii libdolfin-dev 2016.2.0-1~ppa3~yakkety1 ii libmshr-dev 2016.2.0-1~ppa1~yakkety1 ii mshr-demos 2016.2.0-1~ppa1~yakkety1 ii python-dijitso 2016.2.0-1~ppa1~yakkety1 ii python-dolfin 2016.2.0-1~ppa3~yakkety1 ii python-ffc 2016.2.0-1~ppa1~yakkety1 ii python-fiat 2016.2.0-1~ppa1~yakkety1 ii python-instant 2016.2.0-1~ppa1~yakkety1 ii python-mshr 2016.2.0-1~ppa1~yakkety1 ii python-ufl 2016.2.0-1~ppa1~yakkety1 ii python-ufl-doc 2016.2.0-1~ppa1~yakkety1 Versions of packages fenics recommends: pn python-scitools fenics suggests no packages. -- no debconf information -- 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#810254:
Thanks Anton for the swift reply. Is the vtk7-branch in the vtk6 or the original vtk package (which is VTK 5)? Considering that history, I would have opened up a whole new package vtk7. Cheers, Nico On Sat, Feb 4, 2017 at 11:13 AM Anton Gladky <gl...@debian.org> wrote: > Hi Nico, > > thanks for your contribution! We will definitely upload VTK7 after > Stretch will be released. Feel free to commit into the alioth > into the vtk7-branch. > > Best regards > > > Anton > > 2017-02-04 10:54 GMT+01:00 Nico Schlömer <nico.schloe...@gmail.com>: > > Alright, so I've spend last night packaging VTK7 (nightly master) [1]. > It's basically a clone of the vtk6 package with a bunch of fixes. Will have > to be tested some more, but for certain it's already a better-than-nothing. > > Comments and PRs are more than welcome; the code is on GitHub [2]. > > Cheers, > Nico > > [1] https://launchpad.net/~nschloe/+archive/ubuntu/vtk7-nightly > [2] https://github.com/nschloe/debian-vtk7 > > > -- > debian-science-maintainers mailing list > debian-science-maintainers@lists.alioth.debian.org > > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers > > -- 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#810254:
Alright, so I've spend last night packaging VTK7 (nightly master) [1]. It's basically a clone of the vtk6 package with a bunch of fixes. Will have to be tested some more, but for certain it's already a better-than-nothing. Comments and PRs are more than welcome; the code is on GitHub [2]. Cheers, Nico [1] https://launchpad.net/~nschloe/+archive/ubuntu/vtk7-nightly [2] https://github.com/nschloe/debian-vtk7 -- 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#853686: trilinos: ftbfs with GCC-7
I see now that you've already filed one for Debian as well [1]. Cheers, Nico [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853679 On Tue, Jan 31, 2017 at 12:11 PM Nico Schlömer <nico.schloe...@gmail.com> wrote: > Thanks Matthias for reporting. > > This looks like a TBB error; I've filed a bug at [1]. > > Cheers, > Nico > > [1] https://github.com/01org/tbb/issues/12 > > On Tue, Jan 31, 2017 at 10:52 AM Matthias Klose <d...@debian.org> wrote: > > Package: src:trilinos > Version: 12.10.1-3 > Severity: normal > Tags: sid buster > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-7 > > Please keep this issue open in the bug tracker for the package it > was filed for. If a fix in another package is required, please > file a bug for the other package (or clone), and add a block in this > package. Please keep the issue open until the package can be built in > a follow-up test rebuild. > > The package fails to build in a test rebuild on at least amd64 with > gcc-7/g++-7, but succeeds to build with gcc-6/g++-6. The > severity of this report may be raised before the buster release. > There is no need to fix this issue in time for the stretch release. > > The full build log can be found at: > > http://people.debian.org/~doko/logs/gcc7-20170126/trilinos_12.10.1-3_unstable_gcc7.log > The last lines of the build log are at the end of this report. > > To build with GCC 7, either set CC=gcc-7 CXX=g++-7 explicitly, > or install the gcc, g++, gfortran, ... packages from experimental. > > apt-get -t=experimental install g++ > > Common build failures are new warnings resulting in build failures with > -Werror turned on, or new/dropped symbols in Debian symbols files. > For other C/C++ related build failures see the porting guide at > http://gcc.gnu.org/gcc-7/porting_to.html > > [...] > cd /<>/obj-x86_64-linux-gnu/packages/sacado/test/UnitTests && > /usr/bin/cmake -E cmake_link_script > CMakeFiles/Sacado_FadKokkosTests_Serial.dir/link.txt --verbose=1 > /usr/bin/mpicxx -g -O2 -fdebug-prefix-map=/<>=. > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time > -D_FORTIFY_SOURCE=2 -std=c++11 -Wl,-z,relro -Wl,--as-needed > CMakeFiles/Sacado_FadKokkosTests_Serial.dir/Fad_KokkosTests_Serial.cpp.o > -o Sacado_FadKokkosTests_Serial.exe > -Wl,-rpath,/<>/obj-x86_64-linux-gnu/packages/sacado/src:/<>/obj-x86_64-linux-gnu/packages/kokkos/containers/src:/<>/obj-x86_64-linux-gnu/packages/teuchos/kokkoscomm/src:/<>/obj-x86_64-linux-gnu/packages/teuchos/kokkoscompat/src:/<>/obj-x86_64-linux-gnu/packages/teuchos/remainder/src:/<>/obj-x86_64-linux-gnu/packages/teuchos/numerics/src:/<>/obj-x86_64-linux-gnu/packages/teuchos/comm/src:/<>/obj-x86_64-linux-gnu/packages/teuchos/parameterlist/src:/<>/obj-x86_64-linux-gnu/packages/teuchos/core/src:/<>/obj-x86_64-linux-gnu/packages/kokkos/core/src > -rdynamic ../../src/libtrilinos_sacado.so.12.10.1 > ../../../kokkos/containers/src/libtrilinos_kokkoscontainers.so.12.10.1 > ../../../teuchos/kokkoscomm/src/libtrilinos_teuchoskokkoscomm.so.12.10.1 > ../../../teuchos/kokkoscompat/src/libtrilinos_teuchoskokkoscompat.so.12.10.1 > ../../../teuchos/remainder/src/libtrilinos_teuchosremainder.so.12.10.1 > ../../../teuchos/numerics/src/libtrilinos_teuchosnumerics.so.12.10.1 > /usr/lib/liblapack.so /usr/lib/libblas.so > ../../../teuchos/comm/src/libtrilinos_teuchoscomm.so.12.10.1 > ../../../teuchos/parameterlist/src/libtrilinos_teuchosparameterlist.so.12.10.1 > ../../../teuchos/core/src/libtrilinos_teuchoscore.so.12.10.1 > ../../../kokkos/core/src/libtrilinos_kokkoscore.so.12.10.1 > /usr/lib/x86_64-linux-gnu/libdl.so > make[4]: Leaving directory '/<>/obj-x86_64-linux-gnu' > [ 49%] Built target Sacado_FadKokkosTests_Serial > [ 49%] Linking CXX executable TpetraKernels_blas2_MV_Serial.exe > cd /<>/obj-x86_64-linux-gnu/packages/tpetra/kernels/unit_test > && /usr/bin/cmake -E cmake_link_script > CMakeFiles/TpetraKernels_blas2_MV_Serial.dir/link.txt --verbose=1 > /usr/bin/mpicxx -g -O2 -fdebug-prefix-map=/<>=. > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time > -D_FORTIFY_SOURCE=2 -std=c++11 -Wl,-z,relro -Wl,--as-needed > CMakeFiles/TpetraKernels_blas2_MV_Serial.dir/blas2_MV_Serial.cpp.o -o > TpetraKernels_blas2_MV_Serial.exe > -Wl,-rpath,/<>/obj-x86_64-linux-gnu/packages/tpetra/kernels/src:/<>/obj-x86_64-linux-gnu/packages/teuchos/comm/src:/<>/obj-x86_64-linux-gnu/packages/teuchos/parameterlist/src:/<>/obj-x86_64-linux-gnu/packages/teuchos/core/src:/<>/obj-x86_64-linux-gnu/packages/kokkos/algorithms/src:/<>/obj-x86_64-linux-gnu/packages/kokkos/containers/src:/<>/obj-x
Bug#853686: trilinos: ftbfs with GCC-7
Thanks Matthias for reporting. This looks like a TBB error; I've filed a bug at [1]. Cheers, Nico [1] https://github.com/01org/tbb/issues/12 On Tue, Jan 31, 2017 at 10:52 AM Matthias Klosewrote: > Package: src:trilinos > Version: 12.10.1-3 > Severity: normal > Tags: sid buster > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-7 > > Please keep this issue open in the bug tracker for the package it > was filed for. If a fix in another package is required, please > file a bug for the other package (or clone), and add a block in this > package. Please keep the issue open until the package can be built in > a follow-up test rebuild. > > The package fails to build in a test rebuild on at least amd64 with > gcc-7/g++-7, but succeeds to build with gcc-6/g++-6. The > severity of this report may be raised before the buster release. > There is no need to fix this issue in time for the stretch release. > > The full build log can be found at: > > http://people.debian.org/~doko/logs/gcc7-20170126/trilinos_12.10.1-3_unstable_gcc7.log > The last lines of the build log are at the end of this report. > > To build with GCC 7, either set CC=gcc-7 CXX=g++-7 explicitly, > or install the gcc, g++, gfortran, ... packages from experimental. > > apt-get -t=experimental install g++ > > Common build failures are new warnings resulting in build failures with > -Werror turned on, or new/dropped symbols in Debian symbols files. > For other C/C++ related build failures see the porting guide at > http://gcc.gnu.org/gcc-7/porting_to.html > > [...] > cd /<>/obj-x86_64-linux-gnu/packages/sacado/test/UnitTests && > /usr/bin/cmake -E cmake_link_script > CMakeFiles/Sacado_FadKokkosTests_Serial.dir/link.txt --verbose=1 > /usr/bin/mpicxx -g -O2 -fdebug-prefix-map=/<>=. > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time > -D_FORTIFY_SOURCE=2 -std=c++11 -Wl,-z,relro -Wl,--as-needed > CMakeFiles/Sacado_FadKokkosTests_Serial.dir/Fad_KokkosTests_Serial.cpp.o > -o Sacado_FadKokkosTests_Serial.exe > -Wl,-rpath,/<>/obj-x86_64-linux-gnu/packages/sacado/src:/<>/obj-x86_64-linux-gnu/packages/kokkos/containers/src:/<>/obj-x86_64-linux-gnu/packages/teuchos/kokkoscomm/src:/<>/obj-x86_64-linux-gnu/packages/teuchos/kokkoscompat/src:/<>/obj-x86_64-linux-gnu/packages/teuchos/remainder/src:/<>/obj-x86_64-linux-gnu/packages/teuchos/numerics/src:/<>/obj-x86_64-linux-gnu/packages/teuchos/comm/src:/<>/obj-x86_64-linux-gnu/packages/teuchos/parameterlist/src:/<>/obj-x86_64-linux-gnu/packages/teuchos/core/src:/<>/obj-x86_64-linux-gnu/packages/kokkos/core/src > -rdynamic ../../src/libtrilinos_sacado.so.12.10.1 > ../../../kokkos/containers/src/libtrilinos_kokkoscontainers.so.12.10.1 > ../../../teuchos/kokkoscomm/src/libtrilinos_teuchoskokkoscomm.so.12.10.1 > ../../../teuchos/kokkoscompat/src/libtrilinos_teuchoskokkoscompat.so.12.10.1 > ../../../teuchos/remainder/src/libtrilinos_teuchosremainder.so.12.10.1 > ../../../teuchos/numerics/src/libtrilinos_teuchosnumerics.so.12.10.1 > /usr/lib/liblapack.so /usr/lib/libblas.so > ../../../teuchos/comm/src/libtrilinos_teuchoscomm.so.12.10.1 > ../../../teuchos/parameterlist/src/libtrilinos_teuchosparameterlist.so.12.10.1 > ../../../teuchos/core/src/libtrilinos_teuchoscore.so.12.10.1 > ../../../kokkos/core/src/libtrilinos_kokkoscore.so.12.10.1 > /usr/lib/x86_64-linux-gnu/libdl.so > make[4]: Leaving directory '/<>/obj-x86_64-linux-gnu' > [ 49%] Built target Sacado_FadKokkosTests_Serial > [ 49%] Linking CXX executable TpetraKernels_blas2_MV_Serial.exe > cd /<>/obj-x86_64-linux-gnu/packages/tpetra/kernels/unit_test > && /usr/bin/cmake -E cmake_link_script > CMakeFiles/TpetraKernels_blas2_MV_Serial.dir/link.txt --verbose=1 > /usr/bin/mpicxx -g -O2 -fdebug-prefix-map=/<>=. > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time > -D_FORTIFY_SOURCE=2 -std=c++11 -Wl,-z,relro -Wl,--as-needed > CMakeFiles/TpetraKernels_blas2_MV_Serial.dir/blas2_MV_Serial.cpp.o -o > TpetraKernels_blas2_MV_Serial.exe > -Wl,-rpath,/<>/obj-x86_64-linux-gnu/packages/tpetra/kernels/src:/<>/obj-x86_64-linux-gnu/packages/teuchos/comm/src:/<>/obj-x86_64-linux-gnu/packages/teuchos/parameterlist/src:/<>/obj-x86_64-linux-gnu/packages/teuchos/core/src:/<>/obj-x86_64-linux-gnu/packages/kokkos/algorithms/src:/<>/obj-x86_64-linux-gnu/packages/kokkos/containers/src:/<>/obj-x86_64-linux-gnu/packages/kokkos/core/src > -rdynamic ../src/libtrilinos_tpetrakernels.so.12.10.1 > ../../../teuchos/comm/src/libtrilinos_teuchoscomm.so.12.10.1 > ../../../teuchos/parameterlist/src/libtrilinos_teuchosparameterlist.so.12.10.1 > ../../../teuchos/core/src/libtrilinos_teuchoscore.so.12.10.1 > ../../../kokkos/algorithms/src/libtrilinos_kokkosalgorithms.so.12.10.1 > ../../../kokkos/containers/src/libtrilinos_kokkoscontainers.so.12.10.1 > ../../../kokkos/core/src/libtrilinos_kokkoscore.so.12.10.1 > /usr/lib/x86_64-linux-gnu/libdl.so > make[4]: Leaving directory '/<>/obj-x86_64-linux-gnu' > [ 49%] Built target
Bug#848770: trilinos: FTBFS: Test failures
Thanks Lucas for the report. A new version (12.10.1-2) has already been submitted to NEW, fixing the test failures. Cheers, Nico On Mon, Dec 19, 2016 at 10:43 PM Lucas Nussbaumwrote: > Source: trilinos > Version: 12.10.1-1 > Severity: serious > Tags: stretch sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20161219 qa-ftbfs > Justification: FTBFS on amd64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. > > Relevant part (hopefully): > > Stokhos = 15.38 sec (52 tests) > > Teko = 45.70 sec (19 tests) > > Teuchos = 10.19 sec (53 tests) > > Thyra= 22.12 sec (80 tests) > > Tpetra = 31.81 sec (113 tests) > > Triutils = 0.55 sec (2 tests) > > > > Total Test time (real) = 320.29 sec > > > > The following tests FAILED: > > 592 - Isorropia_part_sizes_MPI_4 (Failed) > > 630 - ShyLUCore_belos_driver_MPI_4 (Failed) > > 631 - ShyLUCore_shylu_factor_MPI_4 (Failed) > > 677 - Teko_ProbingFactory_MPI_1 (Failed) > > Errors while running CTest > > Makefile:152: recipe for target 'test' failed > > The full build log is available from: >http://aws-logs.debian.net/2016/12/19/trilinos_12.10.1-1_unstable.log > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > About the archive rebuild: The rebuild was done on EC2 VM instances from > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every > failed build was retried once to eliminate random failures. > > -- 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
Done [1] and done [2]. Graham, you might want to subscribe to those PRs. Cheers, Nico [1] https://github.com/kokkos/kokkos/pull/57 <https://github.com/kokkos/kokkos/pull/576>5 [2] https://github.com/kokkos/kokkos/pull/576 On Fri, Dec 9, 2016 at 11:22 AM Graham Inggs <gin...@debian.org> wrote: > On 9 December 2016 at 09:49, Nico Schlömer <nico.schloe...@gmail.com> > wrote: > > The patch looks really simple. Great! Do you think it'd be worthwhile > > updating the PR [1] (or opening a new one)? Perhaps the kokkos devs can > > figure out why the remaining tests are failing. > > No harm in trying, I guess. :) > Please update the PR, but I suggest leaving out the static_asserts, > i.e. don't include the changes to Kokkos_Core_fwd.hpp and > Kokkos_TaskQueue.hpp. > Also, I think the changes to Kokkos_Macros.hpp from > kokkos-disable-asm.patch should go in a separate PR. Hopefully they > can merge that right away. > -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#835406: trilinos: FTBFS on 32-bit architectures
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. Cheers, Nico [1] https://github.com/kokkos/kokkos/pull/410 On Fri, Dec 9, 2016 at 8:18 AM Graham Inggswrote: > 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 \ > -- 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
> if you think it will be straightforward Definitely. Nothing spectacular has happened upstream. (If, suprisingly, it should happend to FTBFS, let me know and I'll get it straight.) Cheers, Nico On Mon, Aug 29, 2016 at 11:08 PM Graham Inggs <gin...@debian.org> wrote: > On 29 August 2016 at 21:55, Nico Schlömer <nico.schloe...@gmail.com> > wrote: > > When uploading, we could perhaps also include the point release 12.6.4. > > (Current Debian is 12.6.3.) > > Sure, let's do that. > > Do you have time now to prepare 12.6.4 for upload? I can rebase and > test my patches against that version. > Otherwise, if you think it will be straightforward, I can just do it. > -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#835406: trilinos: FTBFS on 32-bit architectures
> I have successfully built trilinos on i386 and armhf, This is amazing! We can certainly upstream those patches, too. When uploading, we could perhaps also include the point release 12.6.4. (Current Debian is 12.6.3.) Cheers, Nico On Mon, Aug 29, 2016 at 5:09 PM Graham Inggswrote: > 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 > > -- 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#831790: fenics: version bump (2016.1.0)
Package: fenics Version: version bump Severity: wishlist FEniCS 2016.1.0 has been released recently (cf. https://fenicsproject.org/download/); note that the versioning scheme has changed. Bump in Debian, please. -- System Information: Debian Release: stretch/sid APT prefers xenial-updates APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 'xenial'), (100, 'xenial-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-31-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#831788: OSError: libmpi.so.1: cannot open shared object file: No such file or directory
Package: python-gmsh Version: 2.10.1+dfsg1-1ubuntu4 Severity: normal Dear Maintainer, The python-gmsh appears to be broken: ``` $ python -c "import gmshpy" Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/dist-packages/gmshpy/__init__.py", line 3, in mpi = CDLL('libmpi.so.1', RTLD_GLOBAL) File "/usr/lib/python2.7/ctypes/__init__.py", line 362, in __init__ self._handle = _dlopen(self._name, mode) OSError: libmpi.so.1: cannot open shared object file: No such file or directory ``` -- System Information: Debian Release: stretch/sid APT prefers xenial-updates APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 'xenial'), (100, 'xenial-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-31-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-gmsh depends on: ii libc6 2.23-0ubuntu3 ii libgcc1 1:6.0.1-0ubuntu1 ii libgmsh2v52.10.1+dfsg1-1ubuntu4 ii libpython2.7 2.7.12-1~16.04 ii libstdc++65.4.0-6ubuntu1~16.04.1 ii python2.7.11-1 Versions of packages python-gmsh recommends: ii gmsh 2.10.1+dfsg1-1ubuntu4 python-gmsh suggests no packages. -- no debconf information -- 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
I've tested and pushed a build without binutils. @Graham, would you like to upload? Cheers, Nico On Mon, Jul 18, 2016 at 1:26 PM Felix Salfelder <fe...@salfelder.org> wrote: > On Mon, Jul 18, 2016 at 11:18:30AM +0000, Nico Schlömer wrote: > > [binutils] just turn it off > > > > @Felix Agreed? > > sure, makes sense! let's postpone the static link bfd thing. > > thank you > felix > -- 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
The binutils support in trilinos is far from being critical, so I'd say for making things a little easier we just turn it off. @Felix Agreed? Cheers, Nico On Fri, Jul 15, 2016 at 12:15 AM Helmut Grohnewrote: > On Sun, Jul 10, 2016 at 01:04:13PM +0200, Felix Salfelder wrote: > > if that's correct, we shouldn't link libtrilinos_teuchoscore.so to a > > particular revision of libbfd-2.26-system.so. how would that be > > possible? > > > > otoh, if libbfd-2.26.1-system.so > > - is meant to replace libbfd-2.26-system.so, shouldn't there be a > > symlink? > > - is NOT meant to provide libbfd-2.26-system.so, then why are these not > > coinstallable? > > Dynamically linking libbfd-*-system.so is no allowed. This is explicitly > stated in the package description of binutils-dev. > > If you absolutely must link libbfd, link it statically and add an > appropriate Built-Using header. > > Helmut > > -- 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#825824: libmumps-dev: MUMPS 5.0.1 version bump
Package: libmumps-dev Version: 4.10.0.dfsg-4 Severity: wishlist MUMPS 5.0.1 has been released a while ago. Please bump. -- System Information: Debian Release: stretch/sid APT prefers xenial-updates APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 'xenial'), (100, 'xenial-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-22-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libmumps-dev depends on: ii libmumps-4.10.0 4.10.0.dfsg-4 ii libscalapack-mpi-dev 1.8.0-12.3 ii mpi-default-dev 1.4 libmumps-dev recommends no packages. libmumps-dev suggests no packages. -- no debconf information -- 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#822255: python-dolfin: remove dependency on python-numpy
Package: python-dolfin Severity: normal Dear Maintainer, python-dolfin depends on the unmaintained python-netcdf. Keeping the dependency has serious implications. For example, since python-netcdf is no longer included in Ubuntu 16.04, so isn't FEniCS. For this reason, please consider removing python-netcdf as a dependency. Cheers, Nico -- System Information: Debian Release: stretch/sid APT prefers xenial-updates APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 'xenial'), (100, 'xenial-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-21-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#805010: VTK 6.3.0 released
Source: vtk6 Severity: wishlist Dear Maintainer, VTK 6.3.0 has been released on Sep 10, 2015 [1]. Please bump. Cheers, Nico [1] http://www.kitware.com/blog/home/post/963 -- System Information: Debian Release: jessie/sid APT prefers wily-updates APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily-proposed'), (500, 'wily'), (100, 'wily-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.19.0-21-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#789169: libvtk6-dev: fix upstream Xdmf3 build bug
Just to clarify: The patch hasn't been merged to upstream yet, so we'll still have to patch manually, even in the rc. --Nico On Fri, Jul 31, 2015 at 7:46 AM Anton Gladky gl...@debian.org wrote: severity 789169 important thanks Hi Nico, thanks for the bug-report and the patch. Xdmf3-source was dropped from Debian for vtk6_6.2.0, so I am not able to apply the patch. But it looks like release candidate of vtk6 is already available. So your patch will be there. Thus I am reducing the bug`s severity. Thanks Anton 2015-06-18 7:30 GMT-07:00 Nico Schlömer nico.schloe...@gmail.com: Package: libvtk6-dev Version: 6.2.0 Severity: serious Tags: upstream Justification: fails to build from source Dear Maintainer, The new Xdmf3 interface in 6.2.0 has a build bug that's already been reported upstream for fixing in 6.3.0 [1]. The PR there fixes the build and may also be interesting for 6.2.0 in Debian. The patch is attached. [1] https://github.com/Kitware/VTK/pull/21 -- System Information: Debian Release: jessie/sid APT prefers vivid-updates APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid'), (100, 'vivid-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.19.0-18-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers -- 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: Trilinos packages
yes. the old trilinos debian source package had a libname.patch and a soname.patch, these fix the names for a monolithic package. i suggest to import these (or just rebase your work on top of that). I already incorporated a fix for proper so-naming upstream a while ago, so that should be fixed. As for the prefixing of the libraries with trilinos_, I'd rather refrain from it for the moment. The arguments I can see for this * The Debian package for Trilinos is meant for a researcher to get an application to compile and run with Trilinos to then deploy it on an HPC. If Debian follows a non-default library naming scheme, the user would have to maintain two separate build files for Debian and the cluster (which will typically host a customized Trilinos installation). * The new Trilinos package includes many more subpackages than the old one did. Maintaining a Debian patch that changes all library names is possible, but would be a substantial effort. * The old README brings up that prefixing avoids conflicts. While it it remains possible that another library by the same name appears in Debian, that has not been the case as long as Trilinos in Debian existed and isn't the case now. * The old README brings up that it would be easier to identify trilinos libraries. While that is true, a user of Trilinos typically has a very good idea of what libraries he or she plans to use. That said, I do see the benefit of prefixing the libraries with trilinos_. I would suggest that I file a bug report upstream, talk to some of the developers, and see if we can incorporate that change in Trilinos itself. We would probably have to wait for a major release, but I think this coming fall they are bumping the major release number. ideally those patches should be included in your package at alioth (whether or not they have been accepted upstream). Really? Why? is there a specific reason to maintain a second and different repository for ubuntu? Not particularly. I just have Trilinos built on a nightly basis on launchpad to make sure upcoming changes won't bite us; it also serves me well as a test bed for changes in debian/. Cheers, Nico On Wed, Mar 26, 2014 at 5:03 PM, Felix Salfelder fe...@salfelder.org wrote: On Wed, Mar 26, 2014 at 10:22:23AM +0100, Nico Schlömer wrote: I would suggest to first go with a monolithic package and split it up at a later point. yes. the old trilinos debian source package had a libname.patch and a soname.patch, these fix the names for a monolithic package. i suggest to import these (or just rebase your work on top of that). also, theres a note on renaming in README.Debian. and a changelog that would be nice to have. README.Debian [..] Debian Trilinos libraries renaming == Following a discussion with ftpmaster, the Trilinos libraries have been renamed to be less generic. They all use the same prefix now : libtrilinos_ . That should also help tremendously with - avoiding conflicts with other libraries/packages - identifying available trilinos libraries [..] In the course of packaging Trilinos for Debian, I have identified quite a number of bugs in Trilinos for which I maintain a little zoo of patches, https://github.com/nschloe/trilinos-ubuntu/tree/master/patches. Some of those have already made it upstream, and we'll have to see if we can get in more of those before the next release freeze. ideally those patches should be included in your package at alioth (whether or not they have been accepted upstream). is there a specific reason to maintain a second and different repository for ubuntu? regards felix -- 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: Trilinos packages
i suspect that the clean way would be (binary) packages for each library the trilinos source package contains. I fully agree. Trilinos is structurally similar to Boost which does provide a sophisticated install structure. Unfortunately, the Trilinos build system is flawed in certain places that make it difficult to take an automated approach to that. One example is that the interdependencies of the subpackages aren't presented in a machine-readable form. Although, I'm submitting patches to Trilinos to address these issues, I would suggest to first go with a monolithic package and split it up at a later point. In the course of packaging Trilinos for Debian, I have identified quite a number of bugs in Trilinos for which I maintain a little zoo of patches, https://github.com/nschloe/trilinos-ubuntu/tree/master/patches. Some of those have already made it upstream, and we'll have to see if we can get in more of those before the next release freeze. I'll keep you all posted. Cheers, Nico On Tue, Mar 18, 2014 at 12:56 PM, Felix Salfelder fe...@salfelder.org wrote: On Tue, Mar 18, 2014 at 12:15:49PM +0100, Nico Schlömer wrote: A quick poll on the Trilinos package naming: Right now, we have libtrilinos, which triggers a package-name-doesnt-match-sonames warning since none of the Trilinos libraries is called libtrilinos.* (rather libepetra.*, libbelos.*, ...). This is similar to the libboost package which doesn't contain a library by the name libboost.* either. i suspect that the clean way would be (binary) packages for each library the trilinos source package contains. and maybe have a trilinos-dev metapackage that depends on all the lib*-dev packages. this will add up to some copy and paste work, and end up with a lot of packages... i don't know if it's worth the effort. fwiw, theres another source package that creates a heap of libraries. it is the old trilinos package [1]. here, all sonames are prefixed by libtrilinos_. looks like an alternative... On the other hand, a software very similar to Trilinos, PETSc, goes by the Debian name petsc. i cannot find a (binary) package called petsc. but there is (e.g.) libpetsc3.4.2, and it contains libpetsc.so.4.3.2. unkike trilinos, the petsc source package creates just one shared library. and afaics its soname matches the package name. hth felix [1] https://packages.debian.org/squeeze/amd64/libtrilinos/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
Re: Trilinos packages
Strange, libparmetis-dev should be in jessie, cf. https://packages.debian.org/jessie/libparmetis-dev. --Nico On Mon, Mar 10, 2014 at 10:22 AM, Felix Salfelder fe...@salfelder.org wrote: On Sat, Mar 08, 2014 at 12:39:57AM +0100, Nico Schlömer wrote: 1) Set VCS=fields 2) Standards-Version is 3.9.5 now 3) Use DEP-3 for patches (Description, Author, Last-Updates is enough) 4) Remove some unnecessary comments from debian/rules. It should be as short as possible. Leave only necessary notes. 5) Check 3rd-party files and add them to debian/copyright (if they are). Done and done; I pushed the changes to alioth. tried to build (dpkg-buildpackage -rfakeroot -b) on a machine close to testing. [..] dpkg-checkbuilddeps: Unmet build dependencies: libparmetis-dev [..] apt-get install libparmetis-dev says Package libparmetis-dev is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source However the following packages replace it: libscotchparmetis-dev:i386 libscotchparmetis-dev:armel libscotchparmetis-dev E: Package 'libparmetis-dev' has no installation candidate installing libscotchparmetis-dev does not help. dpkg-buildpackage -rfakeroot -b -d yields [..] Could not find the ParMETIS headers include directory! Please manually set ParMETIS_INCLUDE_DIRS and/or ParMETIS_LIBRARY_DIRS or [..] i don't know what libscotchparmetis is, does it replaces libparmetis for trilinos? in that case it should be easy to fix... thanks felix -- 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: Trilinos packages
I see that ParMETIS is free for educational purposes only http://glaros.dtc.umn.edu/gkhome/metis/parmetis/download, so requiring it as a dependency makes Trilinos installable for edu-only as well. ParMETIS is optional to Trilinos so I might as well removed it without major repercussions. Are there general Debian guidelines for such situations? What's your opinion on this? --Nico On Mon, Mar 10, 2014 at 11:23 AM, Felix Salfelder fe...@salfelder.org wrote: On Mon, Mar 10, 2014 at 10:52:19AM +0100, Nico Schlömer wrote: Strange, libparmetis-dev should be in jessie, cf. https://packages.debian.org/jessie/libparmetis-dev. indeed it is, and i missed that. curiously, parmetis is non-free, and that is why i missed it. from my understanding (to some extent?) trilinos is free, so it might make sense to not use/link\ against libparmetis. doesn't the build dependency render your package non-free? particularly, there is gplv3 licensed software around (xyce) that build depends on trilinos. i'm no license or dfsg expert, anyhow, this doesn't look very clean to me.. thanks felix -- 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: Trilinos packages
I checked all other dependencies manually and found that libparmetis-dev was the only thing from non-free. I removed it from the list; please retry building. --Nico On Mon, Mar 10, 2014 at 12:27 PM, Nico Schlömer nico.schloe...@gmail.com wrote: my recommendation is to disable parmetis in trilinos and defer the problem until anybody actually requires it. Sure, why not. how many (license) problems are left without parmetis? Not sure. If you build without parmetis (remove the dependency from debian/control and debian/rules), does the builder still complain? --Nico On Mon, Mar 10, 2014 at 11:59 AM, Felix Salfelder fe...@salfelder.org wrote: On Mon, Mar 10, 2014 at 11:33:26AM +0100, Nico Schlömer wrote: Are there general Debian guidelines for such situations? i'm sorry i don't know or care. i'm not even sure in which way non-free is (not) a part of debian. What's your opinion on this? imo it's best to avoid trouble (here: non-free packages). my recommendation is to disable parmetis in trilinos and defer the problem until anybody actually requires it. if that is you, hopefully somebody else will step in and help. how many (license) problems are left without parmetis? regards felix -- 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: Trilinos packages
Hi Nico, is it possible to have working debian/watch? Not right now. Sandia currently doesn't do public ftp reads. They are in the process of switching to their new site trilinos.org right now, and I already requested a public ftp list to be added alongside. Once this is done, I'll adapt debian/watch. It seems, the checksum of tarball on the website and in pristine-tar branch is not the same. So what to do about this? --Nico On Mon, Mar 10, 2014 at 2:20 PM, Anton Gladky gl...@debian.org wrote: Hi Nico, is it possible to have working debian/watch? It seems, the checksum of tarball on the website and in pristine-tar branch is not the same. Anton 2014-03-10 13:51 GMT+01:00 Nico Schlömer nico.schloe...@gmail.com: I checked all other dependencies manually and found that libparmetis-dev was the only thing from non-free. I removed it from the list; please retry building. --Nico On Mon, Mar 10, 2014 at 12:27 PM, Nico Schlömer nico.schloe...@gmail.com wrote: my recommendation is to disable parmetis in trilinos and defer the problem until anybody actually requires it. Sure, why not. how many (license) problems are left without parmetis? Not sure. If you build without parmetis (remove the dependency from debian/control and debian/rules), does the builder still complain? --Nico On Mon, Mar 10, 2014 at 11:59 AM, Felix Salfelder fe...@salfelder.org wrote: On Mon, Mar 10, 2014 at 11:33:26AM +0100, Nico Schlömer wrote: Are there general Debian guidelines for such situations? i'm sorry i don't know or care. i'm not even sure in which way non-free is (not) a part of debian. What's your opinion on this? imo it's best to avoid trouble (here: non-free packages). my recommendation is to disable parmetis in trilinos and defer the problem until anybody actually requires it. if that is you, hopefully somebody else will step in and help. how many (license) problems are left without parmetis? regards felix -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers -- 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: Trilinos packages
E: dh_python2:145: extension for python2.6 is missing. Build extensions for all supported Python versions (`pyversions -vr`) or adjust X-Python-Version field or pass --no-guessing-versions to dh_python2 I added override_dh_python2: dh_python2 --no-guessing-versions to debian/rules. This should fix your error, please retry. --Nico On Mon, Mar 10, 2014 at 3:02 PM, Felix Salfelder fe...@salfelder.org wrote: On Mon, Mar 10, 2014 at 01:51:24PM +0100, Nico Schlömer wrote: I checked all other dependencies manually and found that libparmetis-dev was the only thing from non-free. I removed it from the list; please retry building. the build succeeded without the ENABLE_ParMETIS switch (takes forever..). there's something wrong with dh_python. this is possibly a problem on my side, but i don't have time to investigate right now. [..] dh binary --with python2 dh_python2 W: dh_python2:437: public extension linked with libpython2.7: _Amesos.so W: dh_python2:437: public extension linked with libpython2.7: _Anasazi.so W: dh_python2:437: public extension linked with libpython2.7: _AztecOO.so W: dh_python2:437: public extension linked with libpython2.7: _Epetra.so W: dh_python2:437: public extension linked with libpython2.7: _EpetraExt.so W: dh_python2:437: public extension linked with libpython2.7: _Galeri.so W: dh_python2:437: public extension linked with libpython2.7: _IFPACK.so W: dh_python2:437: public extension linked with libpython2.7: _Komplex.so W: dh_python2:437: public extension linked with libpython2.7: _ML.so W: dh_python2:437: public extension linked with libpython2.7: _Pliris.so W: dh_python2:437: public extension linked with libpython2.7: _Teuchos.so W: dh_python2:437: public extension linked with libpython2.7: _TriUtils.so W: dh_python2:437: public extension linked with libpython2.7: _Abstract.so W: dh_python2:437: public extension linked with libpython2.7: _Solver.so W: dh_python2:437: public extension linked with libpython2.7: _StatusTest.so W: dh_python2:437: public extension linked with libpython2.7: ___init__.so W: dh_python2:437: public extension linked with libpython2.7: _Interface.so W: dh_python2:437: public extension linked with libpython2.7: ___init__.so W: dh_python2:437: public extension linked with libpython2.7: _NestedEpetra.so W: dh_python2:437: public extension linked with libpython2.7: ___init__.so E: dh_python2:145: extension for python2.6 is missing. Build extensions for all supported Python versions (`pyversions -vr`) or adjust X-Python-Version field or pass --no-guessing-versions to dh_python2 thanks felix -- 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: Trilinos packages
Did you repack it? Nope. For creating the printine-tar branch, I used the --git-pristine-tar option as described on https://wiki.debian.org/PackagingWithGit#pristine-tar. --Nico On Mon, Mar 10, 2014 at 4:30 PM, Anton Gladky gl...@debian.org wrote: 2014-03-10 16:25 GMT+01:00 Nico Schlömer nico.schloe...@gmail.com: It seems, the checksum of tarball on the website and in pristine-tar branch is not the same. So what to do about this? Did you repack it? Anton -- 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: Trilinos packages
As mentionned in an earlier email latest trilinos FTBS with gcc 4.8 (sacado module is broken). I've got all my work at https://github.com/nschloe/trilinos-ubuntu. In the debian.trusty/rules, you'll find comments about the Sacado issue with a link to the bug report on Trilinos. If you are more confortable with git we may move to Debian Science git repository. Git would be great. --Nico On Fri, Mar 7, 2014 at 11:36 AM, trophime christophe.troph...@lncmi.cnrs.fr wrote: On Fri, 2014-03-07 at 11:21 +0100, Nico Schlömer wrote: Hi all, I've noticed that Trilinos for Debian is dead now for a while http://packages.qa.debian.org/t/trilinos.html, and I'd like to help reviving it. I already have stable https://launchpad.net/~nschloe/+archive/trilinos/+packages and nightly https://launchpad.net/~nschloe/+archive/trilinos-nightly/+packages builds for Ubuntu going which I actively maintain, so I guess it wouldn't be too much of a leap. I'm not too familiar with the Debian community and infrastructure though, so I'll need some assistance. I'm also trying to rebuild trilinos based on your changes in debian/rules. As mentionned in an earlier email latest trilinos FTBS with gcc 4.8 (sacado module is broken). What I suggest is to share our work using the vcs on Debian Science svn. If you are more confortable with git we may move to Debian Science git repository. Best C. Cheers, Nico -- Christophe TROPHIME Research Engineer LNCMI CNRS - LNCMI 25, rue des Martyrs BP 166 38042 GRENOBLE Cedex 9 FRANCE CNRS Tel : +33 (0)4 76 88 90 02 Fax : +33 (0) 4 76 88 10 01 Office U 19 M@il : christophe.troph...@lncmi.cnrs.fr -- 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: Trilinos packages
Hi Anton, thanks for the links. I've now signed up and go through the package instructions. Small hints/questions about http://debian-science.alioth.debian.org/debian-science-policy.html: * The policy advises to use DM-Upload-Allowed, http://lintian.debian.org/tags/dm-upload-allowed-is-obsolete.html advises against. Which is the current policy? * The copyright format hint should point to http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ instead of the draft. * The Git link could be updated to http://git-scm.com/. I've otherwise adapted the package accordingly and I'm now waiting for debian-science membership approval I guess. Cheers, Nico On Fri, Mar 7, 2014 at 11:42 AM, Anton Gladky gl...@debian.org wrote: Hi Nico, we discussed it a year ago [1] and we keep our promise. Please, follow the procedure according Deb-Sci policy [2], create repo and ping me. [1] http://lists.alioth.debian.org/pipermail/debian-science-maintainers/2013-April/017553.html [2] http://debian-science.alioth.debian.org/debian-science-policy.html Regards Anton 2014-03-07 11:21 GMT+01:00 Nico Schlömer nico.schloe...@gmail.com: Hi all, I've noticed that Trilinos for Debian is dead now for a while http://packages.qa.debian.org/t/trilinos.html, and I'd like to help reviving it. I already have stable https://launchpad.net/~nschloe/+archive/trilinos/+packages and nightly https://launchpad.net/~nschloe/+archive/trilinos-nightly/+packages builds for Ubuntu going which I actively maintain, so I guess it wouldn't be too much of a leap. I'm not too familiar with the Debian community and infrastructure though, so I'll need some assistance. Cheers, Nico -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers -- 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: Trilinos packages
1) Set VCS=fields 2) Standards-Version is 3.9.5 now 3) Use DEP-3 for patches (Description, Author, Last-Updates is enough) 4) Remove some unnecessary comments from debian/rules. It should be as short as possible. Leave only necessary notes. 5) Check 3rd-party files and add them to debian/copyright (if they are). Done and done; I pushed the changes to alioth. --Nico On Fri, Mar 7, 2014 at 10:38 PM, Anton Gladky gl...@debian.org wrote: Please, do the following: 1) Set VCS=fields 2) Standards-Version is 3.9.5 now 3) Use DEP-3 for patches (Description, Author, Last-Updates is enough) 4) Remove some unnecessary comments from debian/rules. It should be as short as possible. Leave only necessary notes. 5) Check 3rd-party files and add them to debian/copyright (if they are). But the package looks fine! Though I did not build it yet. Please, check your .changes file with lintian. I will upload it shortly. Anton 2014-03-07 22:20 GMT+01:00 Nico Schlömer nico.schloe...@gmail.com: I hadn't, but I now found https://wiki.debian.org/PackagingWithGit which I now followed. upstream and pristine-tar are now in place. --Nico On Fri, Mar 7, 2014 at 6:40 PM, Anton Gladky gl...@debian.org wrote: Did you push pristine-tar and upstream branches? Anton 2014-03-07 17:28 GMT+01:00 Nico Schlömer nico.schloe...@gmail.com: Alright. I've now pushed the contents of the ./debian/ folder to alioth:/git/debian-science/packages//trilinos.git from where it can be reviewed. Will someone open a bug about the new package? Do I need to file na official ITP? Cheers, Nico On Fri, Mar 7, 2014 at 2:48 PM, Anton Gladky gl...@debian.org wrote: Hi Nico, we need to update our Policy. Please, follow new rules. Anton -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers