[gentoo-dev] Re: [gentoo-core] RFC new quiz test for when to comment in ebuilds

2009-12-19 Thread Samuli Suominen
On 12/19/2009 05:32 PM, Pacho Ramos wrote:
> Maybe I am wrong, but it could be a different question (not a code
> snippets like the other questions under 6.) with something like:
> 21. What would you do when needing to manually run "make" or
> "./configure" instead of econf/emake?

I can't see any valid usage for "make", certainly it's not for working
around parallel make issues, there's "emake -j1" for that.

Benefits in using "emake -j1" are obvious, repoman will report you
there's parallel make issues with upstream.workaround and other MAKEOPTS
aren't ignored.



[gentoo-dev] Versioning of Python scripts

2009-12-19 Thread Arfrever Frehtes Taifersar Arahesis
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.

[1] Actually Python ABI.
[2] Wrapper scripts can also be created for ELF target files (e.g. "mpipython").
[3] Only scripts of packages supporting installation for multiple Python 
versions will be
renamed. Scripts, whose filenames end in [[:digit:]]+\.[[:digit:]]+, won't 
be renamed.

-- 
Arfrever Frehtes Taifersar Arahesis
# @FUNCTION: python_generate_wrapper_scripts
# @USAGE: [-E|--respect-EPYTHON] [-f|--force] [-q|--quiet] [--]  [files]
# @DESCRIPTION:
# Generate wrapper scripts. Existing files are overwritten only with --force 
option.
# If --respect-EPYTHON option is specified, then generated wrapper scripts will
# respect EPYTHON variable at run time.
python_generate_wrapper_scripts() {
local eselect_python_option file force="0" quiet="0" PYTHON_ABI 
python2_enabled="0" python2_supported_versions python3_enabled="0" 
python3_supported_versions respect_EPYTHON="0"
python2_supported_versions="2.4 2.5 2.6 2.7"
python3_supported_versions="3.0 3.1 3.2"

while (($#)); do
case "$1" in
-E|--respect-EPYTHON)
respect_EPYTHON="1"
;;
-f|--force)
force="1"
;;
-q|--quiet)
quiet="1"
;;
--)
break
;;
-*)
die "${FUNCNAME}(): Unrecognized option '$1'"
;;
*)
break
;;
esac
shift
done

validate_PYTHON_ABIS
for PYTHON_ABI in ${python2_supported_versions}; do
if has "${PYTHON_ABI}" ${PYTHON_ABIS}; then
python2_enabled="1"
fi
done
for PYTHON_ABI in ${python3_supported_versions}; do
if has "${PYTHON_ABI}" ${PYTHON_ABIS}; then
python3_enabled="1"
fi
done

if [[ "${python2_enabled}" == "1" && "${python3_enabled}" == "1" ]]; 
then
eselect_python_option=
elif [[ "${python2_enabled}" == "1" && "${python3_enabled}" == "0" ]]; 
then
eselect_python_option="--python2"
elif [[ "${python2_enabled}" == "0" && "${python3_enabled}" == "1" ]]; 
then
eselect_python_option="--python3"
else
die "${FUNCNAME}(): Unsupported environment"
fi

for file in "$@"; do
if [[ -f "${file}" && "${force}" == "0" ]]; then
die "${FUNCNAME}(): '$1' already exists"
fi

if [[ "${quiet}" == "0" ]]; then
einfo "Generating '${file#${D%/}}' wrapper script"
fi

cat << EOF > "${file}"
#!/usr/bin/env python
# Gentoo '${file##*/}' wrapper script

import os
import re
import subprocess
import sys

EPYTHON_re = re.compile(r"^python(\d+\.\d+)$")

EOF
if [[ "$?" != "0" ]]; then
die "${FUNCNAME}(): Generation of

Re: [gentoo-dev] rewritten epatch

2009-12-19 Thread Mike Frysinger
On Saturday 19 December 2009 07:33:33 Diego Elio “Flameeyes” Pettenò wrote:
> Il giorno ven, 18/12/2009 alle 23.56 -0800, Brian Harring ha scritto:
> > For changes of this sort, abusing the tinderboxes to get a real world
> > test run makes a lot of sense.
> 
> I can put it into run with the tinderbox, no problem with that.

i'll wait until the end of the year to commit it
-mike


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] rewritten epatch

2009-12-19 Thread Diego Elio “Flameeyes” Pettenò
Il giorno ven, 18/12/2009 alle 23.56 -0800, Brian Harring ha scritto:
> 
> For changes of this sort, abusing the tinderboxes to get a real world 
> test run makes a lot of sense. 

I can put it into run with the tinderbox, no problem with that.

But I think that we should really use both: Patrick's should be better
for I/O so maybe you (or Zac) can come up with a script to just try
unpack and prepare phases for all ebuilds rather than keeping the whole
merge…

-- 
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/

If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/