sci-libs:gsl-2.1:20161009-230232.log

sci-libs:gsl-2.1:20161009-230232.log (text/plain), 2.50 KB, created by Toralf Förster on 2016-10-10 07:46:48 UTC

 * Package:    sci-libs/gsl-2.1
 * Repository: gentoo
 * Maintainer: [e-mail]
 * USE:        abi_x86_64 amd64 elibc_glibc kernel_linux userland_GNU
 * FEATURES:   preserve-libs sandbox userpriv usersandbox
[Errno 9] Bad file descriptor:
   /usr/bin/sandbox /usr/lib/portage/python3.4/ebuild.sh unpack
Traceback (most recent call last):
  File "/usr/lib64/python3.4/subprocess.py", line 1421, in _execute_child
    part = _eintr_retry_call(os.read, errpipe_read, 50000)
  File "/usr/lib64/python3.4/subprocess.py", line 491, in _eintr_retry_call
    return func(*args)
OSError: [Errno 9] Bad file descriptor

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib64/python3.4/site-packages/portage/process.py", line 317, in spawn
    unshare_net, unshare_ipc, cgroup)
  File "/usr/lib64/python3.4/site-packages/portage/process.py", line 504, in _exec
    if groups:
  File "/usr/lib64/python3.4/site-packages/portage/proxy/objectproxy.py", line 89, in __bool__
    return bool(object.__getattribute__(self, '_get_target')())
  File "/usr/lib64/python3.4/site-packages/portage/data.py", line 281, in _get_target
    return _get_global(object.__getattribute__(self, '_name'))
  File "/usr/lib64/python3.4/site-packages/portage/data.py", line 212, in _get_global
    stderr=subprocess.STDOUT)
  File "/usr/lib64/python3.4/subprocess.py", line 856, in __init__
    restore_signals, start_new_session)
  File "/usr/lib64/python3.4/subprocess.py", line 1427, in _execute_child
    os.close(errpipe_read)
OSError: [Errno 9] Bad file descriptor
 * The ebuild phase 'unpack' 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.