While bootstrapping Gentoo Prefix (over Ubuntu 16.04) it crashed on Stage 3 while emerging sys-devel/binutils-2.31.1-r3 with the error (and previous interesting lines): 2018-12-30T13:43:33.4447221Z * Applying 9999-Gentoo-We-make-a-release.patch ... 2018-12-30T13:43:33.4468752Z [ ok ] 2018-12-30T13:43:33.4514996Z * Fixing misc issues in configure files 2018-12-30T13:43:33.4932831Z * Using GNU config files from 2018-12-30T13:43:33.4956732Z * Can't read /config.sub, skipping.. 2018-12-30T13:43:33.4979603Z * Can't read /config.guess, skipping.. 2018-12-30T13:43:33.5044174Z /tmp/gentoo/usr/bin/eltpatch: line 10: /tmp/gentoo/lib/gentoo/functions.sh: No such file or directory 2018-12-30T13:43:33.5070421Z * ERROR: sys-devel/binutils-2.31.1-r3::gentoo failed (prepare phase): 2018-12-30T13:43:33.5093290Z * eltpatch failed 2018-12-30T13:43:33.5120216Z * 2018-12-30T13:43:33.5146274Z * Call stack: 2018-12-30T13:43:33.5194643Z * ebuild.sh, line 124: Called src_prepare 2018-12-30T13:43:33.5246246Z * environment, line 2592: Called elibtoolize '--portage' '--no-uclibc' 2018-12-30T13:43:33.5282789Z * environment, line 691: Called die 2018-12-30T13:43:33.5303765Z * The specific snippet of code: 2018-12-30T13:43:33.5368489Z * ELT_LOGDIR=${T} LD=$(tc-getLD) eltpatch "${@}" || die "eltpatch failed" This wasn't happening yesterday. Reproducible: Always
Created attachment 558990 [details] Stage 3 bootstrap log
Created attachment 558994 [details] Previous day successful bootstrap log up until binutils
Hi Sam, Thank you! > /tmp/gentoo/usr/bin/eltpatch: line 10: /tmp/gentoo/lib/gentoo/functions.sh: No such file or directory /tmp/gentoo/lib/gentoo/functions.sh is installed by sys-apps/gentoo-functions in the log. I susspect this is a bug of the CI. Could you please confirm if the file is there? Yours, Benda
I have also run into this. gentoo-functions is installed and CONTENTS says the file is at ~/prefix/lib/gentoo/functions.sh and yet the file is actually located at ~/prefix/usr/lib/gentoo/functions.sh. I have no idea how the hell that happened.
oh this smells like /usr split removal This is RAP? And /{bin,sbin,lib} isn't symlinks into /usr?
(In reply to Fabian Groffen from comment #5) > oh this smells like /usr split removal > > This is RAP? And /{bin,sbin,lib} isn't symlinks into /usr? I don't know if this is RAP or not, this is my first time trying prefix and I just ran bootstrap-prefix.sh. The situation actually looks somewhat confused. lrwxrwxrwx 1 chewi users 7 Dec 31 15:30 bin -> usr/bin drwxr-xr-x 6 chewi users 4.0K Dec 31 15:46 etc lrwxrwxrwx 1 chewi users 5 Dec 31 15:46 lib -> lib64 drwxr-xr-x 2 chewi users 4.0K Dec 31 15:46 lib64 drwxr-xr-x 2 chewi users 4.0K Dec 31 15:43 run lrwxrwxrwx 1 chewi users 8 Dec 31 15:30 sbin -> usr/sbin -rw-r--r-- 1 chewi users 604K Dec 31 15:30 stage1.log -rw-r--r-- 1 chewi users 9.9M Dec 31 15:43 stage2.log -rw-r--r-- 1 chewi users 18M Dec 31 15:46 stage3.log drwxr-xr-x 6 chewi users 4.0K Dec 31 15:30 tmp drwxr-xr-x 8 chewi users 4.0K Dec 31 15:43 usr drwxr-xr-x 7 chewi users 4.0K Dec 31 15:43 var
yup, I'd expect lib to be linked to usr/lib and wouldn't expect lib64 at all, but that may be by design.
(In reply to Fabian Groffen from comment #7) > yup, I'd expect lib to be linked to usr/lib and wouldn't expect lib64 at > all, but that may be by design. I manually moved things around and created a symlink so I could continue. It later failed with a different but related split-usr problem. I believe you tried to fix it in 2d3793c2618b9026ff3c05a9122264967e7f9ebe but the profile that the bootstrap script uses doesn't inherit profiles/prefix, only profiles/features/prefix. Was this a mistake?
(In reply to Fabian Groffen from comment #5) > oh this smells like /usr split removal > > This is RAP? And /{bin,sbin,lib} isn't symlinks into /usr? Yes, it's RAP by default. I didn't know of the recent /usr symlinks. I am looking into this bug.
(In reply to Fabian Groffen from comment #7) > yup, I'd expect lib to be linked to usr/lib and wouldn't expect lib64 at > all, but that may be by design. Why should we symink lib to usr/lib? lib64 is an artifect of RAP to keep in sync with gx86. That's no problem.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=8e1dd215fb9401641e04199d1e69e7a5b498a7a3 commit 8e1dd215fb9401641e04199d1e69e7a5b498a7a3 Author: Benda Xu <heroxbd@gentoo.org> AuthorDate: 2019-01-01 10:17:37 +0000 Commit: Benda Xu <heroxbd@gentoo.org> CommitDate: 2019-01-01 10:17:37 +0000 s/bootstrap-prefix.sh: no /bin symlinks in prefix/standalone. In prefix/standalone, we keep USE=split-usr enabled to align with the default of Gentoo vanilla. Closes: https://bugs.gentoo.org/674084 Signed-off-by: Benda Xu <heroxbd@gentoo.org> scripts/bootstrap-prefix.sh | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)
