from:"Andre Espaze"

Bug#587007: salome: Porting patches to Salome 5.1.4 for upstream inclusion

2010-10-13 Thread Andre Espaze

Hi Adam,
 
 First, apologies for the delay in getting back to you on this.  I was
 waiting for an opportunity to sink a good amount of time into reviewing
 your patches, and it didn't come, until I realized this morning that I
 had missed your deadline by a day. :-(
No problem, I understand that you are very busy. Thank you very much for
the review.
 
 On Thu, 2010-09-23 at 12:00 +0200, Andre Espaze wrote:
  Hello Adam,
  
Then what would be the relevant place for submitting patches of the
remaining modules? Is it a good idea to send them to the bugtracker
like I did for the kernel? Or could I let them on the Mercurial
repository of http://www.python-science.org/project/salome-packaging?
   
   I think the Debian bug tracker is better for me, I find it easier to see
   them and give feedback this way, and it's more of a standard Debian way
   of doing things.
  I have enclosed in the 'salome-packaging-0.2.tar.gz' archive the patches
  updated to the 5.1.4 version for the KERNEL, GUI, GEOM, MED, SMESH and
  VISU modules. Once I get your agreement, I plan to send that archive to
  upstream because I am around half way of the porting task, with around
  50 patches on 100. Moreover most of the essential modules are working.
  My concern is now to know which kind of patches are going to be accepted
  before continuing.
  
  The patches come with a documentation explaining briefly their
  meaning. Then the steps on how to build and run every module on Debian
  sid are described. I did not use the tools in the Debian packaging
  system (debian/rules, fakeroot, git-buildpackage, quilt) in order to
  ease the review process. Instead, I imitate the building process
  by listing commands. By that way, I hope that it will be possible
  to discuss with upstream on a specific point by directly using
  the commands provided by their build system.
 
 Thank you for taking on this huge task!  I can see that you've put an
 enormous amount of work into making the patches really helpful for
 upstream.
 
 My only concern about the whole thing is that the -debian-dirs patches
 right now are not in good shape for upstream, so I think we should
 figure out how to make them more generic using libdir and bindir before
 sending them in.  This will be very tricky for source code files, like
 C++ code.  The best way to do this will probably be to use -DBINDIR=...
 and -DLIBDIR=... where those are substituted in the Makefile by
 configure.
Ok, it sounds good.
 
 I'll see about converting those patches in this way.  In the meantime, I
 think everything else is ready to go in.  Thanks again for a great piece
 of work, and apologies again for the delay in getting this feedback to
 you.
Are you working on those patches or may I try to help you? From now,
I understand that I should wait a little more before sending the first
release. By the end of the month, I can also send patches that are ready
to go in if you would prefer that option.

Best regards,

André




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#598421: CVE-2010-3377 -- security problem in a few files

2010-10-13 Thread Andre Espaze

Hello Adam,
 
 There's a security bug in the Debian package for salome due to insecure
 handling of LD_LIBRARY_PATH in a couple of places, bug 598421.
 
 To fix it, I've patched my runSalome script (this does not affect
 upstream runSalome), and several upstream files, and pushed the fixes to
 the alioth repository.
 
 Can you please forward upstream the *-secure-library-path.patch files
 (*=gui, med, yacs)?  Please mention that it fixes Common Vulnerabilities
 and Exposures issue ID CVE-2010-3377 , as mentioned in the patches.
Ok, I plan to submit them with the report on the 5.1.4 version. In case
it is more urgent, just let me know.

All the best,

André



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#587007: salome: Porting patches to Salome 5.1.4 for upstream inclusion

2010-09-23 Thread Andre Espaze

Hello Adam,

  Then what would be the relevant place for submitting patches of the
  remaining modules? Is it a good idea to send them to the bugtracker
  like I did for the kernel? Or could I let them on the Mercurial
  repository of http://www.python-science.org/project/salome-packaging?
 
 I think the Debian bug tracker is better for me, I find it easier to see
 them and give feedback this way, and it's more of a standard Debian way
 of doing things.
I have enclosed in the 'salome-packaging-0.2.tar.gz' archive the patches
updated to the 5.1.4 version for the KERNEL, GUI, GEOM, MED, SMESH and
VISU modules. Once I get your agreement, I plan to send that archive to
upstream because I am around half way of the porting task, with around
50 patches on 100. Moreover most of the essential modules are working.
My concern is now to know which kind of patches are going to be accepted
before continuing.

The patches come with a documentation explaining briefly their
meaning. Then the steps on how to build and run every module on Debian
sid are described. I did not use the tools in the Debian packaging
system (debian/rules, fakeroot, git-buildpackage, quilt) in order to
ease the review process. Instead, I imitate the building process
by listing commands. By that way, I hope that it will be possible
to discuss with upstream on a specific point by directly using
the commands provided by their build system.

I am open on any of your feedback concerning patches or documentation.
Beyond getting the current patches merged into upstream code, my goal is 
to find how to submit changes that can gain acceptance.

All the best,

André



salome-packaging-0.2.tar.gz
Description: Binary data

Bug#595909: salome-dev: add path to adm_local files

2010-09-20 Thread Andre Espaze

Hi Adam,
 
 On Thu, 2010-09-16 at 09:48 +0200, Andre Espaze wrote:
  On Tue, Sep 14, 2010 at 06:20:34PM -0400, Adam C Powell IV wrote:
   On Tue, 2010-09-14 at 11:05 +0200, Andre Espaze wrote:
Package: salome-dev
Version: 5.1.3-11
Severity: wishlist

It will be nice to include adm_local directory for each salome 
base modules
in the salome-dev package. This will greatly simplify the 
developpement and
packaging of new plugins since the configuration step almost 
refers to
MODULE/adm_local.
Otherwise we ave to include some MODULE_SRC in the src package 
for the plugins
(see what I have done for salome-code-aster on svn debian 
science)
   
   This is a good idea.  Right now the package puts the .m4 files all
   together in one big salome.m4 in /usr/share/aclocal (because
   check_KERNEL.m4 and check_GUI.m4 are far too generic names).  
   But
   something like /usr/share/salome/[module]/adm_local or
   just /usr/share/salome/adm_local could include more than just the 
   .m4
   files.
   
   /usr/share/salome/adm_local is the easiest place to put these.  
   Will
   that work for you?
  
  I would rather try to stick as much as possible to the original
  installation. So my feelings are that adm_local from MODULE_SRC 
  should
  be included in /usr/share/salome/MODULE_SRC.
 
 It's pretty easy either way.  André, as someone closer to upstream, 
 what
 do you think makes more sense?  Right now, all of the adm_local files
 install into /usr/adm_local, which violates the FHS.  Should they go
 into a single directory under /usr/share/salome or into separate 
 module
 directories?
To my point of view, installing the .m4 files in separate module 
directories like /usr/share/salome/MODULE_SRC makes more sense with
upstream packaging philosophy. I understand the clearness of a single 
directory like /usr/share/salome/adm_local but I fear conflicts
because all modules do not necessarily share the same macro for a same 
configuration check. 
   
   Well, I think it's a problem that they don't use the same macro in some
   cases, like GUI checks...  But I'll go ahead and do it this way anyway.
  Just for information, the 'geom-use-gui-check.patch' patch is broken
  on the 5.1.4 version because the macros 'CHECK_SALOME_GUI' and
  'CHECK_CORBA_IN_GUI' are now defined in the check_GUI.m4 file of
  the GEOM module.
 
 Yeah, this bugged me, so I tried to get them all to work with the
 version in the GUI module as you suggested.
 
  From now my solution is to give the path
  '${GUI_ROOT_DIR}/adm_local/unix/config_files' as the first argument
  to aclocal in build_configure (but it could be a problem in case
  a macro really needs to be overloaded locally).
Finally I spoke too soon because the modified 'check_GUI.m4' from the
GUI module will be overwritten when installing GEOM (I discovered this
problem only when porting MED). My current workaround is to overwrite
every 'check_GUI.m4' but of course a better solution is needed.
 
 Okay.  Aster and Saturne will need to also use
 ${GUI_ROOT_DIR}/share/salome/${MODULE}_SRC/adm_local/unix/config_files -
 is this path set somewhere, so we can include both of these?
I did not find this path. Do you plan to modify 'debian/rules' in
the installation steps or patch the autotools process? But I may have
misunderstood your idea.

All the best,

André



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#587007: salome: Porting patches to Salome 5.1.4 for upstream inclusion

2010-09-16 Thread Andre Espaze

Hi Adam,

After a long break, I am back on the Salome packaging.

Welcome back! I hope you enjoyed your break.
Sure, it was really nice.

I have enclosed most of the patches for building the KERNEL module with
the 5.1.4 version. Moreover a start of the documentation that I plan
to send for patches submission can be found here:
https://hg.python-science.org/salome-packaging/file/d60a8c2112dc/debian-patch-review.rst

However I wanted to discuss with you on 3 patches that I did not include
because I thought that they concern Debian choices:

- kernel-config-extra.patch

Definitely Debian-only

- kernel-doc-images-svg.patch

Upstream probably won't accept, I haven't seen a big reduction in the
documentation size with this patch (haven't tested though).
Ok, so I will make a try for this one too.

- kernel-install-without-docs.patch

This one is debatable. I think that when most users do make make
install they don't want to go through the entire documentation building
and installation process, so I would ask and see whether they would be
willing to accept this. It certainly saves us a *ton* of build time and
disk space on the autobuilders, as when they only build for their own
arch, there is no reason to build and install the documentation!
Ok, I will try to submit it in that case, saying that is debatable (like
kernel-doc-images-svg.patch).

and this one does not make sense alone because the command is then
renamed in 'debian/rules':

- kernel-python-noexec.patch

I agree.

In case you have arguments or ideas about how to submit them, I will
include them in the report. Now I plan to continue on the following
modules.

I have a couple more which perhaps should not go upstream.
kernel-debian-dirs.patch is obviouis;
Yes but I added it because it is required for illustrating how Salome
is built on Debian and moreover it shows that hard coded paths are
potentially a problem for custom module installations. In case upstream
is interested by such change, I plan to improve it.

also, kernel-mpi-libs.patch uses
the Debian-specific MPI symlink name libmpi++ .
Thanks for the precision, I thought libmpi++ was a standard. However should
we ask for a MPI_LIBS environment variable in the configure script?
It seems that '-lmpio -lmpiCC' is MPICH specific.

In addition, kernel-hdf5-needs-mpi.patch might not be accepted:
Sylvestre tells me that upstream wants to use the serial HDF5 version,
not parallel.
Yes they told me that too, however the changes should not break a serial
HDF5 version.

And they might not accept kernel-replace-csh-stderr.patch
because I think upstream uses csh/tcsh a lot, and I don't think the 2
syntax works there.
Good news for this one, the file:
KERNEL_SRC_5.1.4/src/LifeCycleCORBA/SALOME_LifeCycleCORBA.cxx
uses already the '2' syntax. So the remaining changes should pass.

But kernel-debian-occ.patch *should* go upstream -- it's compatible both
with the traditional OCC install locations, and the Debian/Ubuntu
locations, which are becoming more commonplace and significant.
Yes, I hope too.

Then what would be the relevant place for submitting patches of the
remaining modules? Is it a good idea to send them to the bugtracker
like I did for the kernel? Or could I let them on the Mercurial
repository of http://www.python-science.org/project/salome-packaging?

All the best,

André

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#595909: salome-dev: add path to adm_local files

2010-09-16 Thread Andre Espaze

On Tue, Sep 14, 2010 at 06:20:34PM -0400, Adam C Powell IV wrote:
 On Tue, 2010-09-14 at 11:05 +0200, Andre Espaze wrote:
  Hello Adam and Christophe,
  
  Package: salome-dev
  Version: 5.1.3-11
  Severity: wishlist
  
  It will be nice to include adm_local directory for each salome 
  base modules
  in the salome-dev package. This will greatly simplify the 
  developpement and
  packaging of new plugins since the configuration step almost refers 
  to
  MODULE/adm_local.
  Otherwise we ave to include some MODULE_SRC in the src package for 
  the plugins
  (see what I have done for salome-code-aster on svn debian science)
 
 This is a good idea.  Right now the package puts the .m4 files all
 together in one big salome.m4 in /usr/share/aclocal (because
 check_KERNEL.m4 and check_GUI.m4 are far too generic names).  But
 something like /usr/share/salome/[module]/adm_local or
 just /usr/share/salome/adm_local could include more than just the .m4
 files.
 
 /usr/share/salome/adm_local is the easiest place to put these.  Will
 that work for you?

I would rather try to stick as much as possible to the original
installation. So my feelings are that adm_local from MODULE_SRC should
be included in /usr/share/salome/MODULE_SRC.
   
   It's pretty easy either way.  André, as someone closer to upstream, what
   do you think makes more sense?  Right now, all of the adm_local files
   install into /usr/adm_local, which violates the FHS.  Should they go
   into a single directory under /usr/share/salome or into separate module
   directories?
  To my point of view, installing the .m4 files in separate module 
  directories like /usr/share/salome/MODULE_SRC makes more sense with
  upstream packaging philosophy. I understand the clearness of a single 
  directory like /usr/share/salome/adm_local but I fear conflicts
  because all modules do not necessarily share the same macro for a same 
  configuration check. 
 
 Well, I think it's a problem that they don't use the same macro in some
 cases, like GUI checks...  But I'll go ahead and do it this way anyway.
Just for information, the 'geom-use-gui-check.patch' patch is broken
on the 5.1.4 version because the macros 'CHECK_SALOME_GUI' and
'CHECK_CORBA_IN_GUI' are now defined in the check_GUI.m4 file of
the GEOM module. From now my solution is to give the path
'${GUI_ROOT_DIR}/adm_local/unix/config_files' as the first argument
to aclocal in build_configure (but it could be a problem in case
a macro really needs to be overloaded locally).
In case you already have a solution for using the same macro, I will
gladly port it to the 5.1.4 version.


André



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#587007: salome: Porting patches to Salome 5.1.4 for upstream inclusion

2010-09-14 Thread Andre Espaze

Hi Adam,

After a long break, I am back on the Salome packaging. I was pleased
to discover all your advances and the new building process for every
module. Thank you very much for all your efforts. I think that it is
the right time to start porting the patches to Salome 5.1.4 so we can
submit them to upstream before a new release.

I have enclosed most of the patches for building the KERNEL module with
the 5.1.4 version. Moreover a start of the documentation that I plan
to send for patches submission can be found here:
https://hg.python-science.org/salome-packaging/file/d60a8c2112dc/debian-patch-review.rst

However I wanted to discuss with you on 3 patches that I did not include
because I thought that they concern Debian choices:

- kernel-config-extra.patch
- kernel-doc-images-svg.patch
- kernel-install-without-docs.patch

and this one does not make sense alone because the command is then
renamed in 'debian/rules':

- kernel-python-noexec.patch

In case you have arguments or ideas about how to submit them, I will
include them in the report. Now I plan to continue on the following
modules.

All the best,

André

Allow a separate MPI include directory (used by Debian's /usr/include/mpi link)

Index: salome/KERNEL_SRC_5.1.4/salome_adm/unix/config_files/check_mpi.m4
===
--- a/KERNEL_SRC_5.1.4/salome_adm/unix/config_files/check_mpi.m4
+++ b/KERNEL_SRC_5.1.4/salome_adm/unix/config_files/check_mpi.m4
@@ -28,6 +28,10 @@ AC_ARG_WITH(mpi_lib,
[AC_HELP_STRING([--with-mpi_lib=DIR],[directory path of MPICH lib installation])],
MPILIBREQUESTED=$withval)
 
+AC_ARG_WITH(mpi_include,
+   [AC_HELP_STRING([--with-mpi_include=DIR],[directory path of MPICH header file installation])],
+   MPIINCLUDEREQUESTED=$withval)
+
 AC_ARG_WITH(mpi,
[AC_HELP_STRING([--with-mpi=DIR],[root directory path of MPICH installation])],
MPIREQUESTED=yes,MPIREQUESTED=no)
@@ -59,6 +63,10 @@ if test x$MPIREQUESTED = xyes; then
 MPI_LIBS=-L$MPILIBREQUESTED
   fi
 
+  if test x$MPIINCLUDEREQUESTED != x; then
+MPI_INCLUDES=-I$MPIINCLUDEREQUESTED
+  fi
+
   CPPFLAGS_old=$CPPFLAGS
   CPPFLAGS=$MPI_INCLUDES $CPPFLAGS
   AC_CHECK_HEADER(mpi.h,WITHMPI=yes,WITHMPI=no)
Debian-specific patch to use our libmpi++.so alternatives symlink.

Index: salome/KERNEL_SRC_5.1.4/salome_adm/unix/config_files/check_mpi.m4
===
--- a/KERNEL_SRC_5.1.4/salome_adm/unix/config_files/check_mpi.m4
+++ b/KERNEL_SRC_5.1.4/salome_adm/unix/config_files/check_mpi.m4
@@ -85,7 +85,7 @@ if test x$MPIREQUESTED = xyes; then
 
   if test $WITHMPI = yes;then
 mpi_ok=yes
-MPI_LIBS=$MPI_LIBS -lmpi -lmpio -lmpiCC
+MPI_LIBS=$MPI_LIBS -lmpi -lmpi++
   else
 mpi_ok=no
   fi
The HDF5 library requires MPI in order to work, so the MPI check needs to go
first, and the MPI variables need to be in the HDF5 check.

Index: salome/KERNEL_SRC_5.1.4/salome_adm/unix/config_files/check_hdf5.m4
===
--- a/KERNEL_SRC_5.1.4/salome_adm/unix/config_files/check_hdf5.m4
+++ b/KERNEL_SRC_5.1.4/salome_adm/unix/config_files/check_hdf5.m4
@@ -66,7 +66,7 @@ fi
 dnl hdf5 headers
 
 CPPFLAGS_old=$CPPFLAGS
-CPPFLAGS=$CPPFLAGS $LOCAL_INCLUDES
+CPPFLAGS=$CPPFLAGS $MPI_INCLUDES $LOCAL_INCLUDES
 AC_CHECK_HEADER(hdf5.h,hdf5_ok=yes ,hdf5_ok=no)
 CPPFLAGS=$CPPFLAGS_old
 
@@ -77,7 +77,7 @@ then
 dnl hdf5 library
 
   LIBS_old=$LIBS
-  LIBS=$LIBS $LOCAL_LIBS
+  LIBS=$LIBS $MPI_LIBS $LOCAL_LIBS
   AC_CHECK_LIB(hdf5,H5open,hdf5_ok=yes,hdf5_ok=no)
   LIBS=$LIBS_old
 
@@ -85,9 +85,9 @@ fi
 
 if  test x$hdf5_ok = xyes
 then
-  HDF5_INCLUDES=$LOCAL_INCLUDES
-  HDF5_LIBS=$LOCAL_LIBS -lhdf5 $LOCAL_RLIBS
-  HDF5_MT_LIBS=$LOCAL_LIBS -lhdf5 $LOCAL_RLIBS
+  HDF5_INCLUDES=$MPI_INCLUDES $LOCAL_INCLUDES
+  HDF5_LIBS=$MPI_LIBS $LOCAL_LIBS -lhdf5 $LOCAL_RLIBS
+  HDF5_MT_LIBS=$MPI_LIBS $LOCAL_LIBS -lhdf5 $LOCAL_RLIBS
 fi
 
 if  test x$hdf5_ok = xyes
Index: salome/KERNEL_SRC_5.1.4/configure.ac
===
--- a/KERNEL_SRC_5.1.4/configure.ac
+++ b/KERNEL_SRC_5.1.4/configure.ac
@@ -222,6 +222,14 @@ echo
 
 CHECK_LIBXML
 
+echo
+echo -
+echo checking if MPI is requested by user
+echo -
+echo
+
+CHECK_MPI
+
 if test x$with_onlylauncher = xno; then
 echo
 echo -
@@ -303,14 +311,6 @@ echo
 
 echo
 echo -
-echo checking if MPI is requested by user
-echo -
-echo
-
-CHECK_MPI
-
-echo
-echo -
 echo checking if PaCO++ is requested by user
 echo -
 echo
Remove unnecessary extern C instances and add one necessary one.
Background: One must not #include mpi.h from

Bug#595909: salome-dev: add path to adm_local files

2010-09-14 Thread Andre Espaze

Hello Adam and Christophe,

Package: salome-dev
Version: 5.1.3-11
Severity: wishlist

It will be nice to include adm_local directory for each salome base 
modules
in the salome-dev package. This will greatly simplify the developpement 
and
packaging of new plugins since the configuration step almost refers to
MODULE/adm_local.
Otherwise we ave to include some MODULE_SRC in the src package for the 
plugins
(see what I have done for salome-code-aster on svn debian science)
   
   This is a good idea.  Right now the package puts the .m4 files all
   together in one big salome.m4 in /usr/share/aclocal (because
   check_KERNEL.m4 and check_GUI.m4 are far too generic names).  But
   something like /usr/share/salome/[module]/adm_local or
   just /usr/share/salome/adm_local could include more than just the .m4
   files.
   
   /usr/share/salome/adm_local is the easiest place to put these.  Will
   that work for you?
  
  I would rather try to stick as much as possible to the original
  installation. So my feelings are that adm_local from MODULE_SRC should
  be included in /usr/share/salome/MODULE_SRC.
 
 It's pretty easy either way.  André, as someone closer to upstream, what
 do you think makes more sense?  Right now, all of the adm_local files
 install into /usr/adm_local, which violates the FHS.  Should they go
 into a single directory under /usr/share/salome or into separate module
 directories?
To my point of view, installing the .m4 files in separate module 
directories like /usr/share/salome/MODULE_SRC makes more sense with
upstream packaging philosophy. I understand the clearness of a single 
directory like /usr/share/salome/adm_local but I fear conflicts
because all modules do not necessarily share the same macro for a same 
configuration check. 

All the best,

André



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#587007: salome: Porting patches to Salome 5.1.4 for upstream inclusion

2010-06-30 Thread Andre Espaze

Hello Adam,

...
 The second issue is the Debian constraint to build Salome with a HDF5
 library needing MPI. The corresponding patches (kernel-hdf5-needs-mpi.patch,
 kernel-mpi-includes.patch, kernel-mpi-libs.patch and so on) are
 not so welcomed by upstream.

Really?  Did they give an indication of why?  Well, that's a relatively
small patch for us to maintain.
From what I understood, building hdf5 with MPI is considered as
unsupported. But I think that we can submit those patches and see
if their politics change for a next release.

 Hopefully an alternative way of using
 HDF5 may be provided as suggested by Sylvestre:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576004

 Thanks.  Unfortunately, the HDF5 group tends to take a long time to
 respond to such requests (often many months, even when a patch is
 available), so we shouldn't count on this to happen before our next
 upload.
I have to confess that I had better hope on that point.

...
 In conclusion what could be the organization for welcoming the future
 Salome 5.1.4 release? Should it be progressively ported on a separate
 branch by using the up-to-date sources [2]? Or would you prefer a one-shot
 transition from 5.1.3?

 If upstream is not going to accept patches before 5.1.4, then I think
 the one-shot transition makes the most sense.  But I appreciate your
 examination of the upstream git repository to determine in advance what
 changes we will need to make in order to port our patches to 5.1.4.
Ok, it sounds fine to me. I am going to be unavailable until the end of
August, then I can try the 5.1.4 transition at the beginning of September
if needed.
By the way, the 5.1.4 Salome version is now available at:
http://www.salome-platform.org/downloads/salome-v5.1.4

All the best,

André




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#587007: salome: Porting patches to Salome 5.1.4 for upstream inclusion

2010-06-24 Thread Andre Espaze

Package: salome
Version: 5.1.3-10
Severity: wishlist

Last week, Nicolas Chauvat, Sylvestre Ledru, Christophe Trophime and
I met some of the Salome upstream developers in Paris (at Logilab).
We presented the current patches [1] on Salomé 5.1.3 for upstream
inclusion. They are not going to be accepted for this release however most
of them have certainly good chances if they get ported to the upcoming
Salomé 5.1.4. We were invited to try by using the up-to-date version
[2].  I have started to have a look on the main modules, KERNEL, GUI,
GEOM, MED, SMESH and VISU and it seems that most of the patches are
still relevant even if they need to be updated.

However two important maintenance points should be considered when
porting actual patches to the future Salomé 5.1.4. The first is that the
'\*-build-in-tree.patch' family is very unlikely to be accepted. The
packaging process should instead configure, build and install each
module one by one like in the official way. Happily, this advice fits
also one of the Denis Barbier's suggestion for reducing the hard disk
space during Salome building by cleaning every module built directory
after its installation. Would the upstream request be an accelerator
for reorganizing the construction steps?
The second issue is the Debian constraint to build Salome with a HDF5 
library needing MPI. The corresponding patches (kernel-hdf5-needs-mpi.patch,
kernel-mpi-includes.patch, kernel-mpi-libs.patch and so on) are
not so welcomed by upstream. Hopefully an alternative way of using
HDF5 may be provided as suggested by Sylvestre:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576004

In conclusion what could be the organization for welcoming the future
Salome 5.1.4 release? Should it be progressively ported on a separate
branch by using the up-to-date sources [2]? Or would you prefer a one-shot
transition from 5.1.3? In order to ease the upstream acceptance, I plan
to write a small report in French for explaining every patch purpose
(for the 5.1.3 version, I already did one for KERNEL and GUI modules
but its delivery is finally delayed).

With kind regards,

André

[1] Found in debian/patches of 
http://git.debian.org/git/debian-science/packages/salome.git 
[2] The sources can be obtained with git 
http://git.salome-platform.org/gitweb/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#587025: salome: Packaging Code Aster module for Salome

2010-06-24 Thread Andre Espaze

Package: salome
Severity: wishlist

The Salome Meca platform has recently been released, see [1].  An archive
made of binaries is available with Salome 5.1.3, Code Aster 10.1 and
the ASTER module for Salome. The latter allows to use some of the Code
Aster functionalities from Salome.

As Salome is already packaged and Code Aster is on the way [2], the Salome
Meca platform ships only three relevant modules written in Python:

- ASTER (allowing to run the Code Aster solver)
- EFICAS (for editing Code Aster files)
- PAL (an EFICAS dependency)

Their sources should be published in a near future on the Code Aster
website [3] and it could then be interesting to bring them to a
salome-meca package. 

With kind regards,

André

[1] http://www.code-aster.org/V2/spip.php?article295
[2] The current version can be browsed at:
http://svn.debian.org/wsvn/debian-science/packages/code-aster/
[3] http://www.code-aster.org



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#584586: Update needed to debian/control

2010-06-10 Thread Andre Espaze

Hi Adam,

While the commit d74f067fc25ed4168473890db05eb74d3932c37a succeeded to
merge libsalome and python2.5-salome into the salome package, it seems
that debian/control was not updated accordingly.
python2.5-salome and libsalome-dev can still be found in the Depends
section of the salome package defined in debian/control. From now,
the solution is to install the salome package by transforming
dependences errors into warnings:

dpkg --force-depends -i salome_5.1.3-9_amd64.deb


All the best,

André

By the way, should I keep you in copy or do you receive any Salomé bug
update automatically?



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#584172: Disabling GetIDMapper inlining for building VISU

2010-06-07 Thread Andre Espaze

Hello Denis,

On Wed, Jun 02, 2010 at 02:13:51PM +0200, Denis Barbier wrote:
 On 2010/6/2 Andre Espaze wrote:
 [...]
  Your solution is however better because the exported symbols
  are in control while in my case I remove every GetIDMapper function
  inlining.
 [...]
 
 It seems that there is some disagreement between us, I believe that
 the sentence above is the root cause.  You say that my solution gives
 a better control on symbols which are exported, but my opinion is that
 both solutions provide the exact same API.  Can you please explain the
 differences induced by those patches?  (For instance by running
 objdump, readelf,... on generated libraries and comparing output)
 Thanks.

Sure, I am going to show the problem on real librairies. I had first
imitated it by the test.cpp code provided in bug 457075, see:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457075#400
From the beginning, the problem is specific to g++ optimizations 
that's why I wanted to reflect that fact in my patch. Am I wrong
on that point? The disagreement is maybe just here.

I assume that you run git-buildpackage on the revision 
f57b74db488c91754eadbca263c065ff2022ac71, thus the build has failed
with the status message given by Adam in that bug entry.
The relevant code is in the CONVERTOR directory of the VISU module:

$ cd VISU_SRC_5.1.3/src/CONVERTOR

The VISUConvertor can not be built because GetIDMapper symbols do not exist.
You can check the problem in the corresponding module:

$ readelf -s .libs/libVisuConvertor_la-VISU_MergeFilterUtilities.o | \ 
grep GetIDMapper

However if you remove the O2 optimizations in the CXXFLAGS of the Makefile
(by first making a backup):

$ cp Makefile Makefile.orig
$ sed -i s/^CXXFLAGS = .*/CXXFLAGS = -D_OCC64 -g -D_DEBUG_ -pthread/ \
Makefile

and then force the module to be built again:

$ rm libVisuConvertor_la-VISU_MergeFilterUtilities.lo
$ make

it will work. Now if you check the exported symbols:

$ readelf -s .libs/libVisuConvertor_la-VISU_MergeFilterUtilities.o | \
grep GetIDMapper
759:    113 FUNCWEAK   DEFAULT  395 
_ZN4VISU11GetIDMapperINS_
769:    113 FUNCWEAK   DEFAULT  411 
_ZN4VISU11GetIDMapperINS_
879:    259 FUNCWEAK   DEFAULT  569 
_ZN4VISU11GetIDMapperINS_
880:    259 FUNCWEAK   DEFAULT  571 
_ZN4VISU11GetIDMapperINS_

you should have 4 entries. At that step, I understood that the upstream
code is valid C++ (but not necessarily robust) and thus I wanted to provide
a patch controlling g++ optimizations while respecting their coding style.
That's why you can find the 'if' statements since the beginning. My patch
no-template-function-inline will remove every template function inlining
of GetIDMapper when compiling with O2 optimizations:

$ cd ../../..
$ patch -p1  no-template-function-inline.patch 
$ patch -p1  debian/patches/visu-no-template-inline.patch
$ cd VISU_SRC_5.1.3/src/CONVERTOR
$ mv Makefile.orig Makefile
$ make
$ readelf -s .libs/libVisuConvertor_la-VISU_MergeFilterUtilities.o | \
grep GetIDMapper
89:    113 FUNCWEAK   DEFAULT   48 
_ZN4VISU11GetIDMapperINS_
95: 54 FUNCWEAK   DEFAULT   50 
_ZN4VISU11GetIDMapperINS_
96: 54 FUNCWEAK   DEFAULT   52 
_ZN4VISU11GetIDMapperINS_
97:    113 FUNCWEAK   DEFAULT   54 
_ZN4VISU11GetIDMapperINS_
 
Finally your solution will only export the needed GetIDMapper symbol:

$ git checkout HEAD VISU_MergeFilterUtilities.hxx
$ cd ../../..
$ patch -p1  visu-template-export.patch
$ cd VISU_SRC_5.1.3/src/CONVERTOR
$ make 
$ readelf -s .libs/libVisuConvertor_la-VISU_MergeFilterUtilities.o | \
grep GetIDMapper
68:    113 FUNCWEAK   DEFAULT   26 
_ZN4VISU11GetIDMapperINS_

I agree with you that your solution is valid and robust C++ code so the 
if statements could be removed no matter if the code is compiled with 
or without optimizations or even with others compilers. But I think that
such a decision should be made by upstream because we discovered the 
problem only when working with g++ O2 optimizations. I am open to further
explanations if needed.

Best regards,

André




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#584124: salome: fails to install (tries to overwrite '/usr/bin/display'

2010-06-07 Thread Andre Espaze

Hi Adam,
 

 
  Are those libraries private to salome?  (In other words, are you sure
  that no other package will be linked against them?)
* If yes, there is no reason to provide libsalome5.1.3-0 and
  libsalome-dev packages, these libs are shipped by another package
  (python2.5-salome?) and can safely be moved into /usr/lib/salome/
* If no, they should indeed go into /usr/lib/ but name collisions will 
  happen.
  Maybe the answer is a mix of both, some libs are private and some
  others are public.
 
 I was thinking the same thing.  Back to André: are there libraries which
 are meant to be shared with other packages, or are they all private to
 Salomé?
To my point of view, all librairies should be private to Salomé. I agree
with the first solution, there is no need to provide libsalome* and
python2.5-salome.
 
  BTW when looking at this issue, I found that python2.5-salome contains
  shared libraries, it thus must be arch:any and not arch:all.  It also
  contains static libraries which can surely be dropped.
  BTW2, I wonder whether salome, python2.5-salome, libsalome5.1.3-0 and
  libsalome-dev could be merged into a single package (if all libs are
  private, of course).
 
 Indeed.  There's still value in having a separate -common package, to
 reduce archive disk footprint.  I'll first try to get the new paths
 working, then do this merger, and upload, then we can think about
 splitting things up differently.  (core, extras, dev, test)
Excellent. I saw anyway that you have just opened bug 584590 where 
we are going to try to solve that problem.

Best regards,

André




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#584172: Disabling GetIDMapper inlining for building VISU

2010-06-07 Thread Andre Espaze

On Mon, Jun 07, 2010 at 06:06:58PM +0200, Denis Barbier wrote:
 On 2010/6/7 Andre Espaze wrote:
 [...]
     $ patch -p1  no-template-function-inline.patch
     $ patch -p1  debian/patches/visu-no-template-inline.patch
 
 Thanks André for these detailed explanations, but why do you apply
 both patches?  
If you check out revision f57b74db488c, visu-no-template-inline.patch
does not exist yet, so the first patch adds it. 

 I thought that visu-no-template-inline.patch was
 superseding no-template-function-inline.patch. (Adam too since he
 committed only the former)
Yes, no-template-function-inline.patch was only a way to apply my changes
to Adam's repository (we decided to work like that since the beginning so
Adam can review every patch and I do not need write access).

 To make it clear, my point is that #if macro can be dropped from
 visu-no-template-inline.patch, the result will be unchanged:
  * When compiled in debug mode, functions are not inlined and 4
 symbols are exported.
  * When compiled with optimization, only one symbol is exported.
 Since those macros do nothing, it is better to strip them off and
 follow what is described in the C++ faq.
Ok but what about respecting the upstream coding style? Moreover
the macros do nothing only when using g++. I am fine to remove
the if macros but I think that we will need to provide upstream
with more explanations.
 
 If you want no-template-function-inline.patch to be applied, then
 visu-no-template-inline.patch should be dropped.
No, no-template-function-inline.patch is only a communication tool.
I am sorry if it has created confusion. The only patch
that matters for us is visu-no-template-inline.patch. However I did 
not want to add one more patch to the bug and for describing 
reproductible steps I needed to introduce
no-template-function-inline.patch.
 
     $ cd VISU_SRC_5.1.3/src/CONVERTOR
     $ mv Makefile.orig Makefile
     $ make
     $ readelf -s .libs/libVisuConvertor_la-VISU_MergeFilterUtilities.o | \
     grep GetIDMapper
     89:    113 FUNC    WEAK   DEFAULT   48 
  _ZN4VISU11GetIDMapperINS_
     95:     54 FUNC    WEAK   DEFAULT   50 
  _ZN4VISU11GetIDMapperINS_
     96:     54 FUNC    WEAK   DEFAULT   52 
  _ZN4VISU11GetIDMapperINS_
     97:    113 FUNC    WEAK   DEFAULT   54 
  _ZN4VISU11GetIDMapperINS_
 [...]
 
 These symbols are exported because of
 no-template-function-inline.patch, not visu-no-template-inline.patch.
Isn't is the opposite? no-template-function-inline.patch modifies the
Debian repo while visu-no-template-inline.patch modifies the Salome sources.

André



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#584172: Disabling GetIDMapper inlining for building VISU

2010-06-02 Thread Andre Espaze

It is finally not necessary to build the module with the -g option,
I have enclosed a patch that disable the GetIDMapper function inlining
when built with g++ and optimizations.


commit 73f793cb0076b6847fc17750a5e1511af502e06c
Author: André Espaze andre.esp...@logilab.fr
Date:   Tue Jun 1 16:53:53 2010 +0200

No GetIDMapper inlining when building VISU

The template function GetIDMapper should not be inlined by g++ when
compiling with optimizations (the Debian build system used -O2) because
the VISUConvertor command needs to link with the resulting symbol
contained in libVisuConvertor.so. The patch is provided in:
	debian/patches/visu-no-template-inline.patch
and will be applied by quilt thanks to the list:
	debian/patches/series

diff --git a/debian/patches/series b/debian/patches/series
index 524b45d..d280ec5 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -26,6 +26,7 @@ med-fix-clean.patch
 visu-hdf5-needs-mpi.patch
 visu-build-in-tree.patch
 visu-flags-typo.patch
+visu-no-template-inline.patch
 visu-fix-clean.patch
 smesh-hdf5-needs-mpi.patch
 smesh-use-gui-check.patch
diff --git a/debian/patches/visu-no-template-inline.patch b/debian/patches/visu-no-template-inline.patch
new file mode 100644
index 000..ead1d55
--- /dev/null
+++ b/debian/patches/visu-no-template-inline.patch
@@ -0,0 +1,28 @@
+The template function GetIDMapper should not be inlined by g++ when
+compiling with optimizations (the Debian build system used -O2) because
+the VISUConvertor command needs to link with the resulting symbol
+contained in libVisuConvertor.so.
+
+diff --git a/VISU_SRC_5.1.3/src/CONVERTOR/VISU_MergeFilterUtilities.hxx b/VISU_SRC_5.1.3/src/CONVERTOR/VISU_MergeFilterUtilities.hxx
+index 52f7440..e4f63ae 100755
+--- a/VISU_SRC_5.1.3/src/CONVERTOR/VISU_MergeFilterUtilities.hxx
 b/VISU_SRC_5.1.3/src/CONVERTOR/VISU_MergeFilterUtilities.hxx
+@@ -93,12 +93,18 @@ namespace VISU
+ TObjectId2TupleGaussIdMap theObjectId2TupleGaussIdMap);
+   
+   templateclass TGetFieldData
++#if (__GNUG__  __OPTIMIZE__)
++  __attribute__((noinline))
++#endif
+   vtkIntArray*
+   GetIDMapper(VISU::TFieldList* theFieldList,
+ 	  TGetFieldData theGetFieldData,
+ 	  const char* theFieldName);
+ 
+   templateclass TGetFieldData
++#if (__GNUG__  __OPTIMIZE__)
++  __attribute__((noinline))
++#endif
+   vtkIntArray*
+   GetIDMapper(vtkDataSet* theIDMapperDataSet,
+ 	  TGetFieldData theGetFieldData,

Bug#584172: Disabling GetIDMapper inlining for building VISU

2010-06-02 Thread Andre Espaze

Hello Denis,

On Wed, Jun 02, 2010 at 10:30:15AM +0200, Denis Barbier wrote:
 On 2010/6/2 Andre Espaze wrote:
  It is finally not necessary to build the module with the -g option,
  I have enclosed a patch that disable the GetIDMapper function inlining
  when built with g++ and optimizations.
 
 I am no C++ expert, but this looks very similar to
http://www.parashift.com/c++-faq-lite/templates.html#faq-35.13
 and it is thus not clear whether this is really a g++ bug.
 Here is a different fix, I tested this approach with Andre's
 test.cpp, but not with salome.
Thank you very much for the suggestion, it works but it seems to 
me that you forgot a 'template' keyword before the symbol export.
I have enclosed a patch tested on my machine, fell free to correct
it if I was wrong. 
For the -9 release, I am anyway going to submit my change to Adam
for getting a working version with VISU. A full build will again
be required because other symbol exports may be needed in other 
modules. Your solution is however better because the exported symbols
are in control while in my case I remove every GetIDMapper function
inlining.
I am neither a C++ expert but I found the FAQ entry different
from our case because the symbol gets exported without -O2 
optimizations. I would not say that it is a g++ bug because
I think that you should control inlining when optimizing
(as I have done in my first patch). However your solution is right and
succeeds to export template function symbols with optimizations.
Once again thank you because I would not have figured it out myself.

Best regards,

André

diff --git a/VISU_SRC_5.1.3/src/CONVERTOR/VISU_MergeFilterUtilities.cxx b/VISU_SRC_5.1.3/src/CONVERTOR/VISU_MergeFilterUtilities.cxx
index 126effb..89d1b50 100755
--- a/VISU_SRC_5.1.3/src/CONVERTOR/VISU_MergeFilterUtilities.cxx
+++ b/VISU_SRC_5.1.3/src/CONVERTOR/VISU_MergeFilterUtilities.cxx
@@ -718,7 +718,12 @@ namespace VISU
 }
 return NULL;
   }
-
+  // Explicit symbol export when compiling with g++ and optimizations,
+  // needed by VISUConvertor during linking
+  #if (__GNUG__  __OPTIMIZE__)
+  template vtkIntArray*
+  GetIDMapperTGetPointData(TFieldList*, TGetPointData, const char* );
+  #endif
 
   //---
   templateclass TGetFieldData

37 matches

Mail list logo