mips-softfloat-linux-uclibc-emerge -v1 =sys-apps/portage-2.2.8-r2 all data is installed to /usr/lib64 mips-softfloat-linux-uclibc-emerge -v1 =sys-apps/portage-2.2.14 part of data is installed to /usr/lib another part to /usr/lib64 Reproducible: Always Steps to Reproduce: Use 32bit crossdev emerge (for example mips-softfloat-linux-uclibc) on 64bit host and install >=sys-apps/portage-2.2.14 Actual Results: You will obtain "ImportError: No module named 'portage'" after chroot to /usr/mips-softfloat-linux-uclibc For example "site-packages" is installed into /usr/lib64/python3.3/site-packages But "ebuild-helpers" is installed into /usr/lib/portage/python3.3/ebuild-helpers
Created attachment 393166 [details] emerge log
Sorry, I can't edit the comment above. mips-softfloat-linux-uclibc-emerge -v1 =sys-apps/portage-2.2.8-r2 all data is installed to /usr/lib So =sys-apps/portage-2.2.8-r2 works perfect.
Yes, portage changed it's install system along with some directory changes where some of those things are installed. The crossdev emerge code will need updating for newer portage. In the meantime, you will have to stay with 2.2.8.
pretty sure this has nothing to do with crossdev. the fact that you're getting host libdir paths when using python eclasses is due to python itself failing. *** This bug has been marked as a duplicate of bug 268887 ***
I haven't looked at this stuff recently but this smells a lot like bug #503874. Apply the simple patch there and see if it helps.
(In reply to James Le Cuirot from comment #5) yeah, that's part of the meta 268887 bug, but that has probably blown out of control now so splitting it up to make progress would be better
