Summary: | x11-libs/libxcb-1.10 - No Python implementation found for the build. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alex Barker <alex> |
Component: | [OLD] Library | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | multilib+disabled, python |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
build_debug.log libxcb-fix.patch |
Description
Alex Barker
2014-08-17 19:58:09 UTC
Please upload the pastebins as attachments. Thanks Created attachment 383060 [details]
build.log
Created attachment 383062 [details]
build_debug.log
Created attachment 383098 [details, diff] libxcb-fix.patch After 3 days of digging this is the only workaround I can come up with. I have no idea why, but for some reason has_version just doesn't work with the --host-root flag. I guess the first question is, what is this host-root? I assume this is the HOST install location vs the TARGET install location? If that is the case the it still doesn't explain why "$PORTAGE_BIN_PATH"/ebuild-ipc has_version "${eroot}" "${atom}" inside of /usr/lib64/portage/bin/phase-helpers.sh is returning 0 when my python installation matches in both roots. Which brings me to my second question, what is ebuild-ipc and how it is suppose to operate? I would assume `ebuild-ipc has_version "/" ">=dev-lang/python-2.7.5-r2:2.7[xml]"` would return true because 2.7.7 is what is installed at root and set as the default python interpreter! P.S. /usr/portage/eclass/python-any-r1.eclass is still calling has_version with ROOT=/ Should this be changed? (bug #401239) "if ROOT=/ has_version "${PYTHON_PKG_DEP}"; then" Way beyond my knowledge of python stuff in portage. Calling in help from those in the know. @python: help! Which use flags are enabled on x11-proto/xcb-proto in your build/host system? I suspect that using --host-root with ${MULTILIB_USEDEP} is not valid -- MULTILIB_USEDEP would be populated according to the configuration under ROOT, not /. (In reply to Mike Gilbert from comment #6) > Which use flags are enabled on x11-proto/xcb-proto in your build/host system? I am not doing anything particularly ground breaking here. Installed versions: 2.7.7(2.7)(05:58:12 PM 08/14/2014)(berkdb gdbm ncurses readline ssl threads wide-unicode xml -build -doc -examples -hardened -ipv6 -sqlite -tk -wininst ELIBC="-uclibc") > I suspect that using --host-root with ${MULTILIB_USEDEP} is not valid -- > MULTILIB_USEDEP would be populated according to the configuration under > ROOT, not /. I have tried both with and without a multilib profile on the build/host, same result. On a related note the x11-proto/xcb-proto-1.10 fails to get pulled in due to --root-deps=rdeps, which is interesting because if I remove --root-deps complacently, it still throws away the dependency info. Its not a huge deal to emerge xcb-proto first, the question is why all this fancy dancing around resolving dependencies with things like python_gen_any_dep && has_version --host-root if they don't work? Is this a mulitlib isn't finished yet issue or a eclass are buggy issue or I am totally lost here? (In reply to Alex Barker from comment #7) > I am not doing anything particularly ground breaking here. > Installed versions: 2.7.7(2.7)(05:58:12 PM 08/14/2014)(berkdb gdbm ncurses > readline ssl threads wide-unicode xml -build -doc -examples -hardened -ipv6 > -sqlite -tk -wininst ELIBC="-uclibc") That's python, not xcb-proto. Anyway, I was able to sucessfully cross-compile x11-libs/libxcb for armv7a after installing x11-proto/xcb-proto with valid PYTHON_TARGETS in both the build system (/) and the host/target system (ROOT), using the embedded profile. There's something funky with your system. (In reply to Mike Gilbert from comment #9) > Anyway, I was able to sucessfully cross-compile x11-libs/libxcb for armv7a > after installing x11-proto/xcb-proto with valid PYTHON_TARGETS in both the > build system (/) and the host/target system (ROOT), using the embedded > profile. > > There's something funky with your system. Correct, I am also able to cross compile x11-libs/libxcb for armvj and armv7a after manually merging xcb-proto. That part seems to function *somewhat* correctly. The issue with the xcb-proto stuff is that if I emerge WITHOUT '--root-deps=rdeps' the documentation suggests that it should pull in the xcb-proto stuff and a lot of other dependencies... however it does not. This is probably an issue for another bug. The issue at hand is trying to compile libxcb for i-any-86 where regardless of xcb-proto being merged first, it just fails with cannot find python because has_version --host-root is returning 0 instead of 1 as it did with previous armv[67]{1}. When I remove --host-root it works as expected with i686, but only with i-any-86! To add a little more wtf to the mix, all of the arguments being passed to has_verison for the package are identical between arm and x86 leading me to believe the issue is in some eclass somewhere. Again I have tired with a mulilib and no-multilib amd64 profile and it behaves exactly the same. I have just ended up sprinkling around patches and local overlays to work around these issues. Someone who knows a bit more about the python integration than I do may want to look at the way that the python-any-r1.eclass is searching for software versions at '/'. (In reply to Alex Barker from comment #10) > Correct, I am also able to cross compile x11-libs/libxcb for armvj and > armv7a after manually merging xcb-proto. That part seems to function > *somewhat* correctly. The issue with the xcb-proto stuff is that if I > emerge WITHOUT '--root-deps=rdeps' the documentation suggests that it should > pull in the xcb-proto stuff and a lot of other dependencies... however it > does not. This is probably an issue for another bug. The emerge manpage says this: --root-deps[=rdeps] If no argument is given then build-time dependencies of packages for ROOT are installed to ROOT instead of /. So, you would need to run emerge --root-deps ... to see the behavior your are expecting. I will try to build an i586 cross-toolchain and reproduce this issue. I am still unable to reproduce this failure with a i586-gentoo-linux-gnu cross-toolchain with either the default/linux/x86/13.0 or embedded profile. So, I will be unable to troubleshoot this on my own. Can you try removing ${MULTILIB_USEDEP} or ${PYTHON_USEDEP} from the has_version --host-root ">=x11-proto/xcb-proto-1.10[${MULTILIB_USEDEP},${PYTHON_USEDEP}]" call to see which one is tripping it up? Or maybe it is neither of them; either way, it would be helpful to narrow down the problem. This might be the issue. + 21 Aug 2014; Mike Gilbert <floppym@gentoo.org> libxcb-1.10.ebuild: + Add missing ${PYTHON_DEPS} to DEPEND, bug 520146. (In reply to Mike Gilbert from comment #12) > Can you try removing ${MULTILIB_USEDEP} or ${PYTHON_USEDEP} from the > has_version --host-root > ">=x11-proto/xcb-proto-1.10[${MULTILIB_USEDEP},${PYTHON_USEDEP}]" call to > see which one is tripping it up? It is def the ${MULTILIB_USEDEP}, things work fine with only the ${PYTHON_USEDEP} > + 21 Aug 2014; Mike Gilbert <floppym@gentoo.org> libxcb-1.10.ebuild: > + Add missing ${PYTHON_DEPS} to DEPEND, bug 520146. I am not sure where that came from or what it means. I tried adding the following but it had no effect: DEPEND="${RDEPEND} dev-libs/libxslt ${PYTHON_USEDEP} $(python_gen_any_dep \ ">=x11-proto/xcb-proto-1.10[${MULTILIB_USEDEP},\${PYTHON_USEDEP}]")" Copying the multilib team since this seems to be some issue with MULTILIB_USEDEP. Thinking on this, python doesn't support multilib, so it makes no sense to enforce MULTILIB_USEDEP in python_check_deps. As well, xcb-proto does not install any libraries; the only thing multilib does is install a pkg-config file in each libdir. + 03 Sep 2014; Mike Gilbert <floppym@gentoo.org> libxcb-1.10.ebuild: + Drop MULTILIB_USEDEP from xcb-proto in python_check_deps, bug 520146. |