Dear Kostas, Thanks again for your work. I integrated the patches and I added the optional removal of "superlu/Makefile" (r3074).
Note that the dependence on the qhull package is essential for a growing number of applications (I don't konw if this optional dependence has been taken into account). Yann Collette is currently working on the scilab interface (which is also a debian package). He added a corresponding sub-directory in interface/src. Normally it should not interfere because the makefiles have not been added. This interface is nearly fully working and it would be interesting in the future to make package it since scilab is also a debian package. Regards, Yves. Konstantinos Poulios <[email protected]> a écrit : > 1. a-c) is ok now. Thanks for the quick response. > d) For getfem++ to compile with "--disable-superlu" and the superlu folder > removed, the attached patch "disable_superlu.patch" is necessary (Please > don't merge the patch as is. The removal of "superlu/Makefile" from > AC_CONFIG_FILES in configure.in has to depend on the "--disable-superlu" > option). > Additionally the "getfem_superlu.patch" is needed, otherwise installed > headers of superlu cannot be found. I believe the "../" prefix in the > include directives wasn't really necessary. > > 2.-4. is ok in r3056. Thanks > > 6. A new issue. r3056 fails to compile with gcc 4.4. The patch > "gmm_inoutput.patch" workarounds the issue by an explicit variable > recasting. A real solution would be to change both "writeHB_mat_double" > arguments "Valfmt" and "Rhsfmt" from "const char*" to "char*", since "const > char*" declaration is a promise not to change the variable value, which is > not held. Anyway I don't know what could get broken by such an interface > change. > > Regards > > Kostas > > > > On Tue, Aug 18, 2009 at 1:49 PM, Renard Yves <[email protected]>wrote: > >> >> Dear Kostas, >> >> Thank you for your important work ! >> >> 1) I made some modifications on the license of most of the files listed by >> you, except for superlu files (r3056). I agree with Luis. Superlu could be >> an external dependence for the package. >> >> 4) The problem is fixed. >> >> 5) Name without ++ are ok. >> >> Regards, >> >> Yves. >> >> >> Luis Saavedra <[email protected]> a écrit : >> >> Hi Kostas, >>> >>> thanks for your work!!! >>> >>> 1) The folder superlu can be removed, and reemplaced: >>> >>> * In debian: with package libsuperlu3 (or libsuperlu3-dev for >>> build-package). >>> * In the rest: with >>> http://crd.lbl.gov/~xiaoye/SuperLU/superlu_4.0.tar.gz<http://crd.lbl.gov/%7Exiaoye/SuperLU/superlu_4.0.tar.gz> >>> >>> I think it would be a good idea create a branch dedicated to this issue. >>> >>> 2-3) in r3055, is this ok? >>> >>> 5) libgetfem, python-getfem, but getfem4 don't exist yet. >>> >>> Regards, >>> Luis >>> >>> Konstantinos Poulios escribió: >>> >>>> Hi all, >>>> >>>> The following bug report exists in Debian archive about the packaging >>>> of getfem++: >>>> >>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453065 >>>> >>>> The current work in Debian can be found here: >>>> >>>> http://svn.debian.org/wsvn/pkg-kde/krap/getfem%2B%2B/#_krap_getfem++_ >>>> http://svn.debian.org/wsvn/pkg-kde/krap/getfem/#_krap_getfem_ >>>> >>>> I've opened the following bug report in order to ask for the inclusion >>>> of getfem++ in Ubuntu: >>>> >>>> https://launchpad.net/bugs/413165 >>>> >>>> My current work on debianization of getfem++, including experimental >>>> packages for ubuntu jaunty and karmic, can be found here: >>>> >>>> https://launchpad.net/~logari81/+archive/ppa<https://launchpad.net/%7Elogari81/+archive/ppa> >>>> <https://launchpad.net/%7Elogari81/+archive/ppa> >>>> >>>> During the packaging process, several issues came up: >>>> >>>> 1. Licensing. In the attached file "getfem_license_exceptions" I ve >>>> listed all licenses which differ from "LGPL 2.1 or later". >>>> a) In the "tests-2.0", "tests", "internal_tools", "interface", >>>> "contrib", "doc" and "superlu" folders, there are many source files >>>> missing any license and copyright information. >>>> b) Source files referring to "LGPL", "LGPL with incorrect FSF >>>> address" and "LGPL (v2.1 or later) with missing copyright >>>> information", can be found in "internal_tools", "interface" and >>>> "contrib" folders. Probably most of the LGPL'ed files can be >>>> relicensed to "LGPL 2.1 or later" since their authors are using this >>>> LGPL version elsewhere. >>>> c) In the "src" folder, there are double licensed gmm files, but this >>>> is no problem for the packaging. One problem is the missing time >>>> period specification for the contribution of Thorsten Ottosen. >>>> d) Apparently, "superlu" belongs mostly to Xerox. I suppose that the >>>> rest of the files in this folder missing a license declaration are >>>> probably Xerox's contribution. Please complete the missing license >>>> information. >>>> >>>> 2. The "configure" script generated with autoconf 2.64 is broken, as a >>>> workaround, a blank line in "m4/ac_python_devel.m4" has been added >>>> (see patch "ac_python_devel.patch"). Further investigation would be >>>> necessary (probably an autoconf bug). >>>> >>>> 3. Using automake 1.11 installation with "make install" is broken. The >>>> double entry for "check_all.sh" in >>>> "interface/tests/matlab/Makefile.am" has been removed to fix the >>>> problem (see patch tests_matlab_makefile.patch) >>>> >>>> 4. "autogen.sh" spooks many annoying warnings about "AC_CACHE_VAL" >>>> (see the following build log >>>> >>>> http://launchpadlibrarian.net/30384527/buildlog_ubuntu-karmic-i386.getfem%2B%2B_4.0~svn3053-0ubuntu0ppak9_FULLYBUILT.txt.gz<http://launchpadlibrarian.net/30384527/buildlog_ubuntu-karmic-i386.getfem%2B%2B_4.0%7Esvn3053-0ubuntu0ppak9_FULLYBUILT.txt.gz> >>>> < >>>> http://launchpadlibrarian.net/30384527/buildlog_ubuntu-karmic-i386.getfem%2B%2B_4.0%7Esvn3053-0ubuntu0ppak9_FULLYBUILT.txt.gz >>>> >). >>>> >>>> 5. Names of the packages. I 've used the root "getfem" without "++" to >>>> name the various packages in order to comply with the so-name of the >>>> main library. I suppose this can be further discussed in debian and/or >>>> ubuntu when the packages are considered to be accepted. Any remarks on >>>> my choice are always welcome. (A bad example is the gmm standalone >>>> package which in Debian is called libgmm++-dev whether in Ubuntu it is >>>> named libgmm-dev). >>>> >>>> It would be very helpful to solve the issues 1-4 here in upstream >>>> rather than in the packaging. It would also be nice to synchronize with >>>> http://svn.debian.org/wsvn/pkg-kde/krap/getfem%2B%2B/#_krap_getfem++_ >>>> I hope my work can be somehow useful for Debian also. >>>> >>>> Regarding the functionality of the packages, up to now, I have only >>>> tested the python interface, which seems to work fine. Any help with >>>> testing the rest (i.e. the -dev packages) is welcome. >>>> >>>> Regards >>>> >>>> Kostas >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Getfem-users mailing list >>>> [email protected] >>>> https://mail.gna.org/listinfo/getfem-users >>>> >>> >>> >>> _______________________________________________ >>> Getfem-users mailing list >>> [email protected] >>> https://mail.gna.org/listinfo/getfem-users >>> >>> >> >> >> > _______________________________________________ Getfem-users mailing list [email protected] https://mail.gna.org/listinfo/getfem-users
