When using bootstrap-prefix.sh on macOS Sierra 10.12.3, stage1 wget is built --without-ssl. This wouldn't be an issue, except that, in stage2, make.globals calls wget with "--no-check-certificate", which is not present unless wget is built --with-ssl. As a result, stage2 fails attempting to fetch any files. Reproducible: Always Steps to Reproduce: 1. Run bootstrap-prefix.sh $EPREFIX stage1 (this works, assuming that a workaround from #609290 is used) 2. Run bootstrap-prefix.sh $EPREFIX stage2 Actual Results: stage2 emerge is unable to download source files via the wget built in stage1 Expected Results: One of the following: 1) stage1 should build wget --with-ssl (probably a bad idea, but it would solve the problem) 2) stage2 portage should not pass --no-check-certificate to wget (this would fail on systems with built-in wget that do check certificates) 3) stage2 portage should check if wget was built --with-ssl, and add --no-check-certificate accordingly (this might need to be done with post-emerge checking and immediate editing of $EPREFIX/usr/share/portage/config/make.globals; or alternatively by a patch to portage built during stage1, and ensuring that wget is built with ssl support before portage is reemerged later)
Fixed in https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=f5840c3791b26a429407aa68291241a5af87c8a7 Thanks for the report!
(In reply to Michael Haubenwallner from comment #1) > Fixed in > https://gitweb.gentoo.org/repo/proj/prefix.git/commit/ > ?id=f5840c3791b26a429407aa68291241a5af87c8a7 > > Thanks for the report! Thanks for the quick fix. Come to think of it, we should probably instead put a line into make.conf (both /tmp/etc/portage and /etc/portage), with a comment (and notice in the script) telling the user to remove it later (i.e.: when wget is re-emerged with SSL, or after emerge -e world is done). Adding it to make.globals will cause it to remain after the prefix is fully ready, which is probably not desired behavior.
(In reply to Isaac Richter from comment #2) > Come to think of it, we should probably instead put a line into make.conf > (both /tmp/etc/portage and /etc/portage), with a comment (and notice in the > script) telling the user to remove it later (i.e.: when wget is re-emerged > with SSL, or after emerge -e world is done). Telling the user something means it won't happen. > Adding it to make.globals will cause it to remain after the prefix is fully > ready, which is probably not desired behavior. Doesn't subsequent (during bootstrap still) remerge of portage overwrite make.globals?
(In reply to Michael Haubenwallner from comment #3) > > Doesn't subsequent (during bootstrap still) remerge of portage overwrite > make.globals? Hmm... possibly. It's not obvious that wget will be reemerged with ssl before portage overwrites make.globals.
(In reply to Isaac Richter from comment #4) > Hmm... possibly. It's not obvious that wget will be reemerged with ssl > before portage overwrites make.globals. When wget was without ssl, we did not add --no-check-certificate firsthand... Other than that: Without ssl support in wget, we fail to download gcc patches from dev.gentoo.org, where toolchain.eclass uses https nowadays... Not sure how to deal with that though.
It should try mirrors first (from Portage), so if we use files that are no longer in gx86, we just need to upload them to /space/distfiles-local (+/space/distfiles-whitelist/prefix) to make them available over http via the mirrors.
For distfiles required by ebuilds in prefix-overlay, https://github.com/redlizard/prefix-whitelists still is updating /space/distfiles-whitelist/prefix-{tree,bootstrap-snapshot} - but that has stopped being useful since prefix-overlay moved from mercurial to git. Cloned into https://github.com/gentoo/prefix-whitelists: now updating links, porting to git...
Continues in bug#612122.
