Created attachment 288393 [details] Patch that fixes the ebuild It seems that sys-libs/talloc has begun to require that python is install to be able to be compiled, even if the python use flag is not defined. This is a problem when you build the package to another folder using the ROOT parameter (in this case to create a small embedded system, without python or anything else). Could you please change the ebuilds, so they don't require python if the python use flag is not set? I have attach a patch that fixes the problem, by only calling "python_set_active_version 2" if the python use flag is set. The problem is really that python_set_active_version tries to set the python version in the build output system (defined in the ROOT folder) instead of in the parent build system.
Upstream uses waf for the build system - that's python.
...though if you have a better idea how to fix your original problem, feel free to reopen.
Well, it builds fine without python being installed on the target system as long as that function isn't called. I know python is needed for building talloc, but it shouldn't be required for that target ROOT folder system. I'm NOT talking about the build system, I'm talking about the target system that the package is to be used on. Like I said, this is more likely a bug in the python eclass, since it wants to change the target systems python version instead of the version on the building system. Re-assigning to python team. Python team - is it the meaning that the function python_set_active_version is called in the target system defined using the ROOT variable, instead of in the build environment?
Mishandling of ROOT occurs also in other places in python.eclass. I have fixed this bug in Progress Overlay in r1231: http://code.google.com/p/gentoo-progress/source/detail?r=1231 The fix properly works in EAPI >=4 (in python.eclass from Progress Overlay), because it's possible to express all USE conditionals in new syntax of PYTHON_DEPEND. Syntax of PYTHON_DEPEND in older EAPIs supports at most 1 USE conditional. python_set_active_version() now always uses ROOT="/". If "${ROOT}" != "/" and PYTHON_DEPEND specifies a run-time dependency, which is enabled by USE setting, then python_set_active_version() additionally uses ROOT="${ROOT}".
Created attachment 290049 [details] build log
I just tried that python.eclass version, it still fails when building talloc. I have attached the build log. It seems like it still wants to change the version of python used in the ${ROOT} variable.
(In reply to comment #5) Please attach your ebuild.
(In reply to comment #7) > (In reply to comment #5) > > Please attach your ebuild. The version already in portage: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-libs/talloc/talloc-2.0.7.ebuild?revision=1.1
(In reply to comment #8) Please test the attached ebuild. As I said, the fix works only in EAPI >=4. (Please note that this ebuild currently won't work at all with python.eclass from gentoo-x86.) (PYTHON_BDEPEND specifies build-time dependency on Python. PYTHON_DEPEND specifies build-time and run-time dependency on Python. Build-time dependencies specified in PYTHON_BDEPEND and PYTHON_DEPEND are concatenated.)
Created attachment 290051 [details] talloc-2.0.7.ebuild
Created attachment 290055 [details] build log of modified ebuild Okay, that ebuild builds just fine with the python.eclass linked to before. I have attached the build log for this run, since there is some errors at the top of the build log (it builds fine though). So the process now is to get these changes into the python.eclass in gentoo-x86 and then get the talloc ebuilds updated, right?
Unfortunately that process isn't very easy, since the python.eclass in the progress overlay that Arfrever maintains has significantly diverged from the gentoo-x86 version, including many changes that are indesirable for gentoo-x86.
(In reply to comment #11) Trailing semicolon was cleared too early. I have fixed it in r1232: http://code.google.com/p/gentoo-progress/source/detail?r=1232 Please test again with the updated version of python.eclass from Progress Overlay.
(In reply to comment #13) > (In reply to comment #11) > > Trailing semicolon was cleared too early. I have fixed it in r1232: > http://code.google.com/p/gentoo-progress/source/detail?r=1232 > > Please test again with the updated version of python.eclass from Progress > Overlay. It compiles without making any noice when using that version. Is there a way for just these changes to be merged into the gentoo-x86 version, or would that require alot of other changes to be merged too?
(In reply to comment #14) > Is there a way for just these changes to be merged into the gentoo-x86 > version, or would that require alot of other changes to be merged too? Patches related to PYTHON_BDEPEND/PYTHON_DEPEND/PYTHON_USE_WITH* should still apply cleanly.
Even if there is a way to merge just those changes, the python team feels that they make the eclass more complex to the point where it is unmaintainable (as far as it isn't already). Therefore, adding complexity to the eclass is on hold while we figure out a way forward that will make the eclass more manageable in the future.
(In reply to comment #16) > Even if there is a way to merge just those changes, the python team feels that > they make the eclass more complex to the point where it is unmaintainable (as > far as it isn't already). Therefore, adding complexity to the eclass is on hold > while we figure out a way forward that will make the eclass more manageable in > the future. Thats understandable :) Should I just leave this bug open for the time being, until you find a way forward regarding the python eclass?
That's probably a good idea, yes.
(In reply to comment #16) > Even if there is a way to merge just those changes, the python team feels > that they make the eclass more complex to the point where it is > unmaintainable (as far as it isn't already). Therefore, adding complexity > to the eclass is on hold while we figure out a way forward that will make > the eclass more manageable in the future. If python.eclass was unmaintainable or too complex, then I wouldn't be able to fix various bugs in python.eclass in recent months. The real problem seems to be that some people have insufficient bash experience. When I volunteered to explain code in python.eclass, then nobody asked questions about code in python.eclass (except 1 person temporarily forced by me to ask questions).
I don't think this is an appropriate venue for this discussion. I've stated what I think reflects the feelings of the python team, and I'll leave it at that.
python.eclass is gone.
