Discussion:
Bug#859667: libundead: FTBFS on armhf and ppc64el: tests fail
Add Reply
Aaron M. Ucko
2017-04-05 19:10:02 UTC
Reply
Permalink
Source: libundead
Version: 1.0.6-1
Severity: important
Justification: fails to build from source

The libundead builds for armhf and ppc64 both failed with test suite
errors. On armf, I see no specific indication of what went wrong, but
presume it should be possible to reproduce the problem on a porterbox.
On ppc64el, the log reports an assertion failure at
https://anonscm.debian.org/cgit/debian-med/libundead.git/tree/src/undead/stream.d#n1458:

***@../src/undead/stream.d(1458): Assertion failure

Could you please take a look?

Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?***@monk.mit.edu
Andreas Tille
2017-04-05 20:10:01 UTC
Reply
Permalink
Hi,

I admit I'm totally clueless and thus I'm asking D language team as well as
porters for help.

Thanks for any helpful hint

Andreas.
Post by Aaron M. Ucko
Source: libundead
Version: 1.0.6-1
Severity: important
Justification: fails to build from source
The libundead builds for armhf and ppc64 both failed with test suite
errors. On armf, I see no specific indication of what went wrong, but
presume it should be possible to reproduce the problem on a porterbox.
On ppc64el, the log reports an assertion failure at
Could you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
_______________________________________________
Debian-med-packaging mailing list
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
--
http://fam-tille.de
Iain Buclaw
2017-04-05 20:30:02 UTC
Reply
Permalink
Which compiler? Are NaNs being honoured? What if you were to replace
the `(x != x && f != f)` comparison with `(isNaN(x) && isNaN(f))` ?
Post by Andreas Tille
Hi,
I admit I'm totally clueless and thus I'm asking D language team as well as
porters for help.
Thanks for any helpful hint
Andreas.
Post by Aaron M. Ucko
Source: libundead
Version: 1.0.6-1
Severity: important
Justification: fails to build from source
The libundead builds for armhf and ppc64 both failed with test suite
errors. On armf, I see no specific indication of what went wrong, but
presume it should be possible to reproduce the problem on a porterbox.
On ppc64el, the log reports an assertion failure at
Could you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
_______________________________________________
Debian-med-packaging mailing list
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
--
http://fam-tille.de
_______________________________________________
Pkg-d-devel mailing list
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-d-devel
Andreas Tille
2017-04-07 14:10:02 UTC
Reply
Permalink
Post by Iain Buclaw
Which compiler?
$ LANG=C apt-cache policy ldc
ldc:
Installed: 1:1.1.1-1
Post by Iain Buclaw
Are NaNs being honoured?
Hmmm, no idea how to check this.
Post by Iain Buclaw
What if you were to replace
the `(x != x && f != f)` comparison with `(isNaN(x) && isNaN(f))` ?
If I apply the following patch

--- a/src/undead/stream.d
+++ b/src/undead/stream.d
@@ -1455,7 +1455,7 @@ class Stream : InputStream, OutputStream

float f;
assert(s.readf(&f));
- assert(x == f || (x != x && f != f)); //either equal or both NaN
+ assert(x == f || (isNaN(x) && isNaN(f))); //either equal or both NaN
}

tryFloatRoundtrip(1.0);


I get

...
[12/25] ldc2 '-***@exe' '-I.' '-I..' '-I../src/' '-enable-color' '-O' '-release' '-g' '-unittest' -of '***@exe/src_undead_stream.d.o' -c ../src/undead/stream.d
FAILED: ***@exe/src_undead_stream.d.o
ldc2 '-***@exe' '-I.' '-I..' '-I../src/' '-enable-color' '-O' '-release' '-g' '-unittest' -of '***@exe/src_undead_stream.d.o' -c ../src/undead/stream.d
../src/undead/stream.d(1458): Error: undefined identifier 'isNaN'
../src/undead/stream.d(1458): Error: undefined identifier 'isNaN'


I have the feelingt that this meand "no" to your second question.

Any other hints?

Kind regards

Andreas.
--
http://fam-tille.de
Iain Buclaw
2017-04-07 16:10:02 UTC
Reply
Permalink
Post by Andreas Tille
Post by Iain Buclaw
Which compiler?
$ LANG=C apt-cache policy ldc
Installed: 1:1.1.1-1
Post by Iain Buclaw
Are NaNs being honoured?
Hmmm, no idea how to check this.
Someone who maintains ldc might know. :-)
Post by Andreas Tille
Post by Iain Buclaw
What if you were to replace
the `(x != x && f != f)` comparison with `(isNaN(x) && isNaN(f))` ?
If I apply the following patch
--- a/src/undead/stream.d
+++ b/src/undead/stream.d
@@ -1455,7 +1455,7 @@ class Stream : InputStream, OutputStream
float f;
assert(s.readf(&f));
- assert(x == f || (x != x && f != f)); //either equal or both NaN
+ assert(x == f || (isNaN(x) && isNaN(f))); //either equal or both NaN
}
tryFloatRoundtrip(1.0);
I get
...
../src/undead/stream.d(1458): Error: undefined identifier 'isNaN'
../src/undead/stream.d(1458): Error: undefined identifier 'isNaN'
I have the feelingt that this meand "no" to your second question.
isNaN is from the std.math module.

http://dlang.org/phobos/std_math.html#.isNaN

You would need to import it. ;-)
Konstantinos Margaritis
2017-04-07 17:10:01 UTC
Reply
Permalink
Στις 07-04-2017, ηΌέρα Παρ, και ώρα 18:03 +0200, ο/η Iain Buclaw
Post by Iain Buclaw
Post by Andreas Tille
Post by Iain Buclaw
Which compiler?
$ LANG=C apt-cache policy ldc
  Installed: 1:1.1.1-1
Post by Iain Buclaw
Are NaNs being honoured?
Hmmm, no idea how to check this.
Someone who maintains ldc might know. :-)
Hi Andreas, long time :)

There are some issues with ldc on arm/ppc64le ports currently and I
would like to build a new ldc package based on a 1.2 beta which is out
now as it seems to fix most of those -no idea if that's also the case
with libundead, but it's possible, some of them are math related.

I hope to do that in the next days, but time is really short these
days, I apologize for the delay :)

Regards

Konstantinos
Andreas Tille
2017-04-09 12:50:01 UTC
Reply
Permalink
reopen 859667
thanks
Post by Iain Buclaw
Post by Andreas Tille
I have the feelingt that this meand "no" to your second question.
isNaN is from the std.math module.
http://dlang.org/phobos/std_math.html#.isNaN
You would need to import it. ;-)
I think this helped so far but now I get:

...
ake[1]: Entering directory '/«PKGBUILDDIR»'
ninja -Cbuild -v test
ninja: Entering directory `build'
[0/1] '/usr/bin/python3' '/usr/share/meson/mesontest' '--no-rebuild' '--print-errorlogs'
1/1 undead_tests FAIL 0.03 s

OK: 0
FAIL: 1
SKIP: 0
TIMEOUT: 0


The output from the failed tests:

1/1 undead_tests FAIL 0.03 s
...

(see [1]) which looks even more strange to me. Any further hints?

Kind regards

Andreas.

[1] https://buildd.debian.org/status/fetch.php?pkg=libundead&arch=armhf&ver=1.0.6-2&stamp=1491647055&raw=0
--
http://fam-tille.de
Iain Buclaw
2017-04-09 15:30:02 UTC
Reply
Permalink
Post by Andreas Tille
reopen 859667
thanks
Post by Iain Buclaw
Post by Andreas Tille
I have the feelingt that this meand "no" to your second question.
isNaN is from the std.math module.
http://dlang.org/phobos/std_math.html#.isNaN
You would need to import it. ;-)
...
ake[1]: Entering directory '/«PKGBUILDDIR»'
ninja -Cbuild -v test
ninja: Entering directory `build'
[0/1] '/usr/bin/python3' '/usr/share/meson/mesontest' '--no-rebuild' '--print-errorlogs'
1/1 undead_tests FAIL 0.03 s
OK: 0
FAIL: 1
SKIP: 0
TIMEOUT: 0
1/1 undead_tests FAIL 0.03 s
...
(see [1]) which looks even more strange to me. Any further hints?
Kind regards
Andreas.
[1] https://buildd.debian.org/status/fetch.php?pkg=libundead&arch=armhf&ver=1.0.6-2&stamp=1491647055&raw=0
--
http://fam-tille.de
There's nothing of any concrete value in the logs as far as I can see.

---

[25/25] ldc2 -of undead_test ...

---

I guess you'll get more information by running the undead_test
yourself, rather than through mesontest. Also check the return code
if that doesn't help either.
Andreas Tille
2017-12-13 10:30:02 UTC
Reply
Permalink
control: tags -1 help

I need to admit I have no idea how to proceed with this issue. :-(

Thanks for any help

Andreas.
--
http://fam-tille.de
Matthias Klumpp
2017-12-14 01:10:02 UTC
Reply
Permalink
Post by Andreas Tille
control: tags -1 help
I need to admit I have no idea how to proceed with this issue. :-(
Please try to package the latest version of undead, or - if that is
not desired - request a rebuild of the package on the failing
architectures.
The library seems to have been compiled with an outdated LDC compiler there.

As for the ppc64el version, it might not make sense to keep that
around. Maybe rebuilding it on that arch will fix the issue though.
How to proceed on the ppc64el arch support front is currently a bit
unclear, because upstream doesn't really test that port:
https://github.com/ldc-developers/ldc/issues/2356#issuecomment-350394691

I have a few ideas on how to address that issue potentially though (by
using different D compilers for different architectures, for example,
or by just removing the ppc64el port).

Cheers,
Matthias
Andreas Tille
2017-12-14 07:40:01 UTC
Reply
Permalink
Post by Matthias Klumpp
Post by Andreas Tille
control: tags -1 help
I need to admit I have no idea how to proceed with this issue. :-(
Please try to package the latest version of undead, or - if that is
not desired - request a rebuild of the package on the failing
architectures.
The library seems to have been compiled with an outdated LDC compiler there.
Its completely desired to follow upstream. I just did not noticed
amongst all the other bugs I'm currently fixing in other packages.

Unfortunately it fails to build. I'd be more than happy if you could
have a look at my latest Git commit. It ends with:


...
[26/27] ldc2 -***@exe -I. -I.. -I../src/ -enable-color -O -release -g -unittest -of '***@exe/src_undead_stream.d.o' -c ../src/undead/stream.d
../src/undead/doformat.d(406): Deprecation: function std.utf.toUTF8 is deprecated - To be removed November 2017. Please use std.utf.encode instead.
../src/undead/doformat.d(406): Deprecation: function std.utf.toUTF8 is deprecated - To be removed November 2017. Please use std.utf.encode instead.
[27/27] ldc2 -of undead_test '***@exe/src_undead_stream.d.o' '***@exe/src_undead_string.d.o' '***@exe/src_undead_dateparse.d.o' '***@exe/src_undead_regexp.d.o' '***@exe/src_undead_doformat.d.o' '***@exe/src_undead_cstream.d.o' '***@exe/src_undead_date.d.o' '***@exe/src_undead_socketstream.d.o' '***@exe/src_undead_datebase.d.o' '***@exe/src_undead_metastrings.d.o' '***@exe/src_undead_bitarray.d.o' '***@exe/src_undead_internal_file.d.o' '***@exe/umain.d.o' -O -release -g -L-z -Lrelro
FAILED: undead_test
ldc2 -of undead_test '***@exe/src_undead_stream.d.o' '***@exe/src_undead_string.d.o' '***@exe/src_undead_dateparse.d.o' '***@exe/src_undead_regexp.d.o' '***@exe/src_undead_doformat.d.o' '***@exe/src_undead_cstream.d.o' '***@exe/src_undead_date.d.o' '***@exe/src_undead_socketstream.d.o' '***@exe/src_undead_datebase.d.o' '***@exe/src_undead_metastrings.d.o' '***@exe/src_undead_bitarray.d.o' '***@exe/src_undead_internal_file.d.o' '***@exe/umain.d.o' -O -release -g -L-z -Lrelro
***@exe/src_undead_stream.d.o: In function `_D6undead6stream6Stream16doFormatCallbackMFwZv':
/build/libundead-1.0.9/obj-x86_64-linux-gnu/../src/undead/stream.d:1217: undefined reference to `_D6undead3utf6toUTF8FNaNbNiNfNkJG4awZAa'
collect2: error: ld returned 1 exit status
Error: /usr/bin/gcc failed with status: 1
ninja: build stopped: subcommand failed.
dh_auto_build: cd obj-x86_64-linux-gnu && ninja -j4 -v returned exit code 1
Post by Matthias Klumpp
As for the ppc64el version, it might not make sense to keep that
around. Maybe rebuilding it on that arch will fix the issue though.
How to proceed on the ppc64el arch support front is currently a bit
https://github.com/ldc-developers/ldc/issues/2356#issuecomment-350394691
I have a few ideas on how to address that issue potentially though (by
using different D compilers for different architectures, for example,
or by just removing the ppc64el port).
In practice most packages of Debian Med are used on amd64. So for
practical usage this is possibly no real constraint.

Kind regards

Andreas.
--
http://fam-tille.de
Matthias Klumpp
2017-12-14 11:00:01 UTC
Reply
Permalink
Post by Andreas Tille
Post by Matthias Klumpp
Post by Andreas Tille
control: tags -1 help
I need to admit I have no idea how to proceed with this issue. :-(
Please try to package the latest version of undead, or - if that is
not desired - request a rebuild of the package on the failing
architectures.
The library seems to have been compiled with an outdated LDC compiler there.
Its completely desired to follow upstream. I just did not noticed
amongst all the other bugs I'm currently fixing in other packages.
Unfortunately it fails to build. I'd be more than happy if you could
...
[...]
/build/libundead-1.0.9/obj-x86_64-linux-gnu/../src/undead/stream.d:1217: undefined reference to `_D6undead3utf6toUTF8FNaNbNiNfNkJG4awZAa'
[...]
Those issues are usually easy to fix, most often it's either some
stuff that is not linked or was compiled with the wrong D version, or
a missing source file. In this case it was the latter, I added it to
the Meson build definition and everything works.
Changes are committed to Git :-)
Post by Andreas Tille
Post by Matthias Klumpp
As for the ppc64el version, it might not make sense to keep that
around. Maybe rebuilding it on that arch will fix the issue though.
How to proceed on the ppc64el arch support front is currently a bit
https://github.com/ldc-developers/ldc/issues/2356#issuecomment-350394691
I have a few ideas on how to address that issue potentially though (by
using different D compilers for different architectures, for example,
or by just removing the ppc64el port).
In practice most packages of Debian Med are used on amd64. So for
practical usage this is possibly no real constraint.
I am currently planning to add a new "dcompiler" metapackage for use
in Debian packaging that will install ldc or gdc depending on the
architecture, so we have one compiler with at least some level of
upstream support on each architecture. That might be a way forward
here.

Cheers,
Matthias
Andreas Tille
2017-12-14 16:30:01 UTC
Reply
Permalink
Hi Matthias,
Post by Matthias Klumpp
Those issues are usually easy to fix, most often it's either some
stuff that is not linked or was compiled with the wrong D version, or
a missing source file. In this case it was the latter, I added it to
the Meson build definition and everything works.
Changes are committed to Git :-)
Thanks for the fix to build the latest upstream version of libundead.

Unfortunately the issue of the bug remains also in this version. :-(
Post by Matthias Klumpp
Post by Andreas Tille
In practice most packages of Debian Med are used on amd64. So for
practical usage this is possibly no real constraint.
I am currently planning to add a new "dcompiler" metapackage for use
in Debian packaging that will install ldc or gdc depending on the
architecture, so we have one compiler with at least some level of
upstream support on each architecture. That might be a way forward
here.
I admit I'm a bit concerned about this kind of tricks. Seems the whole
D infrastructure is quite in flux and only available to a very
restricted set of architectures. Wouldn't it be more on the safe side
to stick only to amd64 and i386 where it seems to be tested and leave
out all other architectures?

Kind regards

Andreas.
--
http://fam-tille.de
Andreas Tille
2018-12-22 22:00:01 UTC
Reply
Permalink
Hi,

the package builds only for amd64 and i386. I wonder if it makes sense
to simply restrict the architectures and close this bug.

Kind regards

Andreas.
--
http://fam-tille.de
Andreas Tille
2019-12-02 12:10:02 UTC
Reply
Permalink
Control: retitle -1 "Will be removed once new version of libbiod is available"

Hi,

libundead was maintained as a predependency for libbiod. The latest version
of libbiod will not need this any more (but needs to be uploaded after
solving some issues).

Kind regards, Andreas.
--
http://fam-tille.de
Loading...