Bug#453065: getfem++ 4.0
Hello 4. I would like to suggest that getfem is moved to the Debian Scientific Computing Team, since this team already maintains many similar packages. As I haven't contacted neither the people who worked on getfem in the past nor the Debian Scientific Computing Team yet, I CC persons from both parties in this mail hoping to get some positive response from both. In any case, I would be glad to continue working on this package under the mentoring/sponsoring of anyone who would like to undertake it. I am more than happy if you take over it, all the packages placed under pkg-kde/krap are build depends or depend of KDE that we (KDE team) need but we do not really want to maintain. I do not know if Xavier Bello is still interested in it, but he always can join you in the maintenance under the umbrella of the Scientific Computing Team. I just packaged it as a KDE dependency, I don't have any special interest in it. Please feel free to take over the maintenance. Regards -- Xavier Vello -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#453065: getfem++ 4.0
Hi all, I've uploaded my last packaging effort based on the official release of getfem version 4.0.0 here: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=getfem Some remarks: 1. In accordance with the tar.gz-name and the SO-NAME of the last upstream release I've removed the ++ suffix from the name of the source-package as well as from the names of all binary packages. 2. I let the superlu code included in the upstream package intact. I 've included all its copyright relevant information in debian/copyright, but during the build process I've used the libsuperlu3-dev package instead. 3. In this email I CC'ed Ana Beatriz Guerrero Lopez who is the maintainer of gmm++-dev in order to attract her attention to my previous question: 3. gmm stand alone packages Since there is a debian package for standalone gmm too: http://packages.debian.org/sid/all/libgmm++-dev and since the upstream for gmm++ and getfem++ is the same, I suppose the standalone gmm++ package could be replaced by the one contained in getfem++. At this point a decision should taken also for the name of the package (libgmm vs libgmm++, see point 1). 4. I would like to suggest that getfem is moved to the Debian Scientific Computing Team, since this team already maintains many similar packages. As I haven't contacted neither the people who worked on getfem in the past nor the Debian Scientific Computing Team yet, I CC persons from both parties in this mail hoping to get some positive response from both. In any case, I would be glad to continue working on this package under the mentoring/sponsoring of anyone who would like to undertake it. Regards Kostas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#453065: getfem++ 4.0
Hi Konstantinos, On Wed, Sep 23, 2009 at 02:01:21PM +0200, Konstantinos Poulios wrote: Hi all, I've uploaded my last packaging effort based on the official release of getfem version 4.0.0 here: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=getfem First of all, please take over the ITP. Sadly, Matthew Rosewarne is not longer among us. Some remarks: 1. In accordance with the tar.gz-name and the SO-NAME of the last upstream release I've removed the ++ suffix from the name of the source-package as well as from the names of all binary packages. 2. I let the superlu code included in the upstream package intact. I 've included all its copyright relevant information in debian/copyright, but during the build process I've used the libsuperlu3-dev package instead. IIRC, in some in the past getfem was uploaded to the archive, but it was rejected due to copyright/licensing issues. The packaging in the SVN was ok for some old version of getfem but it was not updated since then. While waiting for it to get cleared, I packaged gmm standalone. 3. In this email I CC'ed Ana Beatriz Guerrero Lopez who is the maintainer of gmm++-dev in order to attract her attention to my previous question: 3. gmm stand alone packages Since there is a debian package for standalone gmm too: http://packages.debian.org/sid/all/libgmm++-dev and since the upstream for gmm++ and getfem++ is the same, I suppose the standalone gmm++ package could be replaced by the one contained in getfem++. At this point a decision should taken also for the name of the package (libgmm vs libgmm++, see point 1). Yes, that was the plan for when getfem were packaged. 4. I would like to suggest that getfem is moved to the Debian Scientific Computing Team, since this team already maintains many similar packages. As I haven't contacted neither the people who worked on getfem in the past nor the Debian Scientific Computing Team yet, I CC persons from both parties in this mail hoping to get some positive response from both. In any case, I would be glad to continue working on this package under the mentoring/sponsoring of anyone who would like to undertake it. I am more than happy if you take over it, all the packages placed under pkg-kde/krap are build depends or depend of KDE that we (KDE team) need but we do not really want to maintain. I do not know if Xavier Bello is still interested in it, but he always can join you in the maintenance under the umbrella of the Scientific Computing Team. Ping me when you have getfem in the archive and i will ask for the removal of getmm. Ana -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#453065: getfem++ 4.0
Hi, I see that the actual packaging work for getfem++ is being done here: http://svn.debian.org/wsvn/pkg-kde/krap/getfem%2B%2B/trunk/ Unfortunately the current packaging status fails to build the getfem++ code from the upstream svn-repository, mainly because of upstream autotools modifications. Hence, for the upcoming version 4.0 extra packaging work is necessary. My efforts on packaging a svn version of getfem++ from scratch (unfortunately not yet tested in Debian) can be found here: https://launchpad.net/~logari81/+archive/ppa/+files/getfem++_4.0~svn3056-0ubuntu0ppak6.diff.gzhttps://launchpad.net/%7Elogari81/+archive/ppa/+files/getfem++_4.0%7Esvn3056-0ubuntu0ppak6.diff.gz https://launchpad.net/~logari81/+archive/ppa/+files/getfem++_4.0~svn3056-0ubuntu0ppak6.dschttps://launchpad.net/%7Elogari81/+archive/ppa/+files/getfem++_4.0%7Esvn3056-0ubuntu0ppak6.dsc https://launchpad.net/~logari81/+archive/ppa/+files/getfem++_4.0~svn3056.orig.tar.gzhttps://launchpad.net/%7Elogari81/+archive/ppa/+files/getfem++_4.0%7Esvn3056.orig.tar.gz My packaging version doesn't use cdbs and uses python-support for the python modules. It also includes a new copyright file. Several minor issues have been fixed in collaboration with upstream. I would like to test my package on Debian too but first I would like to address some issues: 1. Packages names. My suggestion is the following: - getfem++ : source package - libgetfem4 : main lib - libgetfem-dbg : debugging package - libgetfem-dev : dev-package - libgmm-dev (or libgmm++-dev): gmm package - python-getfem : python interface In comparison to the current packaging in http://svn.debian.org/wsvn/pkg-kde/krap/ the ++ suffix has been removed so that the main lib package name is in accordance with the SONAME libgetfem4 which doesn't contain the ++ suffix. The same convention could be considered also for the gmm header files so that all the packages uniformly doesn't contain the ++ suffix in their names. 2. superlu The upstream package includes in a separate folder code which is already available as standalone packages here: http://packages.debian.org/de/source/sid/superlu http://packages.debian.org/de/sid/libsuperlu3-dev in my packaging I build the code with the --disable-superlu configure option in order to use the installed version of superlu instead of the local copy in the upstream package. Though here I have a question: Which of the following possibilities is preferable? a) delete the superlu folder and recreate an orig.tar.gz with the .dfsg name suffix. b) let the superlu folder as is, but use the --disable-superlu configure option to ignore this local copy of superlu during the building. In this case I have to extend my debian/copyright to describe the license of superlu (which apparently is BSD but the superlu folder includes also files missing a license header, is it in accordance with dfsg? In superlu standalone debian package it has been accepted so, is it a ) 3. gmm stand alone packages Since there is a debian package for standalone gmm too: http://packages.debian.org/sid/all/libgmm++-dev and since the upstream for gmm++ and getfem++ is the same, I suppose the standalone gmm++ package could be replaced by the one contained in getfem++. At this point a decision should taken also for the name of the package (libgmm vs libgmm++, see point 1). I would be glad for any feedback. As soon as I have some suggestions on these 3 issues I will upload a sid version of my package (Optimally, with the support of the current maintainer, in a new branch in the same place where he has his work). Regards Kostas
