Created attachment 516304 [details] emerge --info configure says `checking for CAIRO... no`, which could be the issue here. emerge --info, emerge -pqv, build.log attached.
Created attachment 516306 [details] emerge -pqv
Created attachment 516308 [details] build.log
Note: I got this bug after I followed the news item for the 17.1 profile. It shows up when I try to do the last step, `emerge -av /lib32 /usr/lib32`. Attached is the folders' contents.
Created attachment 516312 [details] /usr/lib32 and /lib32 contents
Please attach "/var/tmp/portage/x11-libs/pango-1.40.14/work/pango-1.40.14-abi_x86_32.x86/config.log"
I will have to install Gentoo in a VM then try to migrate it to 17.1. I will add the config.log this weekend.
Look my last comment (comment #82) in bug 506276 I managed to have all packages including pango capable for rebuilding by disabling ABI x64_32 globally and then rebuilding the world and then I could do again emerge -1v /usr/lib32 with the result that no-one apart from mesa claims files in /usr/lib32. I'm on the way to restore the 32-ABI. Will report on the result.
(In reply to Alex from comment #7) > Look my last comment (comment #82) in bug 506276 > > I managed to have all packages including pango capable for rebuilding by > disabling ABI x64_32 globally and then rebuilding the world and then I could > do again > emerge -1v /usr/lib32 > with the result that no-one apart from mesa claims files in /usr/lib32. > > I'm on the way to restore the 32-ABI. Will report on the result. How about, USE=-abi_x86_32 emerge -1v /lib32 /usr/lib32 && emerge --changed-use -v1D @world ? Because I had a lot of multilib packages I did not want to rebuild it. I will test this command in a VM shortly.
(In reply to John Dallahan from comment #8) > (In reply to Alex from comment #7) > > Look my last comment (comment #82) in bug 506276 > > > > I managed to have all packages including pango capable for rebuilding by > > disabling ABI x64_32 globally and then rebuilding the world and then I could > > do again > > emerge -1v /usr/lib32 > > with the result that no-one apart from mesa claims files in /usr/lib32. > > > > I'm on the way to restore the 32-ABI. Will report on the result. > > How about, USE=-abi_x86_32 emerge -1v /lib32 /usr/lib32 && emerge > --changed-use -v1D @world ? > Because I had a lot of multilib packages I did not want to rebuild it. I > will test this command in a VM shortly. No way. First world and then STILL again /usr/lib32. The point is that if you try to disable some flags (not necessarily ABI) and issue emerge over /usr/lib32, the dependency tracker will fail because many other packages (higher level) who rely on the libraries in /usr/lib32 are already build with some flags for these libraries in mind. emerge will not start, I tried. What is really strange (and bad), however, is that rebuilding the world will still put files of, for example pango, explicitly in /usr/lib32. But emerge will go without mistakes. Later, you will have to do again emerge -1v /usr/lib32 and only then pango would say nothing about lib32. Weird in my opinion. I have a thought that you can try rebuilding the world without disabling anything, but this may be not true. In my case, pango was 732 in the queue for world re-emerging and I was reluctant to try different options. I decided to go immediately without 32-ABI to eliminate as much as possible enquires for lib32.
In the general bug about migration I have completed my observations. I believe it is emerge whom to blame for oddities of the process.
Is there anything to fix here for pango or cairo gentoo maintainers?
The failure still exists with pango-1.42.4-r1. At first I had several failures during the configure stage, but those all resolved by re-emerging the packages it apparently couldn't find, and now I'm left with the same error. Note I have "checking for CAIRO... yes" so I suspect that's a red herring. I also have not removed abi_x86_32. At this point, it looks to me like this bug should block the 17.1 migration tracker bug 506276.
Sorry - I need to correct myself. I do have "no" for finding Cairo in 32 bit, but "yes" in 64 bit. That confuses me, because if it didn't find it, why would it be looking for it at all during compile phase for 32 bit?
Is there a way to solve this? I stuck at 1/3 of 17.0 to 17.1 migration making this system partially unusable and completely unupdateable.
(In reply to Paul Osmialowski from comment #14) > Is there a way to solve this? I stuck at 1/3 of 17.0 to 17.1 migration > making this system partially unusable and completely unupdateable. I was also stuck on this for the 17.1 profile migration and solved it by remerging (almost) everything that equery depgraph said x11-libs/pango depended on with a --depth of 3. Something along the lines of: equery -C depgraph --depth 3 x11-libs/pango > depgraph.txt emerge -1av $(awk '{print $3}' depgraph.txt | sed 's/^/=/') Note that I did have to remove ruby from depgraph.txt and fix various things along the way (all along the lines of "configure can't find package foo") but this approach got there in the end.
If you have "dev-util/pkgconfig", then you need to rebuild it. Unlike "dev-util/pkgconf", it doesn't install shared libraries, so rebuilding everything in /usr/lib32 doesn't trigger its rebuild.
If my theory is correct, just after migration you will get something like this: # i686-pc-linux-gnu-pkg-config --libs cairo Package cairo was not found in the pkg-config search path. Perhaps you should add the directory containing `cairo.pc' to the PKG_CONFIG_PATH environment variable No package 'cairo' found # strace i686-pc-linux-gnu-pkg-config --libs cairo 2>&1 | grep lib32 openat(AT_FDCWD, "/lib32/libc.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib32/libpthread.so.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/lib32/pkgconfig/cairo-uninstalled.pc", 0xff8b3c4c) = -1 ENOENT (No such file or directory) stat64("/usr/lib32/pkgconfig/cairo.pc", 0xff8b3cbc) = -1 ENOENT (No such file or directory)
(In reply to Alexander Tsoy from comment #17) > If my theory is correct.. Nevermind. Problems with pkgconfig can happen only after removal of /usr/lib32 symlink. But it seems your migration is stuck somewhere before this point.
Same issue here with the 17.1 profile migration. We need to rebuild media-libs/mesa first because pango depend on cairo and cairo pkgconfig is breaked by the lack of gl.pc file: i686-pc-linux-gnu-pkg-config --cflags cairo Package gl was not found in the pkg-config search path. Perhaps you should add the directory containing `gl.pc' to the PKG_CONFIG_PATH environment variable Package 'gl', required by 'cairo', not found
After handling several such issues manually (seeing what failed why, then emerging the dependency) I tried "emerge -1 --deep /lib32 /usr/lib32". It's now over half done, and does seem to have put things in the right order - no failures so far. It's now on 32 of 44, with no failures yet.
So to get things works on my system: emerge -1 x11-libs/libdrm x11-libs/libXxf86vm x11-libs/libxcb x11-libs/libX11 x11-libs/libXfixes x11-libs/libXdamage x11-libs/libXext then: emerge -1 media-libs/mesa and after all: emerge -1 x11-libs/pango Hope it will help you.
@Luke Bratch Thanks for your hint. Although whole list failed half way through (e.g. libsoup dependency on sqlite and libpsl was not picked) I finally got to the point where I was re-merging packages from the list manually and trying to re-merge pango after each. In the end pango re-emerged after I re-emerged mesa. Whole operation shifted the progress of overall migration from 1/3 to 1/2.
(In reply to Paul Osmialowski from comment #22) Thanks, re-emerging mesa helped here as well - I have USE=vaapi creating a circular dependency as x11-libs/libva also searches for (and doesn't find) libGL ... I had to do USE=-vaapi emerge media-libs/mesa emerge -1 x11-libs/libva media-libs/mesa Afterwards cairo32 installed to correct /usr/lib and pango + dependencies compiled as well.
I have the same problem. I will try to rebuild mesa as suggested by #23
exaclty that comment#23 fixes my problem libva circular dependency so compile mesa without vaapi. then compile libva and mesa again. after that I could compile pango Thanks for sharing this knowledge :-)
The approach in comment #23 has solved my issues as well. Before ... emerge -1 =x11-libs/pango-1.42.4-r2 ... complaint: "fatal error: cairo.h: No such file or directory" After, I could ... emerge -1 =x11-libs/gtk+-2.24.32-r1 =x11-libs/gtk+-3.24.10 ... and the other packages which failed before. Thank you.
This is a problem nobody's Grandma is ever going to solve (unless Grandma's a hacker).... I wish there was some kind of provision in Gentoo EAPI allowing ebuild authors to give package manager hints about how particular circular-dependency-affected migrations could be performed without having to read those awful 'sorry-depsolver-says-"no"' error messages... iow ideally these problems could be sorted out automatically. ... but, admittedly, this particular case might not benefit, even if there were such a thing, since, here, dbapi doesn't correctly reflect the current deployed state of ABI_X86_32 files.
Hello, I am in the same predicament now. One thing went even worst in my case I did a --keep-going @world and it borked the python-3.6.10 needed for portage, lucky enough I had a package Broke as in emerge --info was not working anymore. I did find nearly the same list of packages to re install, missing a few. I'll be trying all the packages listed here.
