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
