Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 655414 - bootstrap-prefix.sh fails to complete successfully (ERROR: app-misc/ca-certificates-20180409.3.37::gentoo failed)
Summary: bootstrap-prefix.sh fails to complete successfully (ERROR: app-misc/ca-certif...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo/Alt
Classification: Unclassified
Component: Prefix Support (show other bugs)
Hardware: All Linux
: Highest blocker with 3 votes (vote)
Assignee: Gentoo Prefix
URL:
Whiteboard:
Keywords:
: 656512 657414 668940 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-05-10 20:18 UTC by Paul Preney
Modified: 2019-02-19 12:27 UTC (History)
12 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch to restore EAPI 6 behavior of python_is_installed() (python-utils.patch,362 bytes, patch)
2018-05-14 20:51 UTC, Stephen McCamant
Details | Diff
libtool-2.4.6-r5 build.log for failed stage3 (prefix bootstrap) (prefix_bootstrap_failed_stage3_libtool-2.4.6-r5.build.log,4.21 KB, text/x-log)
2018-05-23 02:41 UTC, ᎫᏤᏣ (kuzetsa)
Details
Patch against autotools.eclass (autotools-prefix.patch,1.70 KB, patch)
2018-06-12 21:41 UTC, James Le Cuirot
Details | Diff
an approach to define various meanings of words 'prefix', 'root' and 'host' (gentoo-words-prefix-root-host.txt,4.78 KB, text/plain)
2018-06-14 15:08 UTC, Michael Haubenwallner (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Preney 2018-05-10 20:18:44 UTC
When trying to build bootstrap-prefix.sh within CentOS7 into any path, e.g.,
  
  /gentoo
  /usr/local/gentoo
  /home/userdir/gentoo

it always fails in stage3 while building app-misc/ca-certificates-20180409.3.37:

    >>> Emerging (30 of 37) app-misc/ca-certificates-20180409.3.37::gentoo
    * ca-certificates_20180409.tar.xz BLAKE2B SHA512 size ;-) ...           [ ok ]
    * nss-3.37.tar.gz BLAKE2B SHA512 size ;-) ...                           [ ok ]
    * You should run update-ca-certificates manually after etc-update
    >>> Unpacking source...
    >>> Unpacking ca-certificates_20180409.tar.xz to /gentoo/var/tmp/portage/app-misc/ca-certificates-20180409.3.37/work
    >>> Unpacking nss-3.37.tar.gz to /gentoo/var/tmp/portage/app-misc/ca-certificates-20180409.3.37/work
    >>> Source unpacked in /gentoo/var/tmp/portage/app-misc/ca-certificates-20180409.3.37/work
    >>> Preparing source in /gentoo/var/tmp/portage/app-misc/ca-certificates-20180409.3.37/work ...
    * Applying ca-certificates-20150426-root.patch ...
    [ ok ]
    >>> Source prepared.
    >>> Configuring source in /gentoo/var/tmp/portage/app-misc/ca-certificates-20180409.3.37/work ...
    >>> Source configured.
    >>> Compiling source in /gentoo/var/tmp/portage/app-misc/ca-certificates-20180409.3.37/work ...
    ERROR: This version of portageq only supports <eroot>s ending in '/gentoo'. The provided <eroot>, '/gentoo/tmp', doesn't.
    * ERROR: app-misc/ca-certificates-20180409.3.37::gentoo failed (compile phase):
    *   has_version: unexpected portageq exit code: 64
    *
    * Call stack:
    *          ebuild.sh, line  124:  Called src_compile
    *        environment, line 3025:  Called python_setup
    *        environment, line 2898:  Called _python_EPYTHON_supported 'python3.5'
    *        environment, line  328:  Called python_is_installed 'python3_5'
    *        environment, line 2752:  Called has_version '--host-root' 'dev-lang/python:3.5'
    *   phase-helpers.sh, line  882:  Called die
    * The specific snippet of code:
    *                              die "${FUNCNAME[0]}: unexpected portageq exit code: ${retval}"

bootstrap-prefix.sh is being run in automatic mode.
Comment 1 Fabian Groffen gentoo-dev 2018-05-11 06:39:53 UTC
This is a nasty one, thanks for reporting.
Comment 2 Byron Grobe 2018-05-13 23:06:49 UTC
Same behaviour on RHEL 7.5.
Comment 3 Stephen McCamant 2018-05-14 16:11:22 UTC
I've also encountered this failure, since Tuesday of last week; I've been testing using an Ubuntu 16.04 host.

From a binary search, it looks like the following change to the Portage directory was the trigger:

commit 0fabf3873a258d76a14a74475ef185d8b51741a0
Author:     Michał Górny <mgorny@gentoo.org>
AuthorDate: Thu May 3 15:41:10 2018 +0200
Commit:     Michał Górny <mgorny@gentoo.org>
CommitDate: Mon May 7 09:43:29 2018 +0200

    python-utils-r1.eclass: Initial EAPI 7 support
    
    Add initial EAPI 7 support.  Handle trailing slash in D/ED correctly.
    Support new has_version switches.
    
    This does not provide proper cross support.  In particular, the PYTHON
    variable (full path to the interpreter) is used both in contexts
    of BDEPEND and DEPEND, so we need to clean the uses first.

The phrase "This does not provide proper cross support." sounds worrying for Prefix, but I think that's meant to be describing the EAPI 7 behavior that's still somewhat under development. Whereas the problem here seems like a collateral change to the EAPI 6 behavior. The following is my guess at the most relevant hunk of the patch:

@@ -1086,9 +1086,20 @@
 python_is_installed() {
        local impl=${1:-${EPYTHON}}
        [[ ${impl} ]] || die "${FUNCNAME}: no impl nor EPYTHON"
+       local hasv_args=()
+
+       case ${EAPI:-0} in
+               0|1|2|3|4)
+                       local -x ROOT=/
+                       ;;
+               5|6)
+                       hasv_args+=( --host-root )
+                       ;;
+               *)
+                       hasv_args+=( -b )
+                       ;;
+       esac
 
-       # for has_version
-       local -x ROOT=/
        case "${impl}" in
                pypy|pypy3)
                        local append=

Note that "local ROOT=/" used to happen for EAPI 5 and 6, and no longer does; affects the behavior of has_version.
Comment 4 Paul Preney 2018-05-14 17:19:52 UTC
Until there is a fix, this hack work-around worked for me...

While running bootstrap-prefix.sh add to:
  
  ${EPREFIX}/etc/portage/profile/package.provided

the line:

  app-misc/ca-certificates-20180409.3.37

to tell Portage that "ca-certificates" is already installed. After you've finished bootstrap-prefix.sh, you can remove this line and "emerge -uDNav @world" to catch anything that was missed.
Comment 5 Horea Christian 2018-05-14 19:55:10 UTC
I am experiencing the same issue on Ubuntu 16.04.2 LTS .

I attempted a different fix, namely masking the packages by adding the following at the beginning of the `stage3()` function:

```
echo "=app-misc/ca-certificates-20180409.3.36.1-r1" >> "${ROOT}"/etc/portage/package.mask
echo "=app-misc/ca-certificates-20180409.3.37" >> "${ROOT}"/etc/portage/package.mask
``` 

The masking works, but it turns out even the stable `ca-certificates` version fails with the same error.
Comment 6 Stephen McCamant 2018-05-14 20:51:20 UTC
Created attachment 531450 [details, diff]
Patch to restore EAPI 6 behavior of python_is_installed()

Inspired by my previous analysis of the culprit change that triggered the failure, here is a patch that attempts to revert the behavior of the changed function in EAPI 5 and 6 to the previous behavior that allowed Prefix to work.

When I apply this patch on top of gentoo.git commit 7062eb23 and use that directory as $PREFIX/usr/portage in a bootstrap, the bootstrap succeeds for me.

I don't understand enough of the thinking behind the original change to know whether this is the right fix, or if some other change to code elsewhere would eb a better way forward.
Comment 7 Benda Xu gentoo-dev 2018-05-14 22:45:26 UTC
Thanks guys for troubleshooting this bug.

@Michał, what's your comments on this?
Comment 8 Fabian Groffen gentoo-dev 2018-05-15 06:39:28 UTC
(In reply to Stephen McCamant from comment #6)
> Created attachment 531450 [details, diff] [details, diff]
> Patch to restore EAPI 6 behavior of python_is_installed()
> 
> Inspired by my previous analysis of the culprit change that triggered the
> failure, here is a patch that attempts to revert the behavior of the changed
> function in EAPI 5 and 6 to the previous behavior that allowed Prefix to
> work.
> 
> When I apply this patch on top of gentoo.git commit 7062eb23 and use that
> directory as $PREFIX/usr/portage in a bootstrap, the bootstrap succeeds for
> me.
> 
> I don't understand enough of the thinking behind the original change to know
> whether this is the right fix, or if some other change to code elsewhere
> would eb a better way forward.

In my opinion this fix has the problem that as soon as ca-certificates gets EAPI=7, we're back at this bug, am I correct?

(In reply to Paul Preney from comment #4)
> Until there is a fix, this hack work-around worked for me...
> 
> While running bootstrap-prefix.sh add to:
>   
>   ${EPREFIX}/etc/portage/profile/package.provided
> 
> the line:
> 
>   app-misc/ca-certificates-20180409.3.37
> 
> to tell Portage that "ca-certificates" is already installed. After you've
> finished bootstrap-prefix.sh, you can remove this line and "emerge -uDNav
> @world" to catch anything that was missed.

I think this may be a viable workaround, since the root cause for this problem is our alternate EPREFIX (thus ROOT) we use temporarily for pulling ourselves out of the mudd.  I don't know very well how we can steer has_version to the right place (or what the right place would be).
Technically speaking our --nodeps to emerge is rendered useless by has_version check + die.
Comment 9 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-05-15 07:43:14 UTC
Wasn't --host-root supposed to be 1:1 replacement for ROOT=/?
Comment 10 Zac Medico gentoo-dev 2018-05-15 08:34:39 UTC
(In reply to Michał Górny from comment #9)
> Wasn't --host-root supposed to be 1:1 replacement for ROOT=/?

Yes, should be, and we can clearly see that it sets root=/ in the original implementation here:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=bcf4ab871ededc3d535165757ba5597669e33dcb
Comment 11 Zac Medico gentoo-dev 2018-05-15 08:58:14 UTC
It may be a bash bug triggering nonsensical behavior.
Comment 12 Fabian Groffen gentoo-dev 2018-05-15 09:05:21 UTC
this is a cross-eprefix scenario

ROOT=/ is applied for both cases
EPREFIX is different in the environment (/gentoo) vs. the running Portage (/gentoo/tmp)

I don't know why it triggers only now, but my understanding is that we try to install ca-certificates into EPREFIX=/gentoo, with a Portage built for EPREFIX=/gentoo/tmp (bootstrap instance).
Comment 13 Zac Medico gentoo-dev 2018-05-15 18:58:56 UTC
(In reply to Fabian Groffen from comment #12)
> I don't know why it triggers only now, but my understanding is that we try
> to install ca-certificates into EPREFIX=/gentoo, with a Portage built for
> EPREFIX=/gentoo/tmp (bootstrap instance).

In this case, the intention is for the ebuild environment to have PORTAGE_OVERRIDE_EPREFIX=/gentoo/tmp and EPREFIX=/gentoo, which explains the apparent eroot=/gentoo/tmp setting here:

https://gitweb.gentoo.org/proj/portage.git/tree/bin/phase-helpers.sh?id=70aab2af6ad556e45657745a2d4adf64ac23e5b9#n858

Since PORTAGE_IPC_DAEMON is apparently unset, portageq is called, and where the eroot=/gentoo/tmp setting and EPREFIX=/gentoo setting conflict here:

https://gitweb.gentoo.org/proj/portage.git/tree/bin/portageq?id=70aab2af6ad556e45657745a2d4adf64ac23e5b9#n1417
Comment 14 Zac Medico gentoo-dev 2018-05-15 20:24:57 UTC
(In reply to Zac Medico from comment #13)
> Since PORTAGE_IPC_DAEMON is apparently unset, portageq is called, and where
> the eroot=/gentoo/tmp setting and EPREFIX=/gentoo setting conflict here:
> 
> https://gitweb.gentoo.org/proj/portage.git/tree/bin/
> portageq?id=70aab2af6ad556e45657745a2d4adf64ac23e5b9#n1417

Seems like we could avoid this conflict by overriding the EPREFIX variable for this call in bin/phase-helpers.sh:

"${PORTAGE_BIN_PATH}/ebuild-helpers/portageq" best_version "${eroot}" "${atom}"
Comment 15 Larry the Git Cow gentoo-dev 2018-05-16 20:46:08 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/portage.git/commit/?id=17fce85669beec41747d65b37a55747b2f3ddb3c

commit 17fce85669beec41747d65b37a55747b2f3ddb3c
Author:     Zac Medico <zmedico@gentoo.org>
AuthorDate: 2018-05-16 20:35:57 +0000
Commit:     Zac Medico <zmedico@gentoo.org>
CommitDate: 2018-05-16 20:35:57 +0000

    phase-helpers.sh: fix has/best_version for cross-prefix portageq (bug 655414)
    
    When the portageq root argument refers to ${PORTAGE_OVERRIDE_EPREFIX},
    also export a consistent ${EPREFIX}, since portageq asserts that the
    root argument ends with ${EPREFIX}.
    
    Bug: https://bugs.gentoo.org/655414

 bin/phase-helpers.sh | 3 +++
 1 file changed, 3 insertions(+)
Comment 16 Zac Medico gentoo-dev 2018-05-16 21:11:23 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/portage.git/commit/?id=1582103b2f0f64e5dc57eddc4217360eac230b8a

commit 1582103b2f0f64e5dc57eddc4217360eac230b8a
Author: Zac Medico <zmedico@gentoo.org>
Date:   2018-05-16 13:54:23 -0700

    phase-helpers.sh: handle readonly EPREFIX for local override (bug 655414)
    
    Since ebuild.sh calls "declare -r ED EPREFIX EROOT", use env to
    override EPREFIX for the called command.
    
    Fixes: 17fce85669be ("phase-helpers.sh: fix has/best_version for cross-prefix portageq (bug 655414)")

 bin/phase-helpers.sh | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)
Comment 17 giacomo.cappellini.87 2018-05-18 12:28:28 UTC
Hello,

I'm new to gentoo-prefix and I'm facing a similar problem on stage3 while configuring libuv on my first install experience.
Could you kindly show me how can I apply this patch? I tried to replace the updated phase-helpers.sh file from git tree and lanching

./bootstrap-prefix.sh "<myprefix>" stage3

with the right EPREFIX and PATH variables as shown here https://wiki.gentoo.org/wiki/Project:Prefix/Manual_Bootstrap


This is the error occurred during first ./bootstrap-prefix.sh

* Adjusting to prefix /home/jack/gentooprefix
 *   libtool.m4 ...
 [ ok ]
 * Running eautoreconf in '/home/jack/gentooprefix/var/tmp/portage/sys-devel/libtool-2.4.6-r5/work/libtool-2.4.6/libltdl' ...
ERROR: This version of portageq only supports <eroot>s ending in '/home/jack/gentooprefix'. The provided <eroot>, '/home/jack/gentooprefix/tmp', doesn't.
 * ERROR: sys-devel/libtool-2.4.6-r5::gentoo failed (prepare phase):
 *   has_version: unexpected portageq exit code: 64
 *
 * Call stack:
 *          ebuild.sh, line  124:  Called src_prepare
 *        environment, line 2502:  Called eautoreconf
 *        environment, line  887:  Called _elibtoolize '--auto-ltdl' '--install' '--copy' '--force'
 *        environment, line  295:  Called autotools_run_tool 'true' '--install' '--copy' '--force' '--ltdl' '--automake'
 *        environment, line  575:  Called autotools_env_setup
 *        environment, line  526:  Called has_version '--host-root' '=sys-devel/automake-1.16*'
 *   phase-helpers.sh, line  882:  Called die
 * The specific snippet of code:
 *                              die "${FUNCNAME[0]}: unexpected portageq exit code: ${retval}"
 *
 * If you need support, post the output of `emerge --info '=sys-devel/libtool-2.4.6-r5::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-devel/libtool-2.4.6-r5::gentoo'`.
 * The complete build log is located at '/home/jack/gentooprefix/var/tmp/portage/sys-devel/libtool-2.4.6-r5/temp/build.log'.
 * The ebuild environment file is located at '/home/jack/gentooprefix/var/tmp/portage/sys-devel/libtool-2.4.6-r5/temp/environment'.
 * Working directory: '/home/jack/gentooprefix/var/tmp/portage/sys-devel/libtool-2.4.6-r5/work/libtool-2.4.6/libltdl'
 * S: '/home/jack/gentooprefix/var/tmp/portage/sys-devel/libtool-2.4.6-r5/work/libtool-2.4.6'

>>> Failed to emerge sys-devel/libtool-2.4.6-r5, Log file:

>>>  '/home/jack/gentooprefix/var/tmp/portage/sys-devel/libtool-2.4.6-r5/temp/build.log'

 * Messages for package sys-devel/libtool-2.4.6-r5:

 * ERROR: sys-devel/libtool-2.4.6-r5::gentoo failed (prepare phase):
 *   has_version: unexpected portageq exit code: 64
 *
 * Call stack:
 *          ebuild.sh, line  124:  Called src_prepare
 *        environment, line 2502:  Called eautoreconf
 *        environment, line  887:  Called _elibtoolize '--auto-ltdl' '--install' '--copy' '--force'
 *        environment, line  295:  Called autotools_run_tool 'true' '--install' '--copy' '--force' '--ltdl' '--automake'
 *        environment, line  575:  Called autotools_env_setup
 *        environment, line  526:  Called has_version '--host-root' '=sys-devel/automake-1.16*'
 *   phase-helpers.sh, line  882:  Called die
 * The specific snippet of code:
 *                              die "${FUNCNAME[0]}: unexpected portageq exit code: ${retval}"


This is the error on relaunching ./bootstrap-prefix.sh "<myprefix>" stage3


* Bootstrapping Gentoo prefixed portage installation using
* host:   x86_64-pc-linux-gnu
* prefix: /home/jack/gentooprefix
* ready to bootstrap stage3
USE=-acl -berkdb -fortran -gdbm -git -libcxx -nls -pcre-python bootstrap clang internal-glib ssl PKG=sys-devel/gettext

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N     ] sys-devel/libtool-2.4.6-r5:2::gentoo  USE="-vanilla" 0 KiB
[ebuild  N     ] dev-libs/expat-2.2.5::gentoo  USE="unicode -examples -static-libs" 0 KiB
[ebuild  N     ] dev-util/gtk-doc-am-1.25-r1::gentoo  0 KiB
[ebuild  N     ] dev-libs/libxml2-2.9.8:2::gentoo  USE="ipv6 readline -debug -examples -icu -lzma -python -static-libs {-test}" PYTHON_TARGETS="python2_7 python3_5 -python3_4 -python3_6" 0 KiB
[ebuild  N     ] sys-devel/gettext-0.19.8.1::gentoo  USE="cxx ncurses openmp -acl -cvs -doc -emacs -git -java -nls -static-libs" 0 KiB

Total: 5 packages (5 new), Size of downloads: 0 KiB


>>> Verifying ebuild manifests

>>> Emerging (1 of 5) sys-devel/libtool-2.4.6-r5::gentoo
/home/jack/gentooprefix/tmp/usr/lib/portage/bin/phase-helpers.sh: line 5: ___eapi_has_DESTTREE_INSDESTTREE: command not found
 * libtool-2.4.6.tar.xz BLAKE2B SHA512 size ;-) ...                                                   [ ok ]
/home/jack/gentooprefix/tmp/usr/lib/portage/bin/phase-helpers.sh: line 5: ___eapi_has_DESTTREE_INSDESTTREE: command not found
/home/jack/gentooprefix/tmp/usr/lib/portage/bin/phase-helpers.sh: line 5: ___eapi_has_DESTTREE_INSDESTTREE: command not found
>>> Unpacking source...
>>> Unpacking libtool-2.4.6.tar.xz to /home/jack/gentooprefix/var/tmp/portage/sys-devel/libtool-2.4.6-r5/work
>>> Source unpacked in /home/jack/gentooprefix/var/tmp/portage/sys-devel/libtool-2.4.6-r5/work
/home/jack/gentooprefix/tmp/usr/lib/portage/bin/phase-helpers.sh: line 5: ___eapi_has_DESTTREE_INSDESTTREE: command not found
>>> Preparing source in /home/jack/gentooprefix/var/tmp/portage/sys-devel/libtool-2.4.6-r5/work/libtool-2.4.6 ...
 * Applying libtool-2.4.3-use-linux-version-in-fbsd.patch ...                                         [ ok ]
 * Applying libtool-2.4.6-link-specs.patch ...
File build-aux/ltmain.sh is read-only; trying to patch anyway                                         [ ok ]
 * Applying libtool-2.4.6-link-fsanitize.patch ...
File build-aux/ltmain.sh is read-only; trying to patch anyway                                         [ ok ]
 * Applying libtool-2.4.6-link-fuse-ld.patch ...
File build-aux/ltmain.sh is read-only; trying to patch anyway                                         [ ok ]
 * Applying libtool-2.4.6-libtoolize-slow.patch ...                                                   [ ok ]
 * Applying libtool-2.4.6-libtoolize-delay-help.patch ...                                             [ ok ]
 * Applying libtool-2.4.6-sed-quote-speedup.patch ...
File build-aux/ltmain.sh is read-only; trying to patch anyway                                         [ ok ]
 * Applying libtool-2.4.6-ppc64le.patch ...                                                           [ ok ]
 * Applying libtool-2.4.6-mint.patch ...                                                              [ ok ]
 * Applying libtool-2.2.6a-darwin-module-bundle.patch ...                                             [ ok ]
 * Applying libtool-2.4.6-darwin-use-linux-version.patch ...                                          [ ok ]
 * Applying libtool-2.4.6-pthread_bootstrapped.patch ...
File build-aux/ltmain.sh is read-only; trying to patch anyway                                         [ ok ]
 * Applying libtool-2.2.10-eprefix.patch ...                                                          [ ok ]
 * Adjusting to prefix /home/jack/gentooprefix
 *   libtool.m4 ...                                                                                   [ ok ]
 * Running eautoreconf in '/home/jack/gentooprefix/var/tmp/portage/sys-devel/libtool-2.4.6-r5/work/libtool-2.4.6/libltdl' ...
 * ERROR: sys-devel/libtool-2.4.6-r5::gentoo failed (prepare phase):
 *   Cannot find the latest automake! Tried 1.16.1:1.16 1.15.1:1.15
 *
 * Call stack:
 *     ebuild.sh, line  124:  Called src_prepare
 *   environment, line 2534:  Called eautoreconf
 *   environment, line  919:  Called _elibtoolize '--auto-ltdl' '--install' '--copy' '--force'
 *   environment, line  296:  Called autotools_run_tool 'true' '--install' '--copy' '--force' '--ltdl' '--automake'
 *   environment, line  576:  Called autotools_env_setup
 *   environment, line  529:  Called die
 * The specific snippet of code:
 *           [[ ${WANT_AUTOMAKE} == "latest" ]] && die "Cannot find the latest automake! Tried ${_LATEST_AUTOMAKE[*]}";
 *
 * If you need support, post the output of `emerge --info '=sys-devel/libtool-2.4.6-r5::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-devel/libtool-2.4.6-r5::gentoo'`.
 * The complete build log is located at '/home/jack/gentooprefix/var/tmp/portage/sys-devel/libtool-2.4.6-r5/temp/build.log'.
 * The ebuild environment file is located at '/home/jack/gentooprefix/var/tmp/portage/sys-devel/libtool-2.4.6-r5/temp/environment'.
 * Working directory: '/home/jack/gentooprefix/var/tmp/portage/sys-devel/libtool-2.4.6-r5/work/libtool-2.4.6/libltdl'
 * S: '/home/jack/gentooprefix/var/tmp/portage/sys-devel/libtool-2.4.6-r5/work/libtool-2.4.6'
/home/jack/gentooprefix/tmp/usr/lib/portage/bin/phase-helpers.sh: line 5: ___eapi_has_DESTTREE_INSDESTTREE: command not found

>>> Failed to emerge sys-devel/libtool-2.4.6-r5, Log file:

>>>  '/home/jack/gentooprefix/var/tmp/portage/sys-devel/libtool-2.4.6-r5/temp/build.log'

 * Messages for package sys-devel/libtool-2.4.6-r5:

 * ERROR: sys-devel/libtool-2.4.6-r5::gentoo failed (prepare phase):
 *   Cannot find the latest automake! Tried 1.16.1:1.16 1.15.1:1.15
 *
 * Call stack:
 *     ebuild.sh, line  124:  Called src_prepare
 *   environment, line 2534:  Called eautoreconf
 *   environment, line  919:  Called _elibtoolize '--auto-ltdl' '--install' '--copy' '--force'
 *   environment, line  296:  Called autotools_run_tool 'true' '--install' '--copy' '--force' '--ltdl' '--automake'
 *   environment, line  576:  Called autotools_env_setup
 *   environment, line  529:  Called die
 * The specific snippet of code:
 *           [[ ${WANT_AUTOMAKE} == "latest" ]] && die "Cannot find the latest automake! Tried ${_LATEST_AUTOMAKE[*]}";
 *
 * If you need support, post the output of `emerge --info '=sys-devel/libtool-2.4.6-r5::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-devel/libtool-2.4.6-r5::gentoo'`.
 * The complete build log is located at '/home/jack/gentooprefix/var/tmp/portage/sys-devel/libtool-2.4.6-r5/temp/build.log'.
 * The ebuild environment file is located at '/home/jack/gentooprefix/var/tmp/portage/sys-devel/libtool-2.4.6-r5/temp/environment'.
 * Working directory: '/home/jack/gentooprefix/var/tmp/portage/sys-devel/libtool-2.4.6-r5/work/libtool-2.4.6/libltdl'

thank you
Comment 18 ᎫᏤᏣ (kuzetsa) 2018-05-23 02:41:46 UTC
Created attachment 532654 [details]
libtool-2.4.6-r5 build.log for failed stage3 (prefix bootstrap)

(In reply to giacomo.cappellini.87 from comment #17)

{snip}

I'm not sure if 1582103b2f0f64e5dc57eddc4217360eac230b8a
was applied to the relevant distfiles or not, but as-of:
today (2018, May 22) this bug is still occuring for me.

attached log.
Comment 19 Paul Preney 2018-05-24 22:50:09 UTC
It doesn't look like this patch works...

The same bug (as of yesterday May 23, 2018) occurs under CentOS7 aarch64 (ARM) architecture in stage3 of the bootstrap-prefix.sh install:

 * Running eautoreconf in '/dev/shm/preney-prefix/portage/sys-devel/libtool-2.4.6-r5/work/libtool-2.4.6/libltdl' ...
ERROR: This version of portageq only supports <eroot>s ending in '/home/preney/gentoo-aarch64'. The provided <eroot>, '/home/preney/gentoo-aarch64/tmp', doesn't.
 * ERROR: sys-devel/libtool-2.4.6-r5::gentoo failed (prepare phase):
 *   has_version: unexpected portageq exit code: 64

I manually patched usr/portage/eclass/python-utils-r1.eclass with the above patch and re-ran bootstrap-prefix.sh. The same bug occurs.

So I changed the patch to be "local -x ROOT=/" (i.e., what the earliest EAPIs do) but the same bug occurs. :-(

So I set all EAPIs 5|6|* to be "local ROOT=/" (i.e., the patch applied to EAPIs 5, 6, and *). The same bug occurs.

So I reverted to the earlier code mentioned in Comment 3 (i.e., I deleted the case statement and did "local -x ROOT=/"). The same bug occurs.

Conclusions...

1) This appears to show that while this code block might contribute to the problem, the fix does not, in general, fix the problem.

2) Is there a hack to fix this so things can work? libtool is rather important so one cannot simply tell Portage it is pre-installed as I did in comment 4 with ca-certificates. Until such a hack is available, it looks like one cannot install Gentoo Prefix.
Comment 20 Paul Preney 2018-05-24 23:14:55 UTC
Success building libtool! It looks like another patch needs to be made to autotools.eclass. 

That said, might I suggest that this should be refactored into a single function used by all eclasses that do the same / similar so (i) it only appears once, (ii) this can be fixed in one location, and (iii) this can be looked at for EAPI=7 and dealt with more better, etc.?

---

Here is how I found it...

I looked at all eclasses libtool inherits from its ebuild file.

I then did a "grep ROOT filename" on those files. Only two mention ROOT. I assumed patches.eclass is okay and the issue was in the other file: autotools.eclass. 

In autotools.eclass, on line 449 there is a line that sets hv_args="--host-root" for EAPIs 5 and 6, e.g.,

      # Break on first hit to respect _LATEST_AUTOMAKE order.
      local hv_args=""
      case ${EAPI:-0} in
        5|6)
          hv_args="--host-root"
          ;;
        7)
          hv_args="-b"
          ;;
      esac

So I tried commenting out hv_args="--host-root", re-ran bootstrap-prefix.sh and libtool was compiled and installed!

---

Also "--host-root" seems to be something to look for to find where things can file. Running "grep -- '--host-root' *.eclass" in usr/portage/eclass shows three files:

autotools.eclass
git-r3.eclass
python-utils-r1.eclass

In git-r3.eclass it is on line 661 for EAPI 5|6, e.g.,

      if [[ ${r} == http://* || ${r} == https://* ]] &&
          [[ ! ${EGIT_CURL_WARNED} ]]
      then
        case ${EAPI:-0} in
          0|1|2|3|4)
            ROOT=/ has_version 'dev-vcs/git[curl]';;
          5|6)
            has_version --host-root 'dev-vcs/git[curl]';;
          *)
            has_version -b 'dev-vcs/git[curl]';;
        esac

so this might also need to be modified to match that of the earlier EAPIs?
Comment 21 Paul Preney 2018-05-25 14:31:44 UTC
An Update: The CentOS7 ARM Gentoo Prefix stage3 ALSO requires what I did in Comment 3:

While running bootstrap-prefix.sh add to:
  
  ${EPREFIX}/etc/portage/profile/package.provided

the line:

  app-misc/ca-certificates-20180409.3.37

NOTE: ca-certificates is installed after libtool. Stage3 stops with the same error. Since ca-certificates isn't needed for anything critical, adding it to package.provided while bootstrap-prefix.sh runs (and then removing it before doing an emerge -uDNav @world) is sufficient to get past this point.
Comment 22 Fabian Groffen gentoo-dev 2018-05-25 20:08:37 UTC
*** Bug 656512 has been marked as a duplicate of this bug. ***
Comment 23 Fabian Groffen gentoo-dev 2018-05-25 20:09:45 UTC
sys-apps/portage-2.3.40 should be available in Prefix now, we may need to bump the portage version used when bootstrapping though.
Comment 24 Richard Yao (RETIRED) gentoo-dev 2018-05-25 22:20:57 UTC
(In reply to Fabian Groffen from comment #23)
> sys-apps/portage-2.3.40 should be available in Prefix now, we may need to
> bump the portage version used when bootstrapping though.

The bootstrap is still failing for me at libtool. I ran this command to bootstrap:

env TESTING_PV=2.3.40 LATEST_TREE_YES=1 EPREFIX=/opt/gentoo USE_CPU_CORES=8 ./bootstrap-prefix.sh
Comment 25 Richard Yao (RETIRED) gentoo-dev 2018-05-25 22:21:28 UTC
(In reply to Richard Yao from comment #24)
> (In reply to Fabian Groffen from comment #23)
> > sys-apps/portage-2.3.40 should be available in Prefix now, we may need to
> > bump the portage version used when bootstrapping though.
> 
> The bootstrap is still failing for me at libtool. I ran this command to
> bootstrap:
> 
> env TESTING_PV=2.3.40 LATEST_TREE_YES=1 EPREFIX=/opt/gentoo USE_CPU_CORES=8
> ./bootstrap-prefix.sh

I probably should add that I checked and "Portage 2.3.40-prefix" is installed in the prefix. :/
Comment 26 Larry the Git Cow gentoo-dev 2018-05-27 07:14:19 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=e6804a1a78af920b0a9aed027a1582e7a06ee87f

commit e6804a1a78af920b0a9aed027a1582e7a06ee87f
Author:     Fabian Groffen <grobian@gentoo.org>
AuthorDate: 2018-05-27 07:12:54 +0000
Commit:     Fabian Groffen <grobian@gentoo.org>
CommitDate: 2018-05-27 07:12:54 +0000

    scripts/bootstrap-prefix: bump portage and tree snapshots, bug #655414
    
    Use a newer portage, and a snapshot which includes that portage.
    
    Bug: https://bugs.gentoo.org/655414

 scripts/bootstrap-prefix.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
Comment 27 Fabian Groffen gentoo-dev 2018-05-27 07:15:49 UTC
with above commit I was able to successfully bootstrap on OpenIndiana (x86-solaris), this is different from RAP though
Comment 28 Benda Xu gentoo-dev 2018-06-11 12:16:39 UTC
Prefix on Linux is still failing.
Comment 29 Fabian Groffen gentoo-dev 2018-06-11 12:36:10 UTC
I think I found the reason (+ fix) for this.  the portageq command looks into $EPREFIX/tmp, where automake is not installed.  I just changed bootstrap-prefix to install autoconf+automake in $EPREFIX/tmp during stage2.  This seems to allow me to continue at this point.
Comment 30 Fabian Groffen gentoo-dev 2018-06-11 12:46:29 UTC
*** Bug 657414 has been marked as a duplicate of this bug. ***
Comment 31 Benda Xu gentoo-dev 2018-06-11 12:53:23 UTC
(In reply to Michał Górny from comment #9)
> Wasn't --host-root supposed to be 1:1 replacement for ROOT=/?

No, it isn't, zooming into https://gitweb.gentoo.org/proj/portage.git/tree/bin/phase-helpers.sh?id=1d1a20f48f5f37316b7827428e95714137078ea1#n881

We can see that `ROOT=/ has_version category/package` calls `portageq has_version` with EROOT=${ROOT%/}/${EPREFIX#/}, but `has_version --host-root category/package` calls `portageq has_version` with EROOT=${ROOT%/}/${PORTAGE_OVERRIDE_EPREFIX#/}.  They are completely different in cross-prefix.
Comment 32 Benda Xu gentoo-dev 2018-06-11 12:56:05 UTC
(In reply to Fabian Groffen from comment #29)
> I think I found the reason (+ fix) for this.  the portageq command looks
> into $EPREFIX/tmp, where automake is not installed.  I just changed
> bootstrap-prefix to install autoconf+automake in $EPREFIX/tmp during stage2.
> This seems to allow me to continue at this point.

Thanks Fabian.  While this fixes the bootstrap, I don't consider it a clean way to move forward.
Comment 33 Fabian Groffen gentoo-dev 2018-06-11 13:03:56 UTC
I looked at the portage code too, and it confused me too.  I'm not sure if the setup is as we want.  One thing that is very confusing, is that the variable is called "root", while in fact it is "eroot" (portageq also calls it like that) which makes it much more obvious EPREFIX should be appended to it.

Benda do you have a suggestion of what the chosen (e)root should be in the three cases?  --host-root somehow seems to suggest "native EPREFIX", which in our case would indeed be $EPREFIX/tmp.
Comment 34 Larry the Git Cow gentoo-dev 2018-06-11 16:38:54 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=ddf86254b773b1a2205c8ef166c7d8c7fdcfa697

commit ddf86254b773b1a2205c8ef166c7d8c7fdcfa697
Author:     Fabian Groffen <grobian@gentoo.org>
AuthorDate: 2018-06-11 16:37:47 +0000
Commit:     Fabian Groffen <grobian@gentoo.org>
CommitDate: 2018-06-11 16:37:47 +0000

    scripts/bootstrap-prefix: (try to) workaround libtool stage3 issue
    
    Closes: https://bugs.gentoo.org/655414

 scripts/bootstrap-prefix.sh | 11 +++++++++++
 1 file changed, 11 insertions(+)
Comment 35 Kalon Mills 2018-06-11 17:33:29 UTC
Thanks all for working on this. 

Fyi, I just tried the latest bootstrap-prefix.sh on a Linux machine and now I'm getting a different error.  Previously it was the libtool config error in stage3.  Now is a automake config error in stage 2.


2018-06-11 10:19:29 (6.00 MB/s) - ‘/home/user/gprefix/usr/portage/distfiles/automake-1.16.1.tar.xz’ saved [1534936/1534936]

 * automake-1.16.1.tar.xz BLAKE2B SHA512 size ;-) ...                    [ ok ]
>>> Unpacking source...
>>> Unpacking automake-1.16.1.tar.xz to /home/user/gprefix/tmp/var/tmp/portage/sys-devel/automake-1.16.1-r1/work
>>> Source unpacked in /home/user/gprefix/tmp/var/tmp/portage/sys-devel/automake-1.16.1-r1/work
>>> Preparing source in /home/user/gprefix/tmp/var/tmp/portage/sys-devel/automake-1.16.1-r1/work/automake-1.16.1 ...
sh: autom4te: command not found
aclocal.tmp: error: echo failed with exit status: 127
 * ERROR: sys-devel/automake-1.16.1-r1::gentoo failed (prepare phase):
 *   (no error message)
 *
 * Call stack:
 *     ebuild.sh, line 124:  Called src_prepare
 *   environment, line 2188:  Called die
 * The specific snippet of code:
 *       ./bootstrap || die;
 *
 * If you need support, post the output of `emerge --info '=sys-devel/automake-1.16.1-r1::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-devel/automake-1.16.1-r1::gentoo'`.
 * The complete build log is located at '/home/user/gprefix/tmp/var/tmp/portage/sys-devel/automake-1.16.1-r1/temp/build.log'.
 * The ebuild environment file is located at '/home/user/gprefix/tmp/var/tmp/portage/sys-devel/automake-1.16.1-r1/temp/environment'.
 * Working directory: '/home/user/gprefix/tmp/var/tmp/portage/sys-devel/automake-1.16.1-r1/work/automake-1.16.1'
 * S: '/home/user/gprefix/tmp/var/tmp/portage/sys-devel/automake-1.16.1-r1/work/automake-1.16.1'
...
Odd!  Running
  /bin/bash ./bootstrap-prefix.sh "/home/httpd/gprefix" stage2
failed! :(
...

So it looks like automake can't successfully use the autoconf that was installed into stage2's ${EPREFIX}/tmp.
Comment 36 Kalon Mills 2018-06-11 17:36:27 UTC
Opps that last part should have been:

...
Odd!  Running
  /bin/bash ./bootstrap-prefix.sh "/home/user/gprefix" stage2
failed! :(
...

Working from too many workspaces....
Comment 37 Fabian Groffen gentoo-dev 2018-06-11 17:58:11 UTC
Yeah, the fix is temporarily and not really sufficient.  Any ebuild using has_version fails, because portage is pulling in deps for EPREFIX, but has_version looks at the EPREFIX portage was built for.  Since these differ during bootstrap, things like python get installed fine, but installing ca-certificates then fails because has_version returns no python is installed.
Comment 38 Fabian Groffen gentoo-dev 2018-06-11 18:26:24 UTC
replacing PORTAGE_OVERRIDE_EPREFIX with EPREFIX makes has_version work, I'm yet trying to understand what the intention of PORTAGE_OVERRIDE_EPREFIX was (and why only this scenario uses it).
Comment 39 Zac Medico gentoo-dev 2018-06-11 20:54:02 UTC
(In reply to Fabian Groffen from comment #38)
> replacing PORTAGE_OVERRIDE_EPREFIX with EPREFIX makes has_version work, I'm
> yet trying to understand what the intention of PORTAGE_OVERRIDE_EPREFIX was
> (and why only this scenario uses it).

For cross-eprefix mode, the PORTAGE_OVERRIDE_EPREFIX refers to the prefix of the currently running portage instance, while EPREFIX refers to the prefix that packages are being built for. The intention of --host-root is to check for packages in the same prefix as the currently running portage instance, therefore it uses PORTAGE_OVERRIDE_EPREFIX.
Comment 40 Fabian Groffen gentoo-dev 2018-06-12 10:57:14 UTC
(In reply to Zac Medico from comment #39)
> (In reply to Fabian Groffen from comment #38)
> > replacing PORTAGE_OVERRIDE_EPREFIX with EPREFIX makes has_version work, I'm
> > yet trying to understand what the intention of PORTAGE_OVERRIDE_EPREFIX was
> > (and why only this scenario uses it).
> 
> For cross-eprefix mode, the PORTAGE_OVERRIDE_EPREFIX refers to the prefix of
> the currently running portage instance, while EPREFIX refers to the prefix
> that packages are being built for. The intention of --host-root is to check
> for packages in the same prefix as the currently running portage instance,
> therefore it uses PORTAGE_OVERRIDE_EPREFIX.

I've been thinking about this, and I seem to return every time at the point where I think that --host-root should only deal with ROOT, not EPREFIX.  While ROOT and EPREFIX feel like similar things, in fact they are very different in the way that executables/libraries from alternate EPREFIX *can* be used, while the same for an alternate ROOT usually is not the case without help.

The intention of has_version usage seems to be to deal with ROOT, not cross-prefix, which haubi seems to think is tackled in a way by EAPI-7.  That said, I think the proper fix here is to revert the usage of PORTAGE_OVERRIDE_EPREFIX in has_version implemention.
Comment 41 Zac Medico gentoo-dev 2018-06-12 17:04:21 UTC
(In reply to Fabian Groffen from comment #40)
> The intention of has_version usage seems to be to deal with ROOT, not
> cross-prefix, which haubi seems to think is tackled in a way by EAPI-7. 
> That said, I think the proper fix here is to revert the usage of
> PORTAGE_OVERRIDE_EPREFIX in has_version implemention.

I wonder if this aligns with PMS. If not, it would be nice to see things come into alignment one way or another.
Comment 42 James Le Cuirot gentoo-dev 2018-06-12 20:29:07 UTC
I was made aware of this issue today. I tried to keep prefix in mind when I proposed and implemented these changes but admittedly I've never used it before and I was not familiar with its bootstrap process.

I don't believe this is a bug in Portage or PMS as things are working as intended. This has_version check is used to check whether we can execute automate. We avoid executing anything in the target system because that isn't safe. Even if you're not cross-compiling, the libc might be different, the target may have a newer glibc version, or there may be other subtle differences. In this particular case though, it necessary due to the awkward nature of bootstrapping prefix and it is probably safe enough.

It worked before because you were essentially relying on a bug. EAPIs before 5 didn't know how to deal with this properly and the has_version call wasn't updated for newer EAPIs until now. What you're asking for shouldn't be considered normal behaviour because in order to execute automake, it is expected to be in the PATH. The target system wouldn't normally be in the PATH but heroxbd informed me that the bootstrap process hacks around this by adding it via PREROOTPATH.

Fear not though, as I do have an idea. If ROOT is already /, which it is for cross-prefix, then you can call has_version without --host-root for EAPI 5 and 6, and with -d for EAPI 7. This should give the behaviour you need without negatively affecting anyone else. It is a bit of a hack so I suggest we only apply it to autotools.eclass when EPREFIX is non-empty for this specific case. Anything else should try to do the right thing. I'll prepare a patch.
Comment 43 James Le Cuirot gentoo-dev 2018-06-12 21:41:07 UTC
Created attachment 535752 [details, diff]
Patch against autotools.eclass

Try this on for size. I haven't tested it myself.
Comment 44 Benda Xu gentoo-dev 2018-06-13 01:26:41 UTC
I am convinced by the Chewi and the Portage Team that it is sane to require has_version --host-root to point the dependency to build-prefix.

The PORTAGE_OVERRIDE_EPREFIX usage for distinguishing build-prefix and target-prefix has been introduced by redlizard back in 2013 at https://gitweb.gentoo.org/proj/portage.git/commit/?id=c9f6aa9f0151adb3c86706eaef191 .  At that time we had a big debate on the IRC on whether to abuse this variable.  Finally we had reached a conclusion to abuse it.  I hope this addresses Fabian's confusion.

Therefore to fix the bootstrap, we should have the portage regard stage3 as the build-prefix by setting PORTAGE_OVERRIDE_EPREFIX.  It will be future-proof to EAPI-7.
Comment 45 Fabian Groffen gentoo-dev 2018-06-13 08:40:32 UTC
(In reply to James Le Cuirot from comment #42)
> I don't believe this is a bug in Portage or PMS as things are working as
> intended. This has_version check is used to check whether we can execute
> automate. We avoid executing anything in the target system because that
> isn't safe. Even if you're not cross-compiling, the libc might be different,
> the target may have a newer glibc version, or there may be other subtle
> differences. In this particular case though, it necessary due to the awkward
> nature of bootstrapping prefix and it is probably safe enough.

This is where EPREFIX differs from ROOT.  A cross-prefix executing anything in the "target" is *guaranteed* to work (if dependencies are met).

> It worked before because you were essentially relying on a bug. EAPIs before
> 5 didn't know how to deal with this properly and the has_version call wasn't
> updated for newer EAPIs until now. What you're asking for shouldn't be
> considered normal behaviour because in order to execute automake, it is
> expected to be in the PATH. The target system wouldn't normally be in the
> PATH but heroxbd informed me that the bootstrap process hacks around this by
> adding it via PREROOTPATH.

Hmmmmm?  In stage3, we use a portage from /tmp (stage2), we override PREROOTPATH to make sure it uses tools from stage3 as they come available, because portage otherwise would only use tools from stage2 (/tmp).

The problem is that Portage just installed automake in the stage3 environment, but has_version reports it's not there, because it looks in stage2 environment.

Reason for this is that Portage doesn't ensure build dependencies exist in it's own EPREFIX (stage2).  This may be what EAPI7 intends to solve.

> Fear not though, as I do have an idea. If ROOT is already /, which it is for
> cross-prefix, then you can call has_version without --host-root for EAPI 5
> and 6, and with -d for EAPI 7. This should give the behaviour you need
> without negatively affecting anyone else. It is a bit of a hack so I suggest
> we only apply it to autotools.eclass when EPREFIX is non-empty for this
> specific case. Anything else should try to do the right thing. I'll prepare
> a patch.

This feels kind of fragile.  I wonder if ROOT and EPREFIX shouldn't be mutually exclusive.  Or at least an exclusive-or relationship.  You can't have both change at the same time if you want to make some sense.  (Or can you?)

That said, seems like if EPREFIX is different, you cant change ROOT, and vice versa.  If you set --host-root, you change ROOT, so you shouldn't change EPREFIX?

(In reply to Benda Xu from comment #44)
> I am convinced by the Chewi and the Portage Team that it is sane to require
> has_version --host-root to point the dependency to build-prefix.
> 
> The PORTAGE_OVERRIDE_EPREFIX usage for distinguishing build-prefix and
> target-prefix has been introduced by redlizard back in 2013 at
> https://gitweb.gentoo.org/proj/portage.git/commit/
> ?id=c9f6aa9f0151adb3c86706eaef191 .  At that time we had a big debate on the
> IRC on whether to abuse this variable.  Finally we had reached a conclusion
> to abuse it.  I hope this addresses Fabian's confusion.
> 
> Therefore to fix the bootstrap, we should have the portage regard stage3 as
> the build-prefix by setting PORTAGE_OVERRIDE_EPREFIX.  It will be
> future-proof to EAPI-7.

It is very well possible that we abuse stuff here :)  So what do you propose, to change emerge_pkgs() func from bootstrap-prefix.sh?  I assume that change would eliminate the need for any changes in eclasses (as Chewi wants to make) and Portage, right?
Comment 46 James Le Cuirot gentoo-dev 2018-06-13 08:57:45 UTC
I have a new simpler idea but I'll write more when I have time today.
Comment 47 Benda Xu gentoo-dev 2018-06-13 08:59:02 UTC
(In reply to Fabian Groffen from comment #45)
> (In reply to James Le Cuirot from comment #42)
> > Fear not though, as I do have an idea. If ROOT is already /, which it is for
> > cross-prefix, then you can call has_version without --host-root for EAPI 5
> > and 6, and with -d for EAPI 7. This should give the behaviour you need
> > without negatively affecting anyone else. It is a bit of a hack so I suggest
> > we only apply it to autotools.eclass when EPREFIX is non-empty for this
> > specific case. Anything else should try to do the right thing. I'll prepare
> > a patch.
> 
> This feels kind of fragile.  I wonder if ROOT and EPREFIX shouldn't be
> mutually exclusive.  Or at least an exclusive-or relationship.  You can't
> have both change at the same time if you want to make some sense.  (Or can
> you?)
> 
> That said, seems like if EPREFIX is different, you cant change ROOT, and
> vice versa.  If you set --host-root, you change ROOT, so you shouldn't
> change EPREFIX?

EPREFIX does not constrain ROOT and they change independently.  For example, to cross-build an embedded system from a Gentoo Prefix, ROOT changes from / to /nicepath/usr/CHOST, and EPREFIX changes from /nicepath to "".  This is a valid use case.

> (In reply to Benda Xu from comment #44)
> > I am convinced by the Chewi and the Portage Team that it is sane to require
> > has_version --host-root to point the dependency to build-prefix.
> > 
> > The PORTAGE_OVERRIDE_EPREFIX usage for distinguishing build-prefix and
> > target-prefix has been introduced by redlizard back in 2013 at
> > https://gitweb.gentoo.org/proj/portage.git/commit/
> > ?id=c9f6aa9f0151adb3c86706eaef191 .  At that time we had a big debate on the
> > IRC on whether to abuse this variable.  Finally we had reached a conclusion
> > to abuse it.  I hope this addresses Fabian's confusion.
> > 
> > Therefore to fix the bootstrap, we should have the portage regard stage3 as
> > the build-prefix by setting PORTAGE_OVERRIDE_EPREFIX.  It will be
> > future-proof to EAPI-7.
> 
> It is very well possible that we abuse stuff here :)  So what do you
> propose, to change emerge_pkgs() func from bootstrap-prefix.sh?  I assume
> that change would eliminate the need for any changes in eclasses (as Chewi
> wants to make) and Portage, right?

Yes, I am having portage to migrate into stage3 and it can naturally dig stage3 packages for its BDEPEND (or CBUILD).  I am doing the last rounds of tests and we are ready to go.
Comment 48 James Le Cuirot gentoo-dev 2018-06-13 13:07:14 UTC
(In reply to Fabian Groffen from comment #45)
> (In reply to James Le Cuirot from comment #42)
> > I don't believe this is a bug in Portage or PMS as things are working as
> > intended. This has_version check is used to check whether we can execute
> > automate. We avoid executing anything in the target system because that
> > isn't safe. Even if you're not cross-compiling, the libc might be different,
> > the target may have a newer glibc version, or there may be other subtle
> > differences. In this particular case though, it necessary due to the awkward
> > nature of bootstrapping prefix and it is probably safe enough.
> 
> This is where EPREFIX differs from ROOT.  A cross-prefix executing anything
> in the "target" is *guaranteed* to work (if dependencies are met).

Sorry, yes I should have been clearer on this point. I understand that this is safe for prefix but I'm just trying to avoid having different rules and behaviour because this stuff is confusing enough already. :)

> The problem is that Portage just installed automake in the stage3
> environment, but has_version reports it's not there, because it looks in
> stage2 environment.
> 
> Reason for this is that Portage doesn't ensure build dependencies exist in
> it's own EPREFIX (stage2).  This may be what EAPI7 intends to solve.

EAPI 7 does allow you to check against the systems targeted by BDEPEND, DEPEND, or RDEPEND, but in the automake context, we would normally want to execute it from BDEPEND whereas you want to execute it from DEPEND. This is why my patch splits the logic in two.

(In reply to Benda Xu from comment #47)
> EPREFIX does not constrain ROOT and they change independently.  For example,
> to cross-build an embedded system from a Gentoo Prefix, ROOT changes from /
> to /nicepath/usr/CHOST, and EPREFIX changes from /nicepath to "".  This is a
> valid use case.

Indeed, plus variables like EROOT are there for a reason!

> > (In reply to Benda Xu from comment #44)
> > > Therefore to fix the bootstrap, we should have the portage regard stage3 as
> > > the build-prefix by setting PORTAGE_OVERRIDE_EPREFIX.  It will be
> > > future-proof to EAPI-7.
> > 
> > It is very well possible that we abuse stuff here :)  So what do you
> > propose, to change emerge_pkgs() func from bootstrap-prefix.sh?  I assume
> > that change would eliminate the need for any changes in eclasses (as Chewi
> > wants to make) and Portage, right?
> 
> Yes, I am having portage to migrate into stage3 and it can naturally dig
> stage3 packages for its BDEPEND (or CBUILD).  I am doing the last rounds of
> tests and we are ready to go.

I'm not sure whether this would have other consequences but it would at least keep the hack in the prefix script and potentially deal with other issues similar to this one. I'm still surprised that Portage allows you to manually set PORTAGE_OVERRIDE_EPREFIX at all, was that intended?

If that doesn't pan out, I have another suggestion. Instead of checking for automake with has_version, we could just check whether it is in the PATH with "type -P automake-${pv}". Sure, it could *potentially* match some non-Gentoo version of it but that would only happen if you screw around with PREROOTPATH and you end up executing it via the PATH anyway, regardless of what has_version reports. That would make the eclass simpler, shorter, and it would still work equally well for everyone.
Comment 49 Zac Medico gentoo-dev 2018-06-13 19:52:06 UTC
(In reply to James Le Cuirot from comment #48)
> I'm still surprised that Portage allows you to manually set
> PORTAGE_OVERRIDE_EPREFIX at all, was that intended?

I originally introduced PORTAGE_OVERRIDE_EPREFIX in order to create temporary prefixes for use in unit tests, and it also found an internal use in cross-prefix support. It's also useful during development in a prefix environment, when running portage from a git checkout as described here:

   https://wiki.gentoo.org/wiki/Project:Portage#Testing_Portage

If PORTAGE_OVERRIDE_EPREFIX is somehow useful for bootstrap, then that's great, but obviously ebuilds may not behave well if they make assumptions about has_version and best_version results.
Comment 50 Larry the Git Cow gentoo-dev 2018-06-14 01:16:24 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=8207d9c59468ff32600463033821eec20197ca0f

commit 8207d9c59468ff32600463033821eec20197ca0f
Author:     Benda Xu <heroxbd@gentoo.org>
AuthorDate: 2018-06-13 02:12:17 +0000
Commit:     Benda Xu <heroxbd@gentoo.org>
CommitDate: 2018-06-14 01:15:23 +0000

    Regard stage3 as BDEPEND in terms of EAPI7.
    
      So that build dependencies are satisfied by stage3.
    
    Credit: Paul Preney, Byron Grobe, Stephen McCamant, Horea Christian
    Credit: giacomo.cappellini.87, kuzetsa, Kalon Mills, Joey Chagnon
    Closes: https://bugs.gentoo.org/655414
    Closes: https://bugs.gentoo.org/655326

 scripts/bootstrap-prefix.sh | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)
Comment 51 Benda Xu gentoo-dev 2018-06-14 01:21:25 UTC
(In reply to James Le Cuirot from comment #48)
> (In reply to Benda Xu from comment #47)
> > 
> > Yes, I am having portage to migrate into stage3 and it can naturally dig
> > stage3 packages for its BDEPEND (or CBUILD).  I am doing the last rounds of
> > tests and we are ready to go.
> 
> I'm not sure whether this would have other consequences but it would at
> least keep the hack in the prefix script and potentially deal with other
> issues similar to this one. I'm still surprised that Portage allows you to
> manually set PORTAGE_OVERRIDE_EPREFIX at all, was that intended?

This is intended because portage has this flexibility, so why not?

Well, the biggest use case is to relocate a Prefix.  You copy everything over to the new directory and env PORTAGE_OVERRIDE_EPREFIX=new_prefix-dir emerge -e @world and everything is migrated.

> If that doesn't pan out, I have another suggestion. Instead of checking for
> automake with has_version, we could just check whether it is in the PATH
> with "type -P automake-${pv}". Sure, it could *potentially* match some
> non-Gentoo version of it but that would only happen if you screw around with
> PREROOTPATH and you end up executing it via the PATH anyway, regardless of
> what has_version reports. That would make the eclass simpler, shorter, and
> it would still work equally well for everyone.

It's not only automake, but also python.  Let's stick with has_version.
Comment 52 Michael Haubenwallner (RETIRED) gentoo-dev 2018-06-14 06:48:42 UTC
Feels like moving portage around is a workaround for:
* missing knowledge about portage's capability goals to manage another prefix
* probably combined with portage bugs managing another prefix.

Independent of that: I do believe we have quite some confusion here regarding the usage of the words 'host', 'prefix' and 'root', getting worse when combined with various cross situations.
Thus I'm currently trying to compile some cleanup comment - if only for myself...
Comment 53 Benda Xu gentoo-dev 2018-06-14 07:02:11 UTC
(In reply to Michael Haubenwallner from comment #52)
> Feels like moving portage around is a workaround for:
> * missing knowledge about portage's capability goals to manage another prefix

No, here it is a different problem.  The stage2 portage is incomplete (e.g. no perl), therefore we cannot reply on it to manage another prefix without manual care.

The cross-prefix is still valid for a full-fledged Prefix.

> * probably combined with portage bugs managing another prefix.
> 
> Independent of that: I do believe we have quite some confusion here
> regarding the usage of the words 'host', 'prefix' and 'root', getting worse
> when combined with various cross situations.

Luckily --host-root is deprecated in EAPI-7.  Let's move forward and hug EAPI-7.

> Thus I'm currently trying to compile some cleanup comment - if only for
> myself...

Sure.
Comment 54 Michael Haubenwallner (RETIRED) gentoo-dev 2018-06-14 15:08:13 UTC
Created attachment 535866 [details]
an approach to define various meanings of words 'prefix', 'root' and 'host'

Maybe this word clarification approach helps someone else too - improvements welcome!

With that now, I get the impression that the reason causing this very bug originates in portage's EAPI 7 support, specifically due to:

* portage seems to not add EPREFIX locations to PATH any more - even if [[ ${ROOT%/} == "" ]], and [[ ${CHOST} == ${CBUILD} ]]

combined with:

* maybe increased use of explicit has/best_version, which look in BROOT only due to some flag, while they probably should look in EPREFIX too - but only if [[ ${ROOT%/} == "" ]]

and eventually:

* since there is BROOT, it should be synchronized with PORTAGE_OVERRIDE_EPREFIX
Comment 55 James Le Cuirot gentoo-dev 2018-06-14 15:23:01 UTC
(In reply to Michael Haubenwallner from comment #54)
> Created attachment 535866 [details]
> an approach to define various meanings of words 'prefix', 'root' and 'host'
> 
> Maybe this word clarification approach helps someone else too - improvements
> welcome!

Will read later, thanks.

> With that now, I get the impression that the reason causing this very bug
> originates in portage's EAPI 7 support, specifically due to:
> 
> * portage seems to not add EPREFIX locations to PATH any more - even if [[
> ${ROOT%/} == "" ]], and [[ ${CHOST} == ${CBUILD} ]]

I don't think this has ever been the case? heroxbd said he was already adding it via PREROOTPATH. We shouldn't ever consider it normal behaviour to have the target system in the PATH, even if you can safely execute stuff from there, because it is the build system that is supposed to do the building. We're just bending the rules with PORTAGE_OVERRIDE_EPREFIX here to get through the awkward bootstrap process.

> combined with:
> 
> * maybe increased use of explicit has/best_version, which look in BROOT only
> due to some flag, while they probably should look in EPREFIX too - but only
> if [[ ${ROOT%/} == "" ]]

No because that would change the meaning of the flags. If you give -b then that means check the build system, which is the system in the PATH. If you check the target system, which isn't (normally) in the PATH, then the tool you're looking for might not be found when you try to run it.

> and eventually:
> 
> * since there is BROOT, it should be synchronized with
> PORTAGE_OVERRIDE_EPREFIX

It already is. PORTAGE_OVERRIDE_EPREFIX is equivalent to portage.const.EPREFIX and the line from LocationsManager.py in Portage is:

  self.broot = portage.const.EPREFIX
Comment 56 Michael Haubenwallner (RETIRED) gentoo-dev 2018-06-15 11:19:29 UTC
(In reply to Larry the Git Cow from comment #50)
> The bug has been closed via the following commit(s):
> 
> https://gitweb.gentoo.org/repo/proj/prefix.git/commit/
> ?id=8207d9c59468ff32600463033821eec20197ca0f

It turns out that the RAP profile does not set FEATURES="collision-protect",
while the non-RAP (guest) profile does, unable to merge portage in stage3 now.

While I could disable collision-protect to merge portage in stage3, moving the installed portage around does feel ...wrong - time to really dive into now.
Comment 57 Fabian Groffen gentoo-dev 2018-06-15 11:24:37 UTC
I was already affraid of that when I saw the commit to remove removing makeinfo.  What we basically would like to have is a FEATURES=protect-owned-and-non-prefix, which effectively is protect-owned under $EPREFIX and outside of it deny.

Thinking of it, with the QA checks already not accepting stuff outside the prefix, protect-owned should be good enough for Prefix too.
Comment 58 James Le Cuirot gentoo-dev 2018-06-15 11:34:37 UTC
What is colliding exactly? Am I right in thinking that it's trying to install build dependencies but they end up being written to the target system? This isn't great but if you don't care what happens to stage2 in the end, I suppose it doesn't matter. Would using FEATURES="protect-owned" work instead? This is actually the default.
Comment 59 Michael Haubenwallner (RETIRED) gentoo-dev 2018-06-15 11:36:20 UTC
Note that the stage1 portage is a prefix-portage,
while the RAP final portage is not.

Beyond the collisions, copying prefix-portage from stage1 into final leaves orphan files around, because the final portage does install different files.
Comment 60 James Le Cuirot gentoo-dev 2018-06-15 11:36:47 UTC
Sorry, missed Fabian's comments on protect-owned. I think it would be good enough.
Comment 61 Michael Haubenwallner (RETIRED) gentoo-dev 2018-06-15 11:43:07 UTC
(In reply to James Le Cuirot from comment #58)
> What is colliding exactly?

Merging sys-apps/portage in stage3 as GUEST fails with:

 * Detected file collision(s):
 *
 *  /tools/haubi/gentoo/bug655414t0/guest/usr/lib/portage/bin/deprecated-path
 *  /tools/haubi/gentoo/bug655414t0/guest/usr/share/portage/config/repos.conf
 *  /tools/haubi/gentoo/bug655414t0/guest/usr/share/portage/config/make.globals
 *  /tools/haubi/gentoo/bug655414t0/guest/usr/share/portage/config/make.conf.example
 *  /tools/haubi/gentoo/bug655414t0/guest/usr/share/portage/config/sets/portage.conf
 *
 * Searching all installed packages for file collisions... 
 * 
 * Press Ctrl-C to Stop
 * 
 * None of the installed packages claim the file(s).
 * 
 * Package 'sys-apps/portage-2.3.40.1' NOT merged due to file collisions.


The same collision happen for RAP, but it is ignored there:

 * Detected file collision(s):
 *  
 *  /tools/haubi/gentoo/bug655414t0/rap/usr/lib/portage/bin/deprecated-path
 *  /tools/haubi/gentoo/bug655414t0/rap/usr/share/portage/config/repos.conf
 *  /tools/haubi/gentoo/bug655414t0/rap/usr/share/portage/config/make.globals
 *  /tools/haubi/gentoo/bug655414t0/rap/usr/share/portage/config/make.conf.example
 *  /tools/haubi/gentoo/bug655414t0/rap/usr/share/portage/config/sets/portage.conf
 *  
 * Searching all installed packages for file collisions...
 *  
 * Press Ctrl-C to Stop
 *  
 * None of the installed packages claim the file(s).
 *  
 * Package 'sys-apps/portage-2.3.40-r1' merged despite file collisions.
Comment 62 Fabian Groffen gentoo-dev 2018-06-15 11:43:45 UTC
(In reply to James Le Cuirot from comment #58)
> What is colliding exactly? Am I right in thinking that it's trying to
> install build dependencies but they end up being written to the target
> system? This isn't great but if you don't care what happens to stage2 in the
> end, I suppose it doesn't matter. Would using FEATURES="protect-owned" work
> instead? This is actually the default.

we do nasty things like symlinking tools (makeinfo, python2.7) to get certain configure and ebuilds/eclasses happy.  It is impossible to bootstrap an environment pulling in one by one deps, there's many loops in the dependencies that somehow need to get broken.
Comment 63 Benda Xu gentoo-dev 2018-06-15 13:54:37 UTC
Hi Michael,

(In reply to Michael Haubenwallner from comment #61)
> (In reply to James Le Cuirot from comment #58)
> > What is colliding exactly?
> 
> Merging sys-apps/portage in stage3 as GUEST fails with:
> 
>  * Detected file collision(s):
>  *
>  *  /tools/haubi/gentoo/bug655414t0/guest/usr/lib/portage/bin/deprecated-path
>  *  /tools/haubi/gentoo/bug655414t0/guest/usr/share/portage/config/repos.conf
>  * 
> /tools/haubi/gentoo/bug655414t0/guest/usr/share/portage/config/make.globals
>  * 
> /tools/haubi/gentoo/bug655414t0/guest/usr/share/portage/config/make.conf.
> example
>  * 
> /tools/haubi/gentoo/bug655414t0/guest/usr/share/portage/config/sets/portage.
> conf
>  *
>  * Searching all installed packages for file collisions... 
>  * 
>  * Press Ctrl-C to Stop
>  * 
>  * None of the installed packages claim the file(s).
>  * 
>  * Package 'sys-apps/portage-2.3.40.1' NOT merged due to file collisions.

Oh, sorry I didn't test and confirm with prefix-guest.
Comment 64 Benda Xu gentoo-dev 2018-06-15 13:57:23 UTC
(In reply to Fabian Groffen from comment #57)
> I was already affraid of that when I saw the commit to remove removing
> makeinfo.  

Many times a random patch to some package will change the timestamps of some files and trigger regeneration of .info documents.
Comment 65 Michael Haubenwallner (RETIRED) gentoo-dev 2018-06-18 16:39:43 UTC
(In reply to Benda Xu from comment #63)
> Hi Michael,
> 
> (In reply to Michael Haubenwallner from comment #61)
> > 
> > Merging sys-apps/portage in stage3 as GUEST fails with:
> 
> Oh, sorry I didn't test and confirm with prefix-guest.

Never mind, this is what my dev status and buildbot slaves have to deal with.
Comment 66 Larry the Git Cow gentoo-dev 2018-06-20 08:12:13 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8fda0a70c015ef799c81167d9e26b0c70733a7d0

commit 8fda0a70c015ef799c81167d9e26b0c70733a7d0
Author:     Fabian Groffen <grobian@gentoo.org>
AuthorDate: 2018-06-20 08:06:28 +0000
Commit:     Fabian Groffen <grobian@gentoo.org>
CommitDate: 2018-06-20 08:12:07 +0000

    profiles/prefix/make.defaults: drop FEATURES=collision-protect
    
    After many years, we finally came to the conclusion we don't need this
    any more, and can do with protect-owned (the default) very well.
    
    Most prominent reason for this is that Gentoo for Mac OS X has been
    superseeded by Gentoo Prefix for macOS, which no longer tries to install
    binaries side by side with the host provided utilities.  E.g. it is no
    longer the case that files encountered as a conflict can be something
    that is provided by the host system (and hence should not be nuked).
    
    In Gentoo Prefix we assume that $EPREFIX is solely managed by the PM, so
    anything it finds there which it doesn't know about can be safely
    overwritten.  Users that actually use EPREFIX=/ on their systems can set
    FEATURES=collision-protect in their local make.conf.
    
    Bug: https://bugs.gentoo.org/655414

 profiles/prefix/make.defaults | 2 --
 1 file changed, 2 deletions(-)
Comment 67 Benda Xu gentoo-dev 2018-06-20 11:45:51 UTC
Michael, now that we have dropped FEATURES=collision-protect, is moving portage still a bad idea?
Comment 68 Larry the Git Cow gentoo-dev 2018-06-20 12:06:10 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=ce515e60309e2e2c51577410b111209eec5754d0

commit ce515e60309e2e2c51577410b111209eec5754d0
Author:     Michael Haubenwallner <haubi@gentoo.org>
AuthorDate: 2018-06-20 12:02:37 +0000
Commit:     Michael Haubenwallner <haubi@gentoo.org>
CommitDate: 2018-06-20 12:02:37 +0000

    bootstrap-prefix.sh: apply 'stacked-prefix' patch
    
    Introducing the 'stacked-prefix' portage FEATURE via temporary patch,
    subject to be dropped from bootstrap-prefix.sh script once integrated.
    
    This replaces commit 8207d9c59468ff32600463033821eec20197ca0f.
    
    Closes: https://bugs.gentoo.org/655326
    Closes: https://bugs.gentoo.org/655414

 scripts/bootstrap-prefix.sh | 71 ++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 70 insertions(+), 1 deletion(-)
Comment 69 Michael Haubenwallner (RETIRED) gentoo-dev 2018-06-20 12:36:00 UTC
(In reply to Benda Xu from comment #67)
> Michael, now that we have dropped FEATURES=collision-protect, is moving
> portage still a bad idea?

Yes, simply because portage files from /tmp do have the /tmp prefix hardcoded.

Beyond that, there are unmaintained files left:
usr/lib/portage/pym/ and maybe others is installed _without_ the ebuild only.
Comment 70 Benda Xu gentoo-dev 2018-12-20 11:29:37 UTC
Hi Michael,

Unfortunately, the stacked prefix approach does not completely solve this bug.  The remnants of this bug becomes bug 668940.  If stacked-prefix is used, 2 problems rises:

1. In portage, the target eprefix (or target ROOT) does not accept pollution of USE flags from the environment.  That causes dependency circles.

2. From EAPI-7, BDEPENDS are installed into CBUILD, which is EPREFIX/tmp.  That is in conflict with the design of the bootstrap script, namely stage2 into EPREFIX/tmp and stage3 into EPREFIX.  The conflict results in many bugs.

I understand your concern on the orphan files.  It can be easily dealt with by a file list.  The files in /usr/share/portage/ is relatively stable, there won't be too much changes.

Therefore I would like to at first revert Linux-standalone targets with my old moving portage approach.  I will leave it up to you to judge whether linux-rpath and friends are needed to be changed as well.

Benda
Comment 71 Benda Xu gentoo-dev 2018-12-20 11:29:54 UTC
*** Bug 668940 has been marked as a duplicate of this bug. ***
Comment 72 Larry the Git Cow gentoo-dev 2018-12-23 10:32:51 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=a6f69ff45bbbb8b7207569220060a2662c0cb9a7

commit a6f69ff45bbbb8b7207569220060a2662c0cb9a7
Author:     Benda Xu <heroxbd@gentoo.org>
AuthorDate: 2018-12-22 13:43:53 +0000
Commit:     Benda Xu <heroxbd@gentoo.org>
CommitDate: 2018-12-23 10:32:02 +0000

    scripts/bootstrap-prefix.sh: move portage from stage2 to 3.
    
      AS a rework of 8207d9c59468ff32600463033, this is only applied to
      prefix-standalone.
    
    Bug: https://bugs.gentoo.org/655414
    Signed-off-by: Benda Xu <heroxbd@gentoo.org>

 scripts/bootstrap-prefix.sh | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)
Comment 73 Fabian Groffen gentoo-dev 2019-02-19 12:27:14 UTC
this issues has been resolved as far as our bootstraps can tell