[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#787861: review: polyml



Hi James


>I have uploaded 5.5.2-1~rc2 to mentors.



please call it 5.5.2-1 and nothing more :)
you can push the same version many times on mentors with no problems.
>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.


true, nevermind I didn't test carefully rdeps
(so we might go directly on unstable then)

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


ok
>7) I have added arm64, ppc64el and ppc64


what about the "any" keyword? I don't like specifying manually architectures, specially because it makes
porters people angry :)

porters needs a build failure instead of a build that didn't start at all, except when there is a good
reason to not build on a particular architecture
e.g. systemd on kfreebsd-* and hurd-*

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


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


well, no problem
>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).
nice to learn something new! thanks a lot



I guess we are mostly ready, just go on unstable (urgency=low might be better)
think about arch:any

and I guess I'll prepare the upload.

cheers,

G.


Reply to: