First, and hoepfully minor, I just did an eix-sync (2019-06-07 4:45PM New York timd) and the news item 2017-12-26-experimental-amd64-17-1-profiles has been removed from my system, but the new item 2019-06-05 is not on the list. Hopefully I've just done something wrong. Main point is that item 11 (emerge -1v /lib32 /usr/lib32) is not sufficient, as it does not correctly order the rebuilds, so things fail due to not finding something later on the list. For example, see bug 645540, which discussion also spilled over into the tracker bug. For me, doing "emerge -1 --deep /lib32 /usr/lib32" got everything in the right order. Reproducible: Always Steps to Reproduce: Follow the instructions in the news item for 17.1. Actual Results: "emerge /lib32 /usr/lib32" fails for some package, being unable to find a package which is later on the list for rebuilding. Expected Results: emerge correctly orders rebuilds, so dependencies are built first
I suppose "Reproducible: Always" isn't quite right, since this task will only ever be done once on any system.
Not much for toolchain@ to do here.
This is a real problem for me. --deep didn't help me, so right now I'm hoping that using --exclude on problem packages and then doing a second pass over the lib32 directories will work. It feels like there's something missing from the instructions in the news item.
(In reply to rnddim from comment #3) > .... --deep didn't help me, so right now I'm hoping that using --exclude on problem packages and then doing a second pass.... I'd add --keep-going, not use --exclude, and just repeat the whole thing, as long as it gets more packages done on each pass. In a different post, someone also suggested --complete-graph, but I did not need it, so don't know what difference it would make.
Although not a build failure here, but the single advise in 17.1 news item $ emerge -1v --deep /lib32 /usr/lib32 /usr/lib/llvm/*/lib32 does leave some packages (fex. gnome-base/librsvg-2.40.20) providing some /lib32 dir, even if they were rebuilt during that command. Performing the same command again does rebuild the remaining packages here. Maybe repeat until 'equery b lib32' yields nothing? For the OP: Have you been able to try with '--emptytree'?
Is this now sufficiently outdated to close? Not sure if it should be called Fixed, Notabug, or Worksforme? In specific reply to the last question in Comment #5, no, I did not try --emptytree, as I succeeded with a few reiterations with --keep-going.
I can confirm this issue. Just happened for libX11 missing libxcb, missing xcb-proto. I am currently approximately in --keep-going cycle #3…
Again asking if it's time to close this.