Bug#787861: review: polyml

James Clarke jrtc27 at jrtc27.com
Wed Oct 14 23:51:23 UTC 2015


Hi Gianfranco,

I have uploaded 5.5.2-1~rc2 to mentors.

1) Do I need to send a separate email to this then? I also filed #801793 for a transition, but that has already been closed as unnecessary since there are no rdeps.
2) Added

6) The compiler is indeed forcing your code to be linked against a static library. I would argue that the compiler *should* be included in the polyml package along with the interpreter. The libpolyml-dev package provides access to the internal library used by polyml, whereas the static libpolymain.a library provides an entry point stub for your compiled code. It contains the single libpolymain/polystub.c file, defining main (or WinMain if you happen to compile on Windows…) which calls through to polymain, contained in the *shared* libpolyml.so.6 library, like so:

> int main(int argc, char *argv[])
> {
>     return polymain(argc, argv, &poly_exports);
> }

These are the symbols in libpolymain.a:

> debian:polytest james% nm /usr/lib/x86_64-linux-gnu/libpolymain.a
> 
> polystub.o:
> 0000000000000000 T main
>                  U poly_exports
>                  U polymain

I hardly think linking against this static library is an issue.

7) I have added arm64, ppc64el and ppc64

9) Added (libffi/msvcc.sh is MPL-1.1, GPL-2.0+ or LGPL-2.1+)

11) It doesn’t seem to work without the debian/tmp/ prefix. The manpage for dh_install specifically mentions falling back to debian/tmp/, but there is no such statement in dh_installman, so I believe you have to specify that manually.

New Points:

12) I unused-file-paragraph-in-dep5-copyright: Fixed by reordering entries

13) I vcs-field-not-canonical: Changed to Vcs-Browser: https://anonscm.debian.org/cgit/debian-science/packages/polyml.git/ and Vcs-Git: git://anonscm.debian.org/debian-science/packages/polyml.git

14) W shlib-with-executable-stack: This is because libpolyml has one assembly file[1] for x86 (other architectures don’t have any assembly). I have added a patch under debian/patches which I have also submitted upstream to fix this.

[1] GNU as defaults to having an executable stack, unlike with GCC etc, and you have to explicitly tell it to not do so. You can either do this by adding the magic '.section .note.GNU-stack, "", @progbits' statement, or by passing it a command-line argument. The former is apparently generally preferred (and is what libffi does in its assembly files).

Thanks,
James

> On 14 Oct 2015, at 16:46, Gianfranco Costamagna <costamagnagianfranco at yahoo.it> wrote:
> 
> Hi James,
> 
> 
> 
>> Thank you for continuing to look at this. I have just uploaded the newest version (5.5.2-1~rc1) to https://mentors.debian.net/package/polyml.
> 
> 
> thanks to you for caring!
>> 1) I have sent a request to join debian-science. Presumably I should wait until the package is ready to be uploaded before requesting an upload?
> 
> 
> nope, I'm member of debian-science, I can sponsor it because I'm part of the team already.
> (maybe we can cc debian-science too, I'm doing it right now)
> 
> 
> and this is a package that has only *one* maintainer upload dated 2009 and an NMU dated 2012,
> if somebody complains they should start maintain the package instead of making them outdated :)
> 
> 
>> 2) By this do you mean change it from an NMU to a team upload in the changelog? If so, I have done that.
> 
> correct, but you need to start with a "* Team Upload"
> dch --team does this for you
> 
>> 6) It had it before (https://packages.debian.org/sid/amd64/polyml/filelist). It is in fact required by the new “polyc” compiler executable (a shell script; the output binary is linked against libpolymain) which is currently part of the “polyml” binary package.
> 
> well, and then you are forcing people to link against a static library? I would expect the package polyml to depend on the -dev package, and allowing people to choose their favourite library version
> (or moving the polyc inside the -dev package, since it is useful for developing stuff)
> 
> 7) I know it fails to build on hurd-i386 (due to a lack of PATH_MAX), which I plan to fix and submit upstream. However, I imagine it probably does build on a lot of the other architectures that aren’t listed.
> 
> yes, there is no need to restrict where not necessary.
> specially for ppc64* and arm64 archs I guess it should build cleanly
> 
> 9) The entirety of libffi/ is licensed under the MIT license, and is a copy of the source for https://sourceware.org/libffi/, apart from some unlicensed files in its test suite, and a few other files:
> 
>>> debian:polyml-5.5.2 james% licensecheck * -r | grep -v 'GENERATED FILE$' | grep -v 'LGPL (v2.1 or later)$' | grep -v '^libffi/.* MIT/X11 (BSD like)$' | grep -v '^libffi/testsuite/libffi\.call.*\*No copyright\* UNKNOWN$'
>> 
>> I have added an entry to debian/copyright listing libffi as MIT; is this sufficient?
> 
> 
> I guess you should add also them (at least)
> 
> libffi/msvcc.sh: MPL (v1.1) GPL (unversioned/unknown version)
> libffi/texinfo.tex: GPL (v3)
> libffi/ltmain.sh: GPL (v2 or later)
> ltmain.sh: GPL (v2 or later)
> 
> 11) Changed
> 
> 
> nitpick:
> 
> instead of "debian/tmp/usr/share/man/man1/poly.1"
> 
> it should work also a
> "usr/share/man/man1/poly.1" version.
> 
> 
> new points:
> mentors shows something:
> 
> I unused-file-paragraph-in-dep5-copyright
> 
> paragraph at line 10
> paragraph at line 5
> 
> I vcs-field-not-canonical
> 
> http://git.debian.org/?p=debian-science/packages/polyml.git https://anonscm.debian.org/cgit/debian-science/packages/polyml.git
> git://git.debian.org/git/debian-science/packages/polyml.git git://anonscm.debian.org/debian-science/packages/polyml.git
> 
> 
> W shlib-with-executable-stack
> usr/lib/x86_64-linux-gnu/libpolyml.so.6.0.0
> 
> 
> the last specially is something I never encountered, but seems bad
> 
> 
> cheers,
> 
> Gianfranco

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20151015/a4692402/attachment.sig>


More information about the debian-science-maintainers mailing list