On Monday, 6 November 2023 16:16:50 GMT Alan McKinnon wrote: > Hi, > > New install here, recent .isos: > install-amd64-minimal-20230806T163139Z.iso > stage3-amd64-systemd-20230806T163139Z.tar.xz > > Following the handbook, keyworded ~amd64, synced, no issues at all until > the emerge -avuND @world step, making the depgraph goes fine, offers 162 > ebuilds to build. These first 4 build OK: sys-kernel/linux-headers-6.6 > sys-devel/gnuconfig-20230731 > sys-libs/ncurses-6.4_p20230401 > sys-apps/baselayout-2.14 > > app-crypt/libmd-1.1.0 then fails with this: > > ================= > > >>> Emerging (5 of 158) app-crypt/libmd-1.1.0::gentoo > > /usr/bin/env: ‘bash’: No such file or directory > * The ebuild phase 'die_hooks' has been aborted since PORTAGE_BUILDDIR > * does not exist: '/var/tmp/portage/app-crypt/libmd-1.1.0'
Does it exist and does it have the right permissions?
e.g.:
~ $ stat /var/tmp/portage
File: /var/tmp/portage
Size: 40 Blocks: 0 IO Block: 4096 directory
Device: 0,47 Inode: 1 Links: 2
Access: (0775/drwxrwxr-x) Uid: ( 250/ portage) Gid: ( 250/ portage)
Access: 2023-11-06 08:28:27.627998525 +0000
Modify: 2023-11-06 08:28:27.627998525 +0000
Change: 2023-11-06 08:28:27.627998525 +0000
Birth: 2023-11-06 08:28:27.627998525 +0000
> >>> Failed to emerge app-crypt/libmd-1.1.0
>
> ......
> [ERROR] Task was destroyed but it is pending!
> task: <Task pending name='Task-541' coro=<ForkProcess._proc_join() running
> at
> /usr/lib/python3.11/site-packages/portage/util/_async/ForkProcess.py:224>
> wait_for=<Future pending cb=[Task.task_wakeup()]>
> cb=[_EbuildFetcherProcess._proc_join_done(<Process
> name...code=-SIGTERM>)()]>
> [ERROR] Task was destroyed but it is pending!
> task: <Task pending name='Task-545' coro=<ForkProcess._main() running at
> /usr/lib/python3.11/site-packages/portage/util/_async/ForkProcess.py:134>
> wait_for=<Future pending
> cb=[AsynchronousTask.async_wait.<locals>.<lambda>() at
> /usr/lib/python3.11/site-packages/_emerge/AsynchronousTask.py:49,
> Task.task_wakeup()]> cb=[SpawnProcess._main_exit()]>
> [ERROR] Task was destroyed but it is pending!
> task: <Task pending name='Task-544' coro=<PipeLogger._io_loop() running at
> /usr/lib/python3.11/site-packages/portage/util/_async/PipeLogger.py:98>
> wait_for=<Future pending cb=[Task.task_wakeup()]>
> cb=[PipeLogger._io_loop_done()]>
> [ERROR] Task was destroyed but it is pending!
> task: <Task pending name='Task-543' coro=<BuildLogger._main() running at
> /usr/lib/python3.11/site-packages/portage/util/_async/BuildLogger.py:101>
> wait_for=<Future pending
> cb=[AsynchronousTask.async_wait.<locals>.<lambda>() at
> /usr/lib/python3.11/site-packages/_emerge/AsynchronousTask.py:49,
> Task.task_wakeup()]> cb=[BuildLogger._main_exit()]>
> [ERROR] Task was destroyed but it is pending!
> task: <Task pending name='Task-542' coro=<PipeLogger._io_loop() running at
> /usr/lib/python3.11/site-packages/portage/util/_async/PipeLogger.py:98>
> wait_for=<Future pending cb=[Task.task_wakeup()]>
> cb=[PipeLogger._io_loop_done()]>
> ================
>
> Ok that's weird, never seen baselayout produce that.
>
> At this point I see the host can't tab complete ls, mount ... export more
> stuff in PATH fixes that.
Upon the baselayout update did you run (for good measure):
env-update && source /etc/profile
You shouldn't really need to add directories in your PATH manually.
> Now every emerge I attempt does this:
>
> =====================
>
> >>> Running pre-merge checks for dev-libs/gmp-6.3.0
>
> /usr/bin/env: ‘bash’: No such file or directory
> /usr/bin/env: ‘bash’: 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.
> /usr/bin/env: ‘bash’: No such file or directory
> * The ebuild phase 'pretend' 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.
> /usr/bin/env: ‘bash’: 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 to emerge dev-libs/gmp-6.3.0, Log file:
> >>> '/var/log/portage/dev-libs:gmp-6.3.0:20231106-153245.log'
>
> ===================
>
>
> Here is make.conf:
> ===================
> COMMON_FLAGS="-march=native -O2 -pipe"
> CFLAGS="${COMMON_FLAGS}"
> CXXFLAGS="${COMMON_FLAGS}"
> FCFLAGS="${COMMON_FLAGS}"
> FFLAGS="${COMMON_FLAGS}"
>
> # NOTE: This stage was built with the bindist Use flag enabled
>
> # This sets the language of build output to English.
> # Please keep this setting intact when reporting bugs.
> LC_MESSAGES=C.utf8
>
> EMERGE_DEFAULT_OPTS="--backtrack=50"
>
> # Local changes here
> #MAKEOPTS="-j8"
>
> GENTOO_MIRRORS="https://gentoo.osuosl.org/ \
> http://gentoo.osuosl.org/";
>
> ACCEPT_KEYWORDS="~amd64"
> ACCEPT_LICENSE="-* @FREE @BINARY-REDISTRIBUTABLE"
> FEATURES="userfetch"
> GRUB_PLATFORMS="efi-64"
> PORT_LOGDIR="/var/log/portage"
>
> #USE="bash-completion blas ffmpeg fontconfig git graphicsmagick graphviz
> gzip
> # inotify lame lapack libcaca lm-sensors lua lz4 lzma lzo magic matroska
> # modules mplayer mtp musicbrainz offensive rar rdp slang smp snmp szip
> # vdpau vim-syntax webkit xcomposite zip
> # -cdrom -gtk -sdl -semantic-desktop"
>
> VIDEO_CARDS="intel"
> ==============
>
>
> And so, in the words of the wise man, WTF?
I'm guessing the baselayout update changed things around. See if the above
sorts things out for you.
signature.asc
Description: This is a digitally signed message part.
