Bug#892426: pocl: FTBFS on most non-x86 architectures: 12-16% of tests pass
/undominated_variable_from_conditional_barrier_handling_LOOPS (Failed) 62/63 - regression/assigning_a_loop_iterator_variable_to_a_private_makes_it_local_LOOPS (Failed) 63/64 - regression/assigning_a_loop_iterator_variable_to_a_private_makes_it_local_2_LOOPS (Failed) 64/65 - regression/test_program_from_binary_with_local_1_1_1_LOOPS (Failed) 65/66 - regression/setting_a_buffer_argument_to_NULL_causes_a_segfault (Failed) 66/67 - regression/clSetKernelArg_overwriting_the_previous_kernel's_args (Failed) 68/69 - regression/case_with_multiple_variable_length_loops_and_a_barrier_in_one (Failed) 69/70 - regression/autolocals_in_constexprs (Failed) 71/72 - regression/vector_kernel_arguments (Failed) 75/76 - runtime/clCreateProgramWithBinary (Failed) 76/77 - runtime/clBuildProgram (Failed) 77/78 - runtime/test_kernel_cache_includes (Failed) 78/79 - runtime/clFinish (Failed) 85/86 - runtime/clSetEventCallback (Failed) 87/88 - runtime/clCreateKernelsInProgram (Failed) 88/89 - runtime/clCreateSubDevices (Failed) 90/91 - runtime/test_enqueue_kernel_from_binary (Failed) 93/94 - workgroup/unconditional_barriers_REPL (Failed) 94/95 - workgroup/unbarriered_for_loops_REPL (Failed) 95/96 - workgroup/barriered_for_loops_REPL (Failed) 96/97 - workgroup/conditional_barrier_REPL (Failed) 97/98 - workgroup/b_loop_with_none_of_the_WIs_reaching_the_barrier_REPL (Failed) 98/99 - workgroup/forcing_horizontal_parallelization_to_some_outer_loops_REPL (Failed) 99/100 - workgroup/loop_with_two_paths_to_the_latch_REPL (Failed) 100/101 - workgroup/b_loop_with_two_latches_REPL (Failed) 101/102 - workgroup/workgroup_sizes_work_items_get_wrong_ids_REPL (Failed) 102/103 - workgroup/different_implicit_barrier_injection_scenarios_LOOPS (Failed) 103/104 - workgroup/unconditional_barriers_LOOPS (Failed) 104/105 - workgroup/unbarriered_for_loops_LOOPS (Failed) 105/106 - workgroup/barriered_for_loops_LOOPS (Failed) 106/107 - workgroup/conditional_barrier_LOOPS (Failed) 107/108 - workgroup/b_loop_with_none_of_the_WIs_reaching_the_barrier_LOOPS (Failed) 108/109 - workgroup/forcing_horizontal_parallelization_to_some_outer_loops_LOOPS (Failed) 109/110 - workgroup/loop_with_two_paths_to_the_latch_LOOPS (Failed) 110/111 - workgroup/b_loop_with_two_latches_LOOPS (Failed) 111/112 - workgroup/workgroup_sizes_work_items_get_wrong_ids_LOOPS (Failed) 112/113 - workgroup/issue_548_convergent_propagation_LOOPS (Failed) 117/118 - examples/scalarwave (Child aborted) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#892239: ki18n: please version doxygen B-D per upstream
Source: ki18n Version: 5.42.0-3 Severity: important Justification: fails to build from source (but built successfully in the past) User: debian-powerpc@lists.debian.org Usertags: powerpcspe Builds of ki18n for powerpcspe (admittedly not a release architecture) have been failing lately: CMake Error at /usr/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find Doxygen: Found unsuitable version "1.8.12", but required is at least "1.8.13" (found /usr/bin/doxygen) (Doxygen is out of date on this architecture, apparently due to Ruby stack issues.) Could you please version the build dependency on doxygen to (>= 1.8.13~) to match upstream's requirements? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#892236: ruby-grpc: FTBFS on powerpc (big-endian): Unable to add defs to DescriptorPool
Source: ruby-grpc Version: 1.3.2+debian-4 Severity: normal Tags: upstream User: debian-powerpc@lists.debian.org Usertags: powerpc Builds of ruby-grpc for powerpc (the only big-endian architecture on which its build dependencies are all available, though admittedly not a release architecture) have been failing, as detailed in [1]: An error occurred while loading /«BUILDDIR»/ruby-grpc-1.3.2+debian/src/ruby/spec/pb/health/checker_spec.rb. Failure/Error: Google::Protobuf::DescriptorPool.generated_pool.build do add_message "grpc.health.v1.HealthCheckRequest" do optional :service, :string, 1 end add_message "grpc.health.v1.HealthCheckResponse" do optional :status, :enum, 1, "grpc.health.v1.HealthCheckResponse.ServingStatus" end add_enum "grpc.health.v1.HealthCheckResponse.ServingStatus" do value :UNKNOWN, 0 value :SERVING, 1 RuntimeError: Unable to add defs to DescriptorPool: couldn't resolve name '.grpc.health.v1.HealthCheckResponse.ServingStatus' in message 'grpc.health.v1.HealthCheckResponse' Could you please take a look? Thanks! [1] https://buildd.debian.org/status/fetch.php?pkg=ruby-grpc=powerpc=1.3.2%2Bdebian-4=1519229357=0 -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#891684: castle-game-engine: FTBFS (big-endian): lookup and hashing tests fail
Source: castle-game-engine Version: 6.4+dfsg1-2 Severity: important Tags: upstream Justification: fails to build from source User: debian-powerpc@lists.debian.org Usertags: powerpc ppc64 Builds of castle-game-engine for big-endian architectures that get as far as running the test suite (so not mips at present, per #891683) have been failing with errors along the lines of Number of run tests: 227 Number of errors:2 Number of failures: 1 List of errors: Error: Message: TTestX3DNodes.TestRootNodeMeta: Dictionary key does not exist Exception class: EListError Exception message: Dictionary key does not exist at $103FE5D0 line 372 of ./src/base/castlegenericlists.pas Error: Message: TTestGame.TestGameData: Resource type "WalkAttack" not found, mentioned in file "file:///«BUILDDIR»/castle-game-engine-6.4+dfsg1/tests/data/game/resource.xml" Exception class: Exception Exception message: Resource type "WalkAttack" not found, mentioned in file "file:///«BUILDDIR»/castle-game-engine-6.4+dfsg1/tests/data/game/resource.xml" at $10773D20 line 372 of ./src/base/castlegenericlists.pas List of failures: Failure: Message: TTestCastleRandom.TestHash: expected: <3762729884> but was: <3168055629> Exception class: EAssertionFailedError Exception message: expected: <3762729884> but was: <3168055629> at $100BFA34 TTESTCASTLERANDOM__TESTHASH, line 42 of tests/testcastlerandom.pas There are four additional failures on m68k; I'll report them separately. Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#891606: kwayland: please version doxygen B-D per upstream
Source: kwayland Version: 4:5.42.0-2 Severity: normal User: debian-powerpc@lists.debian.org Usertags: powerpcspe Builds of kwayland for powerpcspe (admittedly not a release architecture) have been failing lately: CMake Error at /usr/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find Doxygen: Found unsuitable version "1.8.12", but required is at least "1.8.13" (found /usr/bin/doxygen) (Doxygen is out of date on this architecture, apparently due to Ruby toolchain issues.) Could you please version the build dependency on doxygen to (>= 1.8.13~) to match upstream's requirements? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#891605: kconfig: please version doxygen B-D per upstream
Source: kconfig Version: 5.42.0-2 Severity: normal User: debian-powerpc@lists.debian.org Usertags: powerpcspe Builds of kconfig for powerpcspe (admittedly not a release architecture) have been failing lately: CMake Error at /usr/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find Doxygen: Found unsuitable version "1.8.12", but required is at least "1.8.13" (found /usr/bin/doxygen) (Doxygen is out of date on this architecture, apparently due to Ruby toolchain issues.) Could you please version the build dependency on doxygen to (>= 1.8.13~) to match upstream's requirements? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#890570: aseba: FTBFS on powerpc/ppc64: did not find "thymio-II"
Source: aseba Version: 1.6.0-2 Severity: normal Tags: upstream User: debian-powerpc@lists.debian.org Usertags: powerpc ppc64 Builds of aseba on powerpc [1] and ppc64 [2] (admittedly not release architectures) have been failing: 172/172 Test #172: robot-simulator-thymio .***Failed0.02 sec * Discovering robot nodes manager did not find "thymio-II" 99% tests passed, 1 tests failed out of 172 Total Test time (real) = 49.29 sec The following tests FAILED: 172 - robot-simulator-thymio (Failed) Errors while running CTest Makefile:87: recipe for target 'test' failed Could you please take a look? Thanks! [1] https://buildd.debian.org/status/fetch.php?pkg=aseba=powerpc=1.6.0-2=1518363893=0 [2] https://buildd.debian.org/status/fetch.php?pkg=aseba=ppc64=1.6.0-2=1518364648=0 -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#889860: python3-numpy: TypeError initializing resolution on powerpcspe
Package: python3-numpy Version: 1:1.13.3-2 Severity: normal Tags: upstream User: debian-powerpc Usertags: powerpcspe Control: affects -1 src:chemps2 As observed in [1], numpy encounters two warnings and a type error when initializing itself on powerpcspe: /usr/lib/python3/dist-packages/numpy/core/getlimits.py:82: RuntimeWarning: overflow encountered in power self.resolution = float_to_float(float_conv(10) ** (-self.precision)) /usr/lib/python3/dist-packages/numpy/core/getlimits.py:82: RuntimeWarning: invalid value encountered in power self.resolution = float_to_float(float_conv(10) ** (-self.precision)) Traceback (most recent call last): File "setup.py", line 22, in import numpy as np File "/usr/lib/python3/dist-packages/numpy/__init__.py", line 142, in from . import add_newdocs File "/usr/lib/python3/dist-packages/numpy/add_newdocs.py", line 13, in from numpy.lib import add_newdoc File "/usr/lib/python3/dist-packages/numpy/lib/__init__.py", line 8, in from .type_check import * File "/usr/lib/python3/dist-packages/numpy/lib/type_check.py", line 11, in import numpy.core.numeric as _nx File "/usr/lib/python3/dist-packages/numpy/core/__init__.py", line 51, in from . import getlimits File "/usr/lib/python3/dist-packages/numpy/core/getlimits.py", line 226, in tiny=exp2(_ld(-1022))) File "/usr/lib/python3/dist-packages/numpy/core/getlimits.py", line 82, in __init__ self.resolution = float_to_float(float_conv(10) ** (-self.precision)) TypeError: unsupported operand type(s) for ** or pow(): 'numpy.float128' and 'int' Could you please take a look? Thanks! [1] https://buildd.debian.org/status/fetch.php?pkg=chemps2=powerpcspe=1.8.5-1=1517806729=0 -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#888638: firefox: FTBFS on powerpc and ppc64: Error updating ICU data file
Source: firefox
Version: 58.0-1
Severity: normal
Tags: upstream
User: debian-powerpc@lists.debian.org
Usertags: powerpc ppc64
Builds of firefox for powerpc and ppc64 (the only big-endian
architectures rustc supports at present, and admittedly not release
architectures) have been failing lately. As of 58.0-1, the
(immediate) errors take the form
cd build-browser && MOZCONFIG=mozconfig.icu ../mach python
../intl/icu_sources_data.py "/«PKGBUILDDIR»"
New python executable in
/«PKGBUILDDIR»/build-browser/_virtualenv/bin/python2.7
Also creating executable in
/«PKGBUILDDIR»/build-browser/_virtualenv/bin/python
Installing setuptools, pip, wheel...done.
WARNING: Python.h not found. Install Python development headers.
Error processing command. Ignoring because optional.
(optional:setup.py:third_party/python/psutil:build_ext:--inplace)
Error processing command. Ignoring because optional.
(optional:packages.txt:comm/build/virtualenv_packages.txt)
Error running "make" in directory /tmp/icu-obj-aDwfA5
See output in /tmp/icu-make84ZXyL
Error updating ICU data file
Updating ICU sources lists...
Running ICU configure...
Running ICU make...
debian/rules:205: recipe for target 'stamps/configure-browser' failed
make[1]: *** [stamps/configure-browser] Error 1
When I tried to reproduce these errors on porter boxes for both
architectures to see what they actually were, I ran into *different*
errors:
cd build-browser && MOZCONFIG=mozconfig.icu ../mach python
../intl/icu_sources_data.py "/home/ucko/firefox"
Traceback (most recent call last):
File "../mach", line 86, in
main(sys.argv[1:])
File "../mach", line 78, in main
mach = get_mach()
File "../mach", line 68, in get_mach
mach = check_and_get_mach(dir_path)
File "../mach", line 42, in check_and_get_mach
return load_mach(dir_path, mach_path)
File "../mach", line 30, in load_mach
return mach_bootstrap.bootstrap(dir_path)
File "/home/ucko/firefox/build/mach_bootstrap.py", line 335, in bootstrap
driver.load_commands_from_file(os.path.join(mozilla_dir, path))
File "/home/ucko/firefox/python/mach/mach/main.py", line 267, in
load_commands_from_file
imp.load_source(module_name, path)
File "/home/ucko/firefox/build/valgrind/mach_commands.py", line 16, in
from mozbuild.base import (
File "/home/ucko/firefox/build/mach_bootstrap.py", line 364, in __call__
module = self._original_import(name, globals, locals, fromlist, level)
File "/home/ucko/firefox/python/mozbuild/mozbuild/base.py", line 16, in
from mach.mixin.process import ProcessExecutionMixin
File "/home/ucko/firefox/build/mach_bootstrap.py", line 364, in __call__
module = self._original_import(name, globals, locals, fromlist, level)
File "/home/ucko/firefox/python/mach/mach/mixin/process.py", line 29, in
raise Exception('Could not detect environment shell!')
Exception: Could not detect environment shell!
debian/rules:205: recipe for target 'stamps/configure-browser' failed
Due to this discrepancy, and the lack of available details for the
autobuilders' failures, I have *not* reported anything upstream here.
Could you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#888635: firefox: FTBFS on ppc64el: jit unexpected alignment requirements
Source: firefox Version: 58.0-1 Severity: serious Tags: patch upstream Justification: fails to build from source (but built successfully in the past) User: debian-powerpc@lists.debian.org Usertags: ppc64el Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1425413 Builds of firefox for ppc64el have been failing lately. As of 58.0-1, the (immediate) problem is /<>/js/src/jit/Linker.cpp:27:5: error: static assertion failed: Unexpected alignment requirements static_assert(CodeAlignment >= ExecutableAllocatorAlignment, This appears to be the same problem as in https://bugzilla.mozilla.org/show_bug.cgi?id=1425413, reportedly fixed upstream with a one-line patch: https://hg.mozilla.org/integration/mozilla-inbound/rev/34839f53008f Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#887679: kcoreaddons: please version doxygen B-D per CMake check
Source: kcoreaddons Version: 5.37.0-3 Severity: important Justification: fails to build from source (but built successfully in the past) User: debian-powerpc@lists.debian.org Usertags: powerpcspe Builds of kcoreaddons for powerpcspe (admittedly not a release architecture) have been failing lately: CMake Error at /usr/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find Doxygen: Found unsuitable version "1.8.12", but required is at least "1.8.13" (found /usr/bin/doxygen) Please version its build dependency on doxygen accordingly. (FWIW, doxygen's own build dependencies have been uninstallable on powerpcspe for a while due to issues with the Ruby stack.) Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: Bug#886973: kronosnet: FTBFS on ppc64: knet_handle_new not found in binary lib
Ferenc Wágner <wf...@niif.hu> writes: > The test looks for the exported API function names in the text (T) > section, but the ppc64 nm reports them in the data (D) section: > > $ nm -B -D libknet.so.1.0.0 > A LIBKNET > [...] > 0003ec40 D knet_handle_new > [...] > > Is this a known ppc64 peculiarity or a binutils bug? Good question. Porters? -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#886973: kronosnet: FTBFS on ppc64: knet_handle_new not found in binary lib
Source: kronosnet Version: 1.0-1 Severity: important Tags: upstream Justification: fails to build from source User: debian-powerpc@lists.debian.org Usertags: ppc64 The build of kronosnet for ppc64 (admittedly not a release architecture) failed: ../../libknet/tests/api-test-coverage ../.. ../.. Checking for exported symbols NOT available in header file Checking for symbols in header file NOT exported by binary lib Symbol knet_handle_new not found in binary lib Makefile:2615: recipe for target 'check-api-test-coverage' failed make[6]: *** [check-api-test-coverage] Error 1 The build otherwise went well; in particular, the functionality tests all successfully built and ran. Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#886133: ndpi: FTBFS on mips, s390x, powerpc, and ppc64: tests time out
Source: ndpi Version: 2.2-1 Severity: serious Tags: upstream Justification: fails to build from source (but built successfully in the past) User: debian-m...@lists.debian.org Usertags: mips Builds of ndpi for mips, s390x, and the non-release architectures powerpc and ppc64 all failed because running the test suite hit the autobuilders' inactivity timeouts. These timeouts are generous enough (600 minutes on ppc64, 150 minutes on the other three architectures) that hitting them generally indicates that something managed to hang or spin indefinitely. However, I see that the hppa build ran for a long time before terminating on its own (albeit with test suite errors), so you may simply need to add progress indicators for the sake of slow architectures. (These are inactivity timeouts, so any output to stdout or stderr resets them.) Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#885245: linux: FTBFS on powerpcspe: sstep.c: ptesync unrecognized
Source: linux
Version: 4.14.7-1
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-powerpc@lists.debian.org
Usertags: powerpcspe
Builds of linux for powerpcspe (admittedly not a release architecture)
have been failing lately:
{standard input}: Assembler messages:
{standard input}:5854: Error: unrecognized opcode: `ptesync'
/<>/scripts/Makefile.build:319: recipe for target
'arch/powerpc/lib/sstep.o' failed
make[6]: *** [arch/powerpc/lib/sstep.o] Error 1
Could you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: mpich FTBFS on sh4: MPIUI_Thread TLS definition mismatches tbss
Drew Parsons <dpars...@debian.org> writes: > The link error suggests 2 different versions of MPIUI_Thread are used. > But I can only see a definition in src/util/thread/mpiu_thread.c. > src/mpi/comm does not refer to it, and comm_rank.c does not use any > MPIU object. So the error message doesn't make sense to me. comm_rank's reference to MPIUI_Thread is also present on at least amd64, and presumably due to some macro that (directly or indirectly) calls MPIU_THREADPRIV_FIELD. However, it's not clear why multithreaded build settings would be in effect for mpiu_thread but not also comm_rank. (It looks like MPIUI_Thread's thread-locality is conditional on MPICH_IS_THREADED, which mpichconf.h defines centrally.) I don't have time to dig deeper, but hope that brief analysis helps. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
