build.log

dev-python:pypy-bin-7.0.0-r1:20190216-174013.log (text/plain), 12.18 KB, created by Jan Ziak (atomsymbol) on 2019-02-16 18:00:12 UTC

 * Package:    dev-python/pypy-bin-7.0.0-r1
 * Repository: gentoo
 * Maintainer: [e-mail]
 * USE:        abi_x86_64 amd64 elibc_glibc gdbm jit kernel_linux sqlite tk userland_GNU
 * FEATURES:   ccache nostrip preserve-libs sandbox userpriv
>>> Unpacking pypy2.7-v7.0.0-src.tar.bz2 to /var/tmp/portage/dev-python/pypy-bin-7.0.0-r1/work
>>> Unpacking python-gentoo-patches-2.7.15.tar.xz to /var/tmp/portage/dev-python/pypy-bin-7.0.0-r1/work
>>> Unpacking pypy-bin-7.0.0-amd64+bzip2+jit+ncurses.tar.lz to /var/tmp/portage/dev-python/pypy-bin-7.0.0-r1/work
 * Applying 7.0.0-gentoo-path.patch ...
 [ ok ]
 * Applying 1.9-distutils.unixccompiler.UnixCCompiler.runtime_library_dir_option.patch ...
 [ ok ]
 * Applying 5.8.0_all_distutils_cxx.patch ...
 [ ok ]
 * Applying 0011-use_pyxml.patch ...
 [ ok ]
 * PT_PAX marking -m pypy-c with scanelf
 * PT_PAX marking -m libpypy-c.so with scanelf
 * XATTR_PAX marking -me pypy-c with setfattr
 * XATTR_PAX marking -me libpypy-c.so with setfattr
 * Generating caches and CFFI modules ...
[01m[K_gdbm_cffi.c:[m[K In function ‘[01m[K_cffi_d_gdbm_open[m[K’:
[01m[K_gdbm_cffi.c:901:36:[m[K [01;35m[Kwarning: [m[Kpassing argument 5 of ‘[01m[Kgdbm_open[m[K’ from incompatible pointer type [[01;35m[K-Wincompatible-pointer-types[m[K]
   return gdbm_open(x0, x1, x2, x3, [01;35m[Kx4[m[K);
                                    [01;35m[K^~[m[K
In file included from [01m[K_gdbm_cffi.c:517:0[m[K:
[01m[K/usr/include/gdbm.h:114:18:[m[K [01;36m[Knote: [m[Kexpected ‘[01m[Kvoid (*)(const char *)[m[K’ but argument is of type ‘[01m[Kvoid (*)(void)[m[K’
 extern GDBM_FILE [01;36m[Kgdbm_open[m[K (const char *, int, int, int,
                  [01;36m[K^~~~~~~~~[m[K
[01m[K_gdbm_cffi.c:[m[K In function ‘[01m[K_cffi_d_gdbm_strerror[m[K’:
[01m[K_gdbm_cffi.c:1062:10:[m[K [01;35m[Kwarning: [m[Kreturn discards ‘[01m[Kconst[m[K’ qualifier from pointer target type [[01;35m[K-Wdiscarded-qualifiers[m[K]
   return [01;35m[Kgdbm_strerror(x0)[m[K;
          [01;35m[K^~~~~~~~~~~~~~~~~[m[K
 * Installing PyPy ...
 * PT_PAX marking -m /var/tmp/portage/dev-python/pypy-bin-7.0.0-r1/image/usr/lib/pypy2.7/pypy-c with scanelf
 * PT_PAX marking -m /var/tmp/portage/dev-python/pypy-bin-7.0.0-r1/image/usr/lib/pypy2.7/libpypy-c.so with scanelf
 * XATTR_PAX marking -me /var/tmp/portage/dev-python/pypy-bin-7.0.0-r1/image/usr/lib/pypy2.7/pypy-c with setfattr
 * XATTR_PAX marking -me /var/tmp/portage/dev-python/pypy-bin-7.0.0-r1/image/usr/lib/pypy2.7/libpypy-c.so with setfattr
!!! doins: Unknown install options: -p, ['-p']

!!! doins: Continue with falling back to `install` command execution, which can be slower.

 * Byte-compiling Python standard library...
Compiling /var/tmp/portage/dev-python/pypy-bin-7.0.0-r1/image/usr/lib/pypy2.7/lib-python/2.7/lib2to3/tests/data/py3_test_grammar.py ...
  File "/usr/lib/pypy2.7/lib-python/2.7/lib2to3/tests/data/py3_test_grammar.py", line 130
    x = ...
        ^
SyntaxError: invalid syntax

Compiling /var/tmp/portage/dev-python/pypy-bin-7.0.0-r1/image/usr/lib/pypy2.7/lib-python/2.7/test/bad_coding.py ...
  File "/usr/lib/pypy2.7/lib-python/2.7/test/bad_coding.py", line 0
SyntaxError: Unknown encoding: uft-8

Compiling /var/tmp/portage/dev-python/pypy-bin-7.0.0-r1/image/usr/lib/pypy2.7/lib-python/2.7/test/bad_coding2.py ...
  File "/usr/lib/pypy2.7/lib-python/2.7/test/bad_coding2.py", line 0
SyntaxError: UTF-8 BOM with utf8 coding cookie

Compiling /var/tmp/portage/dev-python/pypy-bin-7.0.0-r1/image/usr/lib/pypy2.7/lib-python/2.7/test/bad_coding3.py ...
  File "/usr/lib/pypy2.7/lib-python/2.7/test/bad_coding3.py", line 0
SyntaxError: codec did not return a unicode object

Compiling /var/tmp/portage/dev-python/pypy-bin-7.0.0-r1/image/usr/lib/pypy2.7/lib-python/2.7/test/badsyntax_future3.py ...
  File "/usr/lib/pypy2.7/lib-python/2.7/test/badsyntax_future3.py", line 3
SyntaxError: future feature rested_snopes is not defined

Compiling /var/tmp/portage/dev-python/pypy-bin-7.0.0-r1/image/usr/lib/pypy2.7/lib-python/2.7/test/badsyntax_future4.py ...
  File "/usr/lib/pypy2.7/lib-python/2.7/test/badsyntax_future4.py", line 3
SyntaxError: __future__ statements must appear at beginning of file

Compiling /var/tmp/portage/dev-python/pypy-bin-7.0.0-r1/image/usr/lib/pypy2.7/lib-python/2.7/test/badsyntax_future5.py ...
  File "/usr/lib/pypy2.7/lib-python/2.7/test/badsyntax_future5.py", line 4
SyntaxError: __future__ statements must appear at beginning of file

Compiling /var/tmp/portage/dev-python/pypy-bin-7.0.0-r1/image/usr/lib/pypy2.7/lib-python/2.7/test/badsyntax_future6.py ...
  File "/usr/lib/pypy2.7/lib-python/2.7/test/badsyntax_future6.py", line 3
SyntaxError: __future__ statements must appear at beginning of file

Compiling /var/tmp/portage/dev-python/pypy-bin-7.0.0-r1/image/usr/lib/pypy2.7/lib-python/2.7/test/badsyntax_future7.py ...
  File "/usr/lib/pypy2.7/lib-python/2.7/test/badsyntax_future7.py", line 3
SyntaxError: __future__ statements must appear at beginning of file

Compiling /var/tmp/portage/dev-python/pypy-bin-7.0.0-r1/image/usr/lib/pypy2.7/lib-python/2.7/test/badsyntax_future8.py ...
  File "/usr/lib/pypy2.7/lib-python/2.7/test/badsyntax_future8.py", line 3
SyntaxError: * not valid in __future__ imports

Compiling /var/tmp/portage/dev-python/pypy-bin-7.0.0-r1/image/usr/lib/pypy2.7/lib-python/2.7/test/badsyntax_future9.py ...
  File "/usr/lib/pypy2.7/lib-python/2.7/test/badsyntax_future9.py", line 3
SyntaxError: not a chance

Compiling /var/tmp/portage/dev-python/pypy-bin-7.0.0-r1/image/usr/lib/pypy2.7/lib-python/2.7/test/badsyntax_nocaret.py ...
  File "/usr/lib/pypy2.7/lib-python/2.7/test/badsyntax_nocaret.py", line 2
SyntaxError: can't assign to list comprehension

 * Final size of build directory: 193200 KiB (188.6 MiB)
 * Final size of installed tree:  144012 KiB (140.6 MiB)
 * The ebuild phase 'postrm' has exited unexpectedly. This type of behavior
 * is known to be triggered by things such as failed variable assignments
 * (bug #190128) or bad substitution errors (bug #200313). Normally, before
 * exiting, bash should have displayed an error message above. If bash did
 * not produce an error message above, it's possible that the ebuild has
 * called `exit` when it should have called `die` instead. This behavior
 * may also be triggered by a corrupt bash binary or a hardware problem
 * such as memory or cpu malfunction. If the problem is not reproducible or
 * it appears to occur randomly, then it is likely to be triggered by a
 * hardware problem. If you suspect a hardware problem then you should try
 * some basic hardware diagnostics such as memtest. Please do not report
 * this as a bug unless it is consistently reproducible and you are sure
 * that your bash binary and hardware are functioning properly.
 * The ebuild phase 'die_hooks' has exited unexpectedly. This type of
 * behavior is known to be triggered by things such as failed variable
 * assignments (bug #190128) or bad substitution errors (bug #200313).
 * Normally, before exiting, bash should have displayed an error message
 * above. If bash did not produce an error message above, it's possible
 * that the ebuild has called `exit` when it should have called `die`
 * instead. This behavior may also be triggered by a corrupt bash binary or
 * a hardware problem such as memory or cpu malfunction. If the problem is
 * not reproducible or it appears to occur randomly, then it is likely to
 * be triggered by a hardware problem. If you suspect a hardware problem
 * then you should try some basic hardware diagnostics such as memtest.
 * Please do not report this as a bug unless it is consistently
 * reproducible and you are sure that your bash binary and hardware are
 * functioning properly.
/var/tmp/portage/._portage_reinstall_.rUWC_7/bin/phase-functions.sh: line 149: /usr/lib64/pypy/pypy-c: No such file or directory
 * ERROR: dev-python/pypy-bin-7.0.0-r1::gentoo failed (postinst phase):
 *   filter-bash-environment.py failed
 * 
 * Call stack:
 *            ebuild.sh, line  792:  Called __ebuild_main 'postinst'
 *   phase-functions.sh, line 1038:  Called __filter_readonly_variables '--filter-path' '--filter-sandbox' '--allow-extra-vars'
 *   phase-functions.sh, line  149:  Called die
 * The specific snippet of code:
 *   	"${PORTAGE_PYTHON:-/usr/bin/python}" "${PORTAGE_BIN_PATH}"/filter-bash-environment.py "${filtered_vars}" || die "filter-bash-environment.py failed"
 * 
 * If you need support, post the output of `emerge --info '=dev-python/pypy-bin-7.0.0-r1::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=dev-python/pypy-bin-7.0.0-r1::gentoo'`.
 * The complete build log is located at '/var/log/portage/dev-python:pypy-bin-7.0.0-r1:20190216-174013.log.gz'.
 * For convenience, a symlink to the build log is located at '/var/tmp/portage/dev-python/pypy-bin-7.0.0-r1/temp/build.log.gz'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-python/pypy-bin-7.0.0-r1/temp/environment'.
 * Working directory: '/var/tmp/portage/._portage_reinstall_.rUWC_7/lib'
 * S: '/var/tmp/portage/dev-python/pypy-bin-7.0.0-r1/work/pypy2.7-v7.0.0-src'
/var/tmp/portage/._portage_reinstall_.rUWC_7/bin/ebuild-ipc: line 7: /usr/lib64/pypy/pypy-c: No such file or directory
 * The ebuild phase 'postinst' has exited unexpectedly. This type of
 * behavior is known to be triggered by things such as failed variable
 * assignments (bug #190128) or bad substitution errors (bug #200313).
 * Normally, before exiting, bash should have displayed an error message
 * above. If bash did not produce an error message above, it's possible
 * that the ebuild has called `exit` when it should have called `die`
 * instead. This behavior may also be triggered by a corrupt bash binary or
 * a hardware problem such as memory or cpu malfunction. If the problem is
 * not reproducible or it appears to occur randomly, then it is likely to
 * be triggered by a hardware problem. If you suspect a hardware problem
 * then you should try some basic hardware diagnostics such as memtest.
 * Please do not report this as a bug unless it is consistently
 * reproducible and you are sure that your bash binary and hardware are
 * functioning properly.
/var/tmp/portage/._portage_reinstall_.rUWC_7/bin/ebuild-ipc: line 7: /usr/lib64/pypy/pypy-c: No such file or directory
 * The ebuild phase 'die_hooks' has exited unexpectedly. This type of
 * behavior is known to be triggered by things such as failed variable
 * assignments (bug #190128) or bad substitution errors (bug #200313).
 * Normally, before exiting, bash should have displayed an error message
 * above. If bash did not produce an error message above, it's possible
 * that the ebuild has called `exit` when it should have called `die`
 * instead. This behavior may also be triggered by a corrupt bash binary or
 * a hardware problem such as memory or cpu malfunction. If the problem is
 * not reproducible or it appears to occur randomly, then it is likely to
 * be triggered by a hardware problem. If you suspect a hardware problem
 * then you should try some basic hardware diagnostics such as memtest.
 * Please do not report this as a bug unless it is consistently
 * reproducible and you are sure that your bash binary and hardware are
 * functioning properly.
 * FAILED postinst: 1
/var/tmp/portage/._portage_reinstall_.rUWC_7/bin/ebuild-ipc: line 7: /usr/lib64/pypy/pypy-c: No such file or directory
 * The ebuild phase 'other' has exited unexpectedly. This type of behavior
 * is known to be triggered by things such as failed variable assignments
 * (bug #190128) or bad substitution errors (bug #200313). Normally, before
 * exiting, bash should have displayed an error message above. If bash did
 * not produce an error message above, it's possible that the ebuild has
 * called `exit` when it should have called `die` instead. This behavior
 * may also be triggered by a corrupt bash binary or a hardware problem
 * such as memory or cpu malfunction. If the problem is not reproducible or
 * it appears to occur randomly, then it is likely to be triggered by a
 * hardware problem. If you suspect a hardware problem then you should try
 * some basic hardware diagnostics such as memtest. Please do not report
 * this as a bug unless it is consistently reproducible and you are sure
 * that your bash binary and hardware are functioning properly.