Bug#895419: Acknowledgement (python3-dolfin: JIT compilation fails as python3-instant tries to includes petsc4py from python2)

[Nico Schlömer]

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 Silva  wrote:

> 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

[Nico Schlömer]

Whoop whoop! Thanks everyone!

[1] https://packages.debian.org/experimental/libvtk7-dev

On Tue, Apr 3, 2018 at 11:55 PM Chris Lamb  wrote:

> 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

[Nico Schlömer]

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

[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.

Cheers,
Nico

On Thu, Nov 9, 2017 at 10:56 AM Gert Wollny  wrote:

> 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:

[Nico Schlömer]

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

[Nico Schlömer]

-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

[Nico Schlömer]

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 Beckmann  wrote:

> 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

[Nico Schlömer]

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. Ucko  wrote:

> 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

[Nico Schlömer]

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

[Nico Schlömer]

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

[Nico Schlömer]

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

[Nico Schlömer]

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

[Nico Schlömer]

> 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

[Nico Schlömer]

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

[Nico Schlömer]

> 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 Parsons  wrote:

> 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

[Nico Schlömer]

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 Wuttke 
wrote:

> > 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

[Nico Schlömer]

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 Wuttke 
wrote:

> 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

[Nico Schlömer]

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

[Nico Schlömer]

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  wrote:

> 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

[Nico Schlömer]

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

[Nico Schlömer]

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 
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#862111: python-slepc4py: Python 3 support

[Nico Schlömer]

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

[Nico Schlömer]

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:

[Nico Schlömer]

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

[Nico Schlömer]

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:

[Nico Schlömer]

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:

[Nico Schlömer]

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

[Nico Schlömer]

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

[Nico Schlömer]

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  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-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

[Nico Schlömer]

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 Nussbaum  wrote:

> 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

[Nico Schlömer]

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

[Nico Schlömer]

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 Inggs  wrote:

> 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

[Nico Schlömer]

> 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

[Nico Schlömer]

> 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 Inggs  wrote:

> 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)

[Nico Schlömer]

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

[Nico Schlömer]

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

[Nico Schlömer]

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

[Nico Schlömer]

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 Grohne  wrote:

> 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

[Nico Schlömer]

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

[Nico Schlömer]

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

[Nico Schlömer]

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

[Nico Schlömer]

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

[Nico Schlömer]

 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

[Nico Schlömer]

 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

[Nico Schlömer]

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

[Nico Schlömer]

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

[Nico Schlömer]

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

[Nico Schlömer]

 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

[Nico Schlömer]

 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

[Nico Schlömer]

 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

[Nico Schlömer]

 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

[Nico Schlömer]

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

[Nico Schlömer]

 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