Re: [gentoo-dev] Versioning of Python scripts
В Сбт, 19/12/2009 в 16:24 +0100, Arfrever Frehtes Taifersar Arahesis пишет: - Scripts of packages supporting only e.g. Python 2 can be executed (without necessity of using of e.g. python2 /usr/bin/${script}) after activating of e.g. Python 3. - Scripts of packages supporting multiple Python versions ignore active Python version. The best solution, which removes these 2 disadvantages and preserves the advantage, seems to be to rename Python scripts to include Python version [1] in filenames, and create wrapper scripts, which call appropriate target scripts [2]. But still additional wrapper scripts and increased number of scripts in total is not really nice. What do you think about another solution: Separate possible script's python API versions into database, e.g. in /var/db/pyabi/${CATEGORY}/${PN}-${SLOT}. Create python wrapper only for unmerged but still in use (found from pyabi db) python versions, e.g. /usr/bin/python3.2 in case you've unmerged python, but scripts still reference python3.2. This way scripts that use python versions that are still in the tree will work without any overhead, fewer scripts in /{usr,}bin and during python merge/unmerge it is possible to warn user about scripts that use unmerged python versions (and thus run with some overhead). I guess still we can add some user defined variable to prefer some python versions over another... - Scripts of packages supporting multiple Python versions cannot be easily (without necessity of using of e.g. python3.1 /usr/bin/${script}) executed with a Python version different than active Python version. If you develop on python then... write your own wrappers or use /usr/bin/python and that's it! In case you are not I'm not sure why such switching is useful. Could you elaborate? -- Peter.
Re: [gentoo-dev] openrc/baselayout2 stabilization update
I am not sure whether init and/or who are part of openrc -- but it is worth noting that who -b which is supposed to produce the system boot time still appears to be broken. I believe I filed a bug report about this around the time of the late 2008 or early 2009 updates to openrc and I believe the developer acknowledged that it was a bug. One can easily run a strace on who -b to see the files it is accessing and presumably this is a bug in the current init (or perhaps in Linux itself) that it is not writing a boot record into /var/tmp/utmp (for that is the file that who -b seems to open and attempt to read a boot-time record from). uptime can substitute for who -b -- but the who -b result was more easily processed into forms that could be used to delete unused temporary files (which tend to be a common problem on gentoo systems where the reboots may not always be clean. Robert On Mon, Dec 21, 2009 at 6:10 PM, William Hubbs willi...@gentoo.org wrote: All, we are still working toward stabilizing openrc and baselayout-2. The current status is that all of the bugs which have anything to do with openrc/baselayout are assigned to the baselayout component in bugzilla. Also, there is a tracker bug at http://bugs.gentoo.org/295613. It would be very helpful if others here could check the bugs and make bugs that should block stabilization block the tracker. Also, any solutions you have for blocking bugs would be very much appreciated. Thanks much, William
Re: [gentoo-dev] openrc/baselayout2 stabilization update
On Tuesday 22 December 2009 14:19:19 Robert Bradbury wrote: please do not top post I am not sure whether init and/or who are part of openrc -- but it is worth noting that who -b which is supposed to produce the system boot time still appears to be broken. I believe I filed a bug report about this around the time of the late 2008 or early 2009 updates to openrc and I believe the developer acknowledged that it was a bug. then find said bug and mark it a blocker to the tracker William mentioned, or open a new bug if there isnt one (i'm pretty sure there is one though) -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] QA last rites for net-libs/libwhisker
# Diego E. Pettenò flamee...@gentoo.org (22 Dec 2009) # on behalf of QA team # # Fails to build and ebuild does not die (bug #297970); # ebuild unused, last bumped in 2005, then untouched till # 2007 for Manifest2 bumps, and never since then. # # Removal on 2010-02-20 net-libs/libwhisker
[gentoo-dev] QA last rites for dev-libs/libredblack
# Diego E. Pettenò flamee...@gentoo.org (22 Dec 2009) # on behalf of QA team # # Once again, removing libredblack; this was previously # saved from a 60-days removal back in August, since the # supplied patch *fails to apply*, this package will not be # deemed salvageable. # # Special note this time: last-rite time has been cut to # minimum 30 days, if you intend on saving this you should # talk *first* with QA. # # Removal on 2010-01-21 dev-libs/libredblack
Re: [gentoo-dev] Versioning of Python scripts
2009-12-21 11:50:14 Brian Harring napisał(a): On Sat, Dec 19, 2009 at 04:24:49PM +0100, Arfrever Frehtes Taifersar Arahesis wrote: Distutils/Setuptools/Distribute modify shebangs of installed Python scripts, so that they contain path of Python interpreter with version included (e.g. #!/usr/bin/python3.2). This behavior has both advantage and disadvantages: - Scripts of packages supporting only e.g. Python 2 can be executed (without necessity of using of e.g. python2 /usr/bin/${script}) after activating of e.g. Python 3. - Scripts of packages supporting multiple Python versions ignore active Python version. - Scripts of packages supporting multiple Python versions cannot be easily (without necessity of using of e.g. python3.1 /usr/bin/${script}) executed with a Python version different than active Python version. The best solution, which removes these 2 disadvantages and preserves the advantage, seems to be to rename Python scripts to include Python version [1] in filenames, and create wrapper scripts, which call appropriate target scripts [2]. Some files sometimes try to execute e.g. /usr/bin/python /usr/bin/${script}, so wrapper scripts must be implemented in Python. Wrapper scripts try to execute ${wrapper_script}-${PYTHON_ABI} files (e.g. py.test will execute py.test-3.1, when Python 3.1 is set as active Python version). distutils.eclass will automatically rename some scripts [3] in ${D}usr/bin and call the function, which generates wrapper scripts. In case somebody is interested in reading of source code of python_generate_wrapper_scripts() function and potential suggesting of improvements, I'm attaching this function and 2 example wrapper scripts. I'm planning to commit addition of this function in next week. Not really a huge fan of the EPYTHON var... can you clarify it's real world usage? It simplifies development of ebuilds of packages having non-Distutils-based build systems. E.g. ebuilds of packages, which support only Python2, install some executables or libraries (e.g. /usr/lib/kvirc/4.0/modules/libkvipythoncore.so of net-irc/kvirc) linked against libpythonX.Y.so and don't install any Python modules, will be able to simply call 'python_set_active_version 2', which will export EPYTHON variable with appropriate value. Ebuilds should never manually set EPYTHON variable. I can see that causing all sorts of mayhem as it passes it's way down through python scripts invoking other scripts- specifically thinking of a py3k only script being forced to 3.1, then invoking a py2k script. EPYTHON variable should be respected only by scripts, which are used during building, testing or installation of other packages and need to be called with appropriate Python version. Examples: py.test, trial distutils_src_install() will call python_generate_wrapper_scripts() (at least by default) without -E option. Beyond that, please provide a way to *disable* this for a pkg. OK. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.