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