It's useful and worked fine with setting environment variable PORTAGE_CONFIGROOT=$EPREFIX
sounds like it needs some patching then, because it apparently doesn't work properly without setting that environment variable
So while working in a Prefix env, prefix-portage implicitly does that? I guess I'll have to look into appropriate files...
If you have questions, please add prefix@g.o to CC - thx
(In reply to comment #3) > If you have questions, please add prefix@g.o to CC - thx Added finally! Could someone explain this a bit to me then?
(In reply to comment #2) > So while working in a Prefix env, prefix-portage implicitly does that? I > guess I'll have to look into appropriate files... depending on what you mean here it is yes or no. % echo $PORTAGE_CONFIGROOT PORTAGE_CONFIGROOT: Undefined variable. % portageq envvar PORTAGE_CONFIGROOT /Library/Gentoo/ I haven't looked into flaggie what it does, but it feels either flaggie should query portage, or get EPREFIX from a compiled in default (eprefixify).
Hmm, so does create_trees(config_root = None) find the correct root then? I'd guess yes. If that's the case, I should probably try to obtain it back rather than relying on env.
this suggests it does (as run by create_trees): % python Python 3.3.0 (default, Dec 2 2012, 17:17:03) [GCC 4.2.1 (Gentoo 4.2.1_p5666-r1, Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from portage.package.ebuild._config.LocationsManager import LocationsManager>>> locations_manager = LocationsManager() >>> print(locations_manager.config_root) /Library/Gentoo/ >>>
flaggie has a couple of problems on Prefix: 1) it installs a dead symlink to python-exec which doesn't exist 2) it doesn't support python3.3 which leads to some legacy python warning I need an example how to use flaggie (or get it to list anything) to see if there actually is anything necessary for Prefix.
(In reply to comment #7) > this suggests it does (as run by create_trees): > > % python > Python 3.3.0 (default, Dec 2 2012, 17:17:03) > [GCC 4.2.1 (Gentoo 4.2.1_p5666-r1, Apple Inc. build 5666) (dot 3)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> from portage.package.ebuild._config.LocationsManager import LocationsManager>>> locations_manager = LocationsManager() > >>> print(locations_manager.config_root) > /Library/Gentoo/ > >>> Thanks. I've just committed a fix which should improve this [1]. [1]:https://bitbucket.org/mgorny/flaggie/commits/a0adfc407c1 (In reply to comment #8) > flaggie has a couple of problems on Prefix: > > 1) it installs a dead symlink to python-exec which doesn't exist That seems to be the problem with python-r1 support for Prefix. Does that mean that python-exec is not installed in the Prefix root, or the symlink is done wrong? > 2) it doesn't support python3.3 which leads to some legacy python warning I don't understand what kind of legacy python warning it could produce. Could you elaborate? Python 3.3 is still masked... > I need an example how to use flaggie (or get it to list anything) to see if > there actually is anything necessary for Prefix. Well, the simplest use is: $ flaggie ? <global> -3dnow -3dnowext acl adns ares avahi bash-completion -berkdb caps -consolekit cups curl dirac -directfb djvu -dracut_modules_plymouth [...] it should list all USE flags enabled in make.conf then.
details: issue 1) % la /Library/Gentoo/usr/bin/flaggie lrwxrwxrwx 1 user staff 31 Dec 9 20:34 /Library/Gentoo/usr/bin/flaggie -> ../../../../usr/bin/python-exec I guess this is a python eclass bug issue 2) * It seems that you need to set USE_PYTHON to make sure that legacy * packages will be built with respect to PYTHON_TARGETS correctly: * * USE_PYTHON='2.7' * * Please note that after changing the USE_PYTHON variable, you may need * to run 'python-updater' to rebuild affected packages. * * For more information on python.eclass compatibility, please see * the appropriate python-r1 User's Guide chapter [1]. * * [1] http://www.gentoo.org/proj/en/Python/python-r1/user-guide.xml#doc_chap2 % portageq envvar PYTHON_TARGETS python2_7 python3_3 I have no clue what the warning is trying to tell me. flaggie is built for python2.7 only (ignoring 3.3 since it doesn't have python3_3 listed in the ebuild), and it doesn't seem there is anything wrong with it.
after applying your patch, flaggie now returns some output: % flaggie-python2.7 \? <global> ipv6 nls -python_targets_jython2_5 -python_targets_pypy1_8 -python_targets_pypy1_9 -python_targets_python2_5 -python_targets_python2_6 python_targets_python2_7 -python_targets_python3_1 -python_targets_python3_2 python_targets_python3_3 -ruby_targets_jruby -ruby_targets_rbx -ruby_targets_ree18 -ruby_targets_ruby18 ruby_targets_ruby19 ssl unicode Seems we're getting in good shape then!
(In reply to comment #10) > details: > > issue 1) > > % la /Library/Gentoo/usr/bin/flaggie > lrwxrwxrwx 1 user staff 31 Dec 9 20:34 /Library/Gentoo/usr/bin/flaggie -> > ../../../../usr/bin/python-exec > > I guess this is a python eclass bug Ai, I think I broke it recently when making the distutils-r1 a bit smarter. I'll open a separate bug for that. > issue 2) > > * It seems that you need to set USE_PYTHON to make sure that legacy > * packages will be built with respect to PYTHON_TARGETS correctly: > * > * USE_PYTHON='2.7' > * > * Please note that after changing the USE_PYTHON variable, you may need > * to run 'python-updater' to rebuild affected packages. > * > * For more information on python.eclass compatibility, please see > * the appropriate python-r1 User's Guide chapter [1]. > * > * [1] > http://www.gentoo.org/proj/en/Python/python-r1/user-guide.xml#doc_chap2 > > % portageq envvar PYTHON_TARGETS > python2_7 python3_3 What's the value of USE_PYTHON (if set)? And both eselected pythons?
(In reply to comment #12) > (In reply to comment #10) > > details: > > > > issue 1) > > > > % la /Library/Gentoo/usr/bin/flaggie > > lrwxrwxrwx 1 user staff 31 Dec 9 20:34 /Library/Gentoo/usr/bin/flaggie -> > > ../../../../usr/bin/python-exec > > > > I guess this is a python eclass bug > > Ai, I think I broke it recently when making the distutils-r1 a bit smarter. > I'll open a separate bug for that. _python_ln_rel goes wrong because it's built on wrong assumptions > > issue 2) > > > > * It seems that you need to set USE_PYTHON to make sure that legacy > > * packages will be built with respect to PYTHON_TARGETS correctly: > > * > > * USE_PYTHON='2.7' > > * > > * Please note that after changing the USE_PYTHON variable, you may need > > * to run 'python-updater' to rebuild affected packages. > > * > > * For more information on python.eclass compatibility, please see > > * the appropriate python-r1 User's Guide chapter [1]. > > * > > * [1] > > http://www.gentoo.org/proj/en/Python/python-r1/user-guide.xml#doc_chap2 > > > > % portageq envvar PYTHON_TARGETS > > python2_7 python3_3 > > What's the value of USE_PYTHON (if set)? And both eselected pythons? Prefix has only two Pythons, 2.7.3 and 3.3.0, both unmasked. % portageq envvar USE_PYTHON % eselect python list Available Python interpreters: [1] python2.7 [2] python3.3 * % eselect python show python3.3 (deliberately on destruction mode, because Prefix has Python 3 for only a week or so now, and we need to catch issues that come from having Python 3 as main interpreter)
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #10) > > > details: > > > > > > issue 1) > > > > > > % la /Library/Gentoo/usr/bin/flaggie > > > lrwxrwxrwx 1 user staff 31 Dec 9 20:34 /Library/Gentoo/usr/bin/flaggie -> > > > ../../../../usr/bin/python-exec > > > > > > I guess this is a python eclass bug > > > > Ai, I think I broke it recently when making the distutils-r1 a bit smarter. > > I'll open a separate bug for that. > > _python_ln_rel goes wrong because it's built on wrong assumptions I see my mistake there but I'm not sure why does the ebuild work at all. I've opened bug 446648 for that. > > > > issue 2) > > > > > > * It seems that you need to set USE_PYTHON to make sure that legacy > > > * packages will be built with respect to PYTHON_TARGETS correctly: > > > * > > > * USE_PYTHON='2.7' > > > * > > > * Please note that after changing the USE_PYTHON variable, you may need > > > * to run 'python-updater' to rebuild affected packages. > > > * > > > * For more information on python.eclass compatibility, please see > > > * the appropriate python-r1 User's Guide chapter [1]. > > > * > > > * [1] > > > http://www.gentoo.org/proj/en/Python/python-r1/user-guide.xml#doc_chap2 > > > > > > % portageq envvar PYTHON_TARGETS > > > python2_7 python3_3 > > > > What's the value of USE_PYTHON (if set)? And both eselected pythons? > > Prefix has only two Pythons, 2.7.3 and 3.3.0, both unmasked. > > % portageq envvar USE_PYTHON > > % eselect python list > Available Python interpreters: > [1] python2.7 > [2] python3.3 * > % eselect python show > python3.3 > > (deliberately on destruction mode, because Prefix has Python 3 for only a > week or so now, and we need to catch issues that come from having Python 3 > as main interpreter) Hmm, I'll look at the whole long piece of code again and try to understand why it complains in this case. I'm assuming 'eselect python --python2 show' shows python2.7, so if it's not the case, please shout loud. But I think that's one of the rare cases where the check isn't able to be good enough not to give incorrect warnings.
> Hmm, I'll look at the whole long piece of code again and try to understand > why it complains in this case. I'm assuming 'eselect python --python2 show' > shows python2.7, so if it's not the case, please shout loud. > > But I think that's one of the rare cases where the check isn't able to be > good enough not to give incorrect warnings. Uh oh... eselect python --python2 show !!! Error: Action python2 unknown exiting % eselect python --python3 show !!! Error: Action python3 unknown exiting % eselect python show --python2 python2.7 % eselect python show --python3 python3.3
(In reply to comment #15) > > Hmm, I'll look at the whole long piece of code again and try to understand > > why it complains in this case. I'm assuming 'eselect python --python2 show' > > shows python2.7, so if it's not the case, please shout loud. > > > > But I think that's one of the rare cases where the check isn't able to be > > good enough not to give incorrect warnings. > > Uh oh... > > eselect python --python2 show > !!! Error: Action python2 unknown > exiting > % eselect python --python3 show > !!! Error: Action python3 unknown > exiting Sorry, my mistake. > % eselect python show --python2 > python2.7 > % eselect python show --python3 > python3.3 One more question: did you unmask 'python_targets_python3_3' USE flag? It's masked via use.mask in the base profile.
(In reply to comment #16) > > % eselect python show --python2 > > python2.7 > > % eselect python show --python3 > > python3.3 > > One more question: did you unmask 'python_targets_python3_3' USE flag? It's > masked via use.mask in the base profile. Yes: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/prefix/use.mask?revision=1.6&view=markup
flock missing, bug too polluted
