Re: ITP: aster -- Finite Element Analysis (FEA) software for engineering simulations
Le 03/06/11 18:14, Andrea Palazzi a écrit :
Il giorno lun, 30/05/2011 alle 23.56 +0200, Sylvestre Ledru ha scritto:
Le lundi 30 mai 2011 à 22:12 +0200, Andrea Palazzi a écrit :
So, apart from the missing mpirun_template file needed for the
compilation of the parallel version (that is already being resolved),
maybe we are ready to upload the package? I'm not expert in debian
packages, and I wold really like to know how good a package must be to
become part of the distribution... e.g. the package is not yet lintian
clean: does it have to pass lintian tests to enter into Debian?
Yes and no. Errors must be fixed.
Some warnings can be easily fixed, some others (like missing manpages)
are longer and not necessary to be fixed.
What are they ?
E: code-aster-test: arch-independent-package-contains-binary-or-object
usr/lib/codeaster/STA10.3/astest/umat001a.44
E: code-aster-test: unstripped-binary-or-object
usr/lib/codeaster/STA10.3/astest/umat001a.44
E: code-aster-test: arch-independent-package-contains-binary-or-object
usr/lib/codeaster/STA10.3/astest/umat002a.44
E: code-aster-test: unstripped-binary-or-object
usr/lib/codeaster/STA10.3/astest/umat002a.44
E: code-aster-test: arch-independent-package-contains-binary-or-object
usr/lib/codeaster/STA10.3/astest/umat002a.46
E: code-aster-test: unstripped-binary-or-object
usr/lib/codeaster/STA10.3/astest/umat002a.46
E: code-aster-test: missing-dependency-on-libc needed by
usr/lib/codeaster/STA10.3/astest/umat001a.44 and 2 others
I: code-aster-engine: package-contains-empty-directory
usr/lib/codeaster/STA10.3/dtag/
I: code-aster-engine: spelling-error-in-binary
usr/lib/codeaster/STA10.3/asteru_py2.6 ment meant
I: code-aster-mpi-engine: package-contains-empty-directory
usr/lib/codeaster/STA10.3_mpi/dtag/
The binaries in the code-aster-test package are related to the umat
funcionality of code aster to allow user defined materials[1]; I think
these particular files can be removed, but they must be built before
runnign the tests - either automatically or by direct user action.
Maybe the postints script could take care of this?
You can remove them. It is fine. If you have time, don't hesitate to fix
others (but they are not blocking the upload)
The package has also some minor issues, regarding only the running of
the validation cases: are those issues to be fixed before uploading, or
can we live with a package with some bugs?
Well, it depends what you mean by "minor" ;)...
If you want to get feedbacks from compilation chains on other archs, we
could upload it to experimental.
Some perl lines in the rules file, used to set the value of some
variables like ASTER_ROOT in the script astout.export (package
code-aster-test, containing the validation test suite) does not work;
so, one has to modify this script after the installation. Note that the
very same lines, used from the shell, work without problem... I'm still
investigating the problem.
Well, a package like Aster has to work out of the box. We must not
expect the user to update a scrupt.
Did you make some progress on this ?
IMHO the package is good enough to be uploaded: by doing this we (I)
could also test the installation on a machine different from mine; we
could also see how it goes on other architectures... however, to be
honest, I don't know if it's expected to work on all architectures or
only on a limited number.
We will find out. Unstable is for that.
Sylvestre
Reply to: