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

[Gianfranco Costamagna]

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

Re: polyml 5.5.2-4

[Gianfranco Costamagna]

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

[Gianfranco Costamagna]

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

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


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

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

not sure if it works, needs to be tested :)

cheers,

G.

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

[Gianfranco Costamagna]

Hi,

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

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


(note I used apt experimental resolver, but it should work with plain apt, or 
apt-classic 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.


ok


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

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/


cheers,

G.

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

[Gianfranco Costamagna]

Hi,




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


ok, I read it wrongly then :)

>Probably not given the lack of power on a pi.



real hw is anyway better because it can exclude qemu related bugs :)

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


mmm I was thinking about:
dh_auto_test || for i=1 to n do ./poly < Tests/Succeed/Test$$i.ML; done && exit 
1

what is printed here is visible on buildd logs, so you might have at least a 
clue to the test output

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


sure, answer already performed, but not sent
(I'm waiting the result of a build to hit enter :p)



cheers,

G.

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

[Gianfranco Costamagna]

Hi,

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


ok

>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

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.

cheers,

Gianfranco

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

[Gianfranco Costamagna]

Hi,

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

cheers,

Gianfranco

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

[Gianfranco Costamagna]

Hi James,


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



wonderful, lets review:

1) you took over the package maintenance, can I see a post where the current 
uploaders acked the change?
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 :)

cheers,

Gianfranco

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

[Gianfranco Costamagna]

Hi,

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



I'm not sure I can help here... for sure you have to patch configure.ac, but 
other than that some code might be needed aswell.
>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).


ok

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


ok (I'll point you to a solution if possible)

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


wonderful :)

BTW you can apply as DM also if you want to maintain only one package, assuming 
you will in the future try to be more involved :)

cheers,

G.



> 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

Re: polyml 5.5.2-4

[Gianfranco Costamagna]

Hi again,



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


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"



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?

cheers,

Gianfranco

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

[Gianfranco Costamagna]

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  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 
>  wrote:
> 
> Signed in a few minutes!
> 
> thanks for your contribution to Debian!
> 
> cheers,
> 
> Gianfranco
> 
> 
> 
> 
> 
> Il Domenica 24 Gennaio 2016 14:54, James Clarke  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

-- 
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 
>  wrote:
> 
> Signed in a few minutes!
> 
> thanks for your contribution to Debian!
> 
> cheers,
> 
> Gianfranco
> 
> 
> 
> 
> 
> Il Domenica 24 Gennaio 2016 14:54, James Clarke  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 
>  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  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 
>>  wrote:
>> 
>> Signed in a few minutes!
>> 
>> thanks for your contribution to Debian!
>> 
>> cheers,
>> 
>> Gianfranco
>> 
>> 
>> 
>> 
>> 
>> Il Domenica 24 Gennaio 2016 14:54, James Clarke  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

[Gianfranco Costamagna]

Signed in a few minutes!

thanks for your contribution to Debian!

cheers,

Gianfranco





Il Domenica 24 Gennaio 2016 14:54, James Clarke  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

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

[Gianfranco Costamagna]

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

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