Bug#859667: libundead: FTBFS on armhf and ppc64el: tests fail
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
Bug#859667: libundead: FTBFS on armhf and ppc64el: tests fail
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
Bug#859667: libundead: FTBFS on armhf and ppc64el: tests fail
Hi Matthias, On Thu, Dec 14, 2017 at 11:53:25AM +0100, Matthias Klumpp wrote: > > 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. :-( > > 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
Bug#859667: libundead: FTBFS on armhf and ppc64el: tests fail
2017-12-14 8:29 GMT+01:00 Andreas Tille : > On Thu, Dec 14, 2017 at 02:06:11AM +0100, Matthias Klumpp wrote: >> 2017-12-13 11:19 GMT+01:00 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: > ... > [...] > /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 :-) >> 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). > > 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
Bug#859667: libundead: FTBFS on armhf and ppc64el: tests fail
On Thu, Dec 14, 2017 at 02:06:11AM +0100, Matthias Klumpp wrote: > 2017-12-13 11:19 GMT+01:00 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 -Iundead_test@exe -I. -I.. -I../src/ -enable-color -O -release -g -unittest -of 'undead_test@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 'undead_test@exe/src_undead_stream.d.o' 'undead_test@exe/src_undead_string.d.o' 'undead_test@exe/src_undead_dateparse.d.o' 'undead_test@exe/src_undead_regexp.d.o' 'undead_test@exe/src_undead_doformat.d.o' 'undead_test@exe/src_undead_cstream.d.o' 'undead_test@exe/src_undead_date.d.o' 'undead_test@exe/src_undead_socketstream.d.o' 'undead_test@exe/src_undead_datebase.d.o' 'undead_test@exe/src_undead_metastrings.d.o' 'undead_test@exe/src_undead_bitarray.d.o' 'undead_test@exe/src_undead_internal_file.d.o' 'undead_test@exe/umain.d.o' -O -release -g -L-z -Lrelro FAILED: undead_test ldc2 -of undead_test 'undead_test@exe/src_undead_stream.d.o' 'undead_test@exe/src_undead_string.d.o' 'undead_test@exe/src_undead_dateparse.d.o' 'undead_test@exe/src_undead_regexp.d.o' 'undead_test@exe/src_undead_doformat.d.o' 'undead_test@exe/src_undead_cstream.d.o' 'undead_test@exe/src_undead_date.d.o' 'undead_test@exe/src_undead_socketstream.d.o' 'undead_test@exe/src_undead_datebase.d.o' 'undead_test@exe/src_undead_metastrings.d.o' 'undead_test@exe/src_undead_bitarray.d.o' 'undead_test@exe/src_undead_internal_file.d.o' 'undead_test@exe/umain.d.o' -O -release -g -L-z -Lrelro undead_test@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 > 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). 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
Bug#859667: libundead: FTBFS on armhf and ppc64el: tests fail
2017-12-13 11:19 GMT+01:00 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
Bug#859667: libundead: FTBFS on armhf and ppc64el: tests fail
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
Bug#859667: [Pkg-d-devel] Bug#859667: libundead: FTBFS on armhf and ppc64el: tests fail
On 9 April 2017 at 14:40, Andreas Tille wrote: > reopen 859667 > thanks > > On Fri, Apr 07, 2017 at 06:03:46PM +0200, Iain Buclaw wrote: >> > >> > >> > 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_testsFAIL 0.03 s > > OK: 0 > FAIL: 1 > SKIP: 0 > TIMEOUT:0 > > > The output from the failed tests: > > 1/1 undead_testsFAIL 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.
Bug#859667: [Pkg-d-devel] Bug#859667: libundead: FTBFS on armhf and ppc64el: tests fail
reopen 859667 thanks On Fri, Apr 07, 2017 at 06:03:46PM +0200, Iain Buclaw wrote: > > > > > > 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_testsFAIL 0.03 s OK: 0 FAIL: 1 SKIP: 0 TIMEOUT:0 The output from the failed tests: 1/1 undead_testsFAIL 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
Bug#859667: [Pkg-d-devel] Bug#859667: libundead: FTBFS on armhf and ppc64el: tests fail
Στις 07-04-2017, ημέρα Παρ, και ώρα 18:03 +0200, ο/η Iain Buclaw έγραψε: > On 7 April 2017 at 16:02, Andreas Tille wrote: > > On Wed, Apr 05, 2017 at 10:22:28PM +0200, Iain Buclaw wrote: > > > Which compiler? > > > > $ LANG=C apt-cache policy ldc > > ldc: > > Installed: 1:1.1.1-1 > > > > > 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 signature.asc Description: This is a digitally signed message part
Bug#859667: [Pkg-d-devel] Bug#859667: libundead: FTBFS on armhf and ppc64el: tests fail
On 7 April 2017 at 16:02, Andreas Tille wrote: > On Wed, Apr 05, 2017 at 10:22:28PM +0200, Iain Buclaw wrote: >> Which compiler? > > $ LANG=C apt-cache policy ldc > ldc: > Installed: 1:1.1.1-1 > >> Are NaNs being honoured? > > Hmmm, no idea how to check this. > Someone who maintains ldc might know. :-) >> 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 '-Iundead_test@exe' '-I.' '-I..' '-I../src/' '-enable-color' > '-O' '-release' '-g' '-unittest' -of 'undead_test@exe/src_undead_stream.d.o' > -c ../src/undead/stream.d > FAILED: undead_test@exe/src_undead_stream.d.o > ldc2 '-Iundead_test@exe' '-I.' '-I..' '-I../src/' '-enable-color' '-O' > '-release' '-g' '-unittest' -of 'undead_test@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. > isNaN is from the std.math module. http://dlang.org/phobos/std_math.html#.isNaN You would need to import it. ;-)
Bug#859667: [Pkg-d-devel] Bug#859667: libundead: FTBFS on armhf and ppc64el: tests fail
On Wed, Apr 05, 2017 at 10:22:28PM +0200, Iain Buclaw wrote: > Which compiler? $ LANG=C apt-cache policy ldc ldc: Installed: 1:1.1.1-1 > Are NaNs being honoured? Hmmm, no idea how to check this. > 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 '-Iundead_test@exe' '-I.' '-I..' '-I../src/' '-enable-color' '-O' '-release' '-g' '-unittest' -of 'undead_test@exe/src_undead_stream.d.o' -c ../src/undead/stream.d FAILED: undead_test@exe/src_undead_stream.d.o ldc2 '-Iundead_test@exe' '-I.' '-I..' '-I../src/' '-enable-color' '-O' '-release' '-g' '-unittest' -of 'undead_test@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
Bug#859667: [Pkg-d-devel] Bug#859667: libundead: FTBFS on armhf and ppc64el: tests fail
Which compiler? Are NaNs being honoured? What if you were to replace the `(x != x && f != f)` comparison with `(isNaN(x) && isNaN(f))` ? On 5 April 2017 at 22:00, Andreas Tille wrote: > 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. > > On Wed, Apr 05, 2017 at 02:43:04PM -0400, Aaron M. Ucko wrote: >> 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: >> >> core.exception.AssertError@../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/?a...@monk.mit.edu >> >> ___ >> Debian-med-packaging mailing list >> debian-med-packag...@lists.alioth.debian.org >> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging >> > > -- > http://fam-tille.de > > ___ > Pkg-d-devel mailing list > pkg-d-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-d-devel
Bug#859667: libundead: FTBFS on armhf and ppc64el: tests fail
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. On Wed, Apr 05, 2017 at 02:43:04PM -0400, Aaron M. Ucko wrote: > 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: > > core.exception.AssertError@../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/?a...@monk.mit.edu > > ___ > Debian-med-packaging mailing list > debian-med-packag...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging > -- http://fam-tille.de
Bug#859667: libundead: FTBFS on armhf and ppc64el: tests fail
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: core.exception.AssertError@../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/?a...@monk.mit.edu
