Accepted gmp 2:6.1.2+dfsg-3 (source) into unstable

[James Clarke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 06 Mar 2018 22:04:40 +
Source: gmp
Binary: libgmp10 libgmpxx4ldbl libgmp-dev libgmp10-doc libgmp3-dev
Architecture: source
Version: 2:6.1.2+dfsg-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Team 
<debian-science-maintainers@lists.alioth.debian.org>
Changed-By: James Clarke <jrt...@debian.org>
Description:
 libgmp-dev - Multiprecision arithmetic library developers tools
 libgmp10   - Multiprecision arithmetic library
 libgmp10-doc - Multiprecision arithmetic library example code
 libgmp3-dev - Multiprecision arithmetic library developers tools
 libgmpxx4ldbl - Multiprecision arithmetic library (C++ bindings)
Closes: 892219
Changes:
 gmp (2:6.1.2+dfsg-3) unstable; urgency=medium
 .
   * Team upload.
   * d/control: Use canonical Salsa URL for Vcs-Browser
   * Update symbols file for riscv64.
 Thanks to Manuel A. Fernandez Montecelo (Closes: #892219)
Checksums-Sha1:
 532c318bbad86cd1e43f9dc89e5124c35ef1e4f2 2123 gmp_6.1.2+dfsg-3.dsc
 0abab60b0bc38c727fd45280dcafa435fab4e68b 20824 gmp_6.1.2+dfsg-3.debian.tar.xz
 d6b065955363aae8b58339ae3b9d641d6cf255ec 7313 gmp_6.1.2+dfsg-3_amd64.buildinfo
Checksums-Sha256:
 1c918d2bf8a4fce98fc6bdcd752b36e1cd897114b9b9aeaf5dc661200bbcf9e2 2123 
gmp_6.1.2+dfsg-3.dsc
 8c61aa9fcc1c90052c53bd723b1391acb4c9032bf90fcce27c6facfd8065bf5a 20824 
gmp_6.1.2+dfsg-3.debian.tar.xz
 89a177b96780c645a5d6d56f995a953976fe53e1c8e3b585e5479eac3b7e1198 7313 
gmp_6.1.2+dfsg-3_amd64.buildinfo
Files:
 0a0e6ba068394cf7cb496974c5a9ad4f 2123 libs optional gmp_6.1.2+dfsg-3.dsc
 28595d41fbd052fe871a66dfcc35c7a7 20824 libs optional 
gmp_6.1.2+dfsg-3.debian.tar.xz
 5f32925b5aca8ec7bce2591345986c47 7313 libs optional 
gmp_6.1.2+dfsg-3_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEj1g0K+q+HvQ3lVH7sZN3DBhqHH0FAlqfEwcACgkQsZN3DBhq
HH0A2g//W6HX2uUQRSsev+EiZPQ5bXaU4/Xmc51az/zuLOFnG5GuNvvvGqiSWoOB
uvKP2vaR+OC7XGRAH5tQLIQkANhzGmTLXERHwoxqKVt9HjtFVxUyXRw59eKDzBj/
vX6VK/T2MoGLXW++OXO2HMwrzvJxJXm64EkM9rNhM2AcOXkPCDNDy9tjuIAH29sP
olPvKmELirZERT1AvsNbfhxZ9Z5TXhU11hLgkTe6Fab7faHXIiPu1JR/4N7kUg4h
yxWXZ1gITfk7kfhYHsEnwcgbtyQpptbUU/NOqHZAh6UF7VuxIjBdithj+IyrH80Z
LXptAUn7btdBnhrXcI3b/zY01xs3eRlM603VjHtYpApqqhz5trbcVZGAhVSVSV8Z
a8xQhrDizRzANGrfHpMJTdZxaKHFirSobxQzgRBROwybaA8gbbhrfDwXXNdc2tCz
GneRuK9BBlFYcKTcwQfHd/aWv46trFll668w7zCd19R9YQowNQyREw6j3hzN99pQ
wNWKqzLzcToV0cOO+/qadHZ6FIIGoxQWyUjYyiET/ht1UHkB3suVDlQNaW44okrl
8SmDMFYjZiajhT+bFY2VyC9RA8W0sAMfWoncO5MuegSl0rEaOCo7xAd4dE5UXhjr
108hlXG1VFg4EX3hxXeqWBbz6MYWlwv+26vdtXdi7CXE2eIT2lo=
=lvyu
-END PGP SIGNATURE-


-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Accepted mpi-defaults 1.10 (source) into unstable

[James Clarke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 05 Feb 2018 12:29:49 +
Source: mpi-defaults
Binary: mpi-default-dev mpi-default-bin
Architecture: source
Version: 1.10
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Team 
<debian-science-maintainers@lists.alioth.debian.org>
Changed-By: James Clarke <jrt...@debian.org>
Description:
 mpi-default-bin - Standard MPI runtime programs (metapackage)
 mpi-default-dev - Standard MPI development files (metapackage)
Changes:
 mpi-defaults (1.10) unstable; urgency=medium
 .
   [ James Clarke ]
   * Team upload.
 .
   [ Alastair McKinstry ]
   * Change control.in to match control
 .
   [ James Clarke ]
   * Add ia64 using openmpi
   * Bump debhelper compat level to 11
   * Use https for copyright format URI
   * Bump standards version to 4.1.3, no changes needed
   * Change deprecated extra priority to optional
   * Update Vcs-* to point to salsa
Checksums-Sha1:
 6d7d823191a7bb80e8ed25b4931247404f959aa4 2680 mpi-defaults_1.10.dsc
 d7cdd9f137db6a80ce9bc7321414843da7a16e5b 4864 mpi-defaults_1.10.tar.xz
 45d870b273a4294e17c924cf7af36c1e92d332a6 6570 mpi-defaults_1.10_amd64.buildinfo
Checksums-Sha256:
 fa42bc3bff329ad4b8f028c47f492a7b61d8c63f2467e7e02f043dfe7e9dfb8d 2680 
mpi-defaults_1.10.dsc
 ca4410036cc8f63ce7e3205238612b25a32b300b9bce73ec8d5b00738e0902c4 4864 
mpi-defaults_1.10.tar.xz
 e28f2266a2551a32771463a8310ee987d6298e2db0d1769deb187c581379004d 6570 
mpi-defaults_1.10_amd64.buildinfo
Files:
 199e2a66bcbc325b086562d76103ff48 2680 devel optional mpi-defaults_1.10.dsc
 aa829aa85b9568f625d147ad8c0b6003 4864 devel optional mpi-defaults_1.10.tar.xz
 951d2f59239f9f58f64598f41369d024 6570 devel optional 
mpi-defaults_1.10_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEj1g0K+q+HvQ3lVH7sZN3DBhqHH0FAlp4UE4ACgkQsZN3DBhq
HH2TDBAAjLZGg0Uy0YxQCCGK83PdgpehR3OJr9zCu68Gy47m+856sPApjt+3I0kD
LriU6yZPLkdTY80iVvzw6rgS+DLMRAN92Y9eJQuLwyCdLbsDQvNrMg6L0tjIuUnc
xTwqljLDOFzGBb82fRGDdP/r7ywzZ6t1rqh74vWeKZ6quPPGlkpm7hPgQ1grxNPF
Ma1+mnFjyoBjxLNfSTnCHu5gX6xwn4D6wxGVHIGTJQV388sB1k5WI+tBhShdUD3q
WikQfFiuVS+UYLbZsAQ07YGsXgHFR07Uv2WjFCeukqMzXLH3HJZVKQUPW1dYYO0Y
v39lbOIVyPldHZaCUtSpvXLZP+v0+UKfAjoFqkDXljsyWaUgyU6AqQz5ajOnUfgC
Eu6UopKVtNlO3vjiTQav+gn2IWVAGBHlMizGATrhFScRxP5NGx247Gxbb+e9EB4/
MH28A8a86c/vWQSDk1wo2d3KbZU3VXFR3Neljt5Fc5UY3O4mK/2UanM6FsIROGuq
8FEpc4Atuok6fk+tscVipmEZe4Ed43iJUOwovHQH+wHs4YASol15YIP37zEARq2H
vk/fooCZyCHd0B6jAmlVNY0aQG1990sqQ0vxSrDQFi8JrDv96RNRGn+EzZgBWbUq
VB+UmWsaKWKgM6UUn752KbUIcNBPK1vK1jDgBLLSawhiGtmSJVc=
=H7Fa
-END PGP SIGNATURE-


-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#884054: polyml: FTBFS on sh4: MemMgr: Assertion `t->tree[r] == 0' failed.

[James Clarke]

On 10 Dec 2017, at 23:06, John Paul Adrian Glaubitz 
<glaub...@physik.fu-berlin.de> wrote:
> On 12/11/2017 12:04 AM, James Clarke wrote:
>> Yeah, I noticed this back when I was uploading to experimental a few months
>> ago. I suspect it's an issue with qemu-user's atomics support on sh4, which
>> have been notoriously unreliable in the past, and asked Adrian to see if he
>> could reproduce this on real hardware, but that never ended up happening.
> Sorry, I must have missed that. I will give that a go.

No problem, I asked once a while ago while you were busy and I've had other
priorities since so never got round to reminding you.

> Is there a reduced test case?

Not that I know of; it dies building a module with the just-built Poly/ML
compiler, so dpkg-buildpackage is probably the easiest reproducer.

James

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#884054: polyml: FTBFS on sh4: MemMgr: Assertion `t->tree[r] == 0' failed.

[James Clarke]

> On 10 Dec 2017, at 22:09, Aaron M. Ucko  wrote:
> 
> Source: polyml
> Version: 5.7.1-1
> Severity: important
> Tags: upstream
> Justification: fails to build from source (but built successfully in the past)
> User: debian-sup...@lists.debian.org
> Usertags: sh4
> 
> Builds of polyml 5.7.x for sh4 (admittedly not a release architecture)
> have been failing:
> 
>  echo "use \"./ROOT.sml\";" | ../../poly -q -error-exit
>  poly: memmgr.cpp:957: void MemMgr::AddTreeRange(SpaceTree**, MemSpace*, 
> uintptr_t, uintptr_t): Assertion `t->tree[r] == 0' failed.
> 
> Could you please take a look?

Yeah, I noticed this back when I was uploading to experimental a few months
ago. I suspect it's an issue with qemu-user's atomics support on sh4, which
have been notoriously unreliable in the past, and asked Adrian to see if he
could reproduce this on real hardware, but that never ended up happening. Given
its reliable reproduction on the sh4 vs9X buildds and nowhere else I would be
surprised if it was in fact a bug in the package, but you never know...

James

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#880023: polyml: FTBFS on hppa - error linking poly

[James Clarke]

[Cc'ing David Matthews, upstream maintainer]

On 2 Nov 2017, at 10:27, Alan Modra  wrote:
> On Sat, 28 Oct 2017 10:51:01 -0400 John David Anglin  
> wrote:
>> Source: polyml
>> Version: 5.7
>> Severity: normal
>> 
>> Dear Maintainer,
>> 
>> Build fails here:
>> 
>> Making STRUCT_CONVERSIONALS
>> Created functor STRUCT_CONVERSIONALS
>> Created structure StructConversionals
>> Created structure CInterface
>> /bin/bash ./libtool  --tag=CC   --mode=link gcc   -Wall -fno-strict-aliasing 
>> -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
>> -Werror=format-security   -Wl,--as-needed -o poly  polyexport.o  
>> libpolymain/libpolymain.la libpolyml/libpolyml.la  -lpthread -lffi -lm -ldl 
>> -lstdc++ -lgcc_s -lgcc 
>> libtool: link: gcc -Wall -fno-strict-aliasing -g -O2 
>> -fdebug-prefix-map=/<>=. -Wformat -Werror=format-security 
>> -Wl,--as-needed -o .libs/poly polyexport.o  libpolymain/.libs/libpolymain.a 
>> libpolyml/.libs/libpolyml.so -lpthread -lffi -lm -ldl -lstdc++ -lgcc_s -lgcc
>> /usr/bin/ld: BFD (GNU Binutils for Debian) 2.29.1 internal error, aborting 
>> at ../../bfd/elf32-hppa.c:4054 in elf32_hppa_relocate_section
>> 
>> /usr/bin/ld: Please report this bug.
>> 
>> collect2: error: ld returned 1 exit status
>> Makefile:588: recipe for target 'poly' failed
>> 
>> Full build log is here:
>> https://buildd.debian.org/status/fetch.php?pkg=polyml=hppa=5.7-2=1507223380=0
>> 
>> The error was reported to binutils:
>> https://sourceware.org/bugzilla/show_bug.cgi?id=22300
>> 
>> See "bug 1: polyimport, the producer of polyexport.o is using the wrong 
>> os/abi for hppa-linux." in comment 4.
>> 
>> The binutils part of this bug should now be fixed by commit 
>> c0e331c794d6bd75d9be9bea6145513074c33f39.
> 
> Even when this has been worked around by the binutils change, polyml
> still fails to build.
> 
> echo "use \"/home/amodra/src/polyml/modules/IntInfAsInt/ROOT.sml\";" |
> ../../poly -q -error-exit
> Segmentation fault
> 
> Some debugging shows this is due to a NULL function pointer, traceable
> back to this relocation in polyexport.o
> 
> 0134  1301 R_PARISC_DIR32   PolyProcessEnvGeneral + 0
> 
> That's also an ABI violation.  Function pointers on hppa32 require
> plabel relocations.
> 
> $ cat funcp.c
> extern void foo(void);
> void (*fp)(void) = foo;
> $ hppa-linux-gcc -O -c -save-temps funcp.c
> $ cat funcp.s
>   .LEVEL 1.1
> .globl fpr
>   .section.data.rel,"aw",@progbits
>   .align 4
>   .type   fp, @object
>   .size   fp, 4
> fp:
>   .word   P%foo
>   .ident  "GCC: (GNU) 8.0.0 20171018 (experimental)"
>   .section.note.GNU-stack,"",@progbits
> $ readelf -r funcp.o
> 
> Relocation section '.rela.data.rel' at offset 0xfc contains 1 entries:
> Offset InfoTypeSym.Value  Sym. Name + Addend
>   0841 R_PARISC_PLABEL32    foo + 0

Hi Alan,
Thank you for for looking at this. Poly/ML used to only need to generate
relocations for data, as compiled code never referenced functions; any RTS
calls were made using a unique integer id, with a big switch statement in the
runtime to dispatch. However this has been changed in the latest release to use
the function names directly and these get turned into relocations for function
pointers when exported to an ELF object.

David,
The ABI issue above should probably be fixed. If HP-UX is to be supported, we
can't just use ELFOSABI_NONE instead (which binutils will accept for Linux and
NetBSD), but need to choose based on whether __NetBSD__, __linux__ or __hpux is
defined; that should be simple for me to write.

Regarding the relocations, I believe the code now needs to have directDataReloc
and directFuncReloc, rather than just directReloc, and addExternalReference
can tell writeRelocation to use a function pointer relocation instead? I think
IA-64 is the only other affected architecture (needing R_IA64_FPTR64LSB instead
of R_IA64_DIR64LSB); ELFv1 (but not v2) PPC64 also has function descriptors, but
just uses the normal R_PPC64_ADDR64 to refer to them.

Regards,
James

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#877419: [Help] Exclusion did not worked (Was: Bug#877419: Bug#877700: RM: pandas [arm64 armel armhf mips mips64el mipsel s390x] ...)

[James Clarke]

On 16 Oct 2017, at 11:08, Andreas Tille  wrote:
> On Sun, Oct 15, 2017 at 08:21:46PM +0100, Rebecca N. Palmer wrote:
>>> raise nose.SkipTest("known failure of test_stata on non-little endian")
>>> E   NameError: name 'nose' is not defined
>> 
>> You need an 'import nose' first, if the test doesn't already have one.
> 
> If the 'import nose' is missing why is the test working for amd64, arm64
> but not for s390x?

NameError is only raised when it tries to run that line.

Regards,
James

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#867987: h5py: FTBFS on sparc64 due to unaliged accesses in test suite

[James Clarke]

Source: h5py
Version: 2.7.0-1
Tags: upstream patch
Forwarded: https://github.com/h5py/h5py/pull/904
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org

Hi,
Currently h5py FTBFS on sparc64 (and has done for as long as sparc64 has
been building packages without nocheck), as the test suite crashes with
SIGBUS due to unaligned memory accesses. I have submitted a fix upstream
at the above URL; please include the patch in the Debian package.

Regards,
James

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#866509: openblas: Please enable on sparc64

[James Clarke]

Source: openblas
Version: 0.2.19-3
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org

Hi,
The upstream code supports 64-bit SPARC; please apply the attached
debdiff to enable the build.

Regards,
James
diff -Nru openblas-0.2.19/debian/control openblas-0.2.19/debian/control
--- openblas-0.2.19/debian/control  2017-01-23 14:09:05.0 +
+++ openblas-0.2.19/debian/control  2017-06-29 17:16:00.0 +0100
@@ -12,7 +12,7 @@

 Package: libopenblas-base
 Section: libs
-Architecture: amd64 arm64 armhf i386 powerpc ppc64el ppc64 kfreebsd-i386 
kfreebsd-amd64 mips64el
+Architecture: amd64 arm64 armhf i386 powerpc ppc64el ppc64 kfreebsd-i386 
kfreebsd-amd64 mips64el sparc64
 Depends: ${shlibs:Depends}, ${misc:Depends}, libblas-common
 Provides: libblas.so.3, liblapack.so.3
 Built-Using: ${Built-Using}
@@ -29,7 +29,7 @@

 Package: libopenblas-dev
 Section: libdevel
-Architecture: amd64 arm64 armhf i386 powerpc ppc64el ppc64 kfreebsd-i386 
kfreebsd-amd64 mips64el
+Architecture: amd64 arm64 armhf i386 powerpc ppc64el ppc64 kfreebsd-i386 
kfreebsd-amd64 mips64el sparc64
 Depends: libopenblas-base (= ${binary:Version}), libblas-dev, 
${shlibs:Depends},
  ${misc:Depends}
 Provides: libblas.so, liblapack.so
diff -Nru openblas-0.2.19/debian/rules openblas-0.2.19/debian/rules
--- openblas-0.2.19/debian/rules2017-01-23 14:11:43.0 +
+++ openblas-0.2.19/debian/rules2017-06-29 17:16:00.0 +0100
@@ -48,6 +48,10 @@
GENERIC_OPTIONS += TARGET=POWER8
 endif

+ifeq ($(DEB_HOST_ARCH),sparc64)
+   GENERIC_OPTIONS += TARGET=SPARC
+endif
+
 # The testsuite crashes on PowerPC. Disable it by pretending we are
 # cross-compiling.
 ifeq ($(DEB_HOST_ARCH),powerpc)
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#862595: FTBFS with python3.6

[James Clarke]

Source: reprozip
Version: 1.0.9-2
Tags: upstream patch

Hi,
Currently reprozip FTBFS in Ubuntu[1], which has switched to python3.6.
The failure is in the test suite:

> ==
> ERROR: test_combine (test_reprozip.TestCombine)
> --
> Traceback (most recent call last):
>   File "/<>/debian/tests/test_reprozip.py", line 403, in 
> test_combine
> traceutils.combine_traces(traces, target)
>   File 
> "/<>/.pybuild/pythonX.Y_3.6/build/reprozip/traceutils.py", line 
> 237, in combine_traces
> ''')
> sqlite3.OperationalError: cannot DETACH database within transaction

Looking at the source, reprozip does a series of inserts and deletes
followed by a detach for a list of databases[2]. However, python3.6's
sqlite3 module no longer implicitly commits an open transaction[3] (and
an implicit transaction has been begun in this case), so the DETACH
fails. I have included a patch which fixes this (tested with an artful +
artful-proposed chroot, as well as unstable to check for regressions). I
see there's another conn.commit right after the final DETACH; maybe that
can go now, though it's probably not doing any harm...

Regards,
James

[1] 
https://launchpadlibrarian.net/319561506/buildlog_ubuntu-artful-amd64.reprozip_1.0.9-2_BUILDING.txt.gz
[2] 
https://sources.debian.net/src/reprozip/1.0.9-2/reprozip/traceutils.py/#L234 
and #L239
[3] https://docs.python.org/3/whatsnew/3.6.html

--- a/reprozip/traceutils.py
+++ b/reprozip/traceutils.py
@@ -230,12 +230,20 @@ def combine_traces(traces, target):
 DELETE FROM maps.map_processes;
 ''')
 
+# An implicit transaction gets created. Python used to implicitly
+# commit it, but no longer does as of 3.6, so we have to explicitly
+# commit before detaching.
+conn.commit()
+
 # Detach
 conn.execute(
 '''
 DETACH DATABASE trace;
 ''')
 
+# See above.
+conn.commit()
+
 conn.execute(
 '''
 DETACH DATABASE maps;

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#862585: Please re-enable build on x32

[James Clarke]

Source: reprozip
Version: 1.0.9-2
Severity: wishlist

Hi,
You disabled every architecture except amd64 and i386 as a result of
#862351, but upstream actually supports x32 too (I just successfully
built it in an x32 chroot). Please could you add x32 back to the list of
architectures?

Regards,
James

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#857093: FTBFS on kFreeBSD and Hurd

[James Clarke]

Source: graywolf
Version: 0.1.4+20170307gite1bf319-1
Severity: normal
Tags: patch upstream

Hi,
I noticed that this currently fails to build on kFreeBSD and Hurd, since
it tries to use stdin in an initializer list, which gives an error
(stdin is not a compile-time constant). There is already code to work
around this on Linux, so I'm not sure why it's not used elsewhere, but
the attached patch fixes the build for me on kfreebsd-amd64 (I assume
kfreebsd-i386 and hurd-i386 too, though I have not actually tested
that). It also removes the strange stdio.h handling, which isn't
necessary, but is even more mind-boggling.

Regards,
James
Description: Fix FTBFS on non-Linux since stdin is not a constant
Author: James Clarke <jrt...@jrtc27.com>
Last-Update: 2017-03-07
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/src/mc_compact/readcgraph_l.h
+++ b/src/mc_compact/readcgraph_l.h
@@ -1,8 +1,4 @@
-#ifdef linux
 #include 
-#else
-# include "stdio.h"
-#endif
 #include 
 # define U(x) ((x)&0377)
 # define NLSTATE yyprevious=YYNEWLINE
@@ -22,11 +18,7 @@ int yyleng; extern char yytext[];
 int yymorfg;
 extern char *yysptr, yysbuf[];
 int yytchar;
-#ifdef linux
 FILE *yyin = NULL, *yyout = NULL;
-#else
-FILE *yyin ={stdin}, *yyout ={stdout};
-#endif
 extern int yylineno;
 struct yysvf { 
 	struct yywork *yystoff;
@@ -461,10 +453,8 @@ yylook(){
 	int debug;
 # endif
 	char *yylastch;
-#ifdef linux
 	if (yyin == NULL) yyin = stdin;
 	if (yyout == NULL) yyout = stdout;
-#endif
 	/* start off machines */
 # ifdef LEXDEBUG
 	debug = 0;
@@ -614,16 +604,12 @@ return(0);
 }
 	/* the following are only used in the lex library */
 yyinput(){
-#ifdef linux
 	if (yyin == NULL) yyin = stdin;
-#endif
 	return(input());
 	}
 yyoutput(c)
   int c; {
-#ifdef linux
 	if (yyout == NULL) yyout = stdout;
-#endif
 	output(c);
 	}
 yyunput(c)
--- a/src/mc_compact/readtiles_l.h
+++ b/src/mc_compact/readtiles_l.h
@@ -1,8 +1,4 @@
-#ifdef linux
 #include 
-#else
-# include "stdio.h"
-#endif
 #include 
 # define U(x) ((x)&0377)
 # define NLSTATE yyprevious=YYNEWLINE
@@ -22,11 +18,7 @@ int yyleng; extern char yytext[];
 int yymorfg;
 extern char *yysptr, yysbuf[];
 int yytchar;
-#ifdef linux
 FILE *yyin = NULL, *yyout = NULL;
-#else
-FILE *yyin ={stdin}, *yyout ={stdout};
-#endif
 extern int yylineno;
 struct yysvf { 
 	struct yywork *yystoff;
@@ -516,10 +508,8 @@ yylook(){
 	int debug;
 # endif
 	char *yylastch;
-#ifdef linux
 	if (yyin == NULL) yyin = stdin;
 	if (yyout == NULL) yyout = stdout;
-#endif
 	/* start off machines */
 # ifdef LEXDEBUG
 	debug = 0;
@@ -669,16 +659,12 @@ return(0);
 }
 	/* the following are only used in the lex library */
 yyinput(){
-#ifdef linux
 	if (yyin == NULL) yyin = stdin;
-#endif
 	return(input());
 	}
 yyoutput(c)
   int c; {
-#ifdef linux
 	if (yyout == NULL) yyout = stdout;
-#endif
 	output(c);
 	}
 yyunput(c)
--- a/src/mincut/readcells_l.h
+++ b/src/mincut/readcells_l.h
@@ -1,8 +1,4 @@
-#ifdef linux
 #include 
-#else
-# include "stdio.h"
-#endif
 # define U(x) ((x)&0377)
 # define NLSTATE yyprevious=YYNEWLINE
 # define BEGIN yybgin = yysvec + 1 +
@@ -21,11 +17,7 @@ int yyleng; extern char yytext[];
 int yymorfg;
 extern char *yysptr, yysbuf[];
 int yytchar;
-#ifdef linux
 FILE *yyin =(FILE *)NULL, *yyout =(FILE *)NULL;
-#else
-FILE *yyin ={stdin}, *yyout ={stdout};
-#endif
 extern int yylineno;
 struct yysvf { 
 	struct yywork *yystoff;
@@ -541,10 +533,8 @@ yylook(){
 	int debug;
 # endif
 	char *yylastch;
-#ifdef linux
 	if (yyin == NULL) yyin = stdin;
 	if (yyout == NULL) yyout = stdout;
-#endif
 	/* start off machines */
 # ifdef LEXDEBUG
 	debug = 0;
@@ -694,16 +684,12 @@ return(0);
 }
 	/* the following are only used in the lex library */
 yyinput(){
-#ifdef linux
 	if (yyin == NULL) yyin = stdin;
-#endif
 	return(input());
 	}
 yyoutput(c)
   int c; {
-#ifdef linux
 	if (yyout == NULL) yyout = stdout;
-#endif
 	output(c);
 	}
 yyunput(c)
--- a/src/syntax/readcells_l.h
+++ b/src/syntax/readcells_l.h
@@ -1,8 +1,4 @@
-#ifdef linux
 #include 
-#else
-# include "stdio.h"
-#endif
 # define U(x) ((x)&0377)
 # define NLSTATE yyprevious=YYNEWLINE
 # define BEGIN yybgin = yysvec + 1 +
@@ -21,11 +17,7 @@ int yyleng; extern char yytext[];
 int yymorfg;
 extern char *yysptr, yysbuf[];
 int yytchar;
-#ifdef linux
 FILE *yyin = NULL, *yyout = NULL;
-#else
-FILE *yyin ={stdin}, *yyout ={stdout};
-#endif
 extern int yylineno;
 struct yysvf { 
 	struct yywork *yystoff;
@@ -541,10 +533,8 @@ yylook(){
 	int debug;
 # endif
 	char *yylastch;
-#ifdef linux
 	if (yyin == NULL) yyin = stdin;
 	if (yyout == NULL) yyout = stdout;
-#endif
 	/* start off machines */
 # ifdef LEXDEBUG
 	debug = 0;
@@ -694,16 +684,12 @@ return(0);
 }
 	/* the following are only used in the lex library */
 yyinput(){
-#ifdef linux
 	if (yyin == NULL) yyin = stdin;
-#endif
 	return(input());
 	}
 yyoutput(c)
   int c; {
-#ifdef linux
 	if (yyout == NULL) yyout =

Re: Poly/ML 5.6-3

[James Clarke]

Hi,

> On 13 Mar 2016, at 09:48, Gianfranco Costamagna 
> <costamagnagianfra...@yahoo.it> wrote:
>> Added in 
>> http://anonscm.debian.org/cgit/keyring/keyring.git/commit/?id=bb8f943a3b54332b65cf4a64644e9e8b57bdbdcf.
> 
> ok :)
> 
> please do source-only uploads, or use pbuilder/sbuild to generate the 
> binaries.
> If you are in doubt, don't hesitate to ask me or to the debian-mentors list :)
> 
> $ dcut -k 92978A6E195E4921825F7FF0F34F09744E9F5DD9 ftp-master dm --uid "James 
> Clarke" --allow polyml
> Uploading commands file to ftp.upload.debian.org (incoming: /pub/UploadQueue/)
> Picking DM James Clarke <jrt...@jrtc27.com> with fingerprint 
> 8F58342BEABE1EF4379551FBB193770C186A1C7D
> 
> You need a passphrase to unlock the secret key for
> user: "Gianfranco Costamagna <locutusofb...@debian.org>"
> 4096-bit RSA key, ID 4E9F5DD9, created 2014-09-14
> 
> Uploading locutus-1457862406.dak-commands to ftp-master
> 
> now you should be able to perform the uploads by yourself :)

Thanks, and thank you once again for all your help! I’m sure you’ll still see 
me around the place, even if you won’t get any more of my emails asking you to 
do things for me :)

James



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: Poly/ML 5.6-3

[James Clarke]

Added in 
http://anonscm.debian.org/cgit/keyring/keyring.git/commit/?id=bb8f943a3b54332b65cf4a64644e9e8b57bdbdcf.

James

> On 12 Mar 2016, at 19:11, James Clarke <jrt...@jrtc27.com> wrote:
> 
> Hi,
> It's in the debian-keyring git repo, but February's release was never 
> uploaded to the archive.
> 
> James
> 
>> On 12 Mar 2016, at 18:31, Gianfranco Costamagna 
>> <costamagnagianfra...@yahoo.it> wrote:
>> 
>> Hi, did you perform step 4?
>> 
>> I'm having a look soon, and if your key gets included in debian-keyring just 
>> ping me
>> https://wiki.debian.org/DebianMaintainer
>> 
>> cheers,
>> 
>> G.
>> 
>> 
>> 
>> 
>> 
>> Il Sabato 12 Marzo 2016 18:48, James Clarke <jrt...@jrtc27.com> ha scritto:
>> Hi Gianfranco,
>> I’m ready to release polyml 5.6-3, with the following changes:
>> 
>> polyml (5.6-3) unstable; urgency=low
>> 
>> * Support for the Hurd
>> * Build is now reproducible
>> * Bump up Standards-Version to 3.9.7
>> * New patches:
>>   - alpha.diff: Add support for alpha
>>   - bss-ioarea.diff: Export ioarea to bss section
>>   - m68k.diff: Add support for m68k
>>   - maxpathlen.diff: Remove all use of MAXPATHLEN
>>   - mips64.diff: Add support for mips64/mips64el
>>   - noexec-stack-gnu.diff: Mark stack as non-executable on all GNU systems
>>   - noflsh-unsigned.diff: Cast NOFLSH to unsigned (fixes a warning on the
>>   Hurd)
>>   - source-date-epoch.diff: Use SOURCE_DATE_EPOCH instead of current time if
>>   it is defined
>>   - x32.diff: Add support for x32
>> 
>> -- James Clarke <jrt...@jrtc27.com>  Sat, 12 Mar 2016 17:17:35 +
>> 
>> I don’t believe I yet have permission to upload polyml; could you please 
>> either grant me permission or sponsor another upload? In case of the latter, 
>> I have uploaded 5.6-3 to mentors.
>> 
>> Thanks,
>> James



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: Poly/ML 5.6-3

[James Clarke]

Hi,
It's in the debian-keyring git repo, but February's release was never uploaded 
to the archive.

James

> On 12 Mar 2016, at 18:31, Gianfranco Costamagna 
> <costamagnagianfra...@yahoo.it> wrote:
> 
> Hi, did you perform step 4?
> 
> I'm having a look soon, and if your key gets included in debian-keyring just 
> ping me
> https://wiki.debian.org/DebianMaintainer
> 
> cheers,
> 
> G.
> 
> 
> 
> 
> 
> Il Sabato 12 Marzo 2016 18:48, James Clarke <jrt...@jrtc27.com> ha scritto:
> Hi Gianfranco,
> I’m ready to release polyml 5.6-3, with the following changes:
> 
> polyml (5.6-3) unstable; urgency=low
> 
>  * Support for the Hurd
>  * Build is now reproducible
>  * Bump up Standards-Version to 3.9.7
>  * New patches:
>- alpha.diff: Add support for alpha
>- bss-ioarea.diff: Export ioarea to bss section
>- m68k.diff: Add support for m68k
>- maxpathlen.diff: Remove all use of MAXPATHLEN
>- mips64.diff: Add support for mips64/mips64el
>- noexec-stack-gnu.diff: Mark stack as non-executable on all GNU systems
>- noflsh-unsigned.diff: Cast NOFLSH to unsigned (fixes a warning on the
>Hurd)
>- source-date-epoch.diff: Use SOURCE_DATE_EPOCH instead of current time if
>it is defined
>- x32.diff: Add support for x32
> 
> -- James Clarke <jrt...@jrtc27.com>  Sat, 12 Mar 2016 17:17:35 +
> 
> I don’t believe I yet have permission to upload polyml; could you please 
> either grant me permission or sponsor another upload? In case of the latter, 
> I have uploaded 5.6-3 to mentors.
> 
> Thanks,
> James

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Poly/ML 5.6-3

[James Clarke]

Hi Gianfranco,
I’m ready to release polyml 5.6-3, with the following changes:

polyml (5.6-3) unstable; urgency=low

  * Support for the Hurd
  * Build is now reproducible
  * Bump up Standards-Version to 3.9.7
  * New patches:
- alpha.diff: Add support for alpha
- bss-ioarea.diff: Export ioarea to bss section
- m68k.diff: Add support for m68k
- maxpathlen.diff: Remove all use of MAXPATHLEN
- mips64.diff: Add support for mips64/mips64el
- noexec-stack-gnu.diff: Mark stack as non-executable on all GNU systems
- noflsh-unsigned.diff: Cast NOFLSH to unsigned (fixes a warning on the
Hurd)
- source-date-epoch.diff: Use SOURCE_DATE_EPOCH instead of current time if
it is defined
- x32.diff: Add support for x32

 -- James Clarke <jrt...@jrtc27.com>  Sat, 12 Mar 2016 17:17:35 +

I don’t believe I yet have permission to upload polyml; could you please either 
grant me permission or sponsor another upload? In case of the latter, I have 
uploaded 5.6-3 to mentors.

Thanks,
James



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: polyml 5.6-2

[James Clarke]

(Cc'd Debian Science as I forgot to in my original email)

That's odd; the only thing I can think of is I changed git-buildpackage from 
re-creating the orig.tar.gz from the upstream tag to it using the pristine-tar 
branch... Perhaps they're not identical then? Anyway, thanks!

I didn't realise you thought I was ready; thanks, I may do so.

Regards,
James

> On 1 Feb 2016, at 10:47, Gianfranco Costamagna 
> <costamagnagianfra...@yahoo.it> wrote:
> 
> Hi, bad tarball is bad
> dpkg-source: error: file /tmp/polyml_5.6.orig.tar.gz has size 6066166 instead 
> of expected 5989514
> 
> 
> anyway, I downloaded the tarball from unstable, applied your debian fixes, 
> signed and uploaded!
> 
> next time please be sure the orig tarball is the same, otherwise I can't 
> upload :)
> 
> and please consider applying as DM, if I didn't asked you already :)
> (I almost blindly trusted the upstream changes, I have no knowledge about the 
> patches)
> 
> cheers,
> 
> Gianfranco
> 
> 
> 
> 
> Il Lunedì 1 Febbraio 2016 1:08, James Clarke <jrt...@jrtc27.com> ha scritto:
> Hi Gianfranco,
> I’ve backported some of upstream’s fixes (including modifying the soft-float 
> patch to reflect what was decided on upstream), and have added a couple of my 
> own (fixed an ld warning on mips, and fixed a narrowing conversion warning on 
> PowerPC which is an error with GCC 6’s C++11 default). These are in 5.6-2 on 
> mentors; could you please take a look?
> 
> Thanks,
> James

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: polyml 5.6-1 (was: polyml 5.5.2-4)

[James Clarke]

Great, thanks! And yes, the ABI bump annoyingly slows things down a little...

Regards,
James

> On 26 Jan 2016, at 10:26, Gianfranco Costamagna 
> <costamagnagianfra...@yahoo.it> wrote:
> 
> Hi, sponsoring in a few moments.
> 
> note: it will go through binNEW queue :)
> 
> cheers,
> 
> G.
> 
> 
> 
> 
> 
> Il Martedì 26 Gennaio 2016 10:12, James Clarke <jrt...@jrtc27.com> ha scritto:
> Hi Gianfranco,
> I have uploaded 5.6-1 to mentors; could you please review it?
> 
> Thanks,
> James
> 
> 
>> On 25 Jan 2016, at 21:08, James Clarke <jrt...@jrtc27.com> wrote:
>> 
>> Ok, hopefully my s390x build will finish soon and I can then upload 5.6-1 to 
>> mentors including S/390 support (and thus, barring any regressions, have 
>> support for every release architecture!).
>> 
>> Thanks,
>> James
>> 
>>> On 25 Jan 2016, at 21:07, Gianfranco Costamagna 
>>> <costamagnagianfra...@yahoo.it> wrote:
>>> 
>>> Again, I think I'll trust your dsc file, but unfortunately I need to prior 
>>> have one to test and double check/report back in case of issues.
>>> 
>>> So if you have a dsc, please share, I think it will be fine!
>>> 
>>> Cheers,
>>> G.
>>> 
>>> Sent from Yahoo Mail on Android
>>> 
>>> On Mon, 25 Jan, 2016 at 22:00, James Clarke
>>> <jrt...@jrtc27.com> wrote:
>>> Hi Gianfranco,
>>> For platforms where fe{g,s}etround (and other equivalent functions for 
>>> different platforms), the implementation of {g,s}etRoundingMode is to raise 
>>> an exception saying “Unable to set floating point rounding control” which 
>>> can be either be caught in the user’s ML code or left to propagate up to 
>>> the top level leading to an uncaught exception.
>>> 
>>> My proposal is this:
>>> 
>>> * On systems with __SOFTFP__ defined, raise an exception as above stating 
>>> that {g,s}etRoundingMode is not supported for software-based floating point 
>>> implementations.
>>> * Modify the test case to catch this exception, in effect skipping it on 
>>> armel.
>>> 
>>> What do you think?
>>> 
>>> Upstream has also just released 5.6 (it’s been on the horizon for a month 
>>> but no date was given; if only they could have done so yesterday!). I have 
>>> already updated locally and got it working for amd64. I also potentially 
>>> have a working s390x patch (had to fix some assumptions in the code that 
>>> break on a 64-bit big-endian architecture); just waiting for it to finish 
>>> building in the emulator. Assuming my s390x patch works and you approve of 
>>> my armel proposal, I will go ahead and add those to the package and then 
>>> upload 5.6-1 to mentors.
>>> 
>>> Thanks,
>>> James
>>> 
>>>> On 25 Jan 2016, at 20:49, Gianfranco Costamagna 
>>>> <costamagnagianfra...@yahoo.it> wrote:
>>>> 
>>>> Hi, you are the maintainer, so it should be only up to you to make the 
>>>> final decision about architectures to support.
>>>> You need to understand the use case of this particular test, what is the 
>>>> probability to hit this with real code running on an armel machine? In 
>>>> fact since this has almost never worked on armel it wouldn't be a real 
>>>> regression, but I'll leave to you the decision about the topic, and to me 
>>>> eventually to complain if I don't like your solution (and you are free to 
>>>> find a sponsor that likes better your approach) :-)
>>>> 
>>>> Just jocking, I always found a common agreement prior to sponsor a package 
>>>> :)
>>>> 
>>>> So, at the end, please tell me your solution, or even better give me a dsc 
>>>> to sponsor :)
>>>> 
>>>> If the bug is in glibc seems rather good to report it and disable the test.
>>>> (Remember to reenable it if glibc gets fixed)
>>>> 
>>>> If it is by design broken on armel you might want to add a pointer 
>>>> somewhere for the user, or a note in the manpage.
>>>> 
>>>> But again you are the maintainer, I trust your opinion after sponsoring 4 
>>>> times already the package!
>>>> 
>>>> Cheers,
>>>> 
>>>> Gianfranco
>>>> 
>>>> Sent from Yahoo Mail on Android
>>>> 
>>>> On Mon, 25 Jan, 2016 at 20:55, James Clarke
>>&

polyml 5.6-1 (was: polyml 5.5.2-4)

[James Clarke]

Hi Gianfranco,
I have uploaded 5.6-1 to mentors; could you please review it?

Thanks,
James

> On 25 Jan 2016, at 21:08, James Clarke <jrt...@jrtc27.com> wrote:
> 
> Ok, hopefully my s390x build will finish soon and I can then upload 5.6-1 to 
> mentors including S/390 support (and thus, barring any regressions, have 
> support for every release architecture!).
> 
> Thanks,
> James
> 
>> On 25 Jan 2016, at 21:07, Gianfranco Costamagna 
>> <costamagnagianfra...@yahoo.it> wrote:
>> 
>> Again, I think I'll trust your dsc file, but unfortunately I need to prior 
>> have one to test and double check/report back in case of issues.
>> 
>> So if you have a dsc, please share, I think it will be fine!
>> 
>> Cheers,
>> G.
>> 
>> Sent from Yahoo Mail on Android
>> 
>> On Mon, 25 Jan, 2016 at 22:00, James Clarke
>> <jrt...@jrtc27.com> wrote:
>> Hi Gianfranco,
>> For platforms where fe{g,s}etround (and other equivalent functions for 
>> different platforms), the implementation of {g,s}etRoundingMode is to raise 
>> an exception saying “Unable to set floating point rounding control” which 
>> can be either be caught in the user’s ML code or left to propagate up to the 
>> top level leading to an uncaught exception.
>> 
>> My proposal is this:
>> 
>> * On systems with __SOFTFP__ defined, raise an exception as above stating 
>> that {g,s}etRoundingMode is not supported for software-based floating point 
>> implementations.
>> * Modify the test case to catch this exception, in effect skipping it on 
>> armel.
>> 
>> What do you think?
>> 
>> Upstream has also just released 5.6 (it’s been on the horizon for a month 
>> but no date was given; if only they could have done so yesterday!). I have 
>> already updated locally and got it working for amd64. I also potentially 
>> have a working s390x patch (had to fix some assumptions in the code that 
>> break on a 64-bit big-endian architecture); just waiting for it to finish 
>> building in the emulator. Assuming my s390x patch works and you approve of 
>> my armel proposal, I will go ahead and add those to the package and then 
>> upload 5.6-1 to mentors.
>> 
>> Thanks,
>> James
>> 
>>> On 25 Jan 2016, at 20:49, Gianfranco Costamagna 
>>> <costamagnagianfra...@yahoo.it> wrote:
>>> 
>>> Hi, you are the maintainer, so it should be only up to you to make the 
>>> final decision about architectures to support.
>>> You need to understand the use case of this particular test, what is the 
>>> probability to hit this with real code running on an armel machine? In fact 
>>> since this has almost never worked on armel it wouldn't be a real 
>>> regression, but I'll leave to you the decision about the topic, and to me 
>>> eventually to complain if I don't like your solution (and you are free to 
>>> find a sponsor that likes better your approach) :-)
>>> 
>>> Just jocking, I always found a common agreement prior to sponsor a package 
>>> :)
>>> 
>>> So, at the end, please tell me your solution, or even better give me a dsc 
>>> to sponsor :)
>>> 
>>> If the bug is in glibc seems rather good to report it and disable the test.
>>> (Remember to reenable it if glibc gets fixed)
>>> 
>>> If it is by design broken on armel you might want to add a pointer 
>>> somewhere for the user, or a note in the manpage.
>>> 
>>> But again you are the maintainer, I trust your opinion after sponsoring 4 
>>> times already the package!
>>> 
>>> Cheers,
>>> 
>>> Gianfranco
>>> 
>>> Sent from Yahoo Mail on Android
>>> 
>>> On Mon, 25 Jan, 2016 at 20:55, James Clarke
>>> <jrt...@jrtc27.com> wrote:
>>> Hi Gianfranco,
>>> 
>>> 
>>>>> I think it’s implemented in glibc, not gcc; certainly fe{g,s}etround are. 
>>>>> Should I get in touch with debian-arm?
>>>> 
>>>> probably yes, even if I don't care there are much armel porters there...
>>>> 
>>>> You might end up in asking ftpmaster to remove the armel binary.
>>> 
>>> 
>>> Ok, I think I’ve worked out what’s going on. The software floating-point 
>>> implementation seems to only support FE_NEAREST. On an ARM device without 
>>> an FPU, fe{g,s}etround are not supported and should return 1. However, if 
>>> you are running on an ARM device which has an FPU, fe{g,s}etround will 
>>

Re: polyml 5.5.2-4

[James Clarke]

Hi Gianfranco,

>> I think it’s implemented in glibc, not gcc; certainly fe{g,s}etround are. 
>> Should I get in touch with debian-arm?
> 
> probably yes, even if I don't care there are much armel porters there...
> 
> You might end up in asking ftpmaster to remove the armel binary.

Ok, I think I’ve worked out what’s going on. The software floating-point 
implementation seems to only support FE_NEAREST. On an ARM device without an 
FPU, fe{g,s}etround are not supported and should return 1. However, if you are 
running on an ARM device which has an FPU, fe{g,s}etround will change the FPU’s 
rounding mode and return 0 for success, but because the floating-point 
operations are done in software, the rounding mode has no effect. In short, 
there’s no way for polyml to have proper rounding support on armel. Evidence 
supporting this is below.

On cortex-r5:

Current rounding: 0
Setting to FE_UPWARD (4194304): 1 <- rounding mode not supported
Current rounding: 0
1.0 / 3.0: 0.15
1.0 / 3.0 * 1.0: 1.00
Current rounding: 0

On cortex-a8:

Current rounding: 0
Setting to FE_UPWARD (4194304): 0
Current rounding: 4194304
1.0 / 3.0: 0.15
1.0 / 3.0 * 1.0: 1.00
Current rounding: 4194304

Given that libc ships on armel but does not conform to the standard for 
rounding, would it make sense to ship polyml for armel with this test disabled? 
It seems a shame not to support armel at all.

Regards,
James


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: polyml 5.5.2-4

[James Clarke]

Ok, hopefully my s390x build will finish soon and I can then upload 5.6-1 to 
mentors including S/390 support (and thus, barring any regressions, have 
support for every release architecture!).

Thanks,
James

> On 25 Jan 2016, at 21:07, Gianfranco Costamagna 
> <costamagnagianfra...@yahoo.it> wrote:
> 
> Again, I think I'll trust your dsc file, but unfortunately I need to prior 
> have one to test and double check/report back in case of issues.
> 
> So if you have a dsc, please share, I think it will be fine!
> 
> Cheers,
> G.
> 
> Sent from Yahoo Mail on Android
> 
> On Mon, 25 Jan, 2016 at 22:00, James Clarke
> <jrt...@jrtc27.com> wrote:
> Hi Gianfranco,
> For platforms where fe{g,s}etround (and other equivalent functions for 
> different platforms), the implementation of {g,s}etRoundingMode is to raise 
> an exception saying “Unable to set floating point rounding control” which can 
> be either be caught in the user’s ML code or left to propagate up to the top 
> level leading to an uncaught exception.
> 
> My proposal is this:
> 
> * On systems with __SOFTFP__ defined, raise an exception as above stating 
> that {g,s}etRoundingMode is not supported for software-based floating point 
> implementations.
> * Modify the test case to catch this exception, in effect skipping it on 
> armel.
> 
> What do you think?
> 
> Upstream has also just released 5.6 (it’s been on the horizon for a month but 
> no date was given; if only they could have done so yesterday!). I have 
> already updated locally and got it working for amd64. I also potentially have 
> a working s390x patch (had to fix some assumptions in the code that break on 
> a 64-bit big-endian architecture); just waiting for it to finish building in 
> the emulator. Assuming my s390x patch works and you approve of my armel 
> proposal, I will go ahead and add those to the package and then upload 5.6-1 
> to mentors.
> 
> Thanks,
> James
> 
> > On 25 Jan 2016, at 20:49, Gianfranco Costamagna 
> > <costamagnagianfra...@yahoo.it> wrote:
> >
> > Hi, you are the maintainer, so it should be only up to you to make the 
> > final decision about architectures to support.
> > You need to understand the use case of this particular test, what is the 
> > probability to hit this with real code running on an armel machine? In fact 
> > since this has almost never worked on armel it wouldn't be a real 
> > regression, but I'll leave to you the decision about the topic, and to me 
> > eventually to complain if I don't like your solution (and you are free to 
> > find a sponsor that likes better your approach) :-)
> >
> > Just jocking, I always found a common agreement prior to sponsor a package 
> > :)
> >
> > So, at the end, please tell me your solution, or even better give me a dsc 
> > to sponsor :)
> >
> > If the bug is in glibc seems rather good to report it and disable the test.
> > (Remember to reenable it if glibc gets fixed)
> >
> > If it is by design broken on armel you might want to add a pointer 
> > somewhere for the user, or a note in the manpage.
> >
> > But again you are the maintainer, I trust your opinion after sponsoring 4 
> > times already the package!
> >
> > Cheers,
> >
> > Gianfranco
> >
> > Sent from Yahoo Mail on Android
> >
> > On Mon, 25 Jan, 2016 at 20:55, James Clarke
> > <jrt...@jrtc27.com> wrote:
> > Hi Gianfranco,
> >
> >
> > >> I think it’s implemented in glibc, not gcc; certainly fe{g,s}etround 
> > >> are. Should I get in touch with debian-arm?
> > >
> > > probably yes, even if I don't care there are much armel porters there...
> > >
> > > You might end up in asking ftpmaster to remove the armel binary.
> >
> >
> > Ok, I think I’ve worked out what’s going on. The software floating-point 
> > implementation seems to only support FE_NEAREST. On an ARM device without 
> > an FPU, fe{g,s}etround are not supported and should return 1. However, if 
> > you are running on an ARM device which has an FPU, fe{g,s}etround will 
> > change the FPU’s rounding mode and return 0 for success, but because the 
> > floating-point operations are done in software, the rounding mode has no 
> > effect. In short, there’s no way for polyml to have proper rounding support 
> > on armel. Evidence supporting this is below.
> >
> > On cortex-r5:
> >
> >Current rounding: 0
> >Setting to FE_UPWARD (4194304): 1<- rounding mode not supported
> >Current rounding: 0
> >1.0 / 3.0: 0.1

Re: polyml 5.5.2-4

[James Clarke]

Hi Gianfranco,
For platforms where fe{g,s}etround (and other equivalent functions for 
different platforms), the implementation of {g,s}etRoundingMode is to raise an 
exception saying “Unable to set floating point rounding control” which can be 
either be caught in the user’s ML code or left to propagate up to the top level 
leading to an uncaught exception.

My proposal is this:

* On systems with __SOFTFP__ defined, raise an exception as above stating that 
{g,s}etRoundingMode is not supported for software-based floating point 
implementations.
* Modify the test case to catch this exception, in effect skipping it on armel.

What do you think?

Upstream has also just released 5.6 (it’s been on the horizon for a month but 
no date was given; if only they could have done so yesterday!). I have already 
updated locally and got it working for amd64. I also potentially have a working 
s390x patch (had to fix some assumptions in the code that break on a 64-bit 
big-endian architecture); just waiting for it to finish building in the 
emulator. Assuming my s390x patch works and you approve of my armel proposal, I 
will go ahead and add those to the package and then upload 5.6-1 to mentors.

Thanks,
James

> On 25 Jan 2016, at 20:49, Gianfranco Costamagna 
> <costamagnagianfra...@yahoo.it> wrote:
> 
> Hi, you are the maintainer, so it should be only up to you to make the final 
> decision about architectures to support.
> You need to understand the use case of this particular test, what is the 
> probability to hit this with real code running on an armel machine? In fact 
> since this has almost never worked on armel it wouldn't be a real regression, 
> but I'll leave to you the decision about the topic, and to me eventually to 
> complain if I don't like your solution (and you are free to find a sponsor 
> that likes better your approach) :-)
> 
> Just jocking, I always found a common agreement prior to sponsor a package :)
> 
> So, at the end, please tell me your solution, or even better give me a dsc to 
> sponsor :)
> 
> If the bug is in glibc seems rather good to report it and disable the test.
> (Remember to reenable it if glibc gets fixed)
> 
> If it is by design broken on armel you might want to add a pointer somewhere 
> for the user, or a note in the manpage.
> 
> But again you are the maintainer, I trust your opinion after sponsoring 4 
> times already the package!
> 
> Cheers,
> 
> Gianfranco
> 
> Sent from Yahoo Mail on Android
> 
> On Mon, 25 Jan, 2016 at 20:55, James Clarke
> <jrt...@jrtc27.com> wrote:
> Hi Gianfranco,
> 
> 
> >> I think it’s implemented in glibc, not gcc; certainly fe{g,s}etround are. 
> >> Should I get in touch with debian-arm?
> >
> > probably yes, even if I don't care there are much armel porters there...
> >
> > You might end up in asking ftpmaster to remove the armel binary.
> 
> 
> Ok, I think I’ve worked out what’s going on. The software floating-point 
> implementation seems to only support FE_NEAREST. On an ARM device without an 
> FPU, fe{g,s}etround are not supported and should return 1. However, if you 
> are running on an ARM device which has an FPU, fe{g,s}etround will change the 
> FPU’s rounding mode and return 0 for success, but because the floating-point 
> operations are done in software, the rounding mode has no effect. In short, 
> there’s no way for polyml to have proper rounding support on armel. Evidence 
> supporting this is below.
> 
> On cortex-r5:
> 
> Current rounding: 0
> Setting to FE_UPWARD (4194304): 1<- rounding mode not supported
> Current rounding: 0
> 1.0 / 3.0: 0.15
> 1.0 / 3.0 * 1.0: 1.00
> Current rounding: 0
> 
> On cortex-a8:
> 
> Current rounding: 0
> Setting to FE_UPWARD (4194304): 0
> Current rounding: 4194304
> 1.0 / 3.0: 0.15
> 1.0 / 3.0 * 1.0: 1.00
> Current rounding: 4194304
> 
> Given that libc ships on armel but does not conform to the standard for 
> rounding, would it make sense to ship polyml for armel with this test 
> disabled? It seems a shame not to support armel at all.
> 
> Regards,
> James



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: polyml 5.5.2-4

[James Clarke]

> On 25 Jan 2016, at 08:03, James Clarke <jrt...@jrtc27.com> wrote:
> 
> Hi Gianfranco,
> 
>>> Is there any way in which I could get access to an armel porter box to try 
>>> and work out what’s causing the failure?
>> 
>> as a normal contributor not, as a DM yes, after you requested the access, as 
>> a DD yes.
> 
> That was my guess.
> 
>> that said, I'm happy to test patches if you have some, but I can't easily 
>> give you access to a machine
>> (I have a raspberrypi in the office, I could try to wake it on :) )
> 
> I have one, though it’s running

Meant to say: I have one, though it’s running raspbian; would that mess with 
things?

> 
>> anyway, back to my DM days, I always managed to fix the porting issues in 
>> this way
>> pbuilder-dist sid armel update
>> 
>> pbuilder-dist sid armel build polyml_5.5.2-4.dsc
>> 
>> or
>> 
>> pbuilder-dist sid armel login
>> 
>> IIRC you need qemu-user-static or something similar, but it is quite handy 
>> when it works :)
>> (slow but nice)
>> 
>> BTW since a few days it is segfaulting with apt set as resolver (or was it 
>> aptitude the default?)
>> anyway, I added this to my pbuilderrc
>> PBUILDERSATISFYDEPENDSCMD="/usr/lib/pbuilder/pbuilder-satisfydepends-experimental”
> 
> I had been using qemu-user-static with pbuilder and ran into segfaults 
> recently; that’s helpful, thanks. It’s no slower than using qemu to emulate a 
> whole system.
> 
>> it doesn't finish completely the build, but I can go until the failing test
>> Test121.ML => Failed!!
>> Test120.ML => Passed
>> Test119.ML => Passed
>> Test118.ML => Passed
>> Test117.ML => Passed
>> Test116.ML => Passed
>> Test115.ML => Passed
>> 
>> [...]
>> Test026.ML => Passed
>> Test025.ML => qemu: uncaught target signal 11 (Segmentation fault) - core 
>> dumped
>> /bin/bash: line 1: 12858 Doneecho "val () = use 
>> \"./Tests/RunTests\"; val () = OS.Process.exit(if runTests \"./Tests\" then 
>> OS.Process.success else OS.Process.failure):unit;"
>> 12859 Segmentation fault  | ./poly
>> Makefile:1178: recipe for target 'check-local' failed
>> make[3]: *** [check-local] Error 139
>> make[3]: Leaving directory '/build/polyml-5.5.2'
>> Makefile:998: recipe for target 'check-am' failed
>> make[2]: *** [check-am] Error 2
>> make[2]: Leaving directory '/build/polyml-5.5.2'
>> Makefile:707: recipe for target 'check-recursive' failed
>> make[1]: *** [check-recursive] Error 1
>> make[1]: Leaving directory '/build/polyml-5.5.2'
>> dh_auto_test: make -j1 check returned exit code 2
>> debian/rules:7: recipe for target 'build' failed
>> make: *** [build] Error 2
>> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>> 
>> 
>> does this help you?
> 
> I don’t know why it’s segfaulting; I’ve never seen it do that on armel. Could 
> you please post the output of running “./poly < Tests/Succeed/Test121.ML” 
> (the output is silenced when it’s run as part of the test suite)?
> 
> Regards,
> James
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: polyml 5.5.2-4

[James Clarke]

Hi Gianfranco,

>> Is there any way in which I could get access to an armel porter box to try 
>> and work out what’s causing the failure?
> 
> as a normal contributor not, as a DM yes, after you requested the access, as 
> a DD yes.

That was my guess.

> that said, I'm happy to test patches if you have some, but I can't easily 
> give you access to a machine
> (I have a raspberrypi in the office, I could try to wake it on :) )

I have one, though it’s running

> anyway, back to my DM days, I always managed to fix the porting issues in 
> this way
> pbuilder-dist sid armel update
> 
> pbuilder-dist sid armel build polyml_5.5.2-4.dsc
> 
> or
> 
> pbuilder-dist sid armel login
> 
> IIRC you need qemu-user-static or something similar, but it is quite handy 
> when it works :)
> (slow but nice)
> 
> BTW since a few days it is segfaulting with apt set as resolver (or was it 
> aptitude the default?)
> anyway, I added this to my pbuilderrc
> PBUILDERSATISFYDEPENDSCMD="/usr/lib/pbuilder/pbuilder-satisfydepends-experimental”

I had been using qemu-user-static with pbuilder and ran into segfaults 
recently; that’s helpful, thanks. It’s no slower than using qemu to emulate a 
whole system.

> it doesn't finish completely the build, but I can go until the failing test
> Test121.ML => Failed!!
> Test120.ML => Passed
> Test119.ML => Passed
> Test118.ML => Passed
> Test117.ML => Passed
> Test116.ML => Passed
> Test115.ML => Passed
> 
> [...]
> Test026.ML => Passed
> Test025.ML => qemu: uncaught target signal 11 (Segmentation fault) - core 
> dumped
> /bin/bash: line 1: 12858 Doneecho "val () = use 
> \"./Tests/RunTests\"; val () = OS.Process.exit(if runTests \"./Tests\" then 
> OS.Process.success else OS.Process.failure):unit;"
> 12859 Segmentation fault  | ./poly
> Makefile:1178: recipe for target 'check-local' failed
> make[3]: *** [check-local] Error 139
> make[3]: Leaving directory '/build/polyml-5.5.2'
> Makefile:998: recipe for target 'check-am' failed
> make[2]: *** [check-am] Error 2
> make[2]: Leaving directory '/build/polyml-5.5.2'
> Makefile:707: recipe for target 'check-recursive' failed
> make[1]: *** [check-recursive] Error 1
> make[1]: Leaving directory '/build/polyml-5.5.2'
> dh_auto_test: make -j1 check returned exit code 2
> debian/rules:7: recipe for target 'build' failed
> make: *** [build] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> 
> 
> does this help you?

I don’t know why it’s segfaulting; I’ve never seen it do that on armel. Could 
you please post the output of running “./poly < Tests/Succeed/Test121.ML” (the 
output is silenced when it’s run as part of the test suite)?

Regards,
James



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: polyml 5.5.2-4

[James Clarke]

Hi Gianfranco,

>> I quickly looked at the test
>> setRoundingMode(TO_POSINF);
>> check(getRoundingMode() = TO_POSINF);
>> val pos = 1.0/3.0;
>> check(pos * 3.0 > 1.0);
>> val neg = ~1.0/3.0;
>> check(neg * 3.0 > ~1.0);
>> 
>> 
>> well, I'm not sure the test is correct, I mean, you might have the exact 1.0 
>> value too
> 
> 1/3 can’t be represented exactly, so when rounding to +Inf, you get a little 
> bit more than 1/3. 3 can be represented exactly, so 3 * 1/3 is a little more 
> than 1, and since the rounding mode is set to +Inf it should therefore round 
> to a little over 1. I’m pretty sure the test is correct; certainly it works 
> on every other supported platform.

I just wrote a test program (modified from when I was debugging and fixing 
qemu’s ppc rounding mode...):

#include 
#include 

int main(int argc, char **argv) {
int ret;
ret = fegetround();
printf("Current rounding: %d\n", ret);
ret = fesetround(FE_UPWARD);
printf("Setting to FE_UPWARD (%d): %d\n", FE_UPWARD, ret);
ret = fegetround();
printf("Current rounding: %d\n", ret);
double one = 1.0;
double three = 3.0;
double third = one / three;
printf("1.0 / 3.0: %.18f\n", third);
double aboutOne = third * 3.0;
printf("1.0 / 3.0 * 1.0: %.18f\n", aboutOne);
ret = fegetround();
printf("Current rounding: %d\n", ret);
return 0;
}

On amd64:

Current rounding: 0
Setting to FE_UPWARD (2048): 0
Current rounding: 2048
1.0 / 3.0: 0.71
1.0 / 3.0 * 1.0: 1.000223
Current rounding: 2048

On armel:

Current rounding: 0
Setting to FE_UPWARD (4194304): 0
Current rounding: 4194304
Current rounding: 4194304
1.0 / 3.0: 0.15
1.0 / 3.0 * 1.0: 1.00

Besides FE_UPWARD having a different value (given that it’s platform-specific), 
armel calculates 1.0 / 3.0 as 0.15, which is wrong for 
FE_UPWARD (but correct for FE_NEAREST), and I imagine there are similar issues 
for the other rounding modes (other than FE_NEAREST). Any thoughts as to what 
could be going on?

Regards,
James



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: polyml 5.5.2-4

[James Clarke]

> Hi,
> 
>> Meant to say: I have one, though it’s running raspbian; would that mess with 
>> things?
> not sure, I'm pretty sure the bug has always been there, just hidden because 
> of a missing
> testsuite run…

That’s my guess. The test suite wasn’t run before I took over (I feared I had 
stopped it running when I changed debian/rules to modern debhelper) either, so 
who knows how long it’s been there.

> and you don't have too much dependencies on your package, so probably you 
> will hit the bug
> on raspbian too (BTW do you have an armel raspbian? I thought nobody was 
> still using armel,
> and everybody was on armhf for raspberrypi now ;) )

It’s armhf, though you can use an armel pbuilder on top of that, no? The armel 
buildd used has Machine Architecture: armhf.

> anyway, my first build was on qemu pbuilder-dist, and I'm running right now 
> two builds.

Thanks to your pbuilderrc fix I’m running a build myself, although it’s going 
to take a while...

> one locally, and one in a porterbox
> 
> ./poly < Tests/Succeed/Test121.ML
> Poly/ML 5.5.2 Release
> val check = fn: bool -> unit
> exception Unordered
> type decimal_approx =
> {class: float_class, digits: int list, exp: int, sign: bool}
> datatype float_class = INF | NAN | NORMAL | SUBNORMAL | ZERO
> val fromString = fn: string -> decimal_approx option
> val getRoundingMode = fn: unit -> rounding_mode
> datatype real_order = EQUAL | GREATER | LESS | UNORDERED
> datatype rounding_mode = TO_NEAREST | TO_NEGINF | TO_POSINF | TO_ZERO
> val scan = fn:
> (char, 'a) StringCvt.reader -> (decimal_approx, 'a) StringCvt.reader
> val setRoundingMode = fn: rounding_mode -> unit
> val toString = fn: decimal_approx -> string
> val it = (): unit
> val it = (): unit
> val pos = 0.33: real
> Exception- Fail "Wrong" raised
> val neg = ~0.33: real
> Exception- Fail "Wrong" raised
> val it = (): unit
> val it = (): unit
> val pos = 0.33: real
> Exception- Fail "Wrong" raised
> val neg = ~0.33: real
> Exception- Fail "Wrong" raised
> val it = (): unit
> val it = (): unit
> val pos = 0.33: real
> Exception- Fail "Wrong" raised
> val neg = ~0.33: real
> Exception- Fail "Wrong" raised
> val it = (): unit
> val it = (): unit
> val it = (): unit
> val pos = 0.33: real
> val neg = ~0.33: real
> val it = (): unit
> 
> 
> I quickly looked at the test
> setRoundingMode(TO_POSINF);
> check(getRoundingMode() = TO_POSINF);
> val pos = 1.0/3.0;
> check(pos * 3.0 > 1.0);
> val neg = ~1.0/3.0;
> check(neg * 3.0 > ~1.0);
> 
> 
> well, I'm not sure the test is correct, I mean, you might have the exact 1.0 
> value too

1/3 can’t be represented exactly, so when rounding to +Inf, you get a little 
bit more than 1/3. 3 can be represented exactly, so 3 * 1/3 is a little more 
than 1, and since the rounding mode is set to +Inf it should therefore round to 
a little over 1. I’m pretty sure the test is correct; certainly it works on 
every other supported platform.

> setRoundingMode(TO_POSINF);
> check(getRoundingMode() = TO_POSINF);
> val pos = 1.0/3.0;
> check(pos * 3.0 >= 1.0);
> val neg = ~1.0/3.0;
> check(neg * 3.0 >= ~1.0);
> 
> 
> seems to be more appropriate to me (replace > with >=)
> not sure if with Real numbers this is something that can happen
> (I mean this kind of rounding), but seems to be fixing the issue.
> 
> I can upload the fix, if you give me a dsc file :)
> (note: I'm not sure this change is sane, I don't understand polyml language, 
> so probably
> you might have a better point of view than me).
> 
> BTW, what about overriding dh_auto_test to print the command you gave me in 
> case of failure?
> 
> something like
> override_dh_auto_test:
> dh_auto_test || do something in case of failure, e.g. loop and print tests || 
> exit 1

I’m not sure what you mean?

Regards,
James



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: polyml 5.5.2-4

[James Clarke]

Hi Gianfranco,

>> That’s my guess. The test suite wasn’t run before I took over (I feared I 
>> had stopped it running when I changed debian/rules to modern debhelper) 
>> either, so who knows how long it’s been there.
> 
> I don't find running testsuites there
> https://buildd.debian.org/status/logs.php?pkg=polyml=armel

Yeah that’s what I was saying; there are no runs for any previous versions.

>> It’s armhf, though you can use an armel pbuilder on top of that, no? The 
>> armel buildd used has Machine Architecture: armhf.
> 
> I don't know... is it faster than a qemu virtual environment? I'm not sure 
> about it, probably yes, but I never did tests

Probably not given the lack of power on a pi.

>>> override_dh_auto_test:
>>> dh_auto_test || do something in case of failure, e.g. loop and print tests 
>>> || exit 1>
>> 
>> I’m not sure what you mean?
> 
> the || means "exec the next command if the first doesn't exit successfully"
> 
> override_dh_auto_foo
>dh_auto_foo
> is usually a no-op, but if you append a || another command
> 
> it means:
> execute dh_auto_foo, if it returns !=0 then execute "another command", that 
> might be the call you asked me to do before
> 
> since the second command might be successful, but the testsuite wasn't, to 
> avoid hiding testfailures, it is nice to append
> 
> && exit 1 (not || this time, it was a typo from my side), this should mean
> do the test suite
> 
> if it fails, try to print something verbose on buildd machine logs, so we can 
> see what happened, but in this case exit the build with a failure
> value
> 
> look e.g. here
> https://sources.debian.net/src/insighttoolkit4/4.8.2-3.1/debian/rules/

I’m aware of the sh syntax; the trouble is, the test suite doesn’t log anything 
to a file like that example, so I would have to re-run the failed tests 
manually, or mess with the testing code itself.

Have you had a look at my other email which includes a short test program?

Regards,
James



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: polyml 5.5.2-4

[James Clarke]

Hi,
>> Besides FE_UPWARD having a different value (given that it’s 
>> platform-specific), armel calculates 1.0 / 3.0 as 0.15, 
>> which is wrong for FE_UPWARD (but correct for FE_NEAREST), and I imagine 
>> there are similar issues for the other rounding modes (other than 
>> FE_NEAREST). Any thoughts as to what could be going >on?
> sorry but I didn't even understand what you said here :) you have a knowledge 
> on the rounding model order of magnitude higher than mine :)
> I don't think I can help here, but BTW

That’s ok.

> 
> IIRC armel doesn't have floating point instructions, but only emulated in 
> software (this should be the difference with armhf), so can this be
> 
> just a gcc-5 bug? you might want to try and use gcc-4.9 or gcc-6 from 
> experimental to see if the bug is still there
> 
> I did a few seconds ago a build with CC=gcc-4.9 CXX=g++-4.9 in rules file
> and also with gcc-6, it fails on all of them.

I think it’s implemented in glibc, not gcc; certainly fe{g,s}etround are. 
Should I get in touch with debian-arm?

Regards,
James


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: polyml 5.5.2-4

[James Clarke]

Hi Gianfranco,

> 1) you took over the package maintenance, can I see a post where the current 
> uploaders acked the change?

Please see the entirety of this thread in debian-science: 
https://lists.debian.org/debian-science/2016/01/msg00035.html

> 2) a patch against testsuite not mentioned in changelog
> 3) patches against mips* not mentioned in changelog.
> 
> basically I would change changelog mentioning the patch name, e.g.
> new patches:
> foo.diff: add support for foo architecture
> 
> and so on.
> the patches should be good :)

I have amended the changelog and re-uploaded to mentors; how is it now?

Thanks,
James


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: polyml 5.5.2-4

[James Clarke]

Hi Gianfranco (cc’d Lionel and Achim as this upload officially makes me 
uploader),
Many thanks; I’ll push the changes to debian-science/polyml.git.

Regards,
James

> On 24 Jan 2016, at 19:36, Gianfranco Costamagna 
> <costamagnagianfra...@yahoo.it> wrote:
> 
> Signed in a few minutes!
> 
> thanks for your contribution to Debian!
> 
> cheers,
> 
> Gianfranco
> 
> 
> 
> 
> 
> Il Domenica 24 Gennaio 2016 14:54, James Clarke <jrt...@jrtc27.com> ha 
> scritto:
> Hi Gianfranco,
> 
>> 1) you took over the package maintenance, can I see a post where the current 
>> uploaders acked the change?
> 
> Please see the entirety of this thread in debian-science: 
> https://lists.debian.org/debian-science/2016/01/msg00035.html
> 
>> 2) a patch against testsuite not mentioned in changelog
>> 3) patches against mips* not mentioned in changelog.
>> 
>> basically I would change changelog mentioning the patch name, e.g.
>> new patches:
>> foo.diff: add support for foo architecture
>> 
>> and so on.
>> the patches should be good :)
> 
> I have amended the changelog and re-uploaded to mentors; how is it now?
> 
> Thanks,
> 
> James



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: polyml 5.5.2-4

[James Clarke]

Oh right, I wasn’t aware such a thing was the done thing; I was just using 
xindy (just so happened to see that someone took over maintenance of it on 
debian-devel) as a reference. Of course it goes without saying that I’m 
grateful for all the work Lionel and Achim have done on it; I hope nobody 
thinks otherwise. Without them there would be no Poly/ML package on Debian and 
its derivatives.

Thanks for continuing to sponsor me!

Regards,
James

> On 24 Jan 2016, at 19:41, Gianfranco Costamagna 
> <costamagnagianfra...@yahoo.it> wrote:
> 
> I uploaded it a few seconds ago, hopefully it will appear before the next 
> dinstall
> (due in 12 minutes), and then start building everywhere.
> 
> BTW nitpick, usually on changelog when a person takes over a package 
> maintenance
> is used to say somthing like
> "take over the package maintenance
> - thanks Lionel, and Achim for your work!"
> 
> and then upload :)
> 
> anyway, thanks to you both for your work, and James, keep up the nice work!
> (as you did in the last three uploads)
> 
> cheers,
> 
> Gianfranco
> 
> 
> 
> 
> 
> Il Domenica 24 Gennaio 2016 20:38, James Clarke <jrt...@jrtc27.com> ha 
> scritto:
> Hi Gianfranco (cc’d Lionel and Achim as this upload officially makes me 
> uploader),
> Many thanks; I’ll push the changes to debian-science/polyml.git.
> 
> Regards,
> James
> 
> 
>> On 24 Jan 2016, at 19:36, Gianfranco Costamagna 
>> <costamagnagianfra...@yahoo.it> wrote:
>> 
>> Signed in a few minutes!
>> 
>> thanks for your contribution to Debian!
>> 
>> cheers,
>> 
>> Gianfranco
>> 
>> 
>> 
>> 
>> 
>> Il Domenica 24 Gennaio 2016 14:54, James Clarke <jrt...@jrtc27.com> ha 
>> scritto:
>> Hi Gianfranco,
>> 
>>> 1) you took over the package maintenance, can I see a post where the 
>>> current uploaders acked the change?
>> 
>> Please see the entirety of this thread in debian-science: 
>> https://lists.debian.org/debian-science/2016/01/msg00035.html
>> 
>>> 2) a patch against testsuite not mentioned in changelog
>>> 3) patches against mips* not mentioned in changelog.
>>> 
>>> basically I would change changelog mentioning the patch name, e.g.
>>> new patches:
>>> foo.diff: add support for foo architecture
>>> 
>>> and so on.
>>> the patches should be good :)
>> 
>> I have amended the changelog and re-uploaded to mentors; how is it now?
>> 
>> Thanks,
>> 
>> James



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: polyml 5.5.2-4

[James Clarke]

I am aware s390x is failing. I have been trying to port it, and it no longer 
segfaults (thanks to the pexport-endian.diff patch from upstream), but one part 
of the build step (the compiler bootstrapping itself) exits with code 1, 
without printing anything. That’s on my list of things to talk to upstream 
about.

x32 fails because there’s some hand-written assembly that isn’t aware of x32 
(it assumes i386 and amd64 are the only two cases).

Interestingly armel has failed a test case for floating-point (funnily enough I 
had just that test failed when I was testing ppc64el and it turned out to be a 
bug in qemu!), so I’ll need to look into that. Previous uploads weren’t running 
the tests as part of the build, so I don’t know if this is a regression or not. 
armhf has built successfully though...

I’m currently a student, so one package is more than enough, although certainly 
one day I would consider applying to be a Debian Maintainer. Having said that, 
for a package in debian-science, there’s hardly any inconvenience on my part.

Regards,
James

> On 24 Jan 2016, at 20:10, Gianfranco Costamagna 
> <costamagnagianfra...@yahoo.it> wrote:
> 
> Sure, thanks for the kind words for the former maintainers :)
> 
> Btw s390x and x32 just failed to build, you might want to poke upstream about 
> a porting, and ping me about testing patches on porter boxes :)
> 
> If you want ti maintain some other packages you might even consider applying 
> for Debian Contributor or Debian Maintainer, you are doing a good job here, 
> you might even have direct upload privileges one day for this package :)
> 
> Cheers,
> 
> G.
> --------
> Dom 24/1/16, James Clarke <jrt...@jrtc27.com> ha scritto:
> 
> Oggetto: Re: polyml 5.5.2-4
> A: "Gianfranco Costamagna" <costamagnagianfra...@yahoo.it>
> Cc: "Debian Science Team" 
> <debian-science-maintainers@lists.alioth.debian.org>, "Lionel Elie Mamane" 
> <lio...@mamane.lu>, "Achim D. Brucker" <adbruc...@0x5f.org>
> Data: Domenica 24 gennaio 2016, 20:47
> 
> Oh right, I wasn’t
> aware such a thing was the done thing; I was just using
> xindy (just so happened to see that someone took over
> maintenance of it on debian-devel) as a reference. Of course
> it goes without saying that I’m grateful for all the work
> Lionel and Achim have done on it; I hope nobody thinks
> otherwise. Without them there would be no Poly/ML package on
> Debian and its derivatives.
> 
> Thanks for continuing to sponsor me!
> 
> Regards,
> James
> 
>> 
> On 24 Jan 2016, at 19:41, Gianfranco Costamagna 
> <costamagnagianfra...@yahoo.it>
> wrote:
>> 
>> I uploaded
> it a few seconds ago, hopefully it will appear before the
> next dinstall
>> (due in 12 minutes), and
> then start building everywhere.
>> 
>> BTW nitpick, usually on changelog when a
> person takes over a package maintenance
>> 
> is used to say somthing like
>> "take
> over the package maintenance
>> - thanks
> Lionel, and Achim for your work!"
>> 
> 
>> and then upload :)
>> 
>> anyway, thanks to
> you both for your work, and James, keep up the nice work!
>> (as you did in the last three uploads)
>> 
>> cheers,
>> 
>> Gianfranco
>> 
>> 
>> 
>> 
>> 
>> Il Domenica 24
> Gennaio 2016 20:38, James Clarke <jrt...@jrtc27.com>
> ha scritto:
>> Hi Gianfranco (cc’d
> Lionel and Achim as this upload officially makes me
> uploader),
>> Many thanks; I’ll push the
> changes to debian-science/polyml.git.
>> 
> 
>> Regards,
>> James
>> 
>> 
>>> On 24 Jan 2016, at 19:36, Gianfranco
> Costamagna <costamagnagianfra...@yahoo.it>
> wrote:
>>> 
>>> 
> Signed in a few minutes!
>>> 
>>> thanks for
> your contribution to Debian!
>>> 
>>> cheers,
>>> 
>>> Gianfranco
>>> 
> 
>>> 
>>> 
>>> 
>>> 
>>> Il Domenica 24 Gennaio 2016 14:54,
> James Clarke <jrt...@jrtc27.com>
> ha scritto:
>>> Hi Gianfranco,
>>> 
>>>> 1) you
> took over the package maintenance, can I see a post where
> the current uploaders acked the change?
>>> 
>>> Please see
> the entirety of this thread in debian-science: 
> https://lists.debian.org/debian-science/2016/01/msg00035.html
>>> 
>>>> 2) a
> patch against testsuite not mentioned in changelog
>>>> 3) patches against mips* not
> mentioned in changelog.
>>>> 
>>>> basically I would change changelog
> mentioning the patch name, e.g.
>>>> 
> new patches:
>>>> foo.diff: add
> support for foo architecture
>>>> 
> 
>>>> and so on.
>>>> the patches should be good :)
>>> 
>>> I have
> amended the changelog and re-uploaded to mentors; how is it
> now?
>>> 
>>> 
> Thanks,
>>> 
>>> 
> James



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

polyml 5.5.2-4

[James Clarke]

Hi Gianfranco (and Debian Science),
I have been working with upstream to port Poly/ML to additional architectures, 
and have backported these changes. I have uploaded 5.5.2-4 to mentors; could 
you please check it and then upload it?

Thanks,
James



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: polyml 5.5.2-3

[James Clarke]

For some reason, mentors is giving a lintian error for 
"postinst-must-call-ldconfig”, although I have extracted the control 
information from the package and the contents of triggers is:

> # Triggers added by dh_makeshlibs
> activate-noawait ldconfig

as expected, which is supposed to make lintian happy. Running lintian locally 
does not give this error which makes this even stranger.

James

> On 20 Oct 2015, at 22:45, James Clarke <jrt...@jrtc27.com> wrote:
> 
> Hi Gianfranco,
> I’ve updated the package to support arm64 using a patch from upstream, and 
> uploaded it to mentors as 5.5.2-3. Could you please check and upload it?
> 
> Thanks,
> James
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: polyml 5.5.2-3

[James Clarke]

My guess is the version of lintian on mentors.debian.net is not completely up 
to date. Lintian has only accepted the trigger since 2015-09-10 
(https://anonscm.debian.org/cgit/lintian/lintian.git/commit/?id=5468a38e208e7041279fa6b68ab7116a38263865)
 with 2.5.37 being the first version to contain it.

James

> On 20 Oct 2015, at 23:09, James Clarke <jrt...@jrtc27.com> wrote:
> 
> For some reason, mentors is giving a lintian error for 
> "postinst-must-call-ldconfig”, although I have extracted the control 
> information from the package and the contents of triggers is:
> 
>> # Triggers added by dh_makeshlibs
>> activate-noawait ldconfig
> 
> as expected, which is supposed to make lintian happy. Running lintian locally 
> does not give this error which makes this even stranger.
> 
> James
> 
>> On 20 Oct 2015, at 22:45, James Clarke <jrt...@jrtc27.com> wrote:
>> 
>> Hi Gianfranco,
>> I’ve updated the package to support arm64 using a patch from upstream, and 
>> uploaded it to mentors as 5.5.2-3. Could you please check and upload it?
>> 
>> Thanks,
>> James
>> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: Bug#787861: review: polyml

[James Clarke]

Hi Gianfranco,

> I sponsored the package

Thank you again for all your help.

> (BTW I was intending to subscribe to debian-science, but also debian-devel is 
> nice to be subscribed)

I have subscribed to debian-science as well.

> However, I would appreciate a fix for the following missing flags in a future 
> release:
> CXXFLAGS missing (-fPIE):
> LDFLAGS missing (-Wl,-z,now)
> CFLAGS missing (-fPIE):
> LDFLAGS missing (-fPIE -pie -Wl,-z,now)
> you can see the full log here [1] or by using blhc tool
> 
> 
> [1] http://debomatic-i386.debian.net/distribution#unstable/polyml/5.5.2-1/blhc

I have uploaded 5.5.2-2 to mentors (and updated my git repository) enabling all 
hardening flags. I also realised that the new polyc shell script requires gcc 
and libffi-dev to produce standalone executables, so I have added those as 
dependencies for polyml.

Should I push my changes to debian-science/packages/polyml.git (especially 
since that’s the repository in debian/control)? Also, going forwards, if I want 
to get a new version uploaded, do I need to file a new RFS “bug” against 
sponsorship-requests, or should I instead just email debian-science asking for 
a team upload (subject to a review of the package)?

James


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: Bug#787861: review: polyml

[James Clarke]

Hi Gianfranco,

>> I have uploaded 5.5.2-2 to mentors (and updated my git repository) enabling 
>> all hardening flags. I also realised that the new polyc shell script 
>> requires gcc and >libffi-dev to produce standalone executables, so I have 
>> added those as dependencies for polyml.
> 
> wonderful, I'll upload again then :)

Great, thanks.

>> Should I push my changes to debian-science/packages/polyml.git (especially 
>> since that’s the repository in debian/control)? Also, going forwards, if I 
>> want to get a >new version uploaded, do I need to file a new RFS “bug” 
>> against sponsorship-requests, or should I instead just email debian-science 
>> asking for a team upload >(subject to a review of the package)?
> 
> yes, and if you can't do it I can do it for you :)

Pushed.

> For another upload you can ping me directly or add an RFS bug, as you prefer.

Ok, I’ll probably come to you first then seeing as creating an RFS bug can be a 
nuisance; having the same uploader would make sense, rather than some new 
person having to start from scratch with the package every time. Of course, if 
you ever want me to find someone else, please say so; I’ll understand :)

Thanks,
James


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: Bug#787861: review: polyml

[James Clarke]

Hi Gianfranco,

> On 15 Oct 2015, at 10:56, Gianfranco Costamagna 
>  wrote:
> 
> 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.

Changed

>> 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)

Changed to unstable

> 
>> 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-*

Changed to "any"

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

Urgency changed to low (other points addressed above)

> 
> and I guess I'll prepare the upload.
> 
> cheers,
> 
> G.

I have uploaded the latest version to mentors. Currently, the old maintainers 
are still listed in debian/control. I’m happy to assume responsibility for bug 
reports etc, so do I need to add myself to Uploaders? I don’t want to tread on 
anyone’s toes though if that’s bad form.

James



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: Bug#787861: review: polyml

[James Clarke]

Hi Gianfranco,

Apologies for the duplicate message, but I forgot to Cc the bug and 
debian-science.

> well, for sure I suggest you to subscribe to debian-devel mail list and to 
> the package [1] at the bottom of the page.

Done (although to the digest for debian-devel!)

> you can also contact MIA team to know if the maintainers are really MIA, in 
> that case the package will be orphaned and you will be able to take it over.

Email sent

> the problem actually is that the package is not building fine on amd64 and 
> i386.
> 
> "configure.ac:410: error: possibly undefined macro: LT_SYS_SYMBOL_USCORE
> If this token and others are legitimate, please use m4_pattern_allow.
> See the Autoconf documentation.”

I was able to reproduce this when building with pbuilder (just set it up). 
LT_SYS_SYMBOL_USCORE is defined in m4/ltdl.m4, which needs libltdl-dev to do 
so, so I added it to Build-Depends. I never actually installed libltdl-dev 
myself; it was pulled in by libtool as a recommended package, but it seems 
pbuilder/debootstrap only pulls in dependencies, which is how I managed to miss 
this dependency.

> BTW you need to add libffi-dev to build-dependencies and enable it in 
> configure script.

Done (upstream’s configure.ac forces libffi to be configured and is apparently 
needed, even in this case, so don’t be alarmed by that being mentioned in the 
logs!)

I have re-uploaded 5.5.2-1 to mentors. I have also forked 
debian-science/packages/polyml.git to 
http://anonscm.debian.org/cgit/users/jrtc27-guest/polyml.git/ and pushed all my 
changes there.

Thanks,
James Clarke


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#801793: transition: polyml

[James Clarke]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
Severity: normal
X-Debbugs-CC: debian-science-maintainers@lists.alioth.debian.org

The latest upstream version of polyml has bumped the soname up to 6.0.0 
(upstream had 2, 3, 4 and 5, including some minor version bumps, but none of 
these were ever packaged).

Ben file:

title = "polyml";
is_affected = .depends ~ "libpolyml1" | .depends ~ "libpolyml6";
is_good = .depends ~ "libpolyml6";
is_bad = .depends ~ "libpolyml1";


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers