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 > > 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> >> >> 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>). >> >> 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
