to generate it, I don't remember). What I know is that they
translated the API in english, in addition to other changes, making it
incompatible with the 2.3 API.
Regards,
David
On Sun, Oct 30, 2011 at 3:36 PM, Gilles Filippini p...@debian.org wrote:
Hi David,
David Monfort a écrit , Le 24/10
Hi,
Just for the record, the API of MED has changed in version 3.0 and thus is
not compatible anymore with SYRTHES 3.4 series.
AFAIK, a new version of SYRTHES (version 4) is supposed to be released later
this year (probably in december) with a proper MED 3 support.
You should probably disable
Thanks for finding the bug and for the fix too.
It will be fixed in the next release of libmei.
Just for the record, the suggested fix is (a bit) buggy due to a missing
test at the beginning of the third test (but correct overall !).
Regards,
David
On Mon, Jun 27, 2011 at 4:36 PM, Sebastian
Hi Martin, Sylvestre,
To begin with, sorry for my deafening silence...
A partitioning library (Scotch or Metis) is not required to run parallel
simulation as we have an internal partitioner based on a Space-Filling Curve
algorithm (with, say, a loss of 20 to 30% in terms of CPU time). Thus, the
Hi again,
The issue is different here.
In Debian, MED is compiled against HDF5 with MPI support (even though MED
3.0 do not support parallel I/O), but Code_Saturne preprocessor do not know
about MPI at all. We're planning to improve MED detection soon (not sure in
which version however...). In
Package: libmedc-dev
Version: 2.3.6-5
Severity: grave
Justification: renders package unusable
Hi all,
MED headers (especially med.h) need to use HDF5 headers (especially hdf5.h) to
be usable, but libmedc-dev does not depend on libhdf5-mpi-dev, thus making the
package unusable without installing
Hence I'm thinking about trying other solutions. The easier would be to drop
the version
hard-coding for the official debian package.
As I told you before, I don't think it is appropriate for such Debian
package to handle this.
I would suggest so; dropping the version number seems the best
On Tue, Feb 23, 2010 at 4:35 PM, Petr Salinger petr.salin...@seznam.cz wrote:
Hi,
the fix/workaround/hack bellow
to configure.ac and similar to configure
is sufficient to build code-saturne on kfreebsd-amd64.
Petr
Hi Petr,
Thanks for the fix/workaround/hack !
I'll integrate it upstream,
This assumptions does not hold. On kfreebsd-* the argv[0] usually really
contains the file name of the executable, but only sometimes absolute file
name. The argv[0] is just what have been passed by parent
in execve().
Petr
Hmmm, I see. Thanks a lot for the clarification!
So, it should work
Hi,
Thanks for reporting the issue.
The fix has been applied upstream.
Cheers,
David
On Wed, Nov 25, 2009 at 4:31 AM, Cyril Brulebois k...@debian.org wrote:
Package: libbft
Version: 1.1.1-2
Severity: serious
Tags: patch
Justification: FTBFS
User: debian-...@lists.debian.org
Usertags:
10 matches
Mail list logo
