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é -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100225161932.ga6...@crater.logilab.fr