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é
Reply to: