>>> Downloading 'http://distfiles.gentoo.org/distfiles/gnuconfig-20180101.tar.bz2' --2020-05-31 14:27:58-- http://distfiles.gentoo.org/distfiles/gnuconfig-20180101.tar.bz2 Resolving distfiles.gentoo.org (distfiles.gentoo.org)... 2605:bc80:3010::134, 2600:3402:200:227::2, 2600:3404:200:237::2, ... Connecting to distfiles.gentoo.org (distfiles.gentoo.org)|2605:bc80:3010::134|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2020-05-31 14:27:58 ERROR 404: Not Found. >>> Downloading 'http://gentoo-distfiles.mirrors.tds.net/distfiles/gnuconfig-20180101.tar.bz2' --2020-05-31 14:27:58-- http://gentoo-distfiles.mirrors.tds.net/distfiles/gnuconfig-20180101.tar.bz2 Resolving gentoo-distfiles.mirrors.tds.net (gentoo-distfiles.mirrors.tds.net)... 216.165.129.135 Connecting to gentoo-distfiles.mirrors.tds.net (gentoo-distfiles.mirrors.tds.net)|216.165.129.135|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2020-05-31 14:27:58 ERROR 404: Not Found. >>> Downloading 'https://ftp.halifax.rwth-aachen.de/gentoo/distfiles/gnuconfig-20180101.tar.bz2' --2020-05-31 14:27:58-- https://ftp.halifax.rwth-aachen.de/gentoo/distfiles/gnuconfig-20180101.tar.bz2 Resolving ftp.halifax.rwth-aachen.de (ftp.halifax.rwth-aachen.de)... 2a00:8a60:e012:a00::21, 137.226.34.46 Connecting to ftp.halifax.rwth-aachen.de (ftp.halifax.rwth-aachen.de)|2a00:8a60:e012:a00::21|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2020-05-31 14:27:59 ERROR 404: Not Found. >>> Downloading 'http://gentoo.ussg.indiana.edu/distfiles/gnuconfig-20180101.tar.bz2' --2020-05-31 14:27:59-- http://gentoo.ussg.indiana.edu/distfiles/gnuconfig-20180101.tar.bz2 Resolving gentoo.ussg.indiana.edu (gentoo.ussg.indiana.edu)... 156.56.247.195 Connecting to gentoo.ussg.indiana.edu (gentoo.ussg.indiana.edu)|156.56.247.195|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2020-05-31 14:27:59 ERROR 404: Not Found. >>> Downloading 'https://gentoo.osuosl.org/distfiles/gnuconfig-20180101.tar.bz2' --2020-05-31 14:27:59-- https://gentoo.osuosl.org/distfiles/gnuconfig-20180101.tar.bz2 Resolving gentoo.osuosl.org (gentoo.osuosl.org)... 2600:3404:200:237::2, 2605:bc80:3010::134, 2600:3402:200:227::2, ... Connecting to gentoo.osuosl.org (gentoo.osuosl.org)|2600:3404:200:237::2|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2020-05-31 14:27:59 ERROR 404: Not Found. !!! Couldn't download 'gnuconfig-20180101.tar.bz2'. Aborting. * Fetch failed for 'sys-devel/gnuconfig-20180101', Log file: * '/home/q/gentoo/var/tmp/portage/sys-devel/gnuconfig-20180101/temp/build.log'
Created attachment 642894 [details] stage3.log
I'll upload the file, I think we need a new snapshot as general fix
ok, brilliant, uploading distfiles is no longer possible, please pull the file manually from: https://bootstrap.prefix.bitzolder.nl/results/x86_64-pc-solaris2.11/20190713/distfiles/gnuconfig-20180101.tar.bz2
That worked, thanks. Do you update the snapshot manually from time to time? Why can't it be done automatically?
The next missing file is openssl-1.1.1b.tar.gz for dev-libs/openssl-1.1.1b-r2
Ah, the one from https://www.openssl.org/source/old/1.1.1/ works
(In reply to Alexey from comment #4) > That worked, thanks. Do you update the snapshot manually from time to time? > Why can't it be done automatically? It usually breaks in subtle and not so subtle ways. So this is done manually. One can, however, bootstap using a nightly snapshot, or even an rsync snapshot, but that's meant for people who understand that this brings unknown factors into the process. (In reply to Alexey from comment #6) > Ah, the one from https://www.openssl.org/source/old/1.1.1/ works nice, I'm working on a replacement to put the missing sources online (without manual searching and all) such that this being out of date no longer is an issue. Note that as part of the bootstrap, the tree is refreshed and everything is re-installed, so the end result is a fully up-to-date environment. This only affects the bootstrap environment.
> this brings unknown factors into the process. Outdated snapshot also brings unknown factors. > the tree is refreshed and everything is re-installed Gentoo doesn't support refreshing too rarely, which is how it broke for me this time. Perhaps it could refresh several times, e.g. with 1 month interval between snapshots, instead of making 1 big leap? Not sure whether it would help though. * stage3 successfully finished * running emerge -e system Deleting invalid mtimedb key: cleared_backup Calculating dependencies... done! The following mask changes are necessary to proceed: (see "package.unmask" in the portage(5) man page for more details) # required by @system (argument) # /home/q/gentoo/var/db/repos/gentoo/profiles/package.mask: # Michał Górny <mgorny@gentoo.org>, Andreas K. Hüttel <dilfridge@gentoo.org>, # Matthias Maier <tamiko@gentoo.org> (2017-05-21 and later updates) # These old versions of toolchain packages (binutils, gcc, glibc) are no # longer officially supported and are not suitable for general use. Using # these packages can result in build failures (and possible breakage) for # many packages, and may leave your system vulnerable to known security # exploits. # If you still use one of these old toolchain packages, please upgrade (and # switch the compiler / the binutils) ASAP. If you need them for a specific # (isolated) use case, feel free to unmask them on your system. =sys-devel/binutils-2.32-r1 NOTE: The --autounmask-keep-masks option will prevent emerge from creating package.unmask or ** keyword changes. Use --autounmask-write to write changes to config files (honoring CONFIG_PROTECT). Carefully examine the list of proposed changes, paying special attention to mask or keyword changes that may expose experimental or unstable packages. !!! The ebuild selected to satisfy ">=dev-util/glib-utils-2.56.2" has unmet requirements. - dev-util/glib-utils-2.64.3::gentoo_prefix USE="(prefix) (prefix-guest)" PYTHON_SINGLE_TARGET="python3_6 python3_7 -python3_8" The following REQUIRED_USE flag constraints are unsatisfied: exactly-one-of ( python_single_target_python3_6 python_single_target_python3_7 python_single_target_python3_8 ) (dependency required by "dev-libs/glib-2.56.2::gentoo_prefix" [ebuild]) (dependency required by "dev-util/pkgconfig-0.29.2::gentoo_prefix[-internal-glib]" [ebuild]) (dependency required by "virtual/pkgconfig-1::gentoo_prefix" [ebuild]) (dependency required by "net-misc/wget-1.20.3-r3::gentoo_prefix" [ebuild]) (dependency required by "@system" [argument]) Oh yeah, I thought I was almost there, and then this! I did emerge -e system and it failed at some point :( Details might be found in the build log: (no build logs found?!?) I have no clue, really. Please find friendly folks in #gentoo-prefix on irc.gentoo.org, gentoo-alt@lists.gentoo.org mailing list, or file a bug at bugs.gentoo.org under Gentoo/Alt, Prefix Support. You know, I got the feeling you just started to like me, but I guess that's all gone now. I'll bother you no longer. -------------------------------- Masking as it suggests shows the next failure: * running emerge -e system Deleting invalid mtimedb key: cleared_backup Calculating dependencies... done! !!! The ebuild selected to satisfy ">=dev-util/glib-utils-2.56.2" has unmet requirements. - dev-util/glib-utils-2.64.3::gentoo_prefix USE="(prefix) (prefix-guest)" PYTHON_SINGLE_TARGET="python3_6 python3_7 -python3_8" The following REQUIRED_USE flag constraints are unsatisfied: exactly-one-of ( python_single_target_python3_6 python_single_target_python3_7 python_single_target_python3_8 ) (dependency required by "dev-libs/glib-2.56.2::gentoo_prefix" [ebuild]) (dependency required by "dev-util/pkgconfig-0.29.2::gentoo_prefix[-internal-glib]" [ebuild]) (dependency required by "virtual/pkgconfig-1::gentoo_prefix" [ebuild]) (dependency required by "net-misc/rsync-3.1.3::gentoo_prefix" [ebuild]) (dependency required by "@system" [argument]) ---------------------------------- Adding "*/* PYTHON_SINGLE_TARGET: -python3_6" shows more failures, so I disabled 3.7 for now. I also had to add "=dev-util/itstool-2.0.6-r1 **" to accept_keywords for ::gentoo_prefix
this is exactly the kind of breakage I meant
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=fda55219e37e3fb4dcb7768802330907cc1af405 commit fda55219e37e3fb4dcb7768802330907cc1af405 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2020-06-01 09:49:13 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2020-06-01 09:55:00 +0000 scripts/bootstrap-prefix: rework efetch(ing) logic somewhat 1) distfiles are in transitioning to hash-based subdir layout 2) distfiles cannot be manually appended to any more To fix 1) use redirection service from distfiles.prefix.b.n to simply calculate the hash, so our existing calls will keep working. To fix 2) use same redirection service, but on /prefix url, that points to a local distfiles mirror for missing files, hopefully providing what's missing The order in efetch tries things now is a bit odd and long, but avoids using the redirection service: 1) try GENTOO_MIRRORS provided hosts, or http://distfiles.g.o when unset 2) try http://distfiles.prefix.b.n to redirect to distfiles (for when the hash approach becomes mandatory) 3) try http://distfiles.prefix.b.n/prefix to redirect to prefix-local distfiles (using the same hash approach) 4) try the original source location Bug: https://bugs.gentoo.org/726462 Signed-off-by: Fabian Groffen <grobian@gentoo.org> scripts/bootstrap-prefix.sh | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
this should be solved by the hosting of distfiles which I provide myself for bootstraps
