Bug#731211: aster: new upstream release, work in progress
Hi, sorry for the late asnwer, I've been busy in these days. So, the package is good, the only thing that should be changed, if we want to upload the package as soon as possible, is that with this packaging, code-aster-mpi-engine should depend on code-aster and not vice-versa. On the other hand, I think that the packaging scheme should stay as it was previously: the code-aster package was originally meant to be a meta-package, just to allow to easlily install the whole thing with apt-get install code-aster; I think we should still follow this concept. So, move all arch-independent files (mostly python) in another package, like code-aster-common; move the elements file and other arch-dependant files common to the serial and parallel version to another package code-aster-elements, and leave the code-aster package as a metapackage. Suggestions on better package scheme ( and naming ) naming are welcome :) Other issues/enhancements/wishes: - the code-aster package creates both /usr/lib/aster an /usr/lib/codeaster; the latter seems to be used just for a symlink from ../../share/aster . It's just a leftover of the old packaging, or CA looks for files in this path? Note however that code-aster-run puts some files under /usr/lib/codeaster, so we shoult ideally take also care of code-aster-run and code-aster-gui packages. - In the process, I'd like also to switch from svn to git. - as_run doesn't work out of the box: it relies on having informations about available versions in the file /etc/codeaster/aster ; the script update-codeaster-engines takes care of this, it should be run on postinst/postrm scripts of the code-aster-*-engine packages. - provide also the serial version - a simple script to run the test cases would be nice... the .comm file that was used for this purpose has been removed from upstream, or it's just me that can't find it? - we should fix libmetis in one way or another, either by adapting the sources to libmetis 5.1.0 (the metis documentation says something about this process) or by changing the default renumerator from METIS to something other, like MD, so that it can be compatible with comm files that doesn't specify the renumerator to be used. - 11.5 is already out - and I'd like to provide also testing/unstable versions So, considering that the actual packages are empty, I propose to fix the dependency and upload the packages, then start working on enhancong the package. Bye Andrea Il Venerdì 21 Marzo 2014 10:09, Denis Laxalde denis.laxa...@logilab.fr ha scritto: Hi, Some other changes and Lintian warnings fixes: - install the elements catalog in /usr/lib/aster as it is architecture dependent. - install the Python library in code-aster binary as it is not tied to the underlying engine. Regards. -- Denis Laxalde Logilab http://www.logilab.fr -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/532bfd49.8040...@logilab.fr
Bug#731211: aster: new upstream release, work in progress
Hi, Andrea Palazzi a écrit : So, the package is good, the only thing that should be changed, if we want to upload the package as soon as possible, is that with this packaging, code-aster-mpi-engine should depend on code-aster and not vice-versa. I don't understand why we'd want this. With the current binary layout, code-aster (the Python library and elements catalog) cannot be used without an engine (the aster binary), whereas the engine could (in theory) be used without the code-aster Python library or elements catalog (although it wouldn't be more useful than a python interpreter). On the other hand, I think that the packaging scheme should stay as it was previously: the code-aster package was originally meant to be a meta-package, just to allow to easlily install the whole thing with apt-get install code-aster; I think we should still follow this concept. Even if it's not a meta package anymore, the code-aster binary package still provides this feature. So, move all arch-independent files (mostly python) in another package, like code-aster-common; move the elements file and other arch-dependant files common to the serial and parallel version to another package code-aster-elements, and leave the code-aster package as a metapackage. Suggestions on better package scheme ( and naming ) naming are welcome :) I think this is over-design. Let's keep it simple, unless there's a real need to have something more complicated. Other issues/enhancements/wishes: - the code-aster package creates both /usr/lib/aster an /usr/lib/codeaster; the latter seems to be used just for a symlink from ../../share/aster . It's just a leftover of the old packaging, or CA looks for files in this path? Note however that code-aster-run puts some files under /usr/lib/codeaster, so we shoult ideally take also care of code-aster-run and code-aster-gui packages. This symlink is precisely here so that as_run (from code-aster-run package) can still be used when aster is installed in /usr/lib/aster (not /usr/lib/codeaster). Ultimately, astk's packaging should be updated in order not to need this, but I currently I no time to do this. - In the process, I'd like also to switch from svn to git. Not sure I get your point. It's already done. - as_run doesn't work out of the box: it relies on having informations about available versions in the file /etc/codeaster/aster ; the script update-codeaster-engines takes care of this, it should be run on postinst/postrm scripts of the code-aster-*-engine packages. What does not work? AFAICT, it works: I can run 'as_run xxx.export' or some tests like 'as_run --test mtlp100a'. - provide also the serial version - a simple script to run the test cases would be nice... the .comm file that was used for this purpose has been removed from upstream, or it's just me that can't find it? - we should fix libmetis in one way or another, either by adapting the sources to libmetis 5.1.0 (the metis documentation says something about this process) or by changing the default renumerator from METIS to something other, like MD, so that it can be compatible with comm files that doesn't specify the renumerator to be used. The tree latter points would be nice, indeed. - 11.5 is already out And I updated the packaging for this version already. - and I'd like to provide also testing/unstable versions Again, let's keep it simple first. Regards, Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731211: aster: new upstream release, work in progress
Il Mercoledì 26 Marzo 2014 10:07, Denis Laxalde de...@laxalde.org ha scritto: Hi, Andrea Palazzi a écrit : So, the package is good, the only thing that should be changed, if we want to upload the package as soon as possible, is that with this packaging, code-aster-mpi-engine should depend on code-aster and not vice-versa. I don't understand why we'd want this. With the current binary layout, code-aster (the Python library and elements catalog) cannot be used without an engine (the aster binary), whereas the engine could (in theory) be used without the code-aster Python library or elements catalog (although it wouldn't be more useful than a python interpreter). From the Debian policy: The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality. So I would say that code-aster-engine depends on code-aster. On the other hand also code-aster depends on engine, which makes it a circular dependency. They are not forbidden and we can live with it, however I would like to avoid it if possible. Note also that as_run (code-aster-run) depends on code-aster because of config.txt so we would have another circular dependency... the more I think about it the more I feel like we have to find a good solution for this. Note however that code-aster-run puts some files under /usr/lib/codeaster, so we shoult ideally take also care of code-aster-run and code-aster-gui packages. This symlink is precisely here so that as_run (from code-aster-run package) can still be used when aster is installed in /usr/lib/aster (not /usr/lib/codeaster). Ultimately, astk's packaging should be updated in order not to need this, but I currently I no time to do this. Ok, let's just keep it as it is then. - In the process, I'd like also to switch from svn to git. Not sure I get your point. It's already done. I was talking about the astk packages, but if you don't have the time to maintain them then let's stay on svn. - as_run doesn't work out of the box: it relies on having informations about available versions in the file /etc/codeaster/aster ; the script update-codeaster-engines takes care of this, it should be run on postinst/postrm scripts of the code-aster-*-engine packages. What does not work? AFAICT, it works: I can run 'as_run xxx.export' or some tests like 'as_run --test mtlp100a'. You're right: it works because the template /etc/codeaster/aster file points to STABLE when installed. However a sysadmin is not supposed to edit the file every time an engine package is installed or removed: as I said previously, this is more a status file than a config file, so the issue is still valid: we need a way to update the /etc/codeaster/aster file when an engine package is installed, be it the old postinst scripts or some other mechanism. - provide also the serial version - a simple script to run the test cases would be nice... the .comm file that was used for this purpose has been removed from upstream, or it's just me that can't find it? In the previous packaging there were an as_test script, maybe I can work on it... - 11.5 is already out And I updated the packaging for this version already. Great :D - and I'd like to provide also testing/unstable versions Again, let's keep it simple first. Sure, it was just a wish :) Bye Andrea -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731211: aster: new upstream release, work in progress
Yet another update: I rebased the packaging on the current stable release (11.5.0 w.r.t. 11.4 at the time I started working on it). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731211: aster: new upstream release, work in progress
Hi, Some other changes and Lintian warnings fixes: - install the elements catalog in /usr/lib/aster as it is architecture dependent. - install the Python library in code-aster binary as it is not tied to the underlying engine. Regards. -- Denis Laxalde Logilab http://www.logilab.fr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731211: aster: new upstream release, work in progress
Andrea Palazzi a écrit : I propose to disable it for the moment and focus on getting a working and lintian-clean package; then we can think about what to do with metis and also work to build multiple versions. That seems reasonable. Added two commits for this. Of course, some tests will not pass anymore, but at least, Aster is back in main. AFAICT, the package is lintian clean except for missing manpages. Anything else? Regards. -- Denis Laxalde Logilab http://www.logilab.fr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731211: aster: new upstream release, work in progress
Hi, Andrea Palazzi a écrit : - I'd really prefer to remove the libmetis dependency and keep it in main and not in contrib; after all libmetis is not absolutely required ( the patch no_metis_default.diff was there to change the default renumerator from metis to md ) , and I think that packages in contrib are out of the auto-builder circuit. Moreover we all prefer 100% free software ;-) I agree that this Aster in Debian would be better with the non-free dependency on libmetis. However, I actually had troubles during build with scotch version of metis. I will look into this further, though. - I would really like to have both the serial and mpi version available: the serial version is faster if you're not running a cluster I'm not opposed to having both versions but, again, I had trouble building the non-mpi flavor. So I actually chose the simplest path to having a working version of code-aster in Debian. - then, if you have two (or more) versions, you'll need a script to update the information in /etc/codeaster/aster ; note that this file is partly a status file - that is, its content represents some kind of status, in our case the available versions: this is what the postinst/postrm scripts were supposed to do Not sure how soon we'll have two (or more) versions of code-aster. - not sure if it's automatically done somewhere, but on 64 bit architectures you'll have to pass -D_MED_USE_SHORT_INT to the compiler to be able to open med files This is done automatically, there's a call to 'check_sizeof_med_int' at configure step. PS: the package fails to build on my system with git-buildpackage - it seems it can't find some metis file, but I have installed libmetis-dev. It also fails with git-buildpackage/cowbuilder because libmetis is in non-free... how do you build the package? Either using debian/rules binary or dpkg-buildpackage or sbuild. It builds fine on Sid and Wheezy, as well as in sbuild's chroots. I'm not surprised git-buildpackage does not work as is, since I didn't figure out yet what the git repository layout should be. Thank you for your comments ! Regards. -- Denis Laxalde Logilab http://www.logilab.fr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731211: aster: new upstream release, work in progress
On Tue, 2014-03-18 at 08:38 +0100, Denis Laxalde wrote: Hi, Andrea Palazzi a écrit : - I'd really prefer to remove the libmetis dependency and keep it in main and not in contrib; after all libmetis is not absolutely required ( the patch no_metis_default.diff was there to change the default renumerator from metis to md ) , and I think that packages in contrib are out of the auto-builder circuit. Moreover we all prefer 100% free software ;-) I agree that this Aster in Debian would be better with the non-free dependency on libmetis. However, I actually had troubles during build with scotch version of metis. I will look into this further, though. libmetis license has recently changed :) It is no longer non-free... but it will require some change in Aster, I guess -- Christophe TROPHIME Research Engineer LNCMI CNRS - LNCMI 25, rue des Martyrs BP 166 38042 GRENOBLE Cedex 9 FRANCE CNRS Tel : +33 (0)4 76 88 90 02 Fax : +33 (0) 4 76 88 10 01 Office U 19 M@il : christophe.troph...@lncmi.cnrs.fr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731211: aster: new upstream release, work in progress
Hi, I did some testing, and I can't build the packages in any way with libmetis or libparmetis, but if I remove it from the build-deps I can make the packages. I propose to disable it for the moment and focus on getting a working and lintian-clean package; then we can think about what to do with metis and also work to build multiple versions. Regarding the build system/repository layout, it seems ok to me: git-buildpackage fails to me for reasons related to metis and not because of the layout of the repository. When I was working on the package, I've found that the best way to build (but not the easiest) is to use git-buildpackage+cowbuilder, in a command like this: $ git-buildpackage --git-builder=pdebuild --pbuilder cowbuilder --buildresult .. --git-ignore-new --git-ignore-branch ../build.log This will build the packages in a pristine environment, and the closest you can get from the buildd environment. You can look at https://wiki.debian.org/cowbuilder for infos on cowbuilder. Feel free to ask if you have doubts or problems with the compilation or other, I'll be glad to help if I can :) Bye Andrea Il Martedì 18 Marzo 2014 9:57, trophime christophe.troph...@lncmi.cnrs.fr ha scritto: On Tue, 2014-03-18 at 08:38 +0100, Denis Laxalde wrote: Hi, Andrea Palazzi a écrit : - I'd really prefer to remove the libmetis dependency and keep it in main and not in contrib; after all libmetis is not absolutely required ( the patch no_metis_default.diff was there to change the default renumerator from metis to md ) , and I think that packages in contrib are out of the auto-builder circuit. Moreover we all prefer 100% free software ;-) I agree that this Aster in Debian would be better with the non-free dependency on libmetis. However, I actually had troubles during build with scotch version of metis. I will look into this further, though. libmetis license has recently changed :) It is no longer non-free... but it will require some change in Aster, I guess -- Christophe TROPHIME Research Engineer LNCMI CNRS - LNCMI 25, rue des Martyrs BP 166 38042 GRENOBLE Cedex 9 FRANCE CNRS Tel : +33 (0)4 76 88 90 02 Fax : +33 (0) 4 76 88 10 01 Office U 19 M@il : christophe.troph...@lncmi.cnrs.fr -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1395132566.15199.2.ca...@calcul8.lcmi.local
Bug#731211: aster: new upstream release, work in progress
Hi,
I am almost done with this packaging work. To sum up:
* There are 3 binary packages: code-aster, code-aster-mpi-engine,
code-aster-tests.
* Everything is installed in /usr/lib/aster or /usr/share/aster
following upstream (instead of /usr/{lib,share}/codeaster as
previously). As a results, as_run (from astk packages) will not find
Aster configuration. To circumvent this, I added a symlink
/usr/share/aster → /usr/lib/codeaster/STABLE so that astk can be used
unmodified.
* I had to move the Python library into /usr/lib/aster (instead of
/usr/lib/pythonX.Y/dist-packages where the build system would have put
it) because it would have cluttered the latter place otherwise (aster
does not have a namespace); it makes sense in general because this
library is essentially private.
* Waf binary is unpacked following instructions from
https://wiki.debian.org/UnpackWaf (leading to a +dfsg1 source package).
* There is a few other patches to the build system, so that it behaves
nicely in a Debian build (e.g. destdir is debian/tmp, ...)
The git repository includes upstream sources:
http://anonscm.debian.org/gitweb/?p=debian-science/packages/aster.git
Could someone review and let me know if this is OK?
Regards,
Denis
--
Denis Laxalde
Logilab http://www.logilab.fr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731211: aster: new upstream release, work in progress
Denis Laxalde a écrit : I've push the current state of my current in a git repository (converted from the svn one): http://anonscm.debian.org/gitweb/?p=debian-science/packages/aster.git Added a few more commits. Currently, I'm able to build aster and to run tests (though with some adjustment to as_run, see below). Now, I have a couple of issues that need to be resolved. 1. The previous packaging shipped the serial and MPI flavor of aster, currently I only build the MPI version (I am not even sure the serial version will work). Do we want to keep both version or could we only ship one, at least over a first phase ? 2. I don't build the -dbg and -dev binaries so far. 3. Why does the package installs into /usr/aster/codeaster, upstream just uses /usr/share/aster ? 4. I cannot use as_run (from code-aster-run binary. astk source) as is, I need to specify the option `--vers /usr/share/codeaster/`, maybe I also need to adjust this package. Most of these questions actually boils down to whether we can step from the previous packaging and consider a simpler approach to begin with and eventually move towards something more complex once everything stabilizes. And if this approach is acceptable, is some sort of transition needed ? Thanks, Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731211: aster: new upstream release, work in progress
Hello, On 06/12/2013 18:48, Denis Laxalde wrote: I've push the current state of my current in a git repository (converted from the svn one): http://anonscm.debian.org/gitweb/?p=debian-science/packages/aster.git It's not finished but I'd welcome any input. I will have a look but I like this kind of commit: http://anonscm.debian.org/gitweb/?p=debian-science/packages/aster.git;a=commitdiff;h=7af3c79a04008c4ec43ca072f41ae15b781956ea ;) S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731211: aster: new upstream release, work in progress
Sylvestre Ledru a écrit : Le 04/12/2013 11:01, Christophe Trophime a écrit : There's a new stable release of Aster available: 11.4. I am currently working on adapting the current packaging for this release. The build system changed (waf inside now), so this requires a bit of work. I think we should stick to the rpevious way of building aster as warf build are discouraged [1] [1] http://lists.debian.org/debian-devel/2012/02/msg00207.html Despite the work of Andrea, Aster has not really been correctly maintained in Debian... We have currently 5 rc bugs... I think that any volunteers to help on aster is welcome :) I've push the current state of my current in a git repository (converted from the svn one): http://anonscm.debian.org/gitweb/?p=debian-science/packages/aster.git It's not finished but I'd welcome any input. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731211: aster: new upstream release, work in progress
Hello, Le 03/12/2013 08:36, Denis Laxalde a écrit : Source: aster Severity: wishlist Hi, There's a new stable release of Aster available: 11.4. I am currently working on adapting the current packaging for this release. The build system changed (waf inside now), so this requires a bit of work. OK. Thanks (and good luck) for doing that work :) Sylvestre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731211: aster: new upstream release, work in progress
There's a new stable release of Aster available: 11.4. I am currently working on adapting the current packaging for this release. The build system changed (waf inside now), so this requires a bit of work. I think we should stick to the rpevious way of building aster as warf build are discouraged [1] [1] http://lists.debian.org/debian-devel/2012/02/msg00207.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731211: aster: new upstream release, work in progress
Le 04/12/2013 11:01, Christophe Trophime a écrit : There's a new stable release of Aster available: 11.4. I am currently working on adapting the current packaging for this release. The build system changed (waf inside now), so this requires a bit of work. I think we should stick to the rpevious way of building aster as warf build are discouraged [1] [1] http://lists.debian.org/debian-devel/2012/02/msg00207.html Despite the work of Andrea, Aster has not really been correctly maintained in Debian... We have currently 5 rc bugs... I think that any volunteers to help on aster is welcome :) Sylvestre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731211: aster: new upstream release, work in progress
Source: aster Severity: wishlist Hi, There's a new stable release of Aster available: 11.4. I am currently working on adapting the current packaging for this release. The build system changed (waf inside now), so this requires a bit of work. Regards, Denis -- Denis Laxalde Logilab http://www.logilab.fr -- System Information: Debian Release: 7.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
