|Summary:||enhancement to news item for profile 17.1 - emerge -1v /lib32 /usr/lib32 is not sufficient, as it does not correctly order the rebuilds|
|Product:||Gentoo Linux||Reporter:||Jack <ostroffjh>|
|Component:||Profiles||Assignee:||Michał Górny <mgorny>|
|Severity:||normal||CC:||base-system, leonard, luke, pacho|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
Description Jack 2019-06-07 20:52:17 UTC
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
Comment 1 Jack 2019-06-07 20:53:54 UTC
I suppose "Reproducible: Always" isn't quite right, since this task will only ever be done once on any system.
Comment 2 Sergei Trofimovich 2019-06-08 17:35:04 UTC
Not much for toolchain@ to do here.
Comment 3 rnddim 2019-06-10 02:41:04 UTC
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.
Comment 4 Jack 2019-06-10 13:20:59 UTC
(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.
Comment 5 Michael Haubenwallner 2019-09-23 07:59:11 UTC
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'?
Comment 6 Jack 2019-10-27 16:40:21 UTC
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.
Comment 7 Stefan Huber 2019-12-11 09:14:05 UTC
I can confirm this issue. Just happened for libX11 missing libxcb, missing xcb-proto. I am currently approximately in --keep-going cycle #3…
Comment 8 Jack 2020-05-20 21:33:41 UTC
Again asking if it's time to close this.