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
Bug#457075: Salomé packaging
Hello Andre,
First, some great news: Salomé was accepted into unstable! Now we can
file multiple independent bugs and track all of these issues separately.
On Tue, 2010-06-01 at 10:53 +0200, Andre Espaze wrote:
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.
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?
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_
Very interesting! It sounds like with a lot of hard work you've found
an important g++ optimization bug...
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.
Sounds good, thank you.
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.
Regards,
Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Engineering consulting with open source tools
http://www.opennovation.com/
signature.asc
Description: This is a digitally signed message part
Bug#457075: Salomé packaging
Hello Andre, 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 hope we can get this working soon! -Adam 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-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.
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
Bug#457075: Salomé packaging
Hello André, Thanks for your work on this, I'm glad it's working. I'm afraid I won't have much time to look into your tree, let alone merge the differences, for a few days, but will get back to you soon. -Adam 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/ signature.asc Description: This is a digitally signed message part
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
Greetings, I am not a Salome user, but here are some (hopefully not too stupid) remarks about http://ftp-master.debian.org/new/salome_5.1.3-8.html * Binary packages are under the contrib/ section, AFAICT they can be moved into main * libsalome and libsalome-dev ships a lot of shared libraries, some of which with very generic names libe libHELLO.so or libLauncher.so. This is a potential source of conflict, can all these libraries be moved into a private directory like /usr/lib/salome/ ? * Libraries generated by swig have an underscore prepended, which means that they are not opened by the dynamic loader and should be moved into a private directory. * Ditto for binaries; and there is a concrete conflict, salome ships /usr/bin/display which means that many people will not be able to install this package since imagemagick is very popular. Can binaries be moved into a private directory, like /usr/lib/salome/bin/ ? I guess that runSalome and killSalome have to be put under /usr/bin/, I can't tell for other binaries. * Binary packages seem to contain lots of tests (/usr/bin/*[tT][eE][sS][tT]* or /usr/lib/lib*[tT][eE][sS][tT]*), can they be dropped? * Description of the salome binary package has to be updated, AFAICT there is no binary under /usr/bin/salome/ * salome-common is quite large, are files under /usr/share/salome/resources/med/ really needed? It looks like *.med files are already provided by salome-examples. Denis -- 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/aanlktin61ecwajynihnwoe4_fxuc0mkbdhyhdwsmz...@mail.gmail.com
Bug#457075: Salomé packaging
Hello Denis, On Mon, 2010-05-10 at 12:28 +0200, Denis Barbier wrote: Greetings, I am not a Salome user, but here are some (hopefully not too stupid) remarks about http://ftp-master.debian.org/new/salome_5.1.3-8.html * Binary packages are under the contrib/ section, AFAICT they can be moved into main Wow, this should have been changed a *long* time ago when Open CASCADE was accepted to Debian main! Thanks, just made the change on alioth. * libsalome and libsalome-dev ships a lot of shared libraries, some of which with very generic names libe libHELLO.so or libLauncher.so. This is a potential source of conflict, can all these libraries be moved into a private directory like /usr/lib/salome/ ? * Libraries generated by swig have an underscore prepended, which means that they are not opened by the dynamic loader and should be moved into a private directory. Good points. The default salome behavior is to have them in a private directory (I think /usr/lib/salome), I moved them into /usr/lib , but you bring up a good reason to put them in the private directory. I'll test this in my next build. * Ditto for binaries; and there is a concrete conflict, salome ships /usr/bin/display which means that many people will not be able to install this package since imagemagick is very popular. Can binaries be moved into a private directory, like /usr/lib/salome/bin/ ? I guess that runSalome and killSalome have to be put under /usr/bin/, I can't tell for other binaries. Same as above, I'll see what happens if they're in a separate directory. * Binary packages seem to contain lots of tests (/usr/bin/*[tT][eE][sS][tT]* or /usr/lib/lib*[tT][eE][sS][tT]*), can they be dropped? The plan is to move them into separate test binary packages. * Description of the salome binary package has to be updated, AFAICT there is no binary under /usr/bin/salome/ You're right, that will just change to /usr/lib/salome/bin under the plan you suggested. * salome-common is quite large, are files under /usr/share/salome/resources/med/ really needed? It looks like *.med files are already provided by salome-examples. Good point -- many of those can probably go into the test binary packages as well. The test packages are described in the recent discussion on Salome packaging on the debian-science email list. [1] The others are errors I really should have caught before! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#457075: Salomé packaging
Hi again, On Wed, 2010-05-05 at 14:44 -0400, Adam C Powell IV wrote: On Wed, 2010-05-05 at 09:40 +0200, Andre Espaze wrote: 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? Sure, though I think it might make sense to remove the .py from the ending then, like avs2med and a couple of others. In Debian, executable scripts are not supposed to have extensions, not even .sh . Make sure your patch eventually puts it into the /usr/bin directory of the python2.5-salome package, or else it will generate another lintian error (python script without python dependency). I just took care of this, the result is in the alioth git repository. I'm going to build and test -8 with this and -doc package removal, and a couple of other little changes, then test and re-upload. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
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 André, On Wed, 2010-05-05 at 09:40 +0200, Andre Espaze wrote: Hi Adam, Sorry for the delay, I have missed the -6 release but I have just built the -7 one which works fine. No problem. -6 had a dumb mistake which caused it to be rejected by Debian right away, so you didn't miss anything. 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. Right, the Debian-GIS team finally updated HDF5, so I was able to upload the new and working MED package. 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. That file should be in the debian directory. debian/rules copies it into debian/tmp, then it's in salome.files so it should get into the salome package (dpkg -c tells which files are in a .deb). 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. I agree, the problem seems to also be in OpenCASCADE (bug 550445), so it may be that Salomé uses OCC's loading mechanism. Yeah, this one will take a bit of time to track down. 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? Sure, though I think it might make sense to remove the .py from the ending then, like avs2med and a couple of others. In Debian, executable scripts are not supposed to have extensions, not even .sh . Make sure your patch eventually puts it into the /usr/bin directory of the python2.5-salome package, or else it will generate another lintian error (python script without python dependency). Thanks, Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#457075: Salomé packaging
Hello all, I think we're getting close to a -6 release and first upload into Debian unstable. I'm noticing two issues though which will need just a tiny bit of work. 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. :-) 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. 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? This is getting exciting, we're just about there! I think this will be ready for its first upload on Monday... Any differing opinions? -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
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
Thank you Andre, the debian-science entry looks terrific! It's very frustrating that bug 510057 against hdf5 is nearly 16 months old, and there has been a simple patch available for 3.5 months, but they have just added a new upstream version, with no progress on this or 571453. :-( I'm going to send a reminder to these two bugs. I've tagged what's on lyre as -5 in alioth, and am working toward -6. I'm also trying to get NETGENPLUGIN working, and have started a port to the nglib 4.9.x API. But I'm having trouble, as you'll see if you try to build with it enabled (I disabled it in debian/rules for now). I did notice a post on Netgen and Salome on the Netgen forum [1] indicating that Salome developers are porting to the 4.9.x nglib.h API, so I guess we'll be able to see that in the git repository [2] soon. But the repository currently doesn't test for the new API, so if a port is in progress, it's not in git yet... [1] http://sourceforge.net/projects/netgen-mesher/forums/forum/905306/topic/3451454 [2] http://git.salome-platform.org/gitweb/?p=NETGENPLUGIN_SRC.git;a=summary I need this plugin for my own purposes, so after finishing an overall package which is upload-worthy I'm going to keep working on it. -Adam On Thu, 2010-04-22 at 17:27 +0200, Andre Espaze wrote: 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é -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
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
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 ? 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. Sylvestre -- 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/1271773125.5384.505.ca...@zlarin
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 André, Apologies for the long delay in replying since your message arrived. I've been very busy, and just yesterday finally compiled Salomé. On Wed, 2010-04-07 at 12:06 +0200, Andre Espaze wrote: 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. 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... 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. 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. 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. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
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 André, On Tue, 2010-04-06 at 14:07 +0200, Andre Espaze wrote: 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. Ah, that would be very helpful. I'd like to get runSalome to work, but I first have to have something working in order to do that. :-) 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... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#457075: Salomé packaging
Hi everyone and apologies for the long delay since I last wrote. On Tue, 2010-03-16 at 06:49 -0400, Adam C Powell IV wrote: On Thu, 2010-03-11 at 17:23 +0100, Andre Espaze wrote: 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. I thought that might be an issue too. You might also try commenting the lines which delete the .pyc (and maybe .pyo) files from /usr/bin. Together they are supposed to make the package more efficient by shipping just .py files and having them compile at install time, but it seems like it will take some time to let Salomé know that those files are not in /usr/bin. 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. Indeed. I am still waiting for the HDF5/GIS team to fix bug 510057 which has had a patch for six weeks now, so we can upload the new MED and not have to use out-of-archive packages... I keep you in touch once my new version is running, I am getting more confortable with the Debian packaging tools. Thanks, I'll let you know if I can test the unstable packages, so we can start a git bisect. 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? -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#457075: Salomé packaging
Hi André, Sorry about the delay, I've been trying to get X working in a chroot but a known bug is making the keyboard and mouse not work... Copying my sid chroot into its own partition now to try to boot and test there. On Thu, 2010-03-11 at 17:23 +0100, Andre Espaze wrote: 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. I thought that might be an issue too. You might also try commenting the lines which delete the .pyc (and maybe .pyo) files from /usr/bin. Together they are supposed to make the package more efficient by shipping just .py files and having them compile at install time, but it seems like it will take some time to let Salomé know that those files are not in /usr/bin. 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. Indeed. I am still waiting for the HDF5/GIS team to fix bug 510057 which has had a patch for six weeks now, so we can upload the new MED and not have to use out-of-archive packages... I keep you in touch once my new version is running, I am getting more confortable with the Debian packaging tools. Thanks, I'll let you know if I can test the unstable packages, so we can start a git bisect. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
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 André, On Tue, 2010-03-09 at 17:23 +0100, Andre Espaze wrote: 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! 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. Thanks, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#457075: Salomé packaging
Hi again, 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... Thanks, Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
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
Hello Andre, On Thu, 2010-03-04 at 17:36 +0100, Andre Espaze wrote: 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. Yes, it's kind of annoying how much disk space it takes! 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. You're right, this would be a serious bug. I just changed and pushed the fix. 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. Thank you, I will look at that. 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! I saw that you already fixed the 'killSalome' command problem pointing on python2.4. Yes, and a few others. The YACS module should now build, it seemed like an important one to get in there. Now only XDATA remains (the others depend on non-free packages, as described in debian/rules). Also, VISU still doesn't finish building, I wish I had the C++ skills to deal with that. :-( I think we're almost there... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#457075: Salomé packaging
Hi Andre, On Thu, 2010-02-25 at 13:11 -0500, Adam C Powell IV wrote: On Thu, 2010-02-25 at 17:19 +0100, Andre Espaze wrote: 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. 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. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
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
On Thu, 2010-02-25 at 17:19 +0100, Andre Espaze wrote: 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. Also, the NETGENPLUGIN module will not work until the new netgen package is uploaded. That in turn depends on togl, which I just learned is packaged but waiting for upload. I'm going to see if I can upload togl, then the new netgen, in order to get all of this working (since I need this plugin for my work). 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/ Great, thanks. 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. Ah, this is good information! I'm including this in runSalome.in . 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. You're right, it's based on an older version of the opencascade package. I'll fix it. 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. You're welcome, I'll let you know when I push everything to alioth (a.k.a. git.debian.org). -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/
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 Andre, 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. 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. 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. Terrific! Onward to the other issues... 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. 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. Indeed, the frustration and the fun. :-) -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
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
Hello Andre, No problem regarding the reply time. It takes a while to come up to speed on git, quilt, and the complicated Debian packaging system. I've made a lot of progress in getting salome to build and clean itself properly, so some things should be much easier. The only thing not building properly at this point is VISU, there's a C++ problem mentioned earlier which I don't know how to resolve. On Wed, 2010-02-17 at 11:37 +0100, Andre Espaze wrote: 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. Good point. I have just made that change, thanks. Anyway I would like to discuss the configure step in the following ticket: http://www.python-science.org/ticket/1405 You make a good point about different features needed for different modules. But I think the loop is helpful because it is easy to change or fix variables which apply to all of the modules, and cuts down on the size of the rules file. It needs to do the documentation separately for each module because not all modules have documentation; I'd like to keep from having to do that in the configure-stamp target. That said, if you can produce a patch which does this without making things too long (for example by having a COMMON_CONFIGURE_OPTIONS makefile variable for options needed by all modules), I will likely adopt it. [Skipping resolved issues...] 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. Great, let's see how we can make the other modules work... 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. Sounds good. Thanks for your help! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#457075: Salomé packaging
On Wed, 2010-02-17 at 11:59 +0100, Andre Espaze wrote: 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? 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. :-) 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. Excellent! I'm glad to hear it. I sent my patches to med-fichier upstream, and they let me know they have already included my changes into their 3.0.0 version under development. 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. 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. 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). I believe all of this should work using both the standard OpenCascade build method and the Debian package, so the resulting patch should be acceptable to upstream. Please let me know if you see anything which does not satisfy this goal. 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. git-buildpackage is very strict about having a pristine tree at the start of the build. I have only just finished getting fakeroot debian/rules clean to restore the tree to the original state so it will work properly. The workflow should go something like this: 1. git-buildpackage (which applies the patches and builds) 2. If it doesn't finish building, fix build issues, using quilt to apply changes to the right patches (see below). Keep using make and make install until it works, then finish package building using fakeroot debian/rules binary 3. Install and test the package, and fix details, again using quilt to apply
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
Bug#457075: Salomé packaging
On 2010/2/11 Andre Espaze: [...] - 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. [...] Hi André, This file has been dropped intentionnally, it does not make sense to ship a config.h file in a -dev package, you would have trouble if you build an application that uses autotools and ship its own config.h. See http://git.debian.org/?p=debian-science/packages/opencascade.git;a=blob;f=debian/patches/drop-config-h.patch Denis -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#457075: Salomé packaging
Hi, On Thu, Feb 11, 2010 at 05:32:35PM +0100, Andre Espaze wrote: 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? If it is to be hosted on python-science.org, please make it a hg repo and it will be easier for us on the admin side since hg.python-science.org is already operationnal. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#457075: Salomé packaging
Le jeudi 11 février 2010 à 18:54 +0100, Nicolas Chauvat a écrit : Hi, On Thu, Feb 11, 2010 at 05:32:35PM +0100, Andre Espaze wrote: 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? If it is to be hosted on python-science.org, please make it a hg repo and it will be easier for us on the admin side since hg.python-science.org is already operationnal. Well, Debian (Science) has hosting capabilities and Debian tools prefers Git or SVN. I also think it would be easier to stick with Debian hosting since we already have accounts, procedures and so on... Sylvestre -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#457075: Salomé packaging
Hello Andre, On Thu, 2010-02-11 at 17:32 +0100, Andre Espaze wrote: 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. Great, thanks for following up on this. 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. - 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. - 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. - 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... I'm impressed that it actually runs -- hadn't tried to run it yet! You can find all the steps that I did, more details and also more problems at: http://www.python-science.org/ticket/1383 Thanks, I'll look over this. 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/ . I'm trying to get it to work with git/quilt, as right now a couple of the clean targets are a bit too aggressive -- they remove a lot that shouldn't be removed. I am looking forward to work with you, I am as well! Thanks for the post. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#457075: Salomé packaging
Hello again, 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. 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? 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. -Adam On Thu, 2010-02-11 at 17:43 -0500, Adam C Powell IV wrote: Hello Andre, On Thu, 2010-02-11 at 17:32 +0100, Andre Espaze wrote: 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. Great, thanks for following up on this. 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. - 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. - 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. - 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... I'm impressed that it actually runs -- hadn't tried to run it yet! You can find all the steps that I did, more details and also more problems at: http://www.python-science.org/ticket/1383 Thanks, I'll look over this. 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/ . I'm trying to get it to work with git/quilt, as right now a couple of the clean targets are a bit too aggressive -- they remove a lot that shouldn't be removed. I am looking forward to work with you, I am as well! Thanks for the post. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This
Bug#457075: Salomé packaging
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/ signature.asc Description: This is a digitally signed message part
Bug#457075: Salomé packaging
Hello again, I now have 10 modules enabled, and have made all but one of the patches upstream-friendly, though I've only uploaded the -3 source package to http://lyre.mit.edu/~powell/salome/ at the moment. Nicolas, can you do me a favor and try to push some of the patches upstream? You can find them in the salome_5.1.3-3.debian.tar.gz file, in the debian/patches directory; I can send them to you individually if you prefer. The patches fall into in several categories, and are separated out by module: * *-safe-include: Eliminate extern C blocks where they are unnecessary -- and even harmful, as they break building with OpenMPI. See the patch head for details. * *-cleanup: Fixes for compiler bugs which break the build with recent compilers. * *-hdf5-needs-mpi: The HDF5 header and library files need MPI in order to work, so this includes the MPI -I and -L flags in with those of HDF5, and puts MPI checks before HDF5 ones. * *-mpich-mpi: Replace MPICH checks with MPI checks, as I've made it compatible with OpenMPI. * *-use-gui-check: Use check_GUI.m4 in the GUI module directory, instead of the rewritten version of that file in several other module directories. * *-build-in-tree: Debian requires that the whole package build first, then install. These patches make this possible. These patches will not only make it easier to maintain the package, but will assist anyone building Salomé on Debian/Ubuntu in the future. And all of them should preserve the ability to build as before, let me know if that is not the case. Other specific patches: * kernel-remove-mpi-undefs: Not sure why these undefs are there, they break OpenMPI compatibility. * kernel-occ-includes: Search for OpenCASCADE header files both in the default location when building OCC from source and also in the Debian/Ubuntu package location. * hxx2solame-destdir: Use DESTDIR for install. * med-scotch: Search for Scotch files both in the default location when building Scotch from source and also in the Debian/Ubuntu package location. * med-missing-libs: Add the MED libraries to the mprint_version link command. * visu-flags-typo: Fix incorrect automake flags variable. * kernel-mpi-libs: This is the one which should *not* go upstream, as it tests for the Debian-specific MPI alternative symlink lib names. 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? Before upload, I think this needs a few more modules, a full copyright audit, and at least a working GUI shell. I've only done the audit for the first two modules (KERNEL and HXX2SALOME), and haven't tried running the shell yet... Cheers, Adam On Sun, 2010-01-10 at 17:53 -0500, Adam C Powell IV wrote: On Sun, 2010-01-10 at 23:28 +0100, Nicolas Chauvat wrote: Hi, As part of the OpenHPC project[1], Logilab commited itself to package Salomé for Debian. We had seen the great work you have done and are glad that you are resuming it. Wow, thank you for this terrific news! Have you started to forward-port the old patches to a new package, or are you using a different approach? A correction: most of my work on this was two years ago, not three. André Espaze has been developing a connector between Salomé and Code_Aster for the past few months. He is about to continue his work with the packaging of Salomé. He will have the help of Pierre-Yves David. We also have a Debian developer on the team, Alexandre Fayolle, but he will not have a lot of time for this particular project in the upcoming months. Okay. Let me know how I can best fit in with your plans for this project. I am cc'ing every person involved to make sure everyone can get in touch easily. Is debian-science the best place to discuss this topic or should we take the discussion off-list? I think this list is pretty good as long as we are talking about generalities, as I think some of the people on the list will have good suggestions. When we start to get into the details of patches and the package, maybe it will make sense to go off-list. Hopefully, the fact that we have been working with upstream for years will help us get this work done more easily. This is terrific. My patches are Debian-specific, and need some work to make them fit the needs of both upstream and Debian. This gives me hope that doing that work will help to actually get the patches into the upstream source! This is the best news I've heard in a long time. Thanks again, I look forward to working with you. Regards, Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools
Bug#457075: Salomé packaging
Greetings, For those interested, I'm re-doing the Salomé .deb I started three years ago. Salomé is a finite element pre-post processing framework, with a lot of other things in there as well. Though some things have improved between version 3.2.6 and 5.1.3, many have not, so although this likely won't take 100+ hours like the last one did, it's taking more effort than I can give to it. I've got five modules configuring, compiling and installing, but will not be able to work on it for the next couple of weeks. rantAmong other things, it needs major updates for modern compilers, for OpenMPI, and for new versions of other packages. It amazes me that upstream can get it to build at all, but then, they seem to only build to certain particular narrow (and old) platforms/targets, and don't accept outside patches (never looked at the 50+ I generated last time), so it is not surprising that this is the result./rant Because I can't do the whole package, I'm putting up the progress I've made thus far at http://lyre.mit.edu/~powell/salome/ for others to work on. The -2 .dsc and .debian.tar.gz files are there, the rest will follow later today. I'm reluctant to put it in git until an audit turns up the non-free and other troublesome files, to avoid having to change the upstream branch and dfsg tarball too many times. (I've only audited the first two modules thus far, which seem dfsg-clean.) Speaking of which, random -legal question: one directory has a .sxw, a .pdf and a .ps. The .pdf and ps files are clearly generated from the sxw. Does a .dfsg tarball have to remove the .pdf and .ps files, and somehow re-generate them from the .sxw, or can it just leave them in? Is there a way to script OO.o to generate a .pdf from a .sxw? Note: the files whose debian/patches/series entries are commented are old patches from 3.2.6 which I haven't backported. They're there to provide some guidance into how to fix problems related to those I fixed back then. The uncommented patches are new, and many of them are ready to go to upstream. A few others need only to be made more general before going upstream, e.g. test for files in dependency packages both where upstream installs them and where Debian installs them, etc. To summarize, I need help with the following: * Copyright audit of the tree * Getting the other modules to configure, compile and install * Making patches upstream-compatible, and sending them to upstream Hopefully in a month or two we'll have both a good Salomé package in Debian, and a more enlightened upstream! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#457075: Salomé packaging
On Sun, 2010-01-10 at 23:28 +0100, Nicolas Chauvat wrote: Hi, On Sun, Jan 10, 2010 at 02:29:03PM -0500, Adam C Powell IV wrote: For those interested, I'm re-doing the Salomé .deb I started three years ... Because I can't do the whole package, I'm putting up the progress I've ... To summarize, I need help with the following: * ... * Getting the other modules to configure, compile and install * Making patches upstream-compatible, and sending them to upstream As part of the OpenHPC project[1], Logilab commited itself to package Salomé for Debian. We had seen the great work you have done and are glad that you are resuming it. Wow, thank you for this terrific news! Have you started to forward-port the old patches to a new package, or are you using a different approach? A correction: most of my work on this was two years ago, not three. André Espaze has been developing a connector between Salomé and Code_Aster for the past few months. He is about to continue his work with the packaging of Salomé. He will have the help of Pierre-Yves David. We also have a Debian developer on the team, Alexandre Fayolle, but he will not have a lot of time for this particular project in the upcoming months. Okay. Let me know how I can best fit in with your plans for this project. I am cc'ing every person involved to make sure everyone can get in touch easily. Is debian-science the best place to discuss this topic or should we take the discussion off-list? I think this list is pretty good as long as we are talking about generalities, as I think some of the people on the list will have good suggestions. When we start to get into the details of patches and the package, maybe it will make sense to go off-list. Hopefully, the fact that we have been working with upstream for years will help us get this work done more easily. This is terrific. My patches are Debian-specific, and need some work to make them fit the needs of both upstream and Debian. This gives me hope that doing that work will help to actually get the patches into the upstream source! This is the best news I've heard in a long time. Thanks again, I look forward to working with you. Regards, Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
