Bug#675207: [Dolfin] Please binNMU python-ufc against latest swig
On Tue, Jun 05, 2012 at 09:33:36AM +0200, Johannes Ring wrote: On Mon, Jun 4, 2012 at 7:30 PM, Julien Cristau jcris...@debian.org wrote: On Mon, Jun  4, 2012 at 08:43:54 +0200, Johannes Ring wrote: On Mon, Jun 4, 2012 at 2:05 AM, Cyril Brulebois k...@debian.org wrote: Johannes Ring joha...@simula.no (31/05/2012): python-ufc needs to be rebuilt against the latest swig (2.0.7). Please binNMU it.  nmu python-ufc_2.0.5-2 . ALL . -m 'Rebuild against swig 2.0.7, see #675207.' if this package has such strict dependencies on swig, why aren't they exposed through strict package dependencies? You mean by adding something like swig2.0 (= 2.0.7) in Build-Depends? The thing is that UFC only depends on SWIG = 2.0.0, however, it will always need to be rebuilt whenever a new SWIG release enters the archive. Can this be automated or will I need to request a binNMU each time? That sounds broken.  Why is that necessary? When you run DOLFIN, efficient low-level C++ code (UFC) is automatically generated. This is done using SWIG and the SWIG version needs to be the same that was used when building UFC and DOLFIN. I'm Cc'ing the DOLFIN list to get more input on this. Johannes Does this break because we check the SWIG version in the JIT compiler, or because it actually breaks (with some link error)? -- Anders -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675207: [Dolfin] Please binNMU python-ufc against latest swig
On Wed, Jun 13, 2012 at 09:53:48PM +0200, Johannes Ring wrote: On Wed, Jun 13, 2012 at 9:15 PM, Anders Logg l...@simula.no wrote: Does this break because we check the SWIG version in the JIT compiler, or because it actually breaks (with some link error)? It is the version check that makes it break. This is the error message: OSError: PyDOLFIN was not compiled with the present version of swig. Install swig version 2.0.5 or recompiled PyDOLFIN with present swig Both UFC and DOLFIN was built with SWIG 2.0.5, while 2.0.7 is the current version in Debian unstable. Does it work if you remove those checks in dolfin/site-packages/dolfin/compilemodules/compilemodule.py dolfin/site-packages/dolfin/compilemodules/jit.py ? If so, we might turn those into warnings. Johan Hake can comment on whether the checks could be losened. -- Anders -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#316159: [DOLFIN-dev] Re: Bug#316159: configuring PETSc to use MPI alternatives
The important thing for DOLFIN is that we pick the same paths for MPI as used when compiling PETSc. DOLFIN gets the path by checking the location of mpirun (see configure.ac). If someone has a better suggestion, please tell me. Unless someone is really having a problem building DOLFIN against a version of PETSc compiled with lam (or mpich), I don't think this is an issue. /Anders On Thu, Sep 08, 2005 at 06:28:07PM -0400, Faheem Mitha wrote: On Thu, 8 Sep 2005, Adam C Powell IV wrote: Hello, MPICH and LAM are *not* binary compatible, so it's not possible to configure their links at runtime. That's why PETSc links specifically to the mpich libraries. It is not possible to use the alternatives system to switch between them. But you can configure PETSc to use lam. The details on how to do this are in the README.Debian file which comes with libpetsc2.2.0-dev. You should tell all this to the DOLFIN developers. I don't understand these issues that well, and am not in a position to change things (if necessary) anyway. How that will work with 2.3.0 will depend on how I package it. I'm afraid I'm stuck now on getting hypre to build at all with the new toolchain, spent about eight hours on it yesterday. :-( When all of the new mpich dependencies get into testing, then I'll focus on petsc again. Ok. I think that a little communication up front with the DOLFIN developers would be beneficial to make sure the Debian DOLFIN package is compatable with the Debian PETSc package. If you could send me a preview of the Debian PETSc 2.3 package when it is available, I'll try to get DOLFIN to build against it. Thanks. Faheem. ___ DOLFIN-dev mailing list [EMAIL PROTECTED] http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev -- Anders Logg Research Assistant Professor Toyota Technological Institute at Chicago http://www.tti-c.org/logg/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308841: Acknowledgement (Mailman threading not working with mailx)
The link I gave to a web page showing the threading before and after the fix is no longer valid. We have rebuilt all our archives with the modified pipermail.py so now the threading is displayed correctly everywhere. /Anders On Thu, May 12, 2005 at 09:48:14AM -0700, Debian Bug Tracking System wrote: Thank you for the problem report you have sent regarding Debian. This is an automatically generated reply, to let you know your message has been received. It is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Tollef Fog Heen [EMAIL PROTECTED] If you wish to submit further information on your problem, please send it to [EMAIL PROTECTED] (and *not* to [EMAIL PROTECTED]). Please do not reply to the address at the top of this message, unless you wish to report a problem with the Bug-tracking system. Debian bug tracking system administrator (administrator, Debian Bugs database) -- Anders Logg Research Assistant Professor Toyota Technological Institute at Chicago http://www.tti-c.org/logg/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308841: Mailman threading not working with mailx
Package: mailman
Version: 2.1.5-8
We have been having some difficulties with getting the threading
working correctly with mailman. When a mail is sent to the mailing
list using the command mailx, the mail is always threaded one level
down.
The problem seems to be that mailx generates Message-ID containing
dash '-' as a separator.
Adding the following line at the end of the function strip_separator()
in /usr/lib/mailman/Mailman/Archiver/pipermail.py seems to fix the
problem:
s = s.replace('-', '.')
See http://www.fenics.org/pipermail/dolfin-dev/2005-May/thread.html
for example output from Mailman (Pipermail) before and after the
change.
Thanks
/Anders Logg
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
