On Thu, 2010-02-25 at 17:19 +0100, Andre Espaze wrote: > 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? That's the current public branch now. I'm working now on my own branch, which doesn't build because of a problem with $(wildcard...) in the rules file which I mentioned on debian-science. I'm testing a possible solution based on Aaron Ucko's reply, and will push everything to alioth if/when it works. Also, the NETGENPLUGIN module will not work until the new netgen package is uploaded. That in turn depends on togl, which I just learned is packaged but waiting for upload. I'm going to see if I can upload togl, then the new netgen, in order to get all of this working (since I need this plugin for my work). > > > > > 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/ Great, thanks. > > > > 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. Ah, this is good information! I'm including this in runSalome.in . > 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. You're right, it's based on an older version of the opencascade package. I'll fix it. > 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. You're welcome, I'll let you know when I push everything to alioth (a.k.a. git.debian.org). -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/
Attachment:
signature.asc
Description: This is a digitally signed message part