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
