Bug#921527: cuneiform_1.1.0+dfsg-7 - FTBFS on ppc64el

[Thierry fa...@linux.ibm.com]

Package: *cuneiform*
Version: *1.1.0+dfsg-7*
Severity: important
Tags: patch

Compile fails with 
CF_DATADIR=/<>/cuneiform-1.1.0+dfsg/datafiles/ 
debian/tests/ground-truth obj/cuneiform
images/phototest.tif ... FAIL
--- images/phototest.tif.txt2011-04-19 12:49:57.0 +
+++ /tmp/cuneiform.test.KgXcP8dD/phototest.tif.out  2018-01-14 
03:21:46.536688277 +
@@ -1,7 +1,7 @@
-This is a lot of 12 point text to test the 
-ocr code and see if it works on all types 
+This is a lot of 12 poiet text to test the 
+ocr code aed see if it works oe all types 
 of file format. 
-The quick brown dog jumped over the 
+The quick browe dog jumped over the 
 lazy fox. The quick brown dog jumped 
 over the lazy fox. The quick brown dog 
 jumped over the lazy fox. The quick 
debian/rules:58: recipe for target 'obj/test-stamp' failed
make: *** [obj/test-stamp] Error 1
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

/*This sounds a similar problem reported for armel on ubuntu
https://bugs.launchpad.net/ubuntu/+source/cuneiform/+bug/791305
*/

/**/

This bug was fixed in the package cuneiform - 1.1.0+dfsg-6

---
cuneiform (1.1.0+dfsg-6) unstable; urgency=medium

  [ Andreas Beckmann ]
  * QA upload.
  * Incorporate changes from Ubuntu.
  * gcc-6.patch: New, fix more FTBFS issues with GCC 6.
  * typos.patch: New, fix typos.

  [ Bhavani Shankar ]
  * Fix double FTBFS with unsigned char and GCC 6. (LP: #791305
)
(Closes: #787207, #837360)
  * Incorporate patch to fix buffer overflow during crash. Thanks
Sławomir Nizio. Hopefully fix (LP: #978183
), (LP: #593409
), (LP: #791864
),
(LP: #996309 ). (Closes:
#781354)

 -- Andreas Beckmann  Sun, 23 Apr 2017
14:02:07 +0200

Bug#921629: zeroc-ice - FTBFS on ppc64el

[Thierry fa...@linux.ibm.com]

Package: *zeroc-ice*
Version: 3.7.2-2
Severity: normal
Tags: patch

Currently build on ppc64el fails with

src/Ice/Network.cpp:451:17: error: declaration of ‘i’ shadows a
previous local [-Werror=shadow]

    for(int i = 0; i < numaddrs; ++i)

^ src/Ice/Network.cpp:395:13: note: shadowed declaration is here
for(int i = 0; i < 2; i++)


An easy patch could be to replace
    for(int i = 0; i < numaddrs; ++i)
with
    for(i = 0; i < numaddrs; ++i)

Bug#921527: cuneiform_1.1.0+dfsg-7 - FTBFS on ppc64el

[Thierry fa...@linux.ibm.com]

Hi,
Sorry - I am not proposing a patch (may have write a bad bug header).
My point is that test is failing on ppc64el as it was failing sometime
ago on other platform apparently. As such I was expecting you had an
idea why on ppc64el the fixes are not accurate (or not sufficient). -
Going to investigate on what was done on ubuntu side as it was
mentionned to be fixed there.
Thanks


On 07/02/2019 13:44, Andreas Beckmann wrote:
> Control: severity -1 important
> Control: tag -1 moreinfo
>
> We currently have no ppc64el binaries for cuneiform, so this is not a
> regressions and therefore not RC.
>
> On Wed, 6 Feb 2019 14:50:47 +0100 "Thierry fa...@linux.ibm.com"
>  wrote:
>> --- images/phototest.tif.txt 2011-04-19 12:49:57.0 +
>> +++ /tmp/cuneiform.test.KgXcP8dD/phototest.tif.out   2018-01-14 
>> 03:21:46.536688277 +
>> @@ -1,7 +1,7 @@
>> -This is a lot of 12 point text to test the 
>> -ocr code and see if it works on all types 
>> +This is a lot of 12 poiet text to test the 
>> +ocr code aed see if it works oe all types 
>>  of file format. 
> Wouldn't that patch break the test for all platforms where it currently
> passes?
>
> Andreas
>

-- 
Thierry Fauck @ fr.ibm.com

Bug#921724: FTBFS - gcc-m68hc1x doesn't compile on ppc64el

[Thierry fa...@linux.ibm.com]

Package: gcc-m68hc1x
Version: 1:3.3.6+3.1+dfsg-3+b2

Severity: normal

With version 1:3.3.6+3.1+dfsg-3+b2

(sid
) ,
package is not compiled any more

With version 1:3.3.6+3.1+dfsg-3 it failed with



** Configuration powerpc64le-unknown-linux-gnu not supported
Configure in /«BUILDDIR»/gcc-m68hc1x-3.3.6+3.1+dfsg/build/gcc failed, 
exiting.
debian/rules:28: recipe for target 'configure-stamp' failed

Bug#922116: tulip - FTBFS - error: there are no arguments to 'memcpy' that depend on a template parameter

[Thierry fa...@linux.ibm.com]

Package: tulip
Version: *4.8**.0+dfsg-7*10
Severity: important
Tags: patch

Hello,
There is a regression on all platforms for tulip version from
4.8.0dfsg-2+b7  to current (4.8.0dfsg-2+b10 ) The error message is

  *  error: there are no arguments to 'memcpy' that depend on a template
parameter, so a declaration of 'memcpy' must be available [-fpermissive]

A simple patch could be to add #include  which includes
definition of memcpy() in some header files like
   . /thirdparty/OGDF/include/ogdf/basic/DisjointSets.h

Thanks
 

Bug#922238: rkt: FTBFS on ppc64el - missing function body

[Thierry fa...@linux.ibm.com]

Package: *rkt*
Version: 1.30.0+dfsg-7
Severity: normal


Hello,
Currently the ppc64el of rkt on sid fails with following error.
ls 
/<>/rkt-1.30.0+dfsg/_build/src/github.com/rkt/rkt/build-rkt-1.30.0/gopath/src/github.com/rkt/rkt/rkt/*.go
 | \
grep -vE '_test.go|main.go|_gen.go|_stub.go' | \
GO15VENDOREXPERIMENT=1 GOOS="linux" GOARCH="ppc64le" CGO_ENABLED=1 
CC="gcc" CXX="g++" GOPATH="/<>/rkt-1.30.0+dfsg/_build/src2" 
GOARCH=ppc64le CC= xargs "go" run 
/<>/rkt-1.30.0+dfsg/_build/src/github.com/rkt/rkt/build-rkt-1.30.0/gopath/src/github.com/rkt/rkt/rkt/manpages_gen.go
# github.com/remyoudompheng/bigfft
../../../../src2/src/github.com/remyoudompheng/bigfft/arith_decl.go:10:6: 
missing function body
../../../../src2/src/github.com/remyoudompheng/bigfft/arith_decl.go:11:6: 
missing function body
../../../../src2/src/github.com/remyoudompheng/bigfft/arith_decl.go:12:6: 
missing function body
../../../../src2/src/github.com/remyoudompheng/bigfft/arith_decl.go:13:6: 
missing function body
../../../../src2/src/github.com/remyoudompheng/bigfft/arith_decl.go:14:6: 
missing function body
../../../../src2/src/github.com/remyoudompheng/bigfft/arith_decl.go:15:6: 
missing function body
../../../../src2/src/github.com/remyoudompheng/bigfft/arith_decl.go:16:6: 
missing function body
../../../../src2/src/github.com/remyoudompheng/bigfft/arith_decl.go:17:6: 
missing function body
../../../../src2/src/github.com/remyoudompheng/bigfft/arith_decl.go:18:6: 
missing function body
../../../../src2/src/github.com/remyoudompheng/bigfft/arith_decl.go:19:6: 
missing function body
../../../../src2/src/github.com/remyoudompheng/bigfft/arith_decl.go:19:6: too 
many errors
make[2]: *** [rkt/rkt.mk:38: manpages] Error 123
make[2]: Leaving directory 
'/<>/rkt-1.30.0+dfsg/_build/src/github.com/rkt/rkt'
make[1]: *** [debian/rules:50: override_dh_auto_build] Error 2

As this sounds a common error with go environment, may be you get an idea to 
fix that easily.
Thanks

Bug#922317: FTBFS - rspamd on ppc64el fails with many errors

[Thierry fa...@linux.ibm.com]

Package: rspamd
Version: 1.8.1-2
Severity: important

Hello,

Current build of rspamd on ppc64el fails with messages

Run Build Command:"/usr/bin/make" "cmTC_35eec/fast"
make[2]: Entering directory 
'/<>/obj-powerpc64le-linux-gnu/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTC_35eec.dir/build.make 
CMakeFiles/cmTC_35eec.dir/build
make[3]: Entering directory 
'/<>/obj-powerpc64le-linux-gnu/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_35eec.dir/src.c.o
/usr/bin/cc -DPCRE2_CODE_UNIT_WIDTH=8  -g -O2 -fstrict-aliasing -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -pthread 
-fPIC  -W -Wall -Wpointer-arith -Wno-unused-parameter -Wno-unused-function 
-Wunused-variable -Wno-pointer-sign -Wstrict-prototypes -Wnull-dereference 
-Wduplicated-cond -Wno-unused-const-variable -Wno-sign-compare -std=c11 
-Wno-implicit-fallthrough -DHAVE_ATOMIC_BUILTINS   -o 
CMakeFiles/cmTC_35eec.dir/src.c.o   -c 
/<>/obj-powerpc64le-linux-gnu/CMakeFiles/CMakeTmp/src.c
Linking C executable cmTC_35eec
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_35eec.dir/link.txt 
--verbose=1
/usr/bin/cc -g -O2 -fstrict-aliasing -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -pthread 
-fPIC  -W -Wall -Wpointer-arith -Wno-unused-parameter -Wno-unused-function 
-Wunused-variable -Wno-pointer-sign -Wstrict-prototypes -Wnull-dereference 
-Wduplicated-cond -Wno-unused-const-variable -Wno-sign-compare -std=c11 
-Wno-implicit-fallthrough -DHAVE_ATOMIC_BUILTINS  -Wl,-z,relro -Wl,-z,now 
-Wl,--as-needed  -rdynamic CMakeFiles/cmTC_35eec.dir/src.c.o  -o cmTC_35eec -lm 
-lrt -ldl -lresolv -lnsl -levent 
make[3]: Leaving directory 
'/<>/obj-powerpc64le-linux-gnu/CMakeFiles/CMakeTmp'
make[2]: Leaving directory 
'/<>/obj-powerpc64le-linux-gnu/CMakeFiles/CMakeTmp'

...and run output:

Return value: 1
Source file was:

#include 
int main(int argc, char **argv) {
int a = 0, b = 0;
if (__atomic_compare_exchange_n(&a, &b, 1, false, __ATOMIC_RELEASE, 
__ATOMIC_RELAXED)) {
return 0;
}
return -1;
}

cd obj-powerpc64le-linux-gnu && tail -v -n \+0 CMakeFiles/CMakeError.log
==> CMakeFiles/CMakeError.log <==
Determining if files sys/endian.h exist failed with the following output:
Change Dir: /<>/obj-powerpc64le-linux-gnu/CMakeFiles/CMakeTmp

We can note errors are while searching for sys/endian.h,
machine/endian.h and siginfo.h
However we can find these files in

/usr/include/powerpc64le-linux-gnu/bits/endian.h
/usr/include/endian.h
/usr/include/powerpc64le-linux-gnu/asm/siginfo.h
/usr/include/asm-generic/siginfo.h

so may be path for ppc64le arch should be reviewed.

libaio.h is  part of package libaio-dev as /usr/include/libaio.h.

Bug#922394: cadvisor - FTBFS - missing package golang.org/x/exp/inotify

[Thierry fa...@linux.ibm.com]

Package: cadvisor
Version: 0.27.1+dfsg2-4+b10
Severity: important

Hello,

With this version all arch compilation fails with the error:

make[1]: Leaving directory '/<>/cadvisor-0.27.1+dfsg2'
   dh_auto_build -a -O--buildsystem=golang -O--builddirectory=_build
cd _build && go install 
-gcflags=all=\"-trimpath=/<>/cadvisor-0.27.1\+dfsg2/_build/src\" 
-asmflags=all=\"-trimpath=/<>/cadvisor-0.27.1\+dfsg2/_build/src\" -v 
-p 4 github.com/google/cadvisor github.com/google/cadvisor/api 
github.com/google/cadvisor/cache github.com/google/cadvisor/cache/memory 
github.com/google/cadvisor/client 
github.com/google/cadvisor/client/clientexample 
github.com/google/cadvisor/client/v2 github.com/google/cadvisor/collector 
github.com/google/cadvisor/container 
github.com/google/cadvisor/container/common 
github.com/google/cadvisor/container/crio 
github.com/google/cadvisor/container/docker 
github.com/google/cadvisor/container/libcontainer 
github.com/google/cadvisor/container/raw 
github.com/google/cadvisor/container/rkt 
github.com/google/cadvisor/container/systemd 
github.com/google/cadvisor/container/testing 
github.com/google/cadvisor/devicemapper 
github.com/google/cadvisor/devicemapper/fake github.com/google/cadvisor/events 
github.com/google/cadvisor/fs github.com/google/cadvisor/healthz 
github.com/google/cadvisor/http github.com/google/cadvisor/http/mux 
github.com/google/cadvisor/info/v1 github.com/google/cadvisor/info/v1/test 
github.com/google/cadvisor/info/v2 
github.com/google/cadvisor/integration/framework 
github.com/google/cadvisor/integration/runner 
github.com/google/cadvisor/integration/tests/api 
github.com/google/cadvisor/integration/tests/healthz 
github.com/google/cadvisor/machine github.com/google/cadvisor/manager 
github.com/google/cadvisor/manager/watcher 
github.com/google/cadvisor/manager/watcher/raw 
github.com/google/cadvisor/manager/watcher/rkt 
github.com/google/cadvisor/metrics github.com/google/cadvisor/pages 
github.com/google/cadvisor/pages/static github.com/google/cadvisor/storage 
github.com/google/cadvisor/storage/bigquery 
github.com/google/cadvisor/storage/bigquery/client 
github.com/google/cadvisor/storage/bigquery/client/example 
github.com/google/cadvisor/storage/elasticsearch 
github.com/google/cadvisor/storage/influxdb 
github.com/google/cadvisor/storage/kafka 
github.com/google/cadvisor/storage/redis 
github.com/google/cadvisor/storage/statsd 
github.com/google/cadvisor/storage/statsd/client 
github.com/google/cadvisor/storage/stdout 
github.com/google/cadvisor/storage/test github.com/google/cadvisor/summary 
github.com/google/cadvisor/utils github.com/google/cadvisor/utils/cloudinfo 
github.com/google/cadvisor/utils/container 
github.com/google/cadvisor/utils/cpuload 
github.com/google/cadvisor/utils/cpuload/netlink 
github.com/google/cadvisor/utils/cpuload/netlink/example 
github.com/google/cadvisor/utils/docker 
github.com/google/cadvisor/utils/oomparser 
github.com/google/cadvisor/utils/oomparser/oomexample 
github.com/google/cadvisor/utils/procfs github.com/google/cadvisor/utils/sysfs 
github.com/google/cadvisor/utils/sysfs/fakesysfs 
github.com/google/cadvisor/utils/sysinfo github.com/google/cadvisor/utils/tail 
github.com/google/cadvisor/validate github.com/google/cadvisor/version 
github.com/google/cadvisor/zfs
src/github.com/google/cadvisor/container/common/inotify_watcher.go:20:2: cannot 
find package "golang.org/x/exp/inotify" in any of:

/<>/cadvisor-0.27.1+dfsg2/_build/src/github.com/google/cadvisor/vendor/golang.org/x/exp/inotify
 (vendor tree)
/usr/lib/go-1.11/src/golang.org/x/exp/inotify (from $GOROOT)
/<>/cadvisor-0.27.1+dfsg2/_build/src/golang.org/x/exp/inotify 
(from $GOPATH)
dh_auto_build: cd _build && go install 
-gcflags=all=\"-trimpath=/<>/cadvisor-0.27.1\+dfsg2/_build/src\" 
-asmflags=all=\"-trimpath=/<>/cadvisor-0.27.1\+dfsg2/_build/src\" -v 
-p 4 github.com/google/cadvisor github.com/google/cadvisor/api 
github.com/google/cadvisor/cache github.com/google/cadvisor/cache/memory 
github.com/google/cadvisor/client 
github.com/google/cadvisor/client/clientexample 
github.com/google/cadvisor/client/v2 github.com/google/cadvisor/collector 
github.com/google/cadvisor/container 
github.com/google/cadvisor/container/common 
github.com/google/cadvisor/container/crio 
github.com/google/cadvisor/container/docker 
github.com/google/cadvisor/container/libcontainer 
github.com/google/cadvisor/container/raw 
github.com/google/cadvisor/container/rkt 
github.com/google/cadvisor/container/systemd 
github.com/google/cadvisor/container/testing 
github.com/google/cadvisor/devicemapper 
github.com/google/cadvisor/devicemapper/fake github.com/google/cadvisor/events 
github.com/google/cadvisor/fs github.com/google/cadvisor/healthz 
github.com/google/cadvisor/http github.com/google/cadvisor/http/mux 
github.com/google/cadvisor/info/v1 github.com/google/cadvisor/info/v1/test 
github.com/google/cadvisor/info/v2 
github.com/google/cadvisor/inte

Bug#922399: isospec : FTBS - -march=native parameter invalid

[Thierry fa...@linux.ibm.com]

Package: isospec
Version: 1.9.1-2
Severity: important
Tag: patch


Hello,

Current build fails on couple of platforms because 

make[2]: Entering directory '/<>/IsoSpec++'
g++ -std=c++11 -O0 -g -Wall -pedantic -Wextra -O3 -march=native -mtune=native 
unity-build.cpp -fPIC -shared -o libIsoSpec++.so.1.9.1 
-Wl,-soname,libIsoSpec++.so.1
g++: error: unrecognized command line option ‘-march=native’

Parameter  -march=native is invalid for some arch and can be replaced with 
-mcpu=native on some other like ppc64el
 

Bug#853443: hidrd: ftbfs with GCC-7

[Thierry fa...@linux.ibm.com]

On Mon, 4 Dec 2017 12:50:24 +0200 Juhani Numminen
 wrote:
> Control: tags -1 patch fixed-upstream
> 
> On Mon, 4 Dec 2017 10:23:34 +0200 Juhani Numminen 
>  wrote:
> > Upstream has committed some GCC-7-related fixes.
> > https://github.com/DIGImend/hidrd/commit/7e94881
> > https://github.com/DIGImend/hidrd/commit/e126127
> 
> I had a successful amd64 build with the two attached patches.
> 
> Cheers,
> Juhani

The problem still remains on ppc64el with gcc version 8.2.0

Bug#922405: pocl : FTBFS on sid - testsuite has failed on ppc64el arch

[Thierry fa...@linux.ibm.com]

Package: pocl
Version: 1.2-5
Severity: important

Hello,

Most of the tests fail on ppc64el arch

The following tests FAILED:
      3 - kernel/test_convert_type_1 (Failed)
      4 - kernel/test_convert_type_2 (Failed)
      5 - kernel/test_convert_type_4 (Failed)
      6 - kernel/test_convert_type_8 (Failed)
      7 - kernel/test_convert_type_16 (Failed)
      8 - kernel/test_bitselect (Failed)
      9 - kernel/test_hadd_loopvec (Failed)
     10 - kernel/test_hadd_loops (Failed)
     16 - kernel/test_rotate (Failed)
     17 - kernel/test_fabs (Failed)
     18 - kernel/test_copy_signbit (Failed)
     19 - kernel/test_ilogb (Failed)
     20 - kernel/test_ldexp (Failed)
     21 - kernel/test_isnan (Failed)
     25 - kernel/test_image_query_funcs (Failed)
     26 - kernel/test_shuffle_char (Failed)
     27 - kernel/test_shuffle_short (Failed)
     28 - kernel/test_shuffle_ushort (Failed)
     29 - kernel/test_shuffle_int (Failed)
     30 - kernel/test_shuffle_uint (Failed)
     31 - kernel/test_shuffle_float (Failed)
     32 - kernel/test_shuffle_long (Failed)
     33 - kernel/test_shuffle_ulong (Failed)
     34 - kernel/test_printf (Failed)
     36 - kernel/test_shuffle_double (Failed)
     74 - regression/struct_kernel_arguments (Failed)
     75 - regression/vector_kernel_arguments (Failed)
     92 - runtime/clCreateSubDevices (Failed)
    122 - examples/trig (Failed)
    124 - EinsteinToolkit_SubDev (Child aborted)
Errors while running CTest

with for example: 2/124 Test  #26: kernel/test_shuffle_char
***Failed 
Error regular expression found in output. Regex=[FAIL]  4.83 sec

  * CMake Error at /<>/cmake/run_test.cmake:34 (message):

  *   FAIL: Test exited with nonzero code (7):

  *  
/<>/obj-powerpc64le-linux-gnu/tests/kernel/test_shuffle;char

  *   STDOUT:

  *   Error in shuffle char 16 => char 2 :[0, 0] = shuffle( [0, 1, 2, 3,
4, 5, 6,  7, 8, 9, 10, 11, 12, 13, 14, 15], [4, 2]); element 0
should be 4 (mask 4), got 0

Bug#922619: mame: FTBFS of version 0.206+dfsg.1-1 on arch ppc64el

[Thierry fa...@linux.ibm.com]

Package: mame
Version: 0.206+dfsg.1-1
Severity: important

Hello,

Since version 0.194 (and even earlier) ppc64el compil fails with messages:


In file included from ../../../../../src/emu/emu.h:31:
../../../../../src/mame/drivers/flyball.cpp:27:39:   in 'constexpr' expansion 
of 'operator""_MHz_XTAL(1.2095e+1l)'
../../../../../src/emu/xtal.h:85:83: error: 
'(1.2095e+1l * 1.0e+6l)' is not a constant 
expression
 constexpr XTAL operator ""_MHz_XTAL(long double clock) { return 
XTAL(double(clock * 1e6)); }
 
~~^

According to https://github.com/mamedev/mame/issues/3157 it could be related to 
gcc handling long double on ppc64el.

Is there anything plan for that ?

Thanks*
*

Bug#922620: minimap2: FTBFS on pppc64el - unknown line option '-msse2';

[Thierry fa...@linux.ibm.com]

Package: minimap2
Version: 2.15+dfsg-1
Severity: important

Hello,

Compilation on ppc64el arch fails with message

cc -c -g -O2 -fdebug-prefix-map=/<>/minimap2-2.15+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -g -Wall -O2 
-Wc++-compat  -msse2 -Wdate-time -D_FORTIFY_SOURCE=2 -DHAVE_KALLOC  
ksw2_ll_sse.c -o ksw2_ll_sse.o
cc: error: unrecognized command line option '-msse2'; did you mean '-misel'?
make[2]: *** [Makefile:51: ksw2_ll_sse.o] Error 1
make[2]: *** Waiting for unfinished jobs

Are we passing the proper flag for ppc64el arch ?
Thanks

Bug#870051: qile FTBFS: test_thermalsensor_regex_compatibility failure

[Thierry fa...@linux.ibm.com]

Hello,
Just wondering why this test seem to have passed in 0.10.6-3 (sid) and
not any more ?
As this test is failing on most arch, shouldn't we disable it ?
Thanks


On Sat, 29 Jul 2017 12:43:02 +0300 Adrian Bunk  wrote:
> Source: qtile
> Version: 0.10.7-2
> Severity: serious
> 
> https://buildd.debian.org/status/package.php?p=qtile&suite=sid
> 
> ...
> === FAILURES 
> ===
>  test_thermalsensor_regex_compatibility 
> 
> 
> def test_thermalsensor_regex_compatibility():
> >   sensors = ThermalSensor()
> 
> test/test_widget.py:62: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> libqtile/widget/sensors.py:73: in __init__
> temp_values = self.get_temp_sensors()
> libqtile/utils.py:202: in wrapper
> return_value = func(*args, **kwargs)
> libqtile/widget/sensors.py:93: in get_temp_sensors
> sensors_out = self.call_process(command)
> libqtile/widget/base.py:262: in call_process
> output = subprocess.check_output(command, **kwargs)
> /usr/lib/python3.6/subprocess.py:336: in check_output
> **kwargs).stdout
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> 
> input = None, timeout = None, check = True, popenargs = (['sensors'],)
> kwargs = {'stdout': -1}, process = 
> stdout = b'', stderr = None, retcode = 1
> 
> def run(*popenargs, input=None, timeout=None, check=False, **kwargs):
> """Run command with arguments and return a CompletedProcess instance.
> 
> The returned instance will have attributes args, returncode, stdout 
> and
> stderr. By default, stdout and stderr are not captured, and those 
> attributes
> will be None. Pass stdout=PIPE and/or stderr=PIPE in order to capture 
> them.
> 
> If check is True and the exit code was non-zero, it raises a
> CalledProcessError. The CalledProcessError object will have the 
> return code
> in the returncode attribute, and output & stderr attributes if those 
> streams
> were captured.
> 
> If timeout is given, and the process takes too long, a TimeoutExpired
> exception will be raised.
> 
> There is an optional argument "input", allowing you to
> pass a string to the subprocess's stdin.  If you use this argument
> you may not also use the Popen constructor's "stdin" argument, as
> it will be used internally.
> 
> The other arguments are the same as for the Popen constructor.
> 
> If universal_newlines=True is passed, the "input" argument must be a
> string and stdout/stderr in the returned object will be strings 
> rather than
> bytes.
> """
> if input is not None:
> if 'stdin' in kwargs:
> raise ValueError('stdin and input arguments may not both be 
> used.')

-- 
Thierry Fauck @ fr.ibm.com

Bug#922685: octave-tisean FTBFS on ppc64el : mutual.cc test failure

[Thierry fa...@linux.ibm.com]

Source: octave-tisean
Version: 0.2.3-3
Severity: important

https://buildd.debian.org/status/fetch.php?pkg=octave-tisean&arch=ppc64el&ver=0.2.3-3&stamp=1518318632&raw=0

[mutual.cc]
> /<>/src/mutual.cc
* fail("mutual((1:10),0)");
* fail("mutual((1:10),-4,5)");
* fail("mutual([(1:10);(1:10)])");
* fail("[a,b,c,d] = mutual ((1:10),1)");
* test
 "'res' was created using 'mutual hen.dat' where from the TISEAN package.";
 "'hen.dat' was created using 'henon(1)' from Tisean package in GNU Octave";
 res = [0, 2.684467e+00; 1, 1.362672e+00; 2, 1.054827e+00; 3, 8.300913e-01; 4, 
6.421677e-01; 5, 4.650269e-01; 6, 3.409740e-01; 7, 2.485991e-01; 8, 
1.621105e-01; 9, 1.144275e-01; 10, 9.430688e-02; 11, 6.796321e-02; 12, 
6.181312e-02; 13, 4.369772e-02; 14, 3.566099e-02; 15, 2.923612e-02; 16, 
2.354500e-02; 17, 1.924072e-02; 18, 1.999171e-02; 19, 1.887493e-02; 20, 
1.464115e-02];
 hen = henon(1);
 [a,b] = mutual (hen(:,1),-20);
 assert ([a,b], res, 1e-6);
! test failed
ASSERT errors for:  assert ([a, b],res,1e-6)

  Location  |  Observed  |  Expected  |  Reason
   (1,2)2.6915   2.6845  Abs err 0.0070095 exceeds tol 1e-06
   (2,2)1.3732   1.3627  Abs err 0.010478 exceeds tol 1e-06
   (3,2)1.0632   1.0548  Abs err 0.0083938 exceeds tol 1e-06
   (4,2)   0.84095  0.83009  Abs err 0.010859 exceeds tol 1e-06
   (5,2)   0.65111  0.64217  Abs err 0.0089386 exceeds tol 1e-06
   (6,2)   0.46682  0.46503  Abs err 0.0017946 exceeds tol 1e-06
   (7,2)   0.35155  0.34097  Abs err 0.010574 exceeds tol 1e-06
   (8,2)   0.25029   0.2486  Abs err 0.0016901 exceeds tol 1e-06
   (9,2)   0.15664  0.16211  Abs err 0.0054678 exceeds tol 1e-06
   (10,2)  0.10487  0.11443  Abs err 0.0095561 exceeds tol 1e-06
   (11,2)  0.08929  0.094307 Abs err 0.0050169 exceeds tol 1e-06
   (12,2)  0.066566 0.067963 Abs err 0.0013968 exceeds tol 1e-06
   (13,2)  0.062383 0.061813 Abs err 0.00056971 exceeds tol 1e-06
   (14,2)  0.045172 0.043698 Abs err 0.0014744 exceeds tol 1e-06
   (15,2)  0.039426 0.035661 Abs err 0.0037654 exceeds tol 1e-06
   (16,2)  0.031089 0.029236 Abs err 0.0018526 exceeds tol 1e-06
   (17,2)  0.024704 0.023545 Abs err 0.0011587 exceeds tol 1e-06
   (18,2)  0.022487 0.019241 Abs err 0.0032467 exceeds tol 1e-06
   (19,2)  0.01685  0.019992 Abs err 0.0031421 exceeds tol 1e-06
   (20,2)  0.021296 0.018875 Abs err 0.0024215 exceeds tol 1e-06
   (21,2)  0.018981 0.014641 Abs err 0.0043399 exceeds tol 1e-06
5 tests, 4 passed, 0 known failure, 0 skipped
Summary: 162 tests, 125 passed, 0 known failures, 0 skipped
debian/rules:5: recipe for target 'binary-arch' failed
make: *** [binary-arch] Error 1

Bug#922692: galax: FTBFS on ppc64el - ERROR: unable to find camomileLibrary.cmi in /usr/lib/ocaml/camomile

[Thierry fa...@linux.ibm.com]

Package: galax
Version: 1.1-15
Severity: important

Compilation on ppc64el fails with the message

ERROR: unable to find camomileLibrary.cmi in /usr/lib/ocaml/camomile

However package libcamomile-ocaml-dev contains
/usr/lib/ocaml/camomile/*library*/camomileLibrary.cmi on buster.

and this package is part of the dependencies :

The following NEW packages will be installed:
  camlp4 dh-ocaml fontconfig-config fonts-dejavu-core fonts-lmodern
  ghostscript hevea libavahi-client3 libavahi-common-data
libavahi-common3
  libbrotli1 libcairo2 libcamlp4-ocaml-dev libcamomile-ocaml-data
  *libcamomile-ocaml-dev *

So the issue on ppc64el seems that configure search for files in
/usr/lib/ocaml/camomile instead of /usr/lib/ocaml/camomile/library

is there a way to change that for ppc64el arch ?

Thanks

Bug#922696: alljoyn-services-1604: FTBFS on sid - build_core/SConscript doesn't allow some linux arch

[Thierry fa...@linux.ibm.com]

Package: alljoyn-services-1604
Version: 16.04-5
Severity: important
Tags: sid buster

Most of the compilation fail with an error similar to

mkdir -p /<>/build/linux/powerpc64le/release/dist
(cd sample_apps; \
scons BINDINGS=cpp CPU=powerpc64le OS=linux VARIANT=release V=1 
GTEST_DIR=/usr/src/gtest \
WS=off BT=off ICE=off \
)
scons: Reading SConscript files ...

scons: *** Invalid value for option CPU: powerpc64le.  Valid values are: 
('x86', 'x86_64', 'arm', 'openwrt')
File "/<>/build_core/SConscript", line 130, in 
make[1]: *** [debian/rules:32: override_dh_auto_build] Error 2


The config file build_core/SConscript doesn't allow some linux arch like 
ppc64el, arm64 

Bug#922698: kcov: FTBFS on sid : error: 'SIGUNUSED' was not declared in this scope

[Thierry fa...@linux.ibm.com]

Package: kcov
Version: 25+dfsg-1
Severity: serious
Tags: sid buster


Compilation usually fails with messages 
cd /<>/kcov-25+dfsg/obj-i686-linux-gnu/src && /usr/bin/c++   
-I/<>/kcov-25+dfsg/src/include -I/usr/include/i386-linux-gnu  
-std=c++0x -g -Wall -D_GLIBCXX_USE_NANOSLEEP -DKCOV_LIBRARY_PREFIX=/tmp   -o 
CMakeFiles/kcov.dir/engines/ptrace.cc.o -c 
/<>/kcov-25+dfsg/src/engines/ptrace.cc
/<>/kcov-25+dfsg/src/engines/ptrace.cc: In member function 'const 
kcov::IEngine::Event Ptrace::waitEvent()':
/<>/kcov-25+dfsg/src/engines/ptrace.cc:337:17: error: 'SIGUNUSED' was 
not declared in this scope
int sigill = SIGUNUSED;
 ^
/<>/kcov-25+dfsg/src/engines/ptrace.cc:337:17: note: suggested 
alternative: 'SI_USER'
int sigill = SIGUNUSED;
 ^
 SI_USER
src/CMakeFiles/kcov.dir/build.make:186: recipe for target 
'src/CMakeFiles/kcov.dir/engines/ptrace.cc.o' failed
make[3]: *** [src/CMakeFiles/kcov.dir/engines/ptrace.cc.o] Error 1
make[3]: Leaving directory '/<>/kcov-25+dfsg/obj-i686-linux-gnu'
CMakeFiles/Makefile2:90: recipe for target 'src/CMakeFiles/kcov.dir/all' failed

Bug#917644: FTBFS: segmentation faults in test suite

[Thierry fa...@linux.ibm.com]

On Mon, 7 Jan 2019 16:49:41 + Steve McIntyre  wrote:
> Hi Matthew,
> 
> On Sun, Dec 30, 2018 at 05:38:57PM -0500, Matthew Fluet wrote:
> >If it is just the `world` regression tests that are failing, then it
> >is almost certainly due to save/restore world being incompatible with
> >ASLR; see http://mlton.org/MLtonWorld#_notes.  Perhaps Debian
> >arm64-linux has gained ASLR since the last time the regression suite
> >was run on this platform?  In any case, you'll notice that the `world`
> >regression tests are explicitly whitelisted (i.e., these tests failing
> >do not cause a failure exit status from the regression script) because
> >of this issue.
> 
As this bug is not specifically opened for one arch, I also want to
mention it fails on ppc64el. I see the sequence
testing wordn-array
testing world1
2c2,3
< I am the clone
---
> unhandled exception: Fail: child failed
> Nonzero exit status.
world1: difference with -type-check true
testing world2
1c1,2
< 30
---
> unhandled exception: Fail: child failed
> Nonzero exit status.
world2: difference with -type-check true
testing world3
1c1,2
< caught foo
---
> unhandled exception: Fail: child failed
> Nonzero exit status.
world3: difference with -type-check true
testing world4
4,6c4,5
< between saves
< after saves
< after saves
---
> unhandled exception: Fail: child failed
> Nonzero exit status.
world4: difference with -type-check true
testing world5
2c2,3
< success
---
> unhandled exception: Fail: child failed
> Nonzero exit status.
world5: difference with -type-check true
testing world6
1,4c1
< ./world6
< a
< b
< c
---
> Segmentation fault
world6: difference with -type-check true
testing DLXSimulator
testing barnes-hut
testing boyer

but then it fails with message:
testing mlprof
make[1]: *** [Makefile:391: check] Error 1
make[1]: Leaving directory '/<>'
make: *** [/usr/share/cdbs/1/class/makefile.mk:113:
debian/stamp-makefile-check] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned
exit status 2

when of course we properly have the messages
make -C . check
make[1]: Entering directory '/<>'
./bin/regression
whitelisting real...
whitelisting world1...
whitelisting world2...
whitelisting world3...
whitelisting world4...
whitelisting world5...
whitelisting world6...
MLton 20180207
flags = -type-check true

Thanks

Bug#922767: libemf : FTBFS - mv: cannot stat 'refman.pdf': No such file or directory -

[Thierry fa...@linux.ibm.com]

Package: libemf
Version: 1.0.11-2
Severity: important
Tags: sid buster

Current compilation fails with message

/This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live
2019/dev/Debian) (preloaded format=pdflatex) restricted \write18
enabled. entering extended mode (./refman.tex LaTeX2e <2018-12-01> mv:
cannot stat 'refman.pdf': No such file or directory make[2]: ***
[Makefile:870: doxygen-doc/libemf.pdf] Error 1 make[2]: Leaving
directory '/<>' dh_auto_build: make -j4 all doxygen-doc
doxygen-pdf returned exit code 2 make[1]: *** [debian/rules:13:
override_dh_auto_build] Error 2/

The command pdflatext refman.tex fails according to refman.log
! Misplaced \cr.
 \cr 

l.46 \end{DoxyParams}
 
I can't figure out why you would want to use a tab mark
or \cr or \span just now. If something like a right brace
up above has ended a previous alignment prematurely,
you're probably due for more error messages, and you
might try typing `S' now just to see what is salvageable.

! Missing \cr inserted.
 
\cr 
l.46 \end{DoxyParams}
 
*(That makes 100 errors; please try again.) *
Here is how much of TeX's memory you used:
 14925 strings out of 494561
 215545 string characters out of 6177454
 324426 words of memory out of 500
 18282 multiletter control sequences out of 15000+60
 43322 words of font info for 66 fonts, out of 800 for 9000
 14 hyphenation exceptions out of 8191
 53i,11n,92p,307b,565s stack positions out of 5000i,500n,1p,20b,8s

!  ==> Fatal error occurred, no output PDF file produced!

Bug#917644: FTBFS: segmentation faults in test suite

[Thierry fa...@linux.ibm.com]

On Tue, 19 Feb 2019 16:50:00 +0100 "Thierry fa...@linux.ibm.com"
 wrote:
> On Mon, 7 Jan 2019 16:49:41 + Steve McIntyre  wrote:
> > Hi Matthew,
> > 
> > On Sun, Dec 30, 2018 at 05:38:57PM -0500, Matthew Fluet wrote:
> > >If it is just the `world` regression tests that are failing, then it
> > >is almost certainly due to save/restore world being incompatible with
> > >ASLR; see http://mlton.org/MLtonWorld#_notes.  Perhaps Debian
> > >arm64-linux has gained ASLR since the last time the regression suite
> > >was run on this platform?  In any case, you'll notice that the `world`
> > >regression tests are explicitly whitelisted (i.e., these tests failing
> > >do not cause a failure exit status from the regression script) because
> > >of this issue.
> > 
> As this bug is not specifically opened for one arch, I also want to
> mention it fails on ppc64el. I see the sequence
> testing wordn-array
> testing world1
> 2c2,3
> < I am the clone
> ---
> > unhandled exception: Fail: child failed
> > Nonzero exit status.
> world1: difference with -type-check true
> testing world2
> 1c1,2
> < 30
> ---
> > unhandled exception: Fail: child failed
> > Nonzero exit status.
> world2: difference with -type-check true
> testing world3
> 1c1,2
> < caught foo
> ---
> > unhandled exception: Fail: child failed
> > Nonzero exit status.
> world3: difference with -type-check true
> testing world4
> 4,6c4,5
> < between saves
> < after saves
> < after saves
> ---
> > unhandled exception: Fail: child failed
> > Nonzero exit status.
> world4: difference with -type-check true
> testing world5
> 2c2,3
> < success
> ---
> > unhandled exception: Fail: child failed
> > Nonzero exit status.
> world5: difference with -type-check true
> testing world6
> 1,4c1
> < ./world6
> < a
> < b
> < c
> ---

This pad is hosted in Toulouse LTC lab. Created at 2019-02-19 09:45:56.

Hi,
I have run make check without world tests and result is code 1 because
of failing tests on some architectures
testing mlton.overload
testing mlton.share
1c1
< size of a is 1600
---
> size of a is 2408
102c102
< size of a is 484
---
> size of a is 920

testing size2
2,23c2,23
< The size of an int list of length 4 is = 48 bytes.
< The size of a string of length 10 is = 24 bytes.
< The size of an int array of length 10 is = 52 bytes.
< The size of a double array of length 10 is = 92 bytes.
< The size of a (word32 * double) array of length 10 is = 132 bytes.
< The size of a (word32 * word32 * double) array of length 10 is = 172
bytes.
< The size of a (word64 * double) array of length 10 is = 172 bytes.
< The size of a (word16 * double) array of length 10 is = 132 bytes.
< The size of a word64 array of length 10 is = 92 bytes.
< The size of a (word32 * word64) array of length 10 is = 132 bytes.
< The size of a (word32 * word32 * word64) array of length 10 is = 172
bytes.
< The size of a (word64 * word64) array of length 10 is = 172 bytes.
< The size of a (word16 * word64) array of length 10 is = 132 bytes.
< The size of an array of length 10 of 2-ples of ints is = 92 bytes.
< The size of an array of length 10 of 2-ples of (shared) ints is = 92
bytes.
< The size of an array of length 10 of arrays of length 20 of ints is =
972 bytes.
< The size of an array of length 10 of (shared) arrays of length 20 of
ints is = 144 bytes.
< The size of an array of length 10 of tuples of word16 * (arrays of
length 20 of ints) is = 1012 bytes.
< The size of an array of length 10 of tuples of word32 * (arrays of
length 20 of ints) is = 1012 bytes.
< The size of an array of length 10 of tuples of word64 * (arrays of
length 20 of ints) is = 1052 bytes.
< The size of an array of length 10 of tuples of real32 * (arrays of
length 20 of ints) is = 1012 bytes.
< The size of an array of length 10 of tuples of real64 * (arrays of
length 20 of ints) is = 1052 bytes.
---
> The size of an int list of length 4 is = 96 bytes.
> The size of a string of length 10 is = 40 bytes.
> The size of an int array of length 10 is = 64 bytes.
> The size of a double array of length 10 is = 104 bytes.
> The size of a (word32 * double) array of length 10 is = 184 bytes.
> The size of a (word32 * word32 * double) array of length 10 is = 184
bytes.
> The size of a (word64 * double) array of length 10 is = 184 bytes.
> The size of a (word16 * double) array of length 10 is = 184 bytes.
testing size3
1c1,114
< size3.$arch-$os.ok missing
---
> The size of unit is = 0 bytes.
> The size of unit * unit is = 0 bytes.
> The size of bool is = 0 bytes.
> The size of bool * bool is = 16 bytes.
> The size of day is = 0 bytes.
> The size of day * day is = 0 bytes.
> The size of a char is = 0 bytes.
> The size of a char * char is = 0 bytes.
> The size of a word8 is = 0 bytes.
> The size of a word8 * word8 is = 0 bytes.
> The size of a word16 is = 0 bytes.


-- 
Thierry Fauck @ fr.ibm.com

Bug#922768: haskell-secret-sharing : FTBFS on sid - src/Crypto/SecretSharing/Internal.hs:129:39: error:

[Thierry fa...@linux.ibm.com]

Package: haskell-secret-sharing
Version: 1.0.0.3-5
Severity: important
Tags: sid buster

Compilation fails with messages

Building test suite 'Main' for secret-sharing-1.0.0.3..

: warning: [-Wmissing-home-modules]
These modules are needed for compilation but not listed in your .cabal 
file's other-modules: Crypto.SecretSharing.Internal
[1 of 2] Compiling Crypto.SecretSharing.Internal ( 
src/Crypto/SecretSharing/Internal.hs, 
dist-ghc/build/Main/Main-tmp/Crypto/SecretSharing/Internal.o )

src/Crypto/SecretSharing/Internal.hs:129:39: error:
* Illegal type: `1021' Perhaps you intended to use DataKinds
* In the untyped splice: $(primeField $ fromIntegral 1021)
|
129 | newtype FField = FField { number :: $(primeField $ fromIntegral 1021) }
|   ^^
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:147: build-ghc-stamp] Error 1

Bug#888733: hyantesite FTBFS on most architectures: test failures

[Thierry fa...@linux.ibm.com]

On Mon, 29 Jan 2018 11:47:06 +0200 Adrian Bunk  wrote:
> Source: hyantesite
> Version: 1.3.0-2
> Severity: serious
> 
> hyantesite FTBFS on most architectures with varying test failures:
> 
> https://buildd.debian.org/status/package.php?p=hyantesite
> 
> 
Since the tests are failing because (apparently) the result of float 0
is being minus signed I suspect this is related to arch representation
of some signed variables during calculation.
Any guess ?

here is an example of the result of the comparison
diff test/two_circles.out /tmp/libhypersmooth.zVpJKq
41c41
< -1.00 0.00 0.00
---
> -1.00 -0.00 0.00
122c122
< -0.975000 0.00 0.00
---
> -0.975000 -0.00 0.00

Bug#922776: libhmsbeagle : FTBFS on ppc64el - cannot convert ‘bool’ to ‘__vector(4) __bool int’ in assignment

[Thierry fa...@linux.ibm.com]

Package: libhmsbeagle
Version: 3.1.2+dfsg-3
Severity: important
Tags: sid buster ppc64el

Hello,

Compilation on ppc64el fails with following message

Apparently this is a known issue mentioned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58241

I have tested that cusing -std=gnu+11 get rid of that problem.

Bug#922778: libhmsbeagle: FTBFS - find: ‘debian/libhmsbeagle1v5’: No such file or directory

[Thierry fa...@linux.ibm.com]

Package: libhmsbeagle
Version: 3.1.2+dfsg-3
Severity: important
Tags: sid buster


Hi,
Compilation on couple of systems fails with message

dh_install
cp --reflink=auto -a debian/tmp/usr/include/libhmsbeagle-1 
debian/libhmsbeagle-dev//usr/include/
install -d debian/libhmsbeagle-dev//usr/lib/ia64-linux-gnu
cp --reflink=auto -a 
debian/tmp/usr/lib/ia64-linux-gnu/libhmsbeagle-cpu.a 
debian/tmp/usr/lib/ia64-linux-gnu/libhmsbeagle-cpu.so 
debian/tmp/usr/lib/ia64-linux-gnu/libhmsbeagle.a 
debian/tmp/usr/lib/ia64-linux-gnu/libhmsbeagle.so 
debian/libhmsbeagle-dev//usr/lib/ia64-linux-gnu/
install -d debian/libhmsbeagle-dev//usr/lib/ia64-linux-gnu/pkgconfig
cp --reflink=auto -a 
debian/tmp/usr/lib/ia64-linux-gnu/pkgconfig/hmsbeagle-1.pc 
debian/libhmsbeagle-dev//usr/lib/ia64-linux-gnu/pkgconfig/
install -d debian/.debhelper/generated/libhmsbeagle-dev
install -d debian/.debhelper/generated/libhmsbeagle1v5
install -d debian/.debhelper/generated/libhmsbeagle-java
jniso=`find debian/libhmsbeagle1v5 -name libhmsbeagle-jni.so` ; \
mkdir -p `dirname $jniso`/jni ; \
mv $jniso `dirname $jniso`/jni
find: ‘debian/libhmsbeagle1v5’: No such file or directory
dirname: missing operand
Try 'dirname --help' for more information.
mkdir: cannot create directory ‘/jni’: Permission denied
dirname: missing operand
Try 'dirname --help' for more information.
mv: missing destination file operand after '/jni'
Try 'mv --help' for more information.
make[1]: *** [debian/rules:31: override_dh_install] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:18: binary-arch] Error 2

debian/rules do find a couple of time 
   jniso=`find debian/$(lib) -name $(DEB_SOURCE)-jni.so`
   opencllib=`find debian/$(lib)/usr/lib -name 
"libhmsbeagle-opencl.so.*"
when the path for these so seems to be debian/tmp/usr/lib... 

Is there an issue with setting of variable lib compared to the build process ?

Bug#922782: dub : FTBFS - gdc : cc1d: warning: command line option '-Wformat=1' is valid for C/C++/ObjC/ObjC++ but not for D

[Thierry fa...@linux.ibm.com]

Package: dub
Version: 1.12.1-160d
Severity: important

Tags: sid buster


Hi,

Compilation on couple of arch fails with 

Generating version file for 1.12.1-1...
Running gdc...
+ gdc -Wall -obin/dub -fversion=DubUseCurl -Isource 
-Wl,--push-state,--no-as-needed -lcurl -lz -Wl,--pop-state -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wl,-z,relro @build-files.txt
*cc1d: warning: command line option '-Wformat=1' is valid for
C/C++/ObjC/ObjC++ but not for D *cc1d: error: cannot find source code for 
runtime library file 'object.d'
cc1d: note: dmd might not be correctly installed. Run 'dmd -man' for 
installation instructions.

(null):0: confused by earlier errors, bailing out
The bug is not reproducible, so it is likely a hardware or OS problem.
make[1]: *** [debian/rules:11: override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:8: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

Bug#909861: shark FTBFS on i386 with gcc 8

[Thierry fa...@linux.ibm.com]

On Sat, 29 Sep 2018 20:48:49 +0300 Adrian Bunk  wrote:
> Source: shark
> Version: 3.1.4+ds1-1
> Severity: serious
> Tags: ftbfs
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/shark.html
> 
> ...
>  57/160 Test  #67: Trainers_MissingFeatureSvmTrainer ***Failed
> 0.52 sec
> Running 2 test cases...
> ./Test/Algorithms/Trainers/MissingFeatureSvmTrainerTests.cpp(165): error: in 
> "Algorithms_Trainers_MissingFeatureSvmTrainerTests/MissingFeatures": check 
> test::verifyVectors(output1, output2) has failed. index:0, seen:1.23556e+267, 
> expected:-5.83284e+118
> 
> *** 1 failure is detected in the test module 
> "MissingFeaturesSvmTrainerTestModule"
> ...
> 99% tests passed, 1 tests failed out of 160
> 
> Total Test time (real) = 697.78 sec
> 
> The following tests FAILED:
>67 - Trainers_MissingFeatureSvmTrainer (Failed)
> Errors while running CTest
> make[2]: *** [Makefile:143: test] Error 8
> 
> 
This test is also failing on amd64 and ppc64el ... and may be others !

Bug#844778: clsync FTBFS on !x86: error: '__NR_select' undeclared here

[Thierry fa...@linux.ibm.com]

On Sat, 19 Nov 2016 01:09:28 +0200 Adrian Bunk  wrote:
> Source: clsync
> Version: 0.4.2-1
> Severity: serious
> 
> https://buildd.debian.org/status/package.php?p=clsync&suite=sid
> 
> ...
> In file included from privileged.c:64:0:
> privileged.c:88:34: error: '__NR_select' undeclared here (not in a function)
>   BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, __NR_##syscall, 0, 1), \
> ...
> 
> 

Depending on arch you have different __NR_ functions not present - for
example, __NR_alarm or __NR_shmdt

Bug#922782: dub : FTBFS - gdc : cc1d: warning: command line option '-Wformat=1' is valid for C/C++/ObjC/ObjC++ but not for D

[Thierry fa...@linux.ibm.com]

Hi,
Thanks for the explanation. As far as I understand gdc will be part of
GCC 9  so you are right , today seems a bit early.


On 20/02/2019 19:36, Matthias Klumpp wrote:
> Am Mi., 20. Feb. 2019 um 16:51 Uhr schrieb Thierry fa...@linux.ibm.com
> :
>> Package: dub
>> Version: 1.12.1-160d
>> Severity: important
>>
>> Tags: sid buster
>>
>> Hi,
>>
>> Compilation on couple of arch fails with
>>
>> Generating version file for 1.12.1-1...
>> Running gdc...
>> + gdc -Wall -obin/dub -fversion=DubUseCurl -Isource 
>> -Wl,--push-state,--no-as-needed -lcurl -lz -Wl,--pop-state -g -O2 
>> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
>> -Werror=format-security -Wl,-z,relro @build-files.txt
>> cc1d: warning: command line option '-Wformat=1' is valid for 
>> C/C++/ObjC/ObjC++ but not for D
>> cc1d: error: cannot find source code for runtime library file 'object.d'
>> cc1d: note: dmd might not be correctly installed. Run 'dmd -man' for 
>> installation instructions.
>>
>> (null):0: confused by earlier errors, bailing out
>> The bug is not reproducible, so it is likely a hardware or OS problem.
>> make[1]: *** [debian/rules:11: override_dh_auto_build] Error 1
>> make[1]: Leaving directory '/<>'
>> make: *** [debian/rules:8: build-arch] Error 2
>> dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
>> status 2
> The problem here is not the warning (that can be ignored), but the
> missing D runtime. And the runtime is missing because D does not work
> on these architectures yet, so the software will start to compile once
> someone fully ported GDC to the respective architectures.
> Since GDC has never been built on any of these arches, I am tempted to
> retitle this issue report and mark it was whishlist.
> (It would be awesome if someone could fully port GDC to more
> architectures, but I am afraid that this might be a rather large task
> for some arches. Currently, upstream supports x86, x86_64, armhf,
> aarch64)
>
> Cheers,
> Matthias
>
>

-- 
Thierry Fauck @ fr.ibm.com

Bug#922776: libhmsbeagle : FTBFS on ppc64el - cannot convert ‘bool’ to ‘__vector?=(4) bool =?UTF-8?Q?int’ in assignment

[Thierry fa...@linux.ibm.com]

Hi Andreas,

Sounds like my report was missing some info - sorry about that.
When we compile it stops with message
  cannot convert ‘bool’ to ‘__vector?=(4) bool
=?UTF-8?Q?int’ in assignment

Searching for that I found a couple of occurences  and mainly bug
gcc.gnu.org/bugzilla/show_bug.cgi?id=58241 
which is named *Bug 58241*
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58241> - [PPC/Altivec]
altivec.h inclusion in -std=c++98..11 causes bool to be redefined

This bug reports that building with -std=gnu++11 does not fail. So I
checked that this is also true with our package.

Trying other workaround like #undef bool around #include 
doesn't work because it is not implicitely specified
in the code, so I haven't find how to do it right.now.

However I don't know what changing -std= value implies.

Is that better ?
Thanks


On 21/02/2019 18:03, Andreas Tille wrote:
> Control: tags -1 help moreinfo
>
> Hi Thierry,
>
> thanks for your bug report.
>
> On Wed, Feb 20, 2019 at 03:46:51PM +0100, Thierry fa...@linux.ibm.com wrote:
>> Package: libhmsbeagle
>> Version: 3.1.2+dfsg-3
>> Severity: important
>> Tags: sid buster ppc64el
>>
>> Hello,
>>
>> Compilation on ppc64el fails with following message
>>
>> Apparently this is a known issue mentioned in
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__gcc.gnu.org_bugzilla_show-5Fbug.cgi-3Fid-3D58241&d=DwIBAg&c=jf_iaSHvJObTbx-siA1ZOg&r=h7r4xiDzcYRFJGiSxqE59fVCroGM6UiP7RqRnP6bOQ0&m=FR0XpCBnzfw_4lfBTNopdxf3_8e_dYP-_liOlNGRIvM&s=vr7mnBtA0Vvjf1xuGZl1cF9ykJ1t1cqe_XVR-3L6Y_U&e=
>>
>> I have tested that cusing -std=gnu+11 get rid of that problem.
> I admit I do not understand what exactly you did.  I've seen in
> configure.ac
>
>AM_CXXFLAGS="$AM_CXXFLAGS -std=c++11"
>
> is set.  Do you want to say that this option should be removed for
> ppc64el?
>
> Kind regards
>
>Andreas.
>

-- 
Thierry Fauck @ fr.ibm.com

Bug#923255: highwayhash: FTBFS on ppc64el due to an entry in debian/libhighwayhash0.symbols.ppc64el

[Thierry fa...@linux.ibm.com]

Package: highwayhash
Version: 0~git20190222.276dd7b
Severity: important
Tags: sid buster


Hello,
On ppc64el compilation fails with following messagesdpkg-gensymbols:
error: some symbols or patterns disappeared in the symbols file: see
diff output below

dpkg-gensymbols: warning: debian/libhighwayhash0/DEBIAN/symbols doesn't match 
completely debian/libhighwayhash0.symbols.ppc64el
--- debian/libhighwayhash0.symbols.ppc64el 

(libhighwayhash0_0~git20190222.276dd7b-1_ppc64el)
+++ dpkg-gensymbols3TMLfe   2019-02-24 03:02:17.446431370 +
@@ -48,7 +48,7 @@
  
_ZNSt23mersenne_twister_engineImLm64ELm312ELm156ELm31ELm13043109905998158313ELm29ELm6148914691236517205ELm17ELm8202884508482404352ELm37ELm1873444759240704ELm43ELm6364136223846793005EEclEv@Base
 0~20180209-g14dedec
  
_ZNSt24uniform_int_distributionImEclISt20discard_block_engineISt26subtract_with_carry_engineImLm48ELm5ELm12EELm389ELm11mRT_RKNS0_10param_typeE@Base
 0~20170419-g1f4a24f
  
_ZNSt6vectorISt4pairIjiESaIS1_EE17_M_realloc_insertIJS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 0~20180209-g14dedec
- 
_ZNSt6vectorIjSaIjEE17_M_realloc_insertIJRKjEEEvN9__gnu_cxx17__normal_iteratorIPjS1_EEDpOT_@Base
 0~20180209-g14dedec
+#MISSING: 0~git20190222.276dd7b-1# 
_ZNSt6vectorIjSaIjEE17_M_realloc_insertIJRKjEEEvN9__gnu_cxx17__normal_iteratorIPjS1_EEDpOT_@Base
 0~20180209-g14dedec
  _ZNSt6vectorImSaImEE17_M_default_appendEm@Base 0~20180209-g14dedec
  
_ZNSt8_Rb_treeImSt4pairIKmSt6vectorIjSaIjEEESt10_Select1stIS5_ESt4lessImESaIS5_EE8_M_eraseEPSt13_Rb_tree_nodeIS5_E@Base
 0~20170419-g1f4a24f
  
_ZSt7shuffleIN9__gnu_cxx17__normal_iteratorIPmSt6vectorImSaImRSt23mersenne_twister_engineImLm64ELm312ELm156ELm31ELm13043109905998158313ELm29ELm6148914691236517205ELm17ELm8202884508482404352ELm37ELm1873444759240704ELm43ELm6364136223846793005EEEvT_SA_OT0_@Base
 0~20180209-g14dedec
dh_makeshlibs: failing due to earlier errors
make: *** [debian/rules:22: binary-arch] Error 2


The entry
_ZNSt6vectorIjSaIjEE17_M_realloc_insertIJRKjEEEvN9__gnu_cxx17__normal_iteratorIPjS1_EEDpOT_@Base
0~20180209-g14dedec
is not needed in debian/libhighwayhash0.symbols.ppc64el
Removing it allows successful compilation. What do you think ?
Thanks

Bug#926843: debci - environment.sh should point to /usr/share/debci if debci_base_dir not set

[Thierry fa...@linux.ibm.com]

Package: debci
Version: 2.0
Severity: normal
Tags: buster debci

Currently default basedir for debci is /usr/share/debci. But 
environment.sh doesn't handle that path by default and reports 'E: no 
\$debci_base_dir not set!'.


Shouldn't we use the following code instead of the current one relative 
to current path (used in test environment) ?


if [ -z "${debci_base_dir:-}" ]; then
  if [ -f /usr/share/debci/lib/environment.sh ]; then
  debci_base_dir="/usr/share/debci/"
          else
                      echo "E: no \$debci_base_dir not set!"
  return 1
           fi
fi

Bug#926945: autopkgtest - autopkgtest-build-qemu on ppc64el

[Thierry fa...@linux.ibm.com]

Package: autopkgtest
Version: 5.10
Severity: important
Tag: autopkgtest qemu patch buster vmdb2
Usertags: ppc64el


While using debci, create-tesbed command for backends/qemu launches
   autopkgtest-build-qemu unstable
/var/lib/debci/qemu/unstable-ppc64el.img http://deb.debian.org/debian
*ppc64el* backends/qemu/customize.sh

1) it fails with   E: Unable to locate package
/*linux-image-ppc64el*/

the proper name should be linux-image-powerpc64le, so on line 123 I
would add the following entry for architecture ppc64el

/*  (ppc64el)*//*
*//*    kernel=linux-image-powerpc64le*//*
*//*    ;;*/

2) Then it calls vmdb2 with an entry:   grub: bios

which calls /usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py
which wants to install package

    grub_package = 'grub-pc'   for grub_target = 'i386-pc'

problem is that grub-pc package doesn't exist on ppc64el
at least*2 solutions there *- either in autopkgtest-build-qemu
conditionally sending the grub: option and install what's needed in
customize.sh script

   either modify vmdb2 to use grub2 package
and target=powerpc-ieee1275

_NOTE:_ because grub-install doesn't install on /dev/loop0 - send a
message : grub-install: error: the chosen partition is not a PReP partition

I was successfull doing /grub-install ... /dev/sda1 but image is not
bootable because slash not found - Not a bootable device !/

/A bit stuck right now !
/


Thanks for your help

Regards


-- 
Thierry Fauck @ fr.ibm.com

Bug#983843: xrdp FTBFS on several architectures

[Thierry fa...@linux.ibm.com]

At least that problem on ppc machines is due to fact that ppc64el is not 
taken in account properly


A patch could be

 diff xrdp-0.9.12/common/arch.h xrdp-bad/common/arch.h
64a65,70
> #if defined(__LITTLE_ENDIAN__)
> #define L_ENDIAN
> #else
> #define B_ENDIAN
> #endif
>
68,69c74,75
< (defined(__PPC__) && defined(__BIG_ENDIAN__)) || \
< (defined(__ppc__) && defined(__BIG_ENDIAN__))
---
> defined(__PPC__) || \
> defined(__ppc__)
82,83c88
< (defined(__PPC__) && defined(__BIG_ENDIAN__)) || \
< (defined(__ppc__) && defined(__BIG_ENDIAN__))
---
> defined(__PPC__) || defined(__ppc__)

Bug#933485: auto-multiple-choice - ppc64el - make manual-test hangs

[Thierry fa...@linux.ibm.com]

Package: auto-multiple-choice

Version: 1.4.0-1


$ make manual-test
make -C tests test
make[1]: Entering directory '/home/debian/auto-multiple-choice-1.4.0/tests'
Using qpdf
./all_tests
[ OK ] t/glade-objects-id/test.sh
[ OK ] t/standard-directory-name/test.sh

 hangs for 3 hours on ppc64el

$ ps -edf

debian   28256   916  0 17:37 pts/0    00:00:00 make manual-test
debian   28265 28256  0 17:37 pts/0    00:00:00 make -C tests test
debian   28270 28265  0 17:37 pts/0    00:00:00 /bin/bash ./all_tests
debian   28547 28270  0 17:37 pts/0    00:00:00 /usr/bin/perl 
t/0assoc/test.pl --to-stdout /usr/bin/perl t/0assoc/test.pl
debian   28716 28547  0 17:37 pts/0    00:00:00 auto-multiple-choice 
analyse
debian   28717 28716  0 17:37 pts/0    00:00:00 auto-multiple-choice 
analyse
debian   28718 28716  0 17:37 pts/0    00:00:00 auto-multiple-choice 
analyse
debian   28719 28716  0 17:37 pts/0    00:00:00 auto-multiple-choice 
analyse
debian   28720 28716  0 17:37 pts/0    00:00:00 auto-multiple-choice 
analyse
debian   28721 28716  0 17:37 pts/0    00:00:00 auto-multiple-choice 
analyse
debian   28722 28717 99 17:37 pts/0    00:16:47 
/usr/lib/AMC/exec/AMC-detect -x 1748.03146533831 -y 2480.31494396015 -d 
42.519511994409 -p 0.4 -m 0.4 -c 3 -t 0.6 -o 1
debian   28723 28718 99 17:37 pts/0    00:16:47 
/usr/lib/AMC/exec/AMC-detect -x 1748.03146533831 -y 2480.31494396015 -d 
42.519511994409 -p 0.4 -m 0.4 -c 3 -t 0.6 -o 1
debian   28724 28719 99 17:37 pts/0    00:16:47 
/usr/lib/AMC/exec/AMC-detect -x 1748.03146533831 -y 2480.31494396015 -d 
42.519511994409 -p 0.4 -m 0.4 -c 3 -t 0.6 -o 1
debian   28725 28720 99 17:37 pts/0    00:16:47 
/usr/lib/AMC/exec/AMC-detect -x 1748.03146533831 -y 2480.31494396015 -d 
42.519511994409 -p 0.4 -m 0.4 -c 3 -t 0.6 -o 1


debian   28726 28721 99 17:37 pts/0    00:16:47 
/usr/lib/AMC/exec/AMC-detect -x 1748.03146533831 -y 2480.31494396015 -d 
42.519511994409 -p 0.4 -m 0.4 -c 3 -t 0.6 -o 1


debian@vm76:~$ sudo strace -p 28726
strace: Process 28726 attached
strace: Process 28726 detached

debian@vm76:~$ sudo strace -p 28721
strace: Process 28721 attached
read(7,

That's has been reported by debci
auto-multiple-choice 
 
1.4.0-1 
 
stable 
 
ppc64el 
 
Temporary failure 	3h 4m 36s
auto-multiple-choice 
 
1.4.0-1 
 
testing 
 
ppc64el 
 
Fail 	2h 53m 49s
auto-multiple-choice 
 
1.4.0-1 
 
unstable 
 
ppc64el 
 
Fail 	3h 6m 59s

Bug#933505: bamtools - ppc64el -run-unit-test hangs

[Thierry fa...@linux.ibm.com]

Package: bamtools
Version: 2.5.1+dfsg-3

bamtools-2.5.1+dfsg/debian/tests$ sh run-unit-test
6


_debci reports_
bamtools  
2.5.1+dfsg-3  
stable  	ppc64el 
 	Fail 	2h 49m 24s
bamtools  
2.5.1+dfsg-3  
testing  
ppc64el  	Fail 
2h 47m 47s
bamtools  
2.5.1+dfsg-3  
unstable  
ppc64el  	Fail 
	2h 47m 47s


--
Thierry Fauck @ fr.ibm.com

Bug#933506: Fwd: Re: boost1.67- ppc64el -autopkgtest hangs

[Thierry fa...@linux.ibm.com]

Package: boost1.67
Version: 1.67.0-13

debci tests hangs for a while when on intel it pass in 30mn.
boost1.67  
1.67.0-13  
stable  
ppc64el  	Fail 
5h 20m 2s
boost1.67  
1.67.0-13  
testing  
ppc64el  	Fail 
	3h 42m 8s
boost1.67  
1.67.0-13  
unstable  
ppc64el  
Fail 	2h 21m 52s

Bug#933505: bamtools - ppc64el -run-unit-test hangs

[Thierry fa...@linux.ibm.com]

On 7/31/19 3:29 PM, Andreas Tille wrote:
> Hi Roger,
>
> On Wed, Jul 31, 2019 at 12:55:23PM +0200, Roger wrote:
>> I have investigated more - the failing test is
>> bamtools filter -script tests/filter_script -in sam_spec_example.bam
>> -out out.bam
> Thanks a lot for your investigation.  Do you think its a sensible
> idea to add some
>
>if [ $(dpkg-architecture -qDEB_HOST_ARCH) != "ppc64el" ] ; then
>bamtools filter -script tests/filter_script -in sam_spec_example.bam 
> -out out.bam
>fi
>
> around the test as some temporary means?

Andreas,

That sounds a good temporary idea.

Thanks

>  
>> all other tests pass.
>>
>> #
>> which traced gives
>> execve("/usr/bin/bamtools", ["bamtools", "filter", "-script",
>> "tests/filter_script", "-in", "sam_spec_example.bam", "-out",
>> "out.bam"], 0x7fffd265a250 /* 14 vars */) = 0
>> fstat(3, {st_mode=S_IFREG|0644, st_size=198896, ...}) = 0
>> mmap(NULL, 262552, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
>> = 0x7fff97cd
>> mmap(0x7fff97d0, 131072, PROT_READ|PROT_WRITE,
>> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0x7fff97d0
>> close(3)= 0
>> mprotect(0x7fff97f2, 65536, PROT_READ) = 0
>> mprotect(0x7fff97d0, 65536, PROT_READ) = 0
>> mprotect(0x7fff97f6, 65536, PROT_READ) = 0
>> mprotect(0x7fff980a, 65536, PROT_READ) = 0
>> mprotect(0x7fff9832, 65536, PROT_READ) = 0
>> mprotect(0x7fff983e, 65536, PROT_READ) = 0
>> mprotect(0x7fff9844, 65536, PROT_READ) = 0
>> mprotect(0x12ce5, 65536, PROT_READ) = 0
>> mprotect(0x7fff984f, 65536, PROT_READ) = 0
>> munmap(0x7fff9846, 215211)  = 0
>> brk(NULL)   = 0x1001ccb
>> brk(0x1001cce)  = 0x1001cce
>> openat(AT_FDCWD, "tests/filter_script", O_RDONLY) = 3
>> fstat(3, {st_mode=S_IFREG|0644, st_size=352, ...}) = 0
>> read(3, "{\n  \"filters\" : \n[\n  { \""..., 4096) = 352
>> read(3, "", 4096)   = 0
>> read(3, "", 4096)   = 0
>> read(3, "", 4096)   = 0
>> read(3, "", 4096)   = 0
>> read(3, "", 4096)   = 0
>> read(3, "", 4096)   = 0
>>
>> ... and that forever
>> I have changed the filter_script to add more lines of data, and trace
>> shows like at the end of file it doesn't get EOF and try to read more -
>> don't understand why !
>>
>> openat(AT_FDCWD, "/tmp/filter_script", O_RDONLY) = 3
>> fstat(3, {st_mode=S_IFREG|0644, st_size=63521, ...}) = 0
>> read(3, "{\n  \"filters\" : \n[\n  { \""..., 4096) = 4096
>> read(3, " }\n{"..., 4096) = 4096
>> read(3, ""..., 4096) = 4096
>> brk(0x100387e)  = 0x100387e
>> read(3, ""..., 4096) = 4096
>> read(3, ""..., 4096) = 4096
>> read(3, ""..., 4096) = 2081
>> read(3, "", 4096)   = 0
> I can forward this investigation to upstream if you have no better clue.
> Your result looks in any case suspicious not only for ppc64el.
>
> Kind regards
>
>Andreas.
>

-- 
Thierry Fauck @ fr.ibm.com

Bug#933506: Fwd: Re: boost1.67- ppc64el -autopkgtest hangs

[Thierry fa...@linux.ibm.com]

On 7/31/19 3:57 PM, Giovanni Mascellani wrote:
> Hi,
>
> Il 30/07/19 18:55, Thierry fa...@linux.ibm.com ha scritto:
>> Package: boost1.67
>> Version: 1.67.0-13
>>
>> debci tests hangs for a while when on intel it pass in 30mn.
>> boost1.67 <http://9.101.18.65/packages/b/boost1.67/stable/ppc64el/>
>> 1.67.0-13 <http://9.101.18.65/packages/b/boost1.67/stable/ppc64el/>
>> stable <http://9.101.18.65/packages/b/boost1.67/stable/ppc64el/>
>> ppc64el <http://9.101.18.65/packages/b/boost1.67/stable/ppc64el/>
> All these links are broken (the remote host does not even reply). Could
> you please verify your setup and then send working links?
>
> Thanks, Giovanni.

Hi Giovanni,

Thanks for reporting the issue - the link points to internal debci
server behind firewall (waiting for a ppc64el server available to the
community). As such I have extracted the errors from the log in another
mail to the bug. Let me know how I can help.

Regards

Thierry

Bug#944222: acl2 - FTBFS on ppc64el - invalid Unknown reloc type 31

[Thierry fa...@linux.ibm.com]

Source: acl2
Version: 8.1dfsg-4
Tags: patch, acl2

FTBFS fails with following message:

OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling /<>/acl2-fns.o.
;; Loading #p"acl2-fns.o"
Unknown reloc type 31

This has been already identified in bug #942312 for gcl
The relocation type 31 == R_PPC64_PLT16_HA and apparently it is not yet handled.
Solution: use compilation flag -mno-pltseq to avoid generation of that bad 
instruction.

Regards

--
Thierry Fauck @ fr.ibm.com

Bug#926843: debci - environment.sh should point to /usr/share/debci if debci_base_dir not set

[Thierry fa...@linux.ibm.com]

On Fri, 19 Apr 2019 11:31:35 +0200 "Thierry fa...@linux.ibm.com"
 wrote:
> Hello,
> 
> Here is a patch for a more complete set of changes.
> Regards
> 
Hi,

Please discard my previous patch as it was solving issues running
directly the debci-* commands - I understand all commands should be run
through the 'wrapper' command debci which properly set the environment.

However I got some issues related to schroot use (test-package doesn't
allow --output-dir passed)

I am currently trying to understand why make check doesn't work on
ppc64el ... start of rabbitmq-server fails within test when using
service command it starts properly. - mopre later

-- 
Thierry Fauck @ fr.ibm.com

Bug#942113: 3depict: FTBFS on PPC64EL - POWERPC macro not always defined

[Thierry fa...@linux.ibm.com]

Package: 3depict
Version 0.0.22-1
Severity: normal


The error when compiling on ppc64el:

g++ -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include/freetype2 -I/usr/include/libpng16 -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security --std=gnu++11   
-I/usr/lib/powerpc64le-linux-gnu/wx/include/gtk3-unicode-3.0 
-I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__  
-I/usr/include  -I/usr/include/libxml2 -L/lib -fopenmp -D_GLIBCXX_PARALLEL  
-pipe  -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security --std=gnu++11 -c -o 
backend/3Depict-viscontrol.o `test -f 'backend/viscontrol.cpp' || echo 
'./'`backend/viscontrol.cpp
In file included from /usr/include/qhull/qhull_a.h:28,
 from backend/filters/algorithms/spatial.cpp:29:
/usr/include/qhull/libqhull.h:46:30: error: operator '&&' has no right operand
   46 | #if __MWERKS__ && __POWERPC__
  |  ^ 
is due to the fact that __POWERPC__ macro is not defined by default on g++

A see a couple of solutions I have tested ,
- define __POWERPC__   before including  qhull_a.h
- or have the included library qhull_a.h using __powerpc__ instead of 
__POWERPC__

Bug#942113: 3depict: FTBFS on PPC64EL - POWERPC macro not always defined

[Thierry fa...@linux.ibm.com]

Changing on file side is not enough as there a couple of file impacted
 > g++ -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include/freetype2 -I/usr/include/libpng16 -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security --std=gnu++11 
-I/usr/lib/powerpc64le-linux-gnu/wx/include/gtk3-unicode-3.0 
-I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ 
-I/usr/include  -I/usr/include/libxml2 -L/lib -fopenmp 
-D_GLIBCXX_PARALLEL  -pipe  -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security --std=gnu++11 
-c -o backend/filters/algorithms/3Depict-spatial.o `test -f 
'backend/filters/algorithms/spatial.cpp' || echo 
'./'`backend/filters/algorithms/spatial.cpp

In file included from /usr/include/qhull/qhull_a.h:28,
 from backend/filters/algorithms/spatial.cpp:30:
/usr/include/qhull/libqhull.h:46:30: error: operator '&&' has no right operand
   46 | #if __MWERKS__ && __POWERPC__
  |  ^



and included files are not common !

Bug#942171: tcpdump: FTBFS on ppc64el for test ikev2pI2

[Thierry fa...@linux.ibm.com]

Source: tcpdump
Version: 4.9.3-1
Severity: serious

https://buildd.debian.org/status/logs.php?pkg=tcpdump&arch=ppc64el&suite=sid

--- 1 tests failed 441 tests 
passed Failed test: ikev2pI2 41c41 < (v2auth: len=196 method=rsasig 
authdata=() 
)) --- > (v2auth: len=196 method=rsasig 
authdata=(9d7686de6fabda36c4b374135ccca0c4596fe7636e19ee71ea7d276b4230948ab529651ba1dbec39e85e506ff90b48a57611be386a5867beccde9c9971587907251df58f0c46b473d9f0abc308eb85482f08383d) 
))



This is similar to bug #873377 which was supposed to be fixed in V 
4.9.1-2 - logs show that for v4.9.1-2 and -3 test was not run - then it 
was failing but not reported as an error for the global count of success !

Bug#942183: Fwd: memcached : FTBFS on ppc64el - missing ss command

[Thierry fa...@linux.ibm.com]

Source: memcached
Version: 1.5.19-1

autopkgtest fails on ppc64el with message ss not found. This command 
coming from package iproute2, I believe it is a missing dependency.

Bug#942312: gcl - FTBFS on ppc64el - invalid relocation type 31

[Thierry fa...@linux.ibm.com]

Source: gcl
Version: 2.6.12-88
Tags: patch

Compilation fails with


;; Loading "../tkl.o"

Unknown reloc type 31

The relocation type 31 == R_PPC64_PLT16_HA and apparently it is not yet handled.
Similar issue have been found on Fedora
 https://lists.gnu.org/archive/html/gcl-devel/2019-07/msg0.html

Using flag -mno-pltseq/finishes properly with GCL (GNU Common Lisp) 2.6.12 ANSI Fri Apr 22 
15:51:11 UTC 2016 Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl) 
Binary License: GPL due to GPL'ed components: (XGCL READLINE UNEXEC) 
Modifications of this banner must retain notice of a compatible license 
Dedicated to the memory of W. Schelter Use (help) to get some basic 
information on how to use GCL. Temporary directory for compiler files: 
/tmp/ >;; Loading "../tkl.o" start address -T 0xf5f8b0 ;; Finished 
loading "../tkl.o" 112159 > NIL >make[1]: Leaving directory 
'/build/gcl-0nFTx8/gcl-2.6.12/gcl-tk' rm h/mcompdefs.h /

Bug#942312: gcl - FTBFS on ppc64el - invalid relocation type 31

[Thierry fa...@linux.ibm.com]

On Mon, 14 Oct 2019 15:21:07 +0200 "Thierry fa...@linux.ibm.com" 
 wrote:

Source: gcl
Version: 2.6.12-88
Tags: patch

Compilation fails with

>;; Loading "../tkl.o"
Unknown reloc type 31

The relocation type 31 == R_PPC64_PLT16_HA and apparently it is not yet handled.
Similar issue have been found on Fedora
  https://lists.gnu.org/archive/html/gcl-devel/2019-07/msg0.html

Using flag -mno-pltseq/finishes properly with GCL (GNU Common Lisp) 2.6.12 ANSI Fri Apr 22 
15:51:11 UTC 2016 Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl) 
Binary License: GPL due to GPL'ed components: (XGCL READLINE UNEXEC) 
Modifications of this banner must retain notice of a compatible license 
Dedicated to the memory of W. Schelter Use (help) to get some basic 
information on how to use GCL. Temporary directory for compiler files: 
/tmp/ >;; Loading "../tkl.o" start address -T 0xf5f8b0 ;; Finished 
loading "../tkl.o" 112159 > NIL >make[1]: Leaving directory 
'/build/gcl-0nFTx8/gcl-2.6.12/gcl-tk' rm h/mcompdefs.h /


Build result after adding -mno-pltseq in configure* for powerpc-linux 
flags is


I: Autopkgtest run was successful.

+--+
| Cleanup 
  |

+--+

Purging /<>
Not cleaning session: cloned chroot in use

+--+
| Summary 
  |

+--+

Autopkgtest: no tests
Build Architecture: ppc64el
Build Type: binary
Build-Space: 1631672
Build-Time: 1067
Distribution: unstable
Host Architecture: ppc64el
Install-Time: 253
Job: gcl
Lintian: warn
Machine Architecture: ppc64el
Package: gcl
Package-Time: 1457
Source-Version: 2.6.12-88
Space: 1631672
Status: successful
Version: 2.6.12-88

Finished at 2019-10-14T13:46:04Z
Build needed 00:24:17, 1631672k disk space

Bug#942432: sagemath FTBFS on ppc64el

[Thierry fa...@linux.ibm.com]

Package: sagemath
Version: 8.9-1
Severity: high

Tests are failing due to programation errors

 * may be GCC 9 is less permissive
 * may be default library don't include objects with expected definition

but result is a strange message

                Success: 38 tests failed, up to 65 failures are tolerated

                dpkg-buildpackage: error: debian/rules binary 
subprocess returned exit status 2



**
File "src/sage/cpython/dict_del_by_value.pyx", line 414, in 
sage.cpython.dict_del_by_value.test_del_dictitem_by_exact_value
Failed example:
test_del_dictitem_by_exact_value(D, ZZ, 2)
Exception raised:
Traceback (most recent call last):
  File 
"/<>/debian/build/usr/lib/python3/dist-packages/sage/doctest/forker.py",
 line 681, in _run
self.compile_and_execute(example, compiler, test.globs)
  File 
"/<>/debian/build/usr/lib/python3/dist-packages/sage/doctest/forker.py",
 line 1123, in compile_and_execute
exec(compiled, globs)
  File "", line 1, in 

test_del_dictitem_by_exact_value(D, ZZ, Integer(2))
  File "sage/cpython/dict_del_by_value.pyx", line 421, in 
sage.cpython.dict_del_by_value.test_del_dictitem_by_exact_value 
(build/cythonized/sage/cpython/dict_del_by_value.c:2387)
del_dictitem_by_exact_value(D, value, h)
TypeError: an integer is required
**
File "src/sage/cpython/dict_del_by_value.pyx", line 417, in 
sage.cpython.dict_del_by_value.test_del_dictitem_by_exact_value
Failed example:
test_del_dictitem_by_exact_value(D, QQ, 1)
Exception raised:
Traceback (most recent call last):
  File 
"/<>/debian/build/usr/lib/python3/dist-packages/sage/doctest/forker.py",
 line 681, in _run
self.compile_and_execute(example, compiler, test.globs)
  File 
"/<>/debian/build/usr/lib/python3/dist-packages/sage/doctest/forker.py",
 line 1123, in compile_and_execute
exec(compiled, globs)
  File "", line 1, in 

test_del_dictitem_by_exact_value(D, QQ, Integer(1))
  File "sage/cpython/dict_del_by_value.pyx", line 421, in 
sage.cpython.dict_del_by_value.test_del_dictitem_by_exact_value 
(build/cythonized/sage/cpython/dict_del_by_value.c:2387)
del_dictitem_by_exact_value(D, value, h)
TypeError: an integer is required
**
1 item had failures:
   2 of  12 in sage.cpython.dict_del_by_value.test_del_dictitem_by_exact_value
[33 tests, 2 failures, 4.30 s]
**
File "src/sage/env.py", line 221, in sage.env._get_shared_lib_filename
Failed example:
Failed example:
fnmatch(lib_filename, pattern)
Exception raised:
Traceback (most recent call last):
  File 
"/<>/debian/build/usr/lib/python3/dist-packages/sage/doctest/forker.py",
 line 681, in _run
self.compile_and_execute(example, compiler, test.globs)
  File 
"/<>/debian/build/usr/lib/python3/dist-packages/sage/doctest/forker.py",
 line 1123, in compile_and_execute
exec(compiled, globs)
  File "", line 1, in 
fnmatch(lib_filename, pattern)
  File "/usr/lib/python3.7/fnmatch.py", line 34, in fnmatch
name = os.path.normcase(name)
  File "/usr/lib/python3.7/posixpath.py", line 54, in normcase
s = os.fspath(s)
TypeError: expected str, bytes or os.PathLike object, not NoneType
**
1 item had failures:
   1 of   8 in sage.env._get_shared_lib_filename
**
File "src/sage/graphs/digraph_generators.py", line 597, in 
sage.graphs.digraph_generators.DiGraphGenerators.nauty_directg
Failed example:
len(dgs)
Expected:
13
Got:
0
**
File "src/sage/graphs/digraph_generators.py", line 599, in 
sage.graphs.digraph_generators.DiGraphGenerators.nauty_directg
Failed example:
dgs[0]
Exception raised:
Traceback (most recent call last):
  File 
"/<>/debian/build/usr/lib/python3/dist-packages/sage/doctest/forker.py",
 line 681, in _run
self.compile_and_execute(example, compiler, test.globs)
  File 
"/<>/debian/build/usr/lib/python3/dist-packages/sage/doctest/forker.py",
 line 1123, in compile_and_execute
exec(compiled, globs)
  File "", line 1, in 
dgs[Integer(0)]
IndexError: list index out of range
***

Bug#942113: 3depict: FTBFS on PPC64EL - POWERPC macro not always defined

[Thierry fa...@linux.ibm.com]

Hello
I've personally always used __powerpc__ .
Here is my reference, very useful for all arch related defines :
https://wiki.debian.org/ArchitectureSpecificsMemo

Cheers
Thierry



I've Cc:-ed tille as his was the most recent upload.  Let me know if
you'd like me to NMU with a s/__POWERPC__/__powerpc__/.

Cheers,
Olly

Bug#918572: check FTBFS on ppc*: test failure

[Thierry fa...@linux.ibm.com]

On Mon, 07 Jan 2019 15:54:46 +0200 Adrian Bunk  wrote:

Source: check
Version: 0.12.0-0.1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=check

...
FAIL: check_check_export
FAIL: check_check
PASS: test_output.sh
PASS: test_check_nofork.sh
PASS: test_check_nofork_teardown.sh
PASS: test_xml_output.sh
PASS: test_log_output.sh
PASS: test_set_max_msg_size.sh
PASS: test_tap_output.sh

   Check 0.12.0: tests/test-suite.log


# TOTAL: 9
# PASS:  7
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0



(powerpcspe builds with nocheck)



Could you recheck compilation as my last test with gcc-9 on SID passes. Thx
--
Thierry Fauck @ fr.ibm.com

Bug#940828: octave-video - FTBFS on ppc64el - AVHandler: Error reading packet after timestamp 0 - knwon failure !

[Thierry fa...@linux.ibm.com]

Package: octave-video
Version:*1.2.4-1*
Severity: important

[src/aviread.cc]

/home/debian/octave-video-1.2.4/src/aviread.cc

* demo
* test
 fn = tmpnam;
 x = avifile(fn);

 # Generate some picture
 I = repmat(0:255, 256, 1)/255;
 I = cat(3, I, repmat([0:255]', 1, 256)/255);
 I = cat(3, I, 0.3*ones(256,256));

 # Write it to the AVI and close the AVI
 addframe(x, I);
 addframe(x, I);  #FIXME: aviread currently fails if only 1 frame
 clear x
 assert(exist(fn,"file"))
 I2 = aviread(fn, 1);

 #allow max. 5% difference between pixels
 assert(!any((I-I2)(:)>0.05))
 delete(fn);
warning: tmpnam is obsolete and will be removed from a future version of 
Octave, please use tempname instead
[avi @ 0x100257da840] Using AVStream.codec to pass codec parameters to muxers 
is deprecated, use AVStream.codecpar instead.
*[NULL @ 0x100257d81b0] Failed to parse extradata*
[swscaler @ 0x1002580b8f0] ALTIVEC: Color Space BGR24
*! test failed*
assert (!any ((I - I2) (:) > 0.05)) failed
* xtest
 fn = tmpnam;
 x = avifile(fn);
 I = ones(256,256);
 addframe(x, I);
 clear x
 # FIXME: This fails if there is only 1 frame (fine with >1 frames) with
 # AVHandler: Error reading packet after timestamp 0
 I = aviread(fn, 1);
[avi @ 0x100257db250] Using AVStream.codec to pass codec parameters to muxers 
is deprecated, use AVStream.codecpar instead.
[NULL @ 0x100258537a0] Failed to parse extradata
*AVHandler: Error reading packet after timestamp 0*
! known failure
aviread: cannot read frame 1
2 tests, 0 passed, 1 known failure, 0 skipped

Bug#918572: check FTBFS on ppc*: test failure

[Thierry fa...@linux.ibm.com]

Hello,
Thanks for pointing out there is still the issue. I realized my test was 
using version 0.10.0-3 instead of 0.12.0-0.1 !
As one of the failing test: ../../tests/check_check_master.c:749:F:Core 
Tests:test_check_all_ftypes:125: For test 125:Simple 
Tests:test_ck_assert_ldouble_eq_tol failure type wrong, expected 2 but got 1
I wonder if it is not related to the double memory representation on 
ppc64el ... usual story of 64bits-128bits may be 

I Will try to investigate again
Thanks



On 9/22/2019 8:32 PM, Boyuan Yang wrote:

I submitted a self-service giveback request and had this package rebuilt on
ppc64el. It is still failing with GCC 9. Looks like further investigation is
needed.

https://buildd.debian.org/status/package.php?p=check

Thanks,
Boyuan Yang


On Fri, 20 Sep 2019 09:57:02 +0200 "Thierry fa...@linux.ibm.com" <
thie...@linux.ibm.com> wrote:

On Mon, 07 Jan 2019 15:54:46 +0200 Adrian Bunk  wrote:

Source: check
Version: 0.12.0-0.1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=check

...
FAIL: check_check_export
FAIL: check_check
PASS: test_output.sh
PASS: test_check_nofork.sh
PASS: test_check_nofork_teardown.sh
PASS: test_xml_output.sh
PASS: test_log_output.sh
PASS: test_set_max_msg_size.sh
PASS: test_tap_output.sh

Check 0.12.0: tests/test-suite.log


# TOTAL: 9
# PASS:  7
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0



(powerpcspe builds with nocheck)



Could you recheck compilation as my last test with gcc-9 on SID passes. Thx
--
Thierry Fauck @ fr.ibm.com




--
Thierry Fauck @ fr.ibm.com

Bug#926945: autopkgtest - autopkgtest-build-qemu on ppc64el

[Thierry fa...@linux.ibm.com]

Regarding that issue I have provided 2 patches (copied for reference)

- one for vmdb2 (pushed to salsa))
- create a new command called set to set the Prep Flag to the first
partition for GRUB2 purpose.
- Calls GRUB2 with target powerpc-ieee1275 for arch ppc64el (instead of
grub-pc/i386-pc for other arch).

- one for autopkgtest-build-qemu which adds a new primary partition of
type Prep for GRUB2 purpose - that partition doesn't prevent grub-pc to
work.

Regards
Thierry

>From 030997e00cc4347aecf2d3029dbb85f4c8b4f4e6 Mon Sep 17 00:00:00 2001
From: Thierry Fauck 
Date: Mon, 3 Jun 2019 10:22:27 +0200
Subject: [PATCH] Add grub2 handling for ppc64el arch Add Prep partition
 setting for grub2

Signed-off-by: Thierry Fauck 

	modified:   vmdb/plugins/grub_plugin.py
	modified:   vmdb/plugins/partition_plugin.py
---
 vmdb/plugins/grub_plugin.py  | 14 +++---
 vmdb/plugins/partition_plugin.py | 10 ++
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/vmdb/plugins/grub_plugin.py b/vmdb/plugins/grub_plugin.py
index 0025011..7622213 100644
--- a/vmdb/plugins/grub_plugin.py
+++ b/vmdb/plugins/grub_plugin.py
@@ -71,6 +71,7 @@
 
 import logging
 import os
+import platform
 import re
 
 import cliapp
@@ -109,9 +110,14 @@ class GrubStepRunner(vmdb.StepRunnerInterface):
 self.install_grub(step, settings, state, grub_package, grub_target)
 
 def install_bios(self, step, settings, state):
-vmdb.progress('Installing GRUB for BIOS')
-grub_package = 'grub-pc'
-grub_target = 'i386-pc'
+if platform.machine() == 'ppc64le':
+vmdb.progress('Installing GRUB2 for BIOS')
+grub_package = 'grub2'
+grub_target = 'powerpc-ieee1275'
+else:
+vmdb.progress('Installing GRUB for BIOS')
+grub_package = 'grub-pc'
+grub_target = 'i386-pc'
 self.install_grub(step, settings, state, grub_package, grub_target)
 
 def install_grub(self, step, settings, state, grub_package, grub_target):
@@ -126,6 +132,8 @@ class GrubStepRunner(vmdb.StepRunnerInterface):
 image_dev = step.get('image-dev')
 if image_dev is None:
 image_dev = self.get_image_loop_device(root_dev)
+if platform.machine() == 'ppc64le':
+image_dev = state.tags.get_dev('prep')
 
 if 'efi' in step:
 efi = step['efi']
diff --git a/vmdb/plugins/partition_plugin.py b/vmdb/plugins/partition_plugin.py
index 71ff58d..d4280ce 100644
--- a/vmdb/plugins/partition_plugin.py
+++ b/vmdb/plugins/partition_plugin.py
@@ -31,6 +31,7 @@ class PartitionPlugin(cliapp.Plugin):
 self.app.step_runners.add(MklabelStepRunner())
 self.app.step_runners.add(MkpartStepRunner())
 self.app.step_runners.add(KpartxStepRunner())
+self.app.step_runners.add(SetflagStepRunner())
 
 
 class MklabelStepRunner(vmdb.StepRunnerInterface):
@@ -94,6 +95,15 @@ class MkpartStepRunner(vmdb.StepRunnerInterface):
 if line not in old
 ]
 
+class SetflagStepRunner(vmdb.StepRunnerInterface):
+
+def get_required_keys(self):
+return ['set', 'device']
+
+def run(self, step, settings, state):
+label_type = step['set']
+device = step['device']
+vmdb.runcmd(['parted', '-s', device, 'set', '1', 'prep', 'on'])
 
 class KpartxStepRunner(vmdb.StepRunnerInterface):
 
-- 
2.7.4

>From 2dffef961db3b0506c50578227aca6f79582f869 Mon Sep 17 00:00:00 2001
From: Thierry Fauck 
Date: Mon, 3 Jun 2019 09:56:18 +0200
Subject: [PATCH] With ppc64el arch and grub2 a primary partition of type Prep
 needs to be created - as this partition doesn't affect grub-pc processing, a
 new call to set the flag to the first partition is been created. Kernel
 release name for ppc64el arch is also added.

Signed-off-by: Thierry Fauck 

	modified:   tools/autopkgtest-build-qemu
---
 tools/autopkgtest-build-qemu | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/tools/autopkgtest-build-qemu b/tools/autopkgtest-build-qemu
index 5b2c996..7b481d7 100755
--- a/tools/autopkgtest-build-qemu
+++ b/tools/autopkgtest-build-qemu
@@ -121,6 +121,9 @@ case "$mirror" in
   (ppc64)
 kernel=linux-image-powerpc64
 ;;
+  (ppc64el)
+kernel=linux-image-powerpc64le
+;;
   (*)
 kernel="linux-image-$architecture"
 ;;
@@ -135,15 +138,24 @@ steps:
   - mkimg: "{{ image }}"
 size: 20G
 
-  - mklabel: msdos
+  - mklabel: gpt
 device: "{{ image }}"
 
   - mkpart: primary
 device: "{{ image }}"
 start: 0%
+end: 5%
+tag: boot
+
+  - mkpart: primary
+device: "{{ image }}"
+start: 5%
 end: 100%
 tag: root
 
+  - set: flag
+device: "{{ image }}"
+
   - kpartx: "{{ image }}"
 
   - mkfs: ext4
-- 
2.7.4

Bug#864423: Software RAID is not activated at boot time

[Thierry fa...@linux.ibm.com]

So what about adding
case $Node_Name in
/dev/*)
Raid_Name=$(dmraid -i -r -cr $Node_Name | grep -vi "No RAID disks" > | 
grep -vi "formats discovered")

break;;
esac

ou similar ?


> > As $Node_Name already contains "/dev", in my case dmraid is called 
with > parameters /dev/dev/sdb and /dev/dev/sda


. > > Regards > Christoph > >

Best regards / Cordialement

Thierry

Bug#921527: cuneiform_1.1.0+dfsg-7 - FTBFS on ppc64el

[Thierry fa...@linux.ibm.com]

The problem reported was fixed for some arch in version 1.1.0+dfsg-6 but 
apparently it is not universal.


The main question is is the 'Architecture: any all' appropriate ? since 
readme says

>Caveats
>There are known limitations in this port. Among these are the 
following:

>- it only works on x86 and amd64 processors
--
Thierry Fauck @ fr.ibm.com

Bug#921099: cpufreqd-2.4.2 on pcc64el doesn't compile

[Thierry fa...@linux.ibm.com]

Package: cpufreqd
Version: 2.4.2
Severity: important
Tags: patch

Following bug #889895 - disable building this package for Power architectures
cpufrequtils package providing libcpufreq0 is not any more compiled.
As such line 41-43 of configure.in are not any more valid and prevent package 
compilation.

bug #889895 suggest to use as dependency package linux-cpupower.

As such, a patch could be to use for ppc systems :
AC_CHECK_LIB([cpupower], [cpupower_is_cpu_online],
[ CPUFREQD_LDFLAGS="${CPUFREQD_LDFLAGS} -lcpupower" ],
[ AC_MSG_ERROR([You need libcpupower from linux-cpupower to 
buid cpufreqd]) ])

Bug#919189: Fwd: probabel FTBFS on arm64, likely due to Eigen 3 NEON code

[Thierry fa...@linux.ibm.com]

Unfortunately the workaround mentioned for arm64 breaks ppc64el arch as
compiling on buster fails with following error - what do we do ?
Thanks


BT check (recess model): prob vs. prob_fv  OK
2c2
< rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938
544.518 437.583 -567.388 435.04 1.75239
---
> rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938
544.518 437.583 -567.387 435.04 1.75239
BT check (2df model): prob vs. prob_fv
FAILED
FAIL test_bt.sh (exit status: 1)
-



On Sun, 13 Jan 2019 16:37:02 +0200 Adrian Bunk  wrote:
> Source: probabel
> Version: 0.5.0+dfsg-1
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/fetch.php?pkg=probabel&arch=arm64&ver=0.5.0%2Bdfsg-1&stamp=1538603399&raw=0
> 
> ...
> FAIL: test_bt
> =
> 
> Analysing BT...
> BT check: dose vs. dose_fv OK
> BT check (add model): prob vs. prob_fv OK
> BT check (domin model): prob vs. prob_fv   OK
> BT check (over_domin model): prob vs. prob_fv  OK
> BT check (recess model): prob vs. prob_fv  OK
> 2c2
> < rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938 544.518 
> 437.583 -567.387 435.04 1.75239
> ---
> > rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938 544.518 
> > 437.583 -567.388 435.04 1.75239
> BT check (2df model): prob vs. prob_fv FAILED
> FAIL test_bt.sh (exit status: 1)
> 
> 
> Testsuite summary for ProbABEL 0.5.0
> 
> # TOTAL: 11
> # PASS:  10
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> See checks/test-suite.log
> Please report to genabel-de...@r-forge.wu-wien.ac.at
> 
> make[4]: *** [Makefile:713: test-suite.log] Error 1
> 
> 
> I suspect this might be a problem with the NEON code in Eigen 3,
> and the fact that this can be fixed with the following workaround
> makes that even more probable:
> 
> --- debian/rules.old  2019-01-09 15:07:11.950823327 +
> +++ debian/rules  2019-01-09 15:17:23.280539016 +
> @@ -6,6 +6,10 @@
>  
>  export DEB_BUILD_MAINT_OPTIONS=hardening=+all
>  
> +ifeq ($(DEB_HOST_ARCH),arm64)
> +  export DEB_CXXFLAGS_MAINT_APPEND = -march=armv8-a+nosimd
> +endif
> +
>  include /usr/share/dpkg/default.mk
>  
>  # Location of the example files, will be converted to the
> 
> 

Bug#862771: sciplot FTBFS on ppc64{,el}: ld: unrecognised emulation mode: minimal-toc

[Thierry fa...@linux.ibm.com]

On Tue, 16 May 2017 22:37:53 +0300 Adrian Bunk  wrote:
> Source: sciplot
> Version: 1.36-16
> Severity: important
> 
> https://buildd.debian.org/status/package.php?p=sciplot&suite=sid
> 
> ...
> ld -shared  -o libsciplot.so.1.36 SciPlot.o SciPlotUtil.o   -mminimal-toc 
>   -lXm -lXmu -lXt -lSM -lICE -lXext -lX11 -lXt -lSM -lICE -lXext -lX11   -lm  
> -lm  -soname libsciplot.so.1 -lc
> ld: unrecognised emulation mode: minimal-toc
> Supported emulations: elf64lppc elf32lppc elf32lppclinux elf32lppcsim 
> elf64ppc elf32ppc elf32ppclinux elf32ppcsim
> Makefile:1105: recipe for target 'shared' failed
> make[2]: *** [shared] Error 1
> 
> 
what about adding in Imakefile:
#ifdef Ppc64Architecture
#define DefaultNotLDOptions -mminimal-toc
NOTLDOPTIONS = DefaultNotLDOptions
LDOPTIONS := $(filter-out $(NOTLDOPTIONS),$(LDOPTIONS))
#endif

Bug#919189: Fwd: probabel FTBFS on arm64, likely due to Eigen 3 NEON code

[Thierry fa...@linux.ibm.com]

Hi,

Thanks for pointing out that my analysis wasn't good - the arm patch
doesn't change anything for ppc64el (which make sense whatsoever) - the
problem on ppc64el is similar to the one on arm except the test value
are opposite ! ( which was confusing).
So what do we need to do ? expect that someone with a better expertise
help going though it  ? ( can you confirm we stay with that bug for both
arch or do we need to open one for ppc64el ?)
Thanks



On 02/02/2019 07:15, Andreas Tille wrote:
> Hi,
>
> I think these are just rounding errors due to different representation of
> floating point numbers.  Relaxing the precision of the test would solve
> the problem (but I have no idea about the test suite and so do not know
> how to implement this).
>
> What I do also not understand why a fix that only occures on arm64 now
> has an influence on ppc64el.  Did ppc64el compiled fine for version
> 0.5.0+dfsg-1 (without that fix)?
>
> Kind regards
>
> Andreas.
>
> On Fri, Feb 01, 2019 at 04:41:04PM +0100, Thierry fa...@linux.ibm.com wrote:
>> Unfortunately the workaround mentioned for arm64 breaks ppc64el arch as
>> compiling on buster fails with following error - what do we do ?
>> Thanks
>>
>> 
>> BT check (recess model): prob vs. prob_fv  OK
>> 2c2
>> < rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938
>> 544.518 437.583 -567.388 435.04 1.75239
>> ---
>>> rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938
>> 544.518 437.583 -567.387 435.04 1.75239
>> BT check (2df model): prob vs. prob_fv
>> FAILED
>> FAIL test_bt.sh (exit status: 1)
>> -
>>
>>
>>
>> On Sun, 13 Jan 2019 16:37:02 +0200 Adrian Bunk  wrote:
>>> Source: probabel
>>> Version: 0.5.0+dfsg-1
>>> Severity: serious
>>> Tags: ftbfs
>>>
>>> https://buildd.debian.org/status/fetch.php?pkg=probabel&arch=arm64&ver=0.5.0%2Bdfsg-1&stamp=1538603399&raw=0
>>>
>>> ...
>>> FAIL: test_bt
>>> =
>>>
>>> Analysing BT...
>>> BT check: dose vs. dose_fv OK
>>> BT check (add model): prob vs. prob_fv OK
>>> BT check (domin model): prob vs. prob_fv   OK
>>> BT check (over_domin model): prob vs. prob_fv  OK
>>> BT check (recess model): prob vs. prob_fv  OK
>>> 2c2
>>> < rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938 544.518 
>>> 437.583 -567.387 435.04 1.75239
>>> ---
>>>> rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938 544.518 
>>>> 437.583 -567.388 435.04 1.75239
>>> BT check (2df model): prob vs. prob_fv 
>>> FAILED
>>> FAIL test_bt.sh (exit status: 1)
>>>
>>> 
>>> Testsuite summary for ProbABEL 0.5.0
>>> 
>>> # TOTAL: 11
>>> # PASS:  10
>>> # SKIP:  0
>>> # XFAIL: 0
>>> # FAIL:  1
>>> # XPASS: 0
>>> # ERROR: 0
>>> 
>>> See checks/test-suite.log
>>> Please report to genabel-de...@r-forge.wu-wien.ac.at
>>> 
>>> make[4]: *** [Makefile:713: test-suite.log] Error 1
>>>
>>>
>>> I suspect this might be a problem with the NEON code in Eigen 3,
>>> and the fact that this can be fixed with the following workaround
>>> makes that even more probable:
>>>
>>> --- debian/rules.old2019-01-09 15:07:11.950823327 +
>>> +++ debian/rules2019-01-09 15:17:23.280539016 +
>>> @@ -6,6 +6,10 @@
>>>  
>>>  export DEB_BUILD_MAINT_OPTIONS=hardening=+all
>>>  
>>> +ifeq ($(DEB_HOST_ARCH),arm64)
>>> +  export DEB_CXXFLAGS_MAINT_APPEND = -march=armv8-a+nosimd
>>> +endif
>>> +
>>>  include /usr/share/dpkg/default.mk
>>>  
>>>  # Location of the example files, will be converted to the
>>>
>>>
>> ___
>> Debian-med-packaging mailing list
>> debian-med-packag...@alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging


-- 
Thierry Fauck @ fr.ibm.com

Bug#926843: debci - environment.sh should point to /usr/share/debci if debci_base_dir not set

[Thierry fa...@linux.ibm.com]

Hello,

Here is a patch for a more complete set of changes.
Regards

>From 4693317d5eef79acd5d36e0c7f99d76c70b6e6d5 Mon Sep 17 00:00:00 2001
From: Thierry Fauck 
Date: Fri, 19 Apr 2019 11:20:40 +0200
Subject: [PATCH] Work on multiple scripts related to #926843

Signed-off-by: Thierry Fauck 
---
 backends/lxc/test-package | 16 +++-
 backends/schroot/test-package |  6 --
 lib/environment.sh|  4 +++-
 tools/analysis/Rakefile   |  3 ++-
 tools/gen-fake-data.sh| 19 +++
 tools/indexer.sh  |  4 ++--
 tools/init-dev.sh | 12 
 tools/purge-package.sh|  3 +++
 tools/workers.sh  |  6 ++
 9 files changed, 58 insertions(+), 15 deletions(-)

diff --git a/backends/lxc/test-package b/backends/lxc/test-package
index 18223fe..a73ceb8 100755
--- a/backends/lxc/test-package
+++ b/backends/lxc/test-package
@@ -10,7 +10,21 @@ $@
 EOF
 }
 
+param=$@
+param1=${1#--output-dir*}
+
+if [ -z $param1 ];then
+	mkdir -p $2
+	shift
+	shift
+	param=$*
+fi
+
 container_name=$(date +ci-%s)
 
-debci-autopkgtest --user debci --apt-upgrade "$@" \
+debci_base_dir=$(readlink -f $(dirname $(readlink -f $0))/../..)
+
+. $debci_base_dir/lib/environment.sh
+
+debci-autopkgtest --user debci --apt-upgrade "$param" \
   -- lxc --sudo --name "${container_name}" "autopkgtest-${debci_suite}-${debci_arch}"
diff --git a/backends/schroot/test-package b/backends/schroot/test-package
index f8341d4..69607e4 100755
--- a/backends/schroot/test-package
+++ b/backends/schroot/test-package
@@ -10,10 +10,12 @@ $@
 EOF
 }
 
+param=$*
 backend="$(dirname "$0")"
+. "${backend}/../../lib/environment.sh"
 . "${backend}/environment.sh"
 
-session_id="${debci_chroot_name}-$(basename "$debci_test_package")"
+session_id="${debci_chroot_name}-$(basename "$0")"
 
-debci-autopkgtest --user debci --apt-upgrade "$@" \
+debci-autopkgtest --user debci --apt-upgrade "$param" \
   -- schroot --session-id="${session_id}" "${debci_chroot_name}"
diff --git a/lib/environment.sh b/lib/environment.sh
index 7569fa5..b2148dd 100644
--- a/lib/environment.sh
+++ b/lib/environment.sh
@@ -14,6 +14,8 @@ export LANG=C.UTF-8
 if [ -z "${debci_base_dir:-}" ]; then
   if [ -f lib/environment.sh ]; then
 debci_base_dir="$(pwd)"
+  elif [ -f /usr/share/debci/lib/environment.sh ]; then
+debci_base_dir="/usr/share/debci"
   else
 echo "E: no \$debci_base_dir not set!"
 return 1
@@ -81,7 +83,7 @@ usage_shared_options="Common options:
   --helpshow this usage message
 "
 
-program_name=${0##*/}
+program_name=$debci_base_dir/backends/$debci_backend/${0##*/}
 TEMP=`getopt --name $program_name -o ${shared_short_options}${short_options:-} --long ${shared_long_options},${long_options:-} -- "$@"`
 
 if [ $? != 0 ]; then
diff --git a/tools/analysis/Rakefile b/tools/analysis/Rakefile
index 16c2e16..70fe0b2 100644
--- a/tools/analysis/Rakefile
+++ b/tools/analysis/Rakefile
@@ -19,7 +19,8 @@ file 'failing.json' => ['packages.json'] do |task|
 end
 
 file 'packages.json' do
-  sh 'wget', 'http://ci.debian.net/data/status/unstable/amd64/packages.json'
+  ARCH=process.arch
+  sh 'wget',"http://ci.debian.net/data/status/unstable/$ARCH/packages.json";
 end
 
 desc 'clean'
diff --git a/tools/gen-fake-data.sh b/tools/gen-fake-data.sh
index 2057f3c..05272e3 100755
--- a/tools/gen-fake-data.sh
+++ b/tools/gen-fake-data.sh
@@ -2,13 +2,24 @@
 
 set -eu
 
+if [[ -f $(which debci) ];then
+ bindir=$(dirname $(which debci))
+elif [ -f bin/debci ];then
+ bindir=$(pwd)/bin
+elif [ -f ../bin/debci ];then
+ bindir=$(pwd)/../bin
+else
+ echo "Can't find debci binary"
+ exit 1
+fi
+
 ./tools/init-dev.sh
 
-configdir=`./bin/debci config --values-only config_dir`
+configdir=`$bindir/debci config --values-only config_dir`
 
-for suite in $(./bin/debci config --values-only suite_list); do
-  for arch in $(./bin/debci config --values-only arch_list); do
+for suite in $($bindir/debci config --values-only suite_list); do
+  for arch in $($bindir/debci config --values-only arch_list); do
 shuf --head-count=50 config/whitelist \
-  | xargs ./bin/debci enqueue --arch="$arch" --suite="$suite"
+  | xargs $bindir/debci enqueue --arch="$arch" --suite="$suite"
   done
 done
diff --git a/tools/indexer.sh b/tools/indexer.sh
index 00b5a53..3290b0d 100755
--- a/tools/indexer.sh
+++ b/tools/indexer.sh
@@ -6,11 +6,11 @@ incoming=`$(dirname $0)/../bin/debci config --values-only autopkgtest_incoming_b
 
 mkdir -p "$incoming"
 
-./bin/debci migrate
+$(dirname $0)/../bin/debci migrate
 
 exec rerun \
   --no-notify \
   --exit \
   --dir "$incoming" \
   --pattern '**/exitcode' \
-  -- ./bin/debci update
+  -- $(dirname $0)/../bin/debci update
diff --git a/tools/init-dev.sh b/tools/init-dev.sh
index b3f9949..34a3b69 100755
--- a/tools/init-dev.sh
+++ b/tools/init-dev.sh
@@ -2,7 +2,7 @@
 
 set -eu
 
-configdir=`./bin/debci config --values-only config_dir`
+configdir=`$(dirname $0)/../bin/debci confi

Bug#878843: util-linux: fsck on btrfs /home hangs, stalling boot

[Thierry fa...@linux.ibm.com]

On Wed, 18 Oct 2017 08:42:32 -0400 Phil Susi  wrote:
> On 10/18/2017 3:54 AM, Bernhard Schmidt wrote:
> > Accessing /home leads to a blocked process. The reason is that (for
> > numerous years, due to reasons I don't remember) I had
> > x-systemd.automount in my fstab for /home
> 
> That makes sense.  Now I wonder why is fsck trying to open /home?  You
> run it on the block device; it should not know or care that the
> filesystem is normally mounted in /home.
> 
> 
Hello,
As this bug has not been updated for more than a year do we expect any
update or do we consider it is irrelevant ?
Thanks for your update

Bug#884128: libical: don't release with buster

[Thierry fa...@linux.ibm.com]

Hello,
As currently we have (for most of the platforms)

$ apt-cache madison libical2
  libical2 | 2.0.0-4+b2 | http://ftp.fr.debian.org/debian buster/main
amd64 Packages
   libical |2.0.0-4 | http://ftp.fr.debian.org/debian buster/main
Sources

What do we do with that bug ?
Thanks



On Wed, 8 Aug 2018 10:39:14 +0200 Emilio Pozuelo Monfort
 wrote:
> On 08/08/18 09:33, Niels Thykier wrote:
> > Control: tags -1 moreinfo
> > 
> > On Mon, 11 Dec 2017 19:43:59 +0100 Emilio Pozuelo Monfort
> >  wrote:
> >> Source: libical
> >> Version: 2.0.0-1
> >> Severity: serious
> >>
> >> Hi,
> >>
> >> We have src:libical3 now, so libical2 should be dropped before the
> >> freeze. We shouldn't need to release buster with both libical 2 and 3.
> >> Filing this bug so we don't forget about that.
> >>
> >> Emilio
> >>
> >> [...]
> > Hi Emilio,
> > 
> > We are getting "close" to the transition freeze.  If it is still the
> > plan to remove libical from Debian buster, please start filing bugs
> > against the (remaining) reverse dependencies and have them fixed.
> 
> That's basically kdepimlibs, as cyrus-imapd is not in testing and kmymoney is
> already fixed in experimental and just needs an upload to sid.
> 
> kdepimlibs may not be easy though as disabling libical will probably disable
> some libs that may be used by rdeps. Someone needs to look at that. I have 
> just
> opened a bug for it and made it block this one.
> 
> Cheers,
> Emilio
> 
> 

-- 
Thierry Fauck @ fr.ibm.com

Bug#876905: qtwebkit should not be release with buster

[Thierry fa...@linux.ibm.com]

On Tue, 26 Sep 2017 22:15:12 +0300 Adrian Bunk  wrote:
> Source: qtwebkit
> Version: 2.3.4.dfsg-9.1
> Severity: serious
> Tags: buster sid
> 
> qtwebkit should not be release with buster
> (RC bugs are already open against all r-deps).
> 
> 

As version 2.3.4.dfsg-10 is part of buster what do we do with that bug ?
thanks

Bug#909750: applications tries to write to /usr/* directories via libfontconfig1

[Thierry fa...@linux.ibm.com]

On Sun, 11 Nov 2018 12:04:06 +0100 Jakub Wilk  wrote:
> * Laurent Bigonville , 2018-11-11, 11:18:
> >Do you have any .uuid files in these directories?
> 
> IIRC, I didn't have any back then.
> 
> >Can you try to run "fc-cache -s -f -v" (as root) and see if it helps.
> 
> I think I upgraded some font package, which triggered fontconfig, which 
> ran the aforementioned command. Yes, it did help.
> 
> >What file system do you use for /usr/share/fonts/?
> 
> ext4
> 
> >The only occurrence I'm seeing on my system is:
> >
> >openat(AT_FDCWD, "/usr/lib/firefox/fonts/.uuid.TMP-EWjEq0", 
> >O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0600) = -1 EACCES (Permission denied)
> 
> Now it's the only occurrence for me, too.
> 
> -- 
> Jakub Wilk
> 
Hello,

With current packages I don't see any more issues of openat()
EACESS(...) when tracing firefox-bin
Can you confirm and state about that bug
Thanks

Bug#916145: closure-compiler: Not working with recent JS code

[Thierry fa...@linux.ibm.com]

Hello,
Is that bug still valid with current version 20130227+dfsg1-10 ?
thanks



On Mon, 10 Dec 2018 17:42:12 +0100 Roland Gruber 
wrote:
> Package: closure-compiler
> Version: 20130227+dfsg1-9
> Severity: important
> 
> Dear Maintainer,
> 
> the current version is so old that it got incompatible with recent JS code.
> E.g. jQuery 3.3.1 cannot be minified as the tool reports parsing errors.
> 
> Please either update the tool or remove it from the archive. This is now
> 5 years in unmaintained state.
> 
> 
> -- System Information:
> Debian Release: 9.6
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages closure-compiler depends on:
> ii  default-jre-headless [java6-runtime-headless]2:1.8-58
> ii  java-wrappers0.1.28
> ii  libclosure-compiler-java 20130227+dfsg1-9
> ii  openjdk-8-jre-headless [java6-runtime-headless]  8u181-b13-2~deb9u1
> ii  oracle-java8-jdk [java6-runtime-headless]8u77
> 
> closure-compiler recommends no packages.
> 
> closure-compiler suggests no packages.
> 
> -- no debconf information
> 
> 

-- 
Thierry Fauck @ fr.ibm.com

Bug#810985: Patch

[Thierry fa...@linux.ibm.com]

Hello,
As the fix for ppc64el is simple, couldn't it be integrated ... or
definitely no interest ?!
Thanks




On Thu, 21 Sep 2017 15:51:56 +0200 =?UTF-8?B?RnLDqWTDqXJpYw==?= Bonnard
 wrote:
> Hi,
> the message "dlopen of .../pl-tai.so failed with error libplstream.so:
> cannot open shared object file: No such file or directory" is not
> actually linked to the FTBFS as far as I understood : the same error
> message happens on other architecture builds, but the install works.
> The dlopen with RTLD_GLOBAL flag of pl-tai.so just doesn't find the 
> libplstream.so
> in the path as it is. For this message to disappear, one need to set the
> LD_LIBRARY_PATH to the same as YAPLIBDIR.
> 
> On debomatic-powerpc the package built fine, so that bug may also depend on 
> other things.
> On ppc64el, yap is just looping in some mmap/munmap related to allocation 
> code :
> (gdb) bt
> #0  0x3fffb784b768 in munmap () from /lib/powerpc64le-linux-gnu/libc.so.6
> #1  0x20043d6c in ExtendWorkSpace (s=3604480, fixed_allocation=16) at 
> ../C/alloc.c:1143
> #2  0x20044b08 in Yap_ExtendWorkSpaceThroughHole (s=3604480) at 
> ../C/alloc.c:1606
> #3  0x200b21fc in execute_growstack (size0=524288, from_trail=0, 
> in_parser=0, old_trp=0x0, tksp=0x0, vep=0x0) at ../C/grow.c:1493
> #4  0x200b2570 in growstack (size=524288) at ../C/grow.c:1604
> #5  0x200b3374 in Yap_growstack (size=) at 
> ../C/grow.c:1471
> #!/usr/bin/make -f
> #6  0x200ba274 in call_gc (gc_lim=4096, predarity=0, 
> current_env=0x10a33818, nextop=0x101ce7e0) at ../C/heapgc.c:4009
> #7  0x200ba52c in Yap_gc (predarity=, 
> current_env=, nextop=) at ../C/heapgc.c:4035
> #8  0x20024ac0 in Yap_absmi (inp=) at ../C/absmi.c:2957
> #9  0x2008d874 in exec_absmi (top=1) at ../C/exec.c:1007
> #10 0x2008de98 in do_goal (t=268551041, CodeAdr=0x100740e0, arity=0, 
> pt=0x0, top=1) at ../C/exec.c:1074
> #11 0x2009a244 in Yap_RunTopGoal (t=268551041) at ../C/exec.c:1292
> #12 0x2001bdf4 in YAP_RunGoalOnce (t=) at 
> ../C/c_interface.c:2037
> #13 0x20016cdc in do_top_goal (Goal=268551041) at ../console/yap.c:116
> #14 exec_top_level (iap=0x3210, BootMode=) at 
> ../console/yap.c:711
> #15 main (argc=, argv=) at ../console/yap.c:752
> 
> Redhat seemed to have that same issue : 
> https://sourceforge.net/p/yap/mailman/message/33828905/
> and using --enable-use-malloc helped.
> So here is a patch that makes the build use that option for powerpc and 
> ppc64el (it
> should work on ppc64, but this arch is not enabled for yap and I wanted the 
> patch
> to be minimal).
> 
> F.

-- 
Thierry Fauck @ fr.ibm.com