[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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).

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: