Bug#457075: Salomé packaging
Hello Adam, First, some great news: Salomé was accepted into unstable! Now we can file multiple independent bugs and track all of these issues separately. Excellent! I am really glad to hear it. I feel really sorry for the wrong patch that I sent you, the reason is that I forgot to add the CXXFLAGS=-g in the configure command, I was building VISU without optimizations. I hope that I did not make you loose too much time. Aha! That makes a lot of sense. Don't worry, it didn't take me a lot of time to rebuild the package a couple of times. But this suggests that it might be best to compile only that file using -g so the rest of VISU can still be optimized. What do you think? In fact g++ can be controlled on function inlining. Since my last successful build, I have looked deeper into the problem and I found that g++ inline small template function with -O2. Here I imitate the GetIDMapper definition found in src/CONVERTOR/VISU_MergeFilterUtilities.cxx:705: ... Very interesting! It sounds like with a lot of hard work you've found an important g++ optimization bug... I am not sure if it is a bug. I guess that template function inlining should be controlled when optimizing. I have enclosed you a tested patch for removing template function inlining of GetIDMapper but it should be applied after the commit: f57b74db488c91754eadbca263c065ff2022ac71 Thu May 27 21:56:53 2010 -0400 Timestamp the changelog It means that the last commit should be reverted. I made a successful build of Salome with VISU by using the corresponding Debian rules (that I have enclosed in case you would like to check) but you will see that VISU is configured in the for loop like others modules. Finally I have sent my patch to bug 584172 where a better solution has already been suggested by Denis but requires a new complete build. Now I will try to improve the package organizations and wait for your Salome bug entries on which I can help. By the way, is the 'git-builpackage' command that exports CXXFLAGS to '-O2 -g'? I could not yet understand that step. I believe dpkg-buildpackage sets those flags. But it should be possible to set them locally within debian/rules or Makefile.am. Thank you for the explanation, I have just discovered dpkg-buildflags used by dpkg-buildpackage: $ dpkg-buildflags --get CXXFLAGS -g -O2 Best regards, André 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, #!/usr/bin/make -f # Made with the aid of debmake, by Christoph Lameter, # based on the sample debian/rules file for GNU hello by Ian Jackson. package=salome SALOME_VERSION=5.1.3 # Support multiple makes at once ifneq (,$(filter
Bug#457075: Salomé packaging
Hi Adam,
I've installed your patches, but still have the same build error:
./.libs/libVisuConvertor.so: undefined reference to `vtkIntArray*
VISU::GetIDMapperVISU::TGetPointData(VISU::TFieldList*,
VISU::TGetPointData, char const*)'
collect2: ld returned 1 exit status
It seems like if the problem were the missing -L...TOOLSGUI then there
would have been a missing library instead of a missing symbol... But
then, you were able to get it to build with these changes, so there must
be something I don't understand going on here.
I did install your patches in pieces, not all at once, so I may have
missed something. Can you compare the tree currently in git with your
own, to see if there are some significant differences which would cause
it to not build?
I feel really sorry for the wrong patch that I sent you, the reason
is that I forgot to add the CXXFLAGS=-g in the configure command, I was
building VISU without optimizations. I hope that I did not make you
loose too much time. Since my last successful build, I have looked
deeper into the problem and I found that g++ inline small template
function with -O2. Here I imitate the GetIDMapper definition found in
src/CONVERTOR/VISU_MergeFilterUtilities.cxx:705:
$ cat test.cpp
class Data{
};
template class TData
void
GetIDMapper(TData data)
{
}
void test(void)
{
GetIDMapper(Data());
}
When compiling without optimizations, the GetIDMapper symbol is built:
$ g++ -c test.cpp readelf -s test.o | grep GetIDMapper
... _Z11GetIDMapperI4DataEvT_
However -O2 will inline the template function:
$ g++ -O2 -c test.cpp readelf -s test.o | grep GetIDMapper
For not loosing optimizations on the whole build, I have finally
found that I can control g++:
$ cat test.cpp
class Data{
};
template class TData
__attribute__((noinline))
void
GetIDMapper(TData data)
{
}
void test(void)
{
GetIDMapper(Data());
}
$ g++ -O2 -c test.cpp readelf -s test.o | grep GetIDMapper
... _Z11GetIDMapperI4DataEvT_
So the good new is that I will provide a VISU patch and we can again
configure VISU in the for loop of debian/rules. Will it be possible
to reset the last commit? I deeply apologize for my mistake. For not
reproducing the same problem, I am going to build a new Salome version
and send you patches carefully once everything works.
By the way, is the 'git-builpackage' command that exports CXXFLAGS
to '-O2 -g'? I could not yet understand that step.
Best regards,
André
On Thu, 2010-05-27 at 18:30 +0200, Andre Espaze wrote:
Hello Adam,
I have just succeeded to make a 5.1.3-9 release with VISU, I have
enclosed the 2 patches. I also wanted to let you know that I have
understood the runtime problems of VISU but I need to progress
by steps (my solution is still too messy for being published). I will
first be glad if the -9 release works for you too.
With a fresh sid version, I got a problem on /bin/sh now linked to dash
because autoconf publishes configure scripts with /bin/sh at top but
the KERNEL configure.ac script uses 'function' which is a bash command.
I could not find a solution yet (even by tweaking SHELL and
CONFIG_SHELL).
Then I wonder if doing a:
chmod -x debian/tmp/usr/lib/python2.5/*-packages/salome/*
is a nice idea because you can not list directories any more. I got
this problem while debugging. I will try to provide a solution on that
point by listing required scripts.
Best regards,
André
On Mon, 2010-05-17 at 12:06 +0200, Andre Espaze wrote:
Hi Adam,
Sorry for the lack of news, I was focus on making VISU work. I have
succeeded to build a Salome package however the current result is
unfortunately split from our development line. That's why I will first
explain my steps and then ask your advice on the merge as I saw that
serious reorganizations are also pending.
My goal is to provide a functional Salome package for mechanical
engineering even if incomplete. As a consequence the necessary modules
are for me KERNEL, GUI, GEOM, MED, SMESH and VISU. As VISU was failing
in the build process of debian/rules, I decided to build it by hand by
exporting the necessary environment variables. In that case I only had
to modify the gui-build-in-tree.patch (attached to the mail) for making
the libVISU linking work by adding the path to libToolsGUI.
However, back to the complete debian/rules process, the compilation
was still failing in the VISU CONVERTER library because of an absent
template symbol (probably the same problem described in your mail on
the 25th of January). So I needed to investigate the configure and
build steps of debian/rules but those steps take lot of time. For
easing my researchs, I decided to work on a package building
only the necessary modules which I called salome
Bug#457075: Salomé packaging
Hello Adam, I have just succeeded to make a 5.1.3-9 release with VISU, I have enclosed the 2 patches. I also wanted to let you know that I have understood the runtime problems of VISU but I need to progress by steps (my solution is still too messy for being published). I will first be glad if the -9 release works for you too. With a fresh sid version, I got a problem on /bin/sh now linked to dash because autoconf publishes configure scripts with /bin/sh at top but the KERNEL configure.ac script uses 'function' which is a bash command. I could not find a solution yet (even by tweaking SHELL and CONFIG_SHELL). Then I wonder if doing a: chmod -x debian/tmp/usr/lib/python2.5/*-packages/salome/* is a nice idea because you can not list directories any more. I got this problem while debugging. I will try to provide a solution on that point by listing required scripts. Best regards, André On Mon, 2010-05-17 at 12:06 +0200, Andre Espaze wrote: Hi Adam, Sorry for the lack of news, I was focus on making VISU work. I have succeeded to build a Salome package however the current result is unfortunately split from our development line. That's why I will first explain my steps and then ask your advice on the merge as I saw that serious reorganizations are also pending. My goal is to provide a functional Salome package for mechanical engineering even if incomplete. As a consequence the necessary modules are for me KERNEL, GUI, GEOM, MED, SMESH and VISU. As VISU was failing in the build process of debian/rules, I decided to build it by hand by exporting the necessary environment variables. In that case I only had to modify the gui-build-in-tree.patch (attached to the mail) for making the libVISU linking work by adding the path to libToolsGUI. However, back to the complete debian/rules process, the compilation was still failing in the VISU CONVERTER library because of an absent template symbol (probably the same problem described in your mail on the 25th of January). So I needed to investigate the configure and build steps of debian/rules but those steps take lot of time. For easing my researchs, I decided to work on a package building only the necessary modules which I called salome-core. The working snapshot is available here: http://www.python-science.org/files/salome-core.tar.gz and I have attached the resulting debian/rules which configure every module separately. I could not find the problem in the previous loop configuration. From there two questions arise. First, I like the debian/rules file of salome-core but I remember that you were against such solution for maintenance reasons. Would you like me to adapt it as a loop or did you finally change your mind? From now it seems anyway that VISU needs to be configured separately. Second, could the current salome-core package be a starting point for the reorganizations that we discussed previously? For me it has the main advantage to build only the necessary modules, thus saving time for every run of Salome packaging. However it will require to write several packages (salome-advance and salome-dev). By comparing to the opencascade package, I understand that the whole building should be made in a row and the subpackages splitted by several *.install files. ... - self.CMD=['SALOME_ContainerPy.py','FactoryServerPy'] + self.CMD=['SALOME_Container','FactoryServerPy'] (I have adapted the patch to the current version.) ... I just took care of this, the result is in the alioth git repository. Thank you for the update. Even if the current version work, I would prefer to rename 'SALOME_ContainerPy.py' to 'SALOME_ContainerPy' because '/usr/bin/SALOME_Container' already exists and is finally overwritten in the install step of debian/rules. Even if several points still need to be discussed or adapted, the good point is that we know now how to build a Salome package with the essential modules. Once again, thank you very much for all your efforts. I am going to track the remaining bugs at runtime (some menu do not show up in SMESH, the results can not be seen in VISU). All the best, André -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ commit 79661ecbf3ef61cf184ca76dca1402559aa59aa4 Author: André Espaze andre.esp...@logilab.fr Date: Tue May 11 16:24:43 2010 +0200 Adding TOOLSGUI to GUI_LDFLAGS for building VISU diff --git a/debian/patches/gui-build-in-tree.patch b/debian/patches/gui-build-in-tree.patch index 6fbee7d..9e54e08 100644 --- a/debian/patches/gui-build-in-tree.patch +++ b/debian/patches/gui-build-in-tree.patch @@ -1,8 +1,10 @@ Changes needed to build all modules before installing them. salome-5.1.3/GUI_SRC_5.1.3/adm_local/unix/config_files/check_GUI.m4~ 2010-01-22 19:55
Bug#457075: Salomé packaging
Hi Adam,
Sorry for the lack of news, I was focus on making VISU work. I have
succeeded to build a Salome package however the current result is
unfortunately split from our development line. That's why I will first
explain my steps and then ask your advice on the merge as I saw that
serious reorganizations are also pending.
My goal is to provide a functional Salome package for mechanical
engineering even if incomplete. As a consequence the necessary modules
are for me KERNEL, GUI, GEOM, MED, SMESH and VISU. As VISU was failing
in the build process of debian/rules, I decided to build it by hand by
exporting the necessary environment variables. In that case I only had
to modify the gui-build-in-tree.patch (attached to the mail) for making
the libVISU linking work by adding the path to libToolsGUI.
However, back to the complete debian/rules process, the compilation
was still failing in the VISU CONVERTER library because of an absent
template symbol (probably the same problem described in your mail on
the 25th of January). So I needed to investigate the configure and
build steps of debian/rules but those steps take lot of time. For
easing my researchs, I decided to work on a package building
only the necessary modules which I called salome-core. The working
snapshot is available here:
http://www.python-science.org/files/salome-core.tar.gz
and I have attached the resulting debian/rules which configure
every module separately. I could not find the problem in the
previous loop configuration.
From there two questions arise. First, I like the debian/rules file
of salome-core but I remember that you were against such solution for
maintenance reasons. Would you like me to adapt it as a loop or did you
finally change your mind? From now it seems anyway that VISU needs to be
configured separately. Second, could the current salome-core package be
a starting point for the reorganizations that we discussed previously?
For me it has the main advantage to build only the necessary modules,
thus saving time for every run of Salome packaging. However it will
require to write several packages (salome-advance and salome-dev).
By comparing to the opencascade package, I understand that the whole
building should be made in a row and the subpackages splitted by
several *.install files.
...
- self.CMD=['SALOME_ContainerPy.py','FactoryServerPy']
+ self.CMD=['SALOME_Container','FactoryServerPy']
(I have adapted the patch to the current version.)
...
I just took care of this, the result is in the alioth git repository.
Thank you for the update. Even if the current version work, I would
prefer to rename 'SALOME_ContainerPy.py' to 'SALOME_ContainerPy' because
'/usr/bin/SALOME_Container' already exists and is finally overwritten in
the install step of debian/rules.
Even if several points still need to be discussed or adapted, the
good point is that we know now how to build a Salome package with the
essential modules. Once again, thank you very much for all your efforts.
I am going to track the remaining bugs at runtime (some menu do not show
up in SMESH, the results can not be seen in VISU).
All the best,
André
Changes needed to build all modules before installing them.
diff --git a/GUI_SRC_5.1.3/adm_local/unix/config_files/check_GUI.m4 b/GUI_SRC_5.1.3/adm_local/unix/config_files/check_GUI.m4
index ec07762..73d2eb9 100755
--- a/GUI_SRC_5.1.3/adm_local/unix/config_files/check_GUI.m4
+++ b/GUI_SRC_5.1.3/adm_local/unix/config_files/check_GUI.m4
@@ -59,19 +59,27 @@ if test -f ${SALOME_GUI_DIR}/bin/salome/$1 ; then
SalomeGUI_ok=yes
AC_MSG_RESULT(Using SALOME GUI distribution in ${SALOME_GUI_DIR})
+ GUI_LDFLAGS=-L${SALOME_GUI_DIR}/lib${LIB_LOCATION_SUFFIX}/salome
+ GUI_CXXFLAGS=-I${SALOME_GUI_DIR}/include/salome
+elif test -f ${SALOME_GUI_DIR}/src/$3/$1.cxx ; then
+ SalomeGUI_ok=yes
+ AC_MSG_RESULT(Using SALOME GUI source directory in ${SALOME_GUI_DIR})
+
+ GUI_LDFLAGS=-L${SALOME_GUI_DIR}/src/SUIT -L${SALOME_GUI_DIR}/src/Qtx -L${SALOME_GUI_DIR}/src/VTKViewer -L${SALOME_GUI_DIR}/src/SVTK -L${SALOME_GUI_DIR}/src/OBJECT -L${SALOME_GUI_DIR}/src/SalomeApp -L${SALOME_GUI_DIR}/src/Session -L${SALOME_GUI_DIR}/src/LightApp -L${SALOME_GUI_DIR}/src/OCCViewer -L${SALOME_GUI_DIR}/src/CAM -L${SALOME_GUI_DIR}/src/SOCC -L${SALOME_GUI_DIR}/src/Event -L${SALOME_GUI_DIR}/src/Prs -L${SALOME_GUI_DIR}/src/STD -L${SALOME_GUI_DIR}/src/PyConsole -L${SALOME_GUI_DIR}/src/SPlot2d -L${SALOME_GUI_DIR}/src/Plot2d -L${SALOME_GUI_DIR}/src/ObjBrowser -L${SALOME_GUI_DIR}/src/PyInterp -L${SALOME_GUI_DIR}/src/LogWindow -L${SALOME_GUI_DIR}/src/GLViewer -L${SALOME_GUI_DIR}/src/SUPERVGraph -L${SALOME_GUI_DIR}/src/SUITApp -L${SALOME_GUI_DIR}/src/QxScene -L${SALOME_GUI_DIR}/src/TOOLSGUI
+ GUI_CXXFLAGS=-I${SALOME_GUI_DIR}/src/SVTK -I${SALOME_GUI_DIR}/src/OBJECT -I${SALOME_GUI_DIR}/src/VTKViewer -I${SALOME_GUI_DIR}/src/SUIT -I${SALOME_GUI_DIR}/src/Qtx -I${SALOME_GUI_DIR}/src/SalomeApp -I${SALOME_GUI_DIR}/src/LightApp
Bug#457075: Salomé packaging
Hi Adam, Sorry for the delay, I have missed the -6 release but I have just built the -7 one which works fine. I have updated the documentation on: http://wiki.debian.org/BuildingSalome It seems that building Med dependencies by hand is no longer needed because libmed-2.3.6-2 is now available in Debian sid. I only had one problem during the installation step with the 'salome.desktop' file which did not exist but it may be an error on my side. I will see if I can reproduce it in the next build. First, the -dev dependency extends beyond libsalome-dev. For example, the GEOM module requires libTKOpenGl.so which is in libopencascade-visualization-dev so salome must depend on at least that package as well. There are likely others. Can some of you help me to figure out what is required? If we miss a couple before upload, that's probably okay, we'll just get even more bug reports for these than we otherwise would. :-) I can help on that part once the VISU module is working, I have just added a ticket on the Logilab's project: http://www.python-science.org/ticket/1841 Later we can hopefully modify Salomé's shared lib loading code so it detects the soname at build time and loads that file at runtime, as this is a bug. If anyone can figure out an easy way to do that now, great; otherwise we need to add a few -dev packages to the dependencies. I have added a ticket too: http://www.python-science.org/ticket/1822 but to my point of view such change should be difficult. Second, I've cut the number of lintian warnings by dozens by making the .py files non-executable. The one problem that results is during startup, which can be solved by the following patch: diff --git a/KERNEL_SRC_5.1.3/bin/runSalome.py b/KERNEL_SRC_5.1.3/bin/runSalome.py index d67d6b0..550a6c2 100755 --- a/KERNEL_SRC_5.1.3/bin/runSalome.py +++ b/KERNEL_SRC_5.1.3/bin/runSalome.py @@ -191,7 +191,7 @@ class ContainerPYServer(Server): if sys.platform == win32: self.CMD=[os.environ[PYTHONBIN], '\'+os.environ[KERNEL_ROOT_DIR] + '/bin/salome/SALOME_ContainerPy.py'+'\','FactoryServerPy'] else: - self.CMD=['SALOME_ContainerPy.py','FactoryServerPy'] + self.CMD=['python','/usr/lib/python2.5/site-packages/salome/SALOME_ContainerPy.py','FactoryServerPy'] # --- My python is even worse than my French, so that's the best I can do, but I'm certain there's a better way. Can someone help my pathetic python, hopefully in a way that will be acceptable to upstream? I think that SALOME_ContainerPy.py should be considered as an executable script because its first line starts with: #! /usr/bin/env python As a consequence, it should live inside /usr/bin like others commands so no patch is required. The only reproach to upstream may be to keep the '.py' extension which is confusing because SALOME_ContainerPy is supposed to be a command. I have moved SALOME_ContainerPy.py to /usr/bin and made it executable and Salome was still working. I think that it should be possible to add this behavior to the Debian package during the installation step. What is your opinion on this point? Would you like me to work on a patch? All the best, André -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100505074016.gb20...@crater.logilab.fr
Bug#457075: Salomé packaging
Hi Adam, I guess that it is not relevant to run the 5.1.3-4 build again if this version works for you. I am now starting a complete build with all modules. I've built -5 with everything but VISU and NETGENPLUGIN (which don't build), they're at http://lyre.mit.edu/~powell/salome/ . There's lots more to do, but having a version which runs seems like a big milestone. If you could test it, that would be great. This may even be worth uploading, so it gets started in the NEW queue, and if all goes well we can start using the Debian bug reporting system. It works that time, I only had to export the LD_LIBRARY_PATH variable in runSalome, I have attached the patch. Now that the first version work, I have added the link BuildingSalome to the page: http://wiki.debian.org/DebianScience/Engineering Comments and changes are very welcome. All the best, André -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100422152713.ga24...@crater.logilab.fr
Bug#457075: Salomé packaging
Hi Sylvestre, On Tue, Apr 20, 2010 at 04:18:45PM +0200, Sylvestre Ledru wrote: Le mardi 20 avril 2010 à 15:25 +0200, Andre Espaze a écrit : By the way, have you had any luck with asking upstream to adopt some of these patches? Let me know if you need more information about any of them. I discussed that point with Nicolas yesterday. I am supposed to submit the KERNEL and GUI patches this week. Great! Do you have some information on the potential inclusions of these patches ? Nicolas knows some of the upstream developers so we hope to succeed the inclusions but there is no guarantee. By the way, Christophe Trophime updated the Code Aster packages that Adam and I wrote a while ago. I am going to review them for their inclusions into Debian. I am interested to help on that task once the first Salome version run. Moreover the metis package will also be useful for the MED module of Salome. See you soon, André -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100421080432.gb21...@crater.logilab.fr
Bug#457075: Salomé packaging
Hi Adam,
I guess that it is not relevant to run the 5.1.3-4 build again
if this version works for you. I am now starting a complete build
with all modules.
I've built -5 with everything but VISU and NETGENPLUGIN (which don't
build), they're at http://lyre.mit.edu/~powell/salome/ .
There's lots more to do, but having a version which runs seems like a
big milestone. If you could test it, that would be great. This may
even be worth uploading, so it gets started in the NEW queue, and if all
goes well we can start using the Debian bug reporting system.
It works that time, I only had to export the LD_LIBRARY_PATH variable
in runSalome, I have attached the patch.
I could run Salome with the GEOM, MED, SMESH and YACS modules which
are loaded by default. The MULTIPTR and HELLO modules work too when
added on the command line. The PYHELLO module seems to have a loading
problem but that is a developer example. The remaining modules do not
seem to have a GUI. I plan to work on the VISU module now once the
patches are sent to upstream.
Thank you very much for the great work, I am glad to see a first
working version in Debian.
All the best,
André
commit 30d1a66cc4b1a4023a1397391ed8bdcf570cd50b
Author: Andre Espaze andre.esp...@logilab.fr
Date: Wed Apr 21 09:39:46 2010 +0200
LD_LIBRARY_PATH is required for runSalome
Exporting the variable LD_LIBRARY_PATH is required for starting Salome
even if the variable points to a default research path.
diff --git a/debian/runSalome.in b/debian/runSalome.in
index a7dddb7..a892a75 100644
--- a/debian/runSalome.in
+++ b/debian/runSalome.in
@@ -23,6 +23,7 @@ export PYTHONPATH=$PYTHONPATH:@pythondir@/omniORB:${SALOME_PYTHON_DIR}
# This is a major kludge! But it's necessary for Salome to open with .py files
# in the right place...
export PATH=$PATH:${SALOME_PYTHON_DIR}
+export LD_LIBRARY_PATH=${prefix}/lib:$LD_LIBRARY_PATH
export casro...@prefix@
export CSF_GraphicShr=${CASROOT}/lib/libTKOpenGl.so
export CSF_UnitsLexicon=${CASROOT}/share/opencascade/6.3.0/src/UnitsAPI/Lexi_Expr.dat
Bug#457075: Salomé packaging
Hi Adam, Apologies for the long delay in replying since your message arrived. I've been very busy, and just yesterday finally compiled Salomé. No problem, I have been busy too last week and I am now coming back on Salomé. I made the KERNEL and GUI modules work this morning on the 5.1.3-5 release. I have enclose the patch 'kernel-gui-building.patch' that should be applied on the revision: 862cebe157a4ce50984d6fc15758da7d3ca96e2a Thu Mar 4 20:29:30 2010 Remove troublesome /usr/bin subdirectory from HXX2SALOME. by: patch -p1 kernel-gui-building.patch The steps for running the resulting Salome are provided inside the patch. For me, the main problem was that I did not install the shared librairies stored in the package libsalome-dev. It explains why I could run Salome by ajusting environment variables to debian/tmp/usr but never once installed on the system. Indeed, you found the problem! The shared libraries themselves are not in the -dev package, only the symlinks are, but for some reason the -dev package is required to run Salomé. We'll have to investigate why... Ok, I will add this point to the ticket list. By the way, it is correct to have the line: usr/lib/*.so inside 'debian/libsalome-dev.files'? That's fine: the shared library package gets the real shared libraries *.so.0.0.0 , and -dev gets the symlinks *.so . If the library loading code needs the .so files, then that's something to fix. Thanks for clarifying this point, it makes sense now. I guess that it is not relevant to run the 5.1.3-4 build again if this version works for you. I am now starting a complete build with all modules. I've built -5 with everything but VISU and NETGENPLUGIN (which don't build), they're at http://lyre.mit.edu/~powell/salome/ . I am building it but the test server got a problem during the night so I had to start from the beginning this morning. However I could run the GEOM, MED and SMESH modules without problem on the last build. There's lots more to do, but having a version which runs seems like a big milestone. Yes, I agree. If you could test it, that would be great. This may even be worth uploading, so it gets started in the NEW queue, and if all goes well we can start using the Debian bug reporting system. Excellent, I keep you in touch once I can test. By the way, have you had any luck with asking upstream to adopt some of these patches? Let me know if you need more information about any of them. I discussed that point with Nicolas yesterday. I am supposed to submit the KERNEL and GUI patches this week. Then I will start to review and test the remaining patches but they look fine. I will also try to have a look at the VISU module because post-processing is an important use case. Best regards, André -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100420132527.ga31...@crater.logilab.fr
Bug#457075: Salomé packaging
Hi Adam, Concerning the 5.1.3-5, I can not start Salomé from debian/tmp/usr. The funny point is that I can run Salomé when compiling it by hand in a dedicated directory. An identified problem was the line: chmod -x $(CURDIR)/debian/tmp/usr/lib/python2.5/*-packages/salome/* however I still get the 'Study server is not found' error at startup. I have reached a point where I am comparing the configuration steps, I hope to identify the problem soon. Thanks for your work on this. Between the two of us, I hope we can find out what's breaking this soon... I made the KERNEL and GUI modules work this morning on the 5.1.3-5 release. I have enclose the patch 'kernel-gui-building.patch' that should be applied on the revision: 862cebe157a4ce50984d6fc15758da7d3ca96e2a Thu Mar 4 20:29:30 2010 Remove troublesome /usr/bin subdirectory from HXX2SALOME. by: patch -p1 kernel-gui-building.patch The steps for running the resulting Salome are provided inside the patch. For me, the main problem was that I did not install the shared librairies stored in the package libsalome-dev. It explains why I could run Salome by ajusting environment variables to debian/tmp/usr but never once installed on the system. By the way, it is correct to have the line: usr/lib/*.so inside 'debian/libsalome-dev.files'? I guess that it is not relevant to run the 5.1.3-4 build again if this version works for you. I am now starting a complete build with all modules. Best regards, André commit 82657a24389490922d070d883cb79730caabc69e Author: Andre Espaze andre.esp...@logilab.fr Date: Wed Apr 7 10:43:38 2010 +0200 Building Salome with KERNEL and GUI modules for testing This Salome version is only built with the KERNEL and GUI modules for testing that the graphical server can be started. As a result all references to others modules have been removed as well as any files that will not exist at the end of the build. The only line relevant for others modules is: chmod -x $(CURDIR)/debian/tmp/usr/lib/python2.5/*-packages/salome/* which should be removed or required code modifications. The steps for testing Salome once the git-buildpackage command is finished are: su dpkg -i libsalome5.1.3-0_5.1.3-5_amd64.deb dpkg -i python2.5-salome_5.1.3-5_amd64.deb dpkg -i salome-common_5.1.3-5_all.deb dpkg -i salome_5.1.3-5_amd64.deb dpkg -i libsalome-dev_5.1.3-5_all.deb exit runSalome diff --git a/debian/rules b/debian/rules index 7cee7e3..cc7ac7d 100755 --- a/debian/rules +++ b/debian/rules @@ -25,29 +25,7 @@ endif # - BLSURFPLUGIN, GHS3D[PRL]PLUGIN and HexoticPLUGIN require non-free # libraries, and will not be part of the Debian package. SALOME_MODULES = KERNEL_SRC_$(SALOME_VERSION) \ - GUI_SRC_$(SALOME_VERSION) \ - GEOM_SRC_$(SALOME_VERSION) \ - MED_SRC_$(SALOME_VERSION) \ - VISU_SRC_$(SALOME_VERSION) \ - SMESH_SRC_$(SALOME_VERSION) \ - NETGENPLUGIN_SRC_$(SALOME_VERSION) \ - YACS_SRC_$(SALOME_VERSION) \ - MULTIPR_SRC_$(SALOME_VERSION) \ - COMPONENT_SRC_$(SALOME_VERSION) \ - RANDOMIZER_SRC_$(SALOME_VERSION) \ - SIERPINSKY_SRC_$(SALOME_VERSION) \ - LIGHT_SRC_$(SALOME_VERSION) \ - PYLIGHT_SRC_$(SALOME_VERSION) \ - HELLO_SRC_$(SALOME_VERSION) \ - PYHELLO_SRC_$(SALOME_VERSION) \ - CALCULATOR_SRC_$(SALOME_VERSION) \ - PYCALCULATOR_SRC_$(SALOME_VERSION) \ - HXX2SALOME_SRC_$(SALOME_VERSION) -# XDATA_SRC_$(SALOME_VERSION) \ - BLSURFPLUGIN_SRC_$(SALOME_VERSION) \ - GHS3DPLUGIN_SRC_$(SALOME_VERSION) \ - GHS3DPRLPLUGIN_SRC_$(SALOME_VERSION) \ - HexoticPLUGIN_SRC_$(SALOME_VERSION) + GUI_SRC_$(SALOME_VERSION) clean: dh_testdir @@ -150,22 +128,6 @@ build-indep-stamp: configure-stamp make -C KERNEL_SRC_$(SALOME_VERSION)/doc usr_docs dev_docs -j $(NJOBS) DESTDIR=$(CURDIR)/debian/tmp bindir=/usr/bin libdir=/usr/lib docdir=/usr/share/doc/salome-doc echo; echo GENERATING DOCUMENTATION IN MODULE GUI; echo make -C GUI_SRC_$(SALOME_VERSION)/doc usr_docs dev_docs -j $(NJOBS) DESTDIR=$(CURDIR)/debian/tmp bindir=/usr/bin libdir=/usr/lib docdir=/usr/share/doc/salome-doc - echo; echo GENERATING DOCUMENTATION IN MODULE GEOM; echo - make -C GEOM_SRC_$(SALOME_VERSION)/doc usr_docs dev_docs -j $(NJOBS) DESTDIR=$(CURDIR)/debian/tmp bindir=/usr/bin libdir=/usr/lib docdir=/usr/share/doc/salome-doc - echo; echo GENERATING DOCUMENTATION IN MODULE MED; echo - make -C MED_SRC_$(SALOME_VERSION)/doc dev_docs -j $(NJOBS) DESTDIR=$(CURDIR)/debian/tmp bindir=/usr/bin libdir=/usr/lib docdir=/usr/share/doc/salome-doc - echo; echo GENERATING DOCUMENTATION IN MODULE HELLO; echo - make -C HELLO_SRC_$(SALOME_VERSION)/doc usr_docs -j $(NJOBS) DESTDIR=$(CURDIR)/debian/tmp bindir=/usr/bin libdir=/usr/lib docdir=/usr/share/doc/salome-doc - echo; echo GENERATING DOCUMENTATION IN MODULE PYHELLO; echo - make -C PYHELLO_SRC_$(SALOME_VERSION)/doc usr_docs -j $(NJOBS) DESTDIR=$(CURDIR)/debian/tmp bindir=/usr/bin
Bug#457075: Salomé packaging
Hi Adam, Hi everyone and apologies for the long delay since I last wrote. No problem, I was also busy on others projects but I am back on Salomé for this week and I should work full time on it for the week starting on the 19th of april. I've been getting VirtualBox to work, as suggested by Sylvestre (thanks again!). I spent a while trying to get shared folders to work, then realized just this morning that I could just download stuff from the net, so I finally have a pure unstable environment to (try to) run Salomé. André, I'm having trouble running version 5.1.3-4 from http://lyre.mit.edu/~powell/salome/ -- I get the same error as with more recent versions: Study server is not found. Are you setting some environment variables to make it work? In fact I did not run an installed version because my system could not build the binary packages due to a lack of memory. That is one of the reason why I work now in a virtual machine on a dedicated server. For using the 5.1.3-4, I simply ran: ./debian/rules install and then I have started Salome from the debian/tmp/usr directory by ajusting the environment variables as you did in runSalome. Would you be interested if I run a build of the 5.1.3-4 again? I could try to find back every step. Concerning the 5.1.3-5, I can not start Salomé from debian/tmp/usr. The funny point is that I can run Salomé when compiling it by hand in a dedicated directory. An identified problem was the line: chmod -x $(CURDIR)/debian/tmp/usr/lib/python2.5/*-packages/salome/* however I still get the 'Study server is not found' error at startup. I have reached a point where I am comparing the configuration steps, I hope to identify the problem soon. Best regards, André -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100406120717.ga6...@crater.logilab.fr
Bug#457075: Salomé packaging
Hi Adam, The last working version was actually the -4: c56f196854092f0dc0d222de71de1a4532f214ec Release 5.1.3-4 Look ma, it builds! That's what I thought. I tried that one today (backported to Ubuntu Karmic), and it didn't work. I guess I'll have to bring X up in the chroot to check it there, then start the bisect process. It still does not work but I wanted to let you know where I am. I have worked at revision: 862cebe157a4ce50984d6fc15758da7d3ca96e2a Thu Mar 4 20:29:30 2010 By applying the following patches on the KERNEL module: kernel-safe-include.patch kernel-mpi-includes.patch kernel-mpi-libs.patch kernel-hdf5-needs-mpi.patch kernel-remove-mpi-undefs.patch and: gui-mpich-mpi.patch on the GUI one, it works when installing it by hand in a local directory (I have used ~/sroot/). However it does not work when following the debian/rules install path. I thought that lines 206 and 207 of debian/rules where the problem: mv debian/tmp/usr/bin/*.py \ $(CURDIR)/debian/tmp/usr/lib/python2.5/*-packages/salome/ chmod -x $(CURDIR)/debian/tmp/usr/lib/python2.5/*-packages/salome/* but it is not enough to make it works. For all the processing at line 200, I do not understand where the files are. By running for example: find /usr/ -name config_appli.xml I do not find anything however I can find this file in my local ~/sroot directory. However I may have messed the install process, I am running a new build now. Then I guess that we need to build Salome with hdf5 including mpi because we can not force the user to use libhdf5-serial when he will want to install Salome. Dealing with patches make the debuging harder for getting a first running version but I think that you have solved the problem. I have tried with and without hdf5 and I get the same behavior for the KERNEL part. I keep you in touch once my new version is running, I am getting more confortable with the Debian packaging tools. With kind regards, André -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100311162357.ga22...@crater.logilab.fr
Bug#457075: Salomé packaging
Hi Adam On Thu, 2010-03-04 at 12:12 -0500, Adam C Powell IV wrote: On Thu, 2010-03-04 at 17:36 +0100, Andre Espaze wrote: However, I got a runtime error with my version, the study server is not found even if I only work with the KERNEL and GUI modules. I am going to run a new build at revision: 1a1c81a479c5c021ff685046623831ffc3621ccf Wed Mar 3 17:36:30 I am having the same problem, and don't know how to fix it. I wonder what has changed since you were last able to run it. I guess we should do a git bisect, but given the build time, that will take quite a while! Which was the last version that ran without this error? I'd like to figure out the differences and try to get this working. I've tried a couple of changes to no avail, and this is the last thing keeping me from a -5 release... The last working version was actually the -4: c56f196854092f0dc0d222de71de1a4532f214ec Release 5.1.3-4 Look ma, it builds! Obviously, the KERNEL module works correctly but the GUI one does not want to start. I am compiling the GUI module separately for comparing the build processes. Kind regards, André -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100309162307.ga21...@crater.logilab.fr
Bug#457075: Salomé packaging
Hi Adam, On Tue, 2010-02-23 at 10:05 +0100, Andre Espaze wrote: Until salome is uploaded into Debian, it will not be possible to use the bug tracking system for individual issues. At this point, the only bug in Debian is that salome isn't there -- #457075. :-) Ok, so from now I organise tickets on http://www.python-science.org/project/salome-packaging and I keep you in touch with my progress. Great, thanks. I'm making pretty quick progress (well, as much as can be done in one or two builds per day), I think the first upload should come fairly soon, within a week or so. Ok, today I have worked on your revision: c56f196854092f0dc0d222de71de1a4532f214ec Release 5.1.3-4 Look ma, it builds! of the master branch or do you have another branch that I could follow? That's the current public branch now. I'm working now on my own branch, which doesn't build because of a problem with $(wildcard...) in the rules file which I mentioned on debian-science. I'm testing a possible solution based on Aaron Ucko's reply, and will push everything to alioth if/when it works. Everything works now, so I just pushed a bunch of changes to alioth, including the LIGHT and PYLIGHT CORBA-free GUI modules. Thank you very much for the push, I have succeeded a complete build at revision: 5f1c9676ce493cb5f31f01c8a12c4f697308e2fe Updated time stamp. Fri Feb 26 However I had to set up a virtual machine with 20Go of disk and 1024Mo of RAM on a server. I had finally to move away from the chrooted environment on my local machine. For the installation part, it seems that there is a cyclic dependency between salome and salome-common. Obviously salome-common should not depend on salome. I'm adding MULTIPR now, which should be the last module (XDATA and YACS gave me some trouble, the others have non-free dependencies). Then I'm going to do a .desktop file so it can run from the Applications or KDE menu, and when that's done it should be set to upload! Oh, except for the HDF5 and MED issue. Well, when bug 510057 closes, then it will be ready to upload. For that point and also the packaging steps, I have started a draft of documentation on the mercurial repo: http://hg.python-science.org/salome-packaging/ in the file: debian-packaging.rst It is supposed to end up on the debian wiki. In case you have time to read it, would you have comments? I really feel beginner for the Debian packaging process. Else I have also uploaded the documentation for the modules MED, SMESH and VISU. However, I got a runtime error with my version, the study server is not found even if I only work with the KERNEL and GUI modules. I am going to run a new build at revision: 1a1c81a479c5c021ff685046623831ffc3621ccf Wed Mar 3 17:36:30 I saw that you already fixed the 'killSalome' command problem pointing on python2.4. Kind regards, André -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100304163600.ga31...@crater.logilab.fr
Bug#457075: Salomé packaging
Hi Adam, On Tue, 2010-02-23 at 10:05 +0100, Andre Espaze wrote: Until salome is uploaded into Debian, it will not be possible to use the bug tracking system for individual issues. At this point, the only bug in Debian is that salome isn't there -- #457075. :-) Ok, so from now I organise tickets on http://www.python-science.org/project/salome-packaging and I keep you in touch with my progress. Great, thanks. I'm making pretty quick progress (well, as much as can be done in one or two builds per day), I think the first upload should come fairly soon, within a week or so. Ok, today I have worked on your revision: c56f196854092f0dc0d222de71de1a4532f214ec Release 5.1.3-4 Look ma, it builds! of the master branch or do you have another branch that I could follow? I would like to add such documentation do the salome.git repo, inside the debian directory. I have added the following ticket: http://www.python-science.org/ticket/1403 that will certainly move. Good point. I haven't used the Debian Science Wiki, perhaps that's a good place to put such documentation at this point. Perfect, I will add a page on the wiki as soon as my documentation is ready. I will restart from a clean sid install today. I plan to document every module so it will help me to supply the 'debian/rules' patch of ticket http://www.python-science.org/ticket/1405. Thanks. I just changed from --with-netgen to NETGENHOME so there should be no more unrecognized option warnings. But NETGENPLUGIN doesn't work because of a missing header file. I'm going to work on the netgen package and see if I can get the Salomé interface changes in there without disrupting the existing interface and applications which link to it. Before you start on the patch, let's discuss its utility: how useful will it be to have separate configure commands and a *very* long configure-stamp target in debian/rules, vs. the current loop? I think my preference is the loop because it's short and easy to maintain. I think you are right, I need a documentation for every module because I should build Salome for other distribution as well. However that is not relevant to mix such work with debian/rules. The start of my documentation can be found here: https://hg.python-science.org/salome-packaging/ My suspicion is that the geom issue might due to incorrect directory usage for the OpenCascade data files. I've just added tests for their location in check_cas.m4, and will change KERNEL/bin/appliskel/env.d/envProducts.sh to use the new CAS_LIBDIR and CAS_DATADIR variables accordingly (will need to move it to envProducts.sh.in and have configure generate the .sh file). Unfortunately, I still get the same crash for GEOM with the SIGFPE Arithmetic exception, forcing me to kill Salome. I plan to investigate this problem as soon as the documentation is ready. Thanks. The runSalome script should be working now, if not let me know what kind of errors it gives. It was still crashing but I finally found the problem by exporting: DISABLE_FPE=1 before running Salomé. You may want to look at: https://hg.python-science.org/salome-packaging/rev/8ab11e56314a for more details. By the way, I did not need the variables CASROOT, CSF_GraphicShr, CSF_UnitsLexicon and CSF_UnitsDefinition for running the GEOM module. Moreover in debian/runSalome.in, the variables CSF_UnitsLexicon and CSF_UnitsDefinition seems to point on a wrong path. The correct one should be: share/opencascade/6.3.0/src instead of: share/opencascade but you may use another opencascade package version. I keep you in touch with the build process, I again ran out of disk space today. But thank you very much for all your efforts, I feel that it is going forward. Kind regards, André -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100225161932.ga6...@crater.logilab.fr
Bug#457075: Salomé packaging
Hi Adam, Until salome is uploaded into Debian, it will not be possible to use the bug tracking system for individual issues. At this point, the only bug in Debian is that salome isn't there -- #457075. :-) Ok, so from now I organise tickets on http://www.python-science.org/project/salome-packaging and I keep you in touch with my progress. ... I would like to add such documentation do the salome.git repo, inside the debian directory. I have added the following ticket: http://www.python-science.org/ticket/1403 that will certainly move. Good point. I haven't used the Debian Science Wiki, perhaps that's a good place to put such documentation at this point. Perfect, I will add a page on the wiki as soon as my documentation is ready. I will restart from a clean sid install today. I plan to document every module so it will help me to supply the 'debian/rules' patch of ticket http://www.python-science.org/ticket/1405. You can get and build my latest salome package by the same git clone command but substitute salome for med-fichier. It still needs a lot of tweaking before it is ready to upload into Debian unstable. And first the patched HDF5 package needs to go in, along with the new med-fichier. I have succeeded to build salome at revision 181964c525693f410d01646a616e5d94f05c7c9d but I got only KERNEL and GUI running out of the box at the end. I plan to investigate on the GEOM runtime problem first, is it allright for you? Yes. But please try re-cloning it, I have made a lot of progress, and some things might work now that didn't before. I think your tickets 1398, 1400 and 1402 are fixed now. Congratulations, your Release 5.1.3-4 worked fine and closed those three tickets concerning MED build and install as well as GEOM install. So now the MED and GEOM modules are present when starting Salome. My suspicion is that the geom issue might due to incorrect directory usage for the OpenCascade data files. I've just added tests for their location in check_cas.m4, and will change KERNEL/bin/appliskel/env.d/envProducts.sh to use the new CAS_LIBDIR and CAS_DATADIR variables accordingly (will need to move it to envProducts.sh.in and have configure generate the .sh file). Unfortunately, I still get the same crash for GEOM with the SIGFPE Arithmetic exception, forcing me to kill Salome. I plan to investigate this problem as soon as the documentation is ready. Thank you very much for your explanations on git-buildpackage and the Debian build process, they clarified many points. My main problem in Salome packaging is that the building process is resource intensive and thus takes lot of time. I sometimes also run out of disk space but that is really part of the fun. Best regards, André -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100223090503.gd22...@crater.logilab.fr
Bug#457075: Salomé packaging
Hi Adam, Thank you very much for your fast reply. I am sorry for not being as responsive, I am new to Debian packaging and I am also discovering git. I have succeeded to build most of the Salomé modules with the version 5.1.3-3 that you uploaded at http://lyre.mit.edu/~powell/salome/ however I wanted to discuss the following problems: - the configure step in 'debian/rules' needs to add VTKSUFFIX=-5.4 else vtk is not found and many components do not build. Indeed, I built -3 before VTK 5.4 was in unstable. I am using --with-vtk-version=5.4 which seems to do the same thing. Yes but I have a slight preference for VTKSUFFIX because it avoids such warning in the configure step:: WARNING: unrecognized options: --with-vtk-version when the module does not deal with VTK. Anyway I would like to discuss the configure step in the following ticket: http://www.python-science.org/ticket/1405 - it lacks the omniorb4-nameserver package in the dependency list else the KERNEL component does not find the omniNames command. Okay, the salome binary package needs to depend on this, right? I don't think it needs to be in Build-Depends. Yes you are right and I made a mistake. The omniorb4-nameserver is already in debian/control, I did not know the difference between Build-Depends and Depends. - as you said, the med 2.3.5 library needs to be built manually with hdf5-1.8.4 but the main problem is that tests do not pass in that case. There are patches to hdf5 (bug 510057) and med (bug 566828, fix is in the git repository) to build these two using the default MPI implementation, e.g. OpenMPI on most arches, LAM on others (soon MPICH2, which will require further changes to the current HDF5 package...). The HDF5 team is a bit slow to adopt patches, but hopefully plans for a March freeze will get this done, so MED-MPI and Salomé can get in. Med is running fine with the build instructions that you provided me off list. Thanks for the informations. - it seems to lack the 'config.h' file in the libopencascade-* packages. Else do you know where that file could be? I fear that some components (like GEOM) really need it. Denis replied to this. I didn't notice any problems building GEOM, are there run-time issues which could result from missing this file? - the GEOM module crashes when trying to add a geometrical object I see. Could this be related to the OCC config.h issue? I don't see how... In fact I do not say that the problem is related but I just wanted to check the preprocessor definitions in that file and maybe find some clues. I was afraid that upstream use the '-config config.h' gcc option when building Salome, thus potentially introducing custom definitions. When I compiled Salomé for my first time on Debian Lenny, I got a runtime crash of GEOM because of the NO_CXX_EXCEPTION definition used by OpenCascade. I got it in my build process because I had not set my OpenCascade version correctly (see KERNEL_SRC_5.1.3/salome_adm/unix/config_files/check_cas.m4 for the complete story). I'm impressed that it actually runs -- hadn't tried to run it yet! Yes, it runs, with very few modules (only KERNEL and GUI from now) but that is already a nice start. How to you plan to collaborate on the package building? I would suggest to use the project http://www.python-science.org/project/salome-packaging because I can be efficiently organized on such a platform. Would you like to add a git or mercurial repository on which we will share the package source code? It is already on the Debian Science git repository at http://git.debian.org/git/debian-science/packages/salome.git/ . Thank you, I built Salomé again from that repo. My tickets are there: http://www.python-science.org/project/salome-packaging/0.1 and we can discuss the specific details off list. Cheers, André -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100217103708.ga28...@crater.logilab.fr
Bug#457075: Salomé packaging
I think this is getting into the technical details, so it is probably not so interesting to the debian-science list. I'm afraid I can't figure out a way to set up an account on ww.python-science.org; if you can let me know how then I'll go ahead and use that. A message with your first and last names needs to be send to: nicolas.chau...@logilab.fr However Nicolas just told me that Sylvestre would prefer to use the Debian tracking system. Do you know where should I move the work from http://www.python-science.org/project/salome-packaging? In the meantime, I'd like to let you know how to build the versions of dependencies I'm using. I don't know why the med-fichier tests are failing with HDF5 1.8.4. To build my patched hdf5 package for Debian, you can do the following (in a Debian unstable chroot): apt-get source hdf5 rm -rf hdf5-1.8.4/debian svn co svn://svn.debian.org/svn/pkg-grass/packages/hdf5 cp -a hdf5/trunk/debian hdf5-1.8.4/ wget 'http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=27;filename=hdf5-default-mpi.patch;att=1;bug=510057' -O hdf5-default-mpi.patch cd hdf5-1.8.4/ patch -p0 ../hdf5-default-mpi.patch dpkg-buildpackage Install the resulting .deb packages, particularly libhdf5-mpi-dev which should depend on libhdf5-openmpi-dev. Then you can build the latest med-fichier using: git clone http://git.debian.org/git/debian-science/packages/med-fichier.git -b master cd med-fichier git-buildpackage It should all build correctly. At this point, does this version of med-fichier pass or fail the tests? All the tests pass, that is really great. I would like to add such documentation do the salome.git repo, inside the debian directory. I have added the following ticket: http://www.python-science.org/ticket/1403 that will certainly move. You can get and build my latest salome package by the same git clone command but substitute salome for med-fichier. It still needs a lot of tweaking before it is ready to upload into Debian unstable. And first the patched HDF5 package needs to go in, along with the new med-fichier. I have succeeded to build salome at revision 181964c525693f410d01646a616e5d94f05c7c9d but I got only KERNEL and GUI running out of the box at the end. I plan to investigate on the GEOM runtime problem first, is it allright for you? Then I have some questions regarding the packaging workflow. My main problem is that running:: git-buildpackage --git-ignore-new cleans everything and start from scratch. By the way I had to add the '--git-ignore-new' option but did not understand why. I finally use: ./debian/rules build for building everything after small changes. And: ./debian/rules install for then testing the updated version in debian/tmp. The step that I did not find is how to apply the series of patch once I pull from http://git.debian.org/git/debian-science/packages/salome.git Reading: http://www.debian.org/doc/maint-guide/ch-build.en.html#s-completebuild I did not find the tool. I first thought about the dpatch candidate but the command is not installed on my system so I wonder how git-buildpackage works. André -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100217105932.gb28...@crater.logilab.fr
Bug#457075: Salomé packaging
Hi Adam, I am André Espaze, the Logilab's employee supposed to help you in the Salomé packaging for Debian. First I wanted to thank you for the great work that you did on the current package. Then I would like to let you know my progress on the testing part. I have succeeded to build most of the Salomé modules with the version 5.1.3-3 that you uploaded at http://lyre.mit.edu/~powell/salome/ however I wanted to discuss the following problems: - the configure step in 'debian/rules' needs to add VTKSUFFIX=-5.4 else vtk is not found and many components do not build. - it lacks the omniorb4-nameserver package in the dependency list else the KERNEL component does not find the omniNames command. - as you said, the med 2.3.5 library needs to be built manually with hdf5-1.8.4 but the main problem is that tests do not pass in that case. - it seems to lack the 'config.h' file in the libopencascade-* packages. Else do you know where that file could be? I fear that some components (like GEOM) really need it. - the GEOM module crashes when trying to add a geometrical object You can find all the steps that I did, more details and also more problems at: http://www.python-science.org/ticket/1383 How to you plan to collaborate on the package building? I would suggest to use the project http://www.python-science.org/project/salome-packaging because I can be efficiently organized on such a platform. Would you like to add a git or mercurial repository on which we will share the package source code? I am looking forward to work with you, André On Tue, Jan 26, 2010 at 10:22:12AM -0500, Adam C Powell IV wrote: Sorry, forgot to mention a couple of things yesterday. First, the package doesn't build in current unstable, because HDF5 transitioned and MED didn't transition with it. I may be able to help with MED to resolve this, but not until next week. (It builds fine in my unstable chroot updated a few days ago, but that machine doesn't have enough disk space to build the whole thing.) On Mon, 2010-01-25 at 11:45 -0500, Adam C Powell IV wrote: Now for one problem. The VISU module doesn't completely compile, because of a symbol/prototype incompatibility within its CONVERTER library. I don't know quite enough C++ to fix this, can someone help? Second, the log with this build failure is in http://lyre.mit.edu/~powell/salome/salome_5.1.3-3_amd64.build - search for *** . The relevant files are VISU_SRC_5.1.3/src/CONVERTOR/VISU_MergeFilterUtilities.cxx and .hxx. I don't understand why TGetFieldData in the prototype with the vtkDataSet* argument works for both TGetPointData and TGetCellData but the one with the VISU::TFieldList* argument doesn't... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
