[gentoo-dev] Lastrite: app-emulation/kqemu
# Doug Goldstein (21 Nov 2012) # Masked for removal. Lots of bugs opened. Upstream # says don't use it. No Gentoo maintainer # activity for some time. qemu no longer supports it. # Removal date: 21 Dec 2012 app-emulation/kqemu -- Doug Goldstein
[gentoo-dev] [python-single-r1 1/3] A conceptual eclass for packages not supporting multiple Python impls.
It's based on the PYTHON_SINGLE_TARGET variable concept. For that
reason, I used '-single' in the name. If someone could come up with
a better name, I'd be happy to use it.
It's used on top of python-r1. Similarly, you use ${PYTHON_DEPS} in your
RDEP/DEP; [${PYTHON_USEDEP}] can be used to depend on single- and multi-
implementation packages.
pkg_setup() is exported. It finds the enabled implementation, and
exports EPYTHON and PYTHON.
You aren't allowed to:
1) depend on python-single-r1 packages from python-r1 packages (why
would you?),
2) use python_foreach_impl() -- it will iterate over all implementations
in PYTHON_TARGETS, ignoring PYTHON_SINGLE_TARGET.
---
gx86/eclass/python-single-r1.eclass | 93 +
1 file changed, 93 insertions(+)
create mode 100644 gx86/eclass/python-single-r1.eclass
diff --git a/gx86/eclass/python-single-r1.eclass
b/gx86/eclass/python-single-r1.eclass
new file mode 100644
index 000..3d21ea8
--- /dev/null
+++ b/gx86/eclass/python-single-r1.eclass
@@ -0,0 +1,93 @@
+# Copyright 1999-2012 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: /var/cvsroot/gentoo-x86/eclass/python-r1.eclass,v 1.20 2012/11/21
09:04:14 mgorny Exp $
+
+# @ECLASS: python-single-r1
+# @MAINTAINER:
+# Michał Górny
+# Python herd
+# @AUTHOR:
+# Author: Michał Górny
+# Based on work of: Krzysztof Pawlik
+# @BLURB: An eclass for Python packages not installed for multiple
implementations.
+# @DESCRIPTION:
+# An extension of the python-r1 eclass suite for packages which
+# don't support being installed for multiple Python implementations.
+# This mostly includes tools embedding Python.
+#
+# This eclass extends the IUSE and REQUIRED_USE set by python-r1
+# to request correct PYTHON_SINGLE_TARGET. It also replaces
+# PYTHON_USEDEP and PYTHON_DEPS with a more suitable form.
+#
+# Please note that packages support multiple Python implementations
+# (using python-r1 eclass) can not depend on packages not supporting
+# them (using this eclass).
+#
+# Also, please note that python-single-r1 will always inherit python-r1
+# as well. Thus, all the variables defined and documented there are
+# relevant to the packages using python-single-r1.
+
+case "${EAPI}" in
+ 0|1|2|3)
+ die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
+ ;;
+ 4|5)
+ # EAPI=4 needed by python-r1
+ ;;
+ *)
+ die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+ ;;
+esac
+
+inherit python-r1
+
+EXPORT_FUNCTIONS pkg_setup
+
+_python_single_set_globals() {
+ local flags=( "${PYTHON_COMPAT[@]/#/python_single_target_}" )
+ local optflags=${flags[@]/%/(+)?}
+
+ IUSE=${flags[*]}
+ REQUIRED_USE="^^ ( ${flags[*]} )"
+ PYTHON_USEDEP+=,${optflags// /,}
+
+ local usestr
+ [[ ${PYTHON_REQ_USE} ]] && usestr="[${PYTHON_REQ_USE}]"
+
+ # 1) well, python-exec would suffice as an RDEP
+ # but no point in making this overcomplex, BDEP doesn't hurt anyone
+ # 2) python-exec should be built with all targets forced anyway
+ # but if new targets were added, we may need to force a rebuild
+ PYTHON_DEPS="dev-python/python-exec[${PYTHON_USEDEP}]"
+ local i
+ for i in "${PYTHON_COMPAT[@]}"; do
+ local d
+ case ${i} in
+ python*)
+ d='dev-lang/python';;
+ jython*)
+ d='dev-java/jython';;
+ pypy*)
+ d='dev-python/pypy';;
+ *)
+ die "Invalid implementation: ${i}"
+ esac
+
+ local v=${i##*[a-z]}
+ PYTHON_DEPS+=" python_single_target_${i}? (
${d}:${v/_/.}${usestr} )"
+ done
+}
+_python_single_set_globals
+
+python-single-r1_pkg_setup() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ for impl in "${_PYTHON_ALL_IMPLS[@]}"; do
+ if has "${impl}" "${PYTHON_COMPAT[@]}" \
+ && use "python_single_target_${impl}"
+ then
+ python_export "${impl}" EPYTHON PYTHON
+ break
+ fi
+ done
+}
--
1.8.0
[gentoo-dev] [python-single-r1 3/3] An example conversion of ebuild to python-single-r1.
---
gx86/net-libs/libproxy/libproxy-0.4.10-r1.ebuild | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/gx86/net-libs/libproxy/libproxy-0.4.10-r1.ebuild
b/gx86/net-libs/libproxy/libproxy-0.4.10-r1.ebuild
index 1ed3336..acaee2d 100644
--- a/gx86/net-libs/libproxy/libproxy-0.4.10-r1.ebuild
+++ b/gx86/net-libs/libproxy/libproxy-0.4.10-r1.ebuild
@@ -3,9 +3,12 @@
# $Header:
/var/cvsroot/gentoo-x86/net-libs/libproxy/libproxy-0.4.10-r1.ebuild,v 1.9
2012/11/21 21:49:49 maekke Exp $
EAPI=4
-PYTHON_DEPEND="python? 2:2.6"
+PYTHON_COMPAT=( python{2_6,2_7} )
-inherit cmake-utils eutils mono python
+# Note 1: this is actually a poor example. AFAICS libproxy should be
+# capable of being built for multiple implementations.
+
+inherit cmake-utils eutils mono python-single-r1
DESCRIPTION="Library for automatic proxy configuration management"
HOMEPAGE="http://code.google.com/p/libproxy/";
@@ -23,6 +26,7 @@ RDEPEND="gnome? ( >=dev-libs/glib-2.26:2 )
mono? ( dev-lang/mono )
networkmanager? ( net-misc/networkmanager )
perl? ( dev-lang/perl )
+ python? ( ${PYTHON_DEPS} )
spidermonkey? ( >=dev-lang/spidermonkey-1.8.5 )
webkit? ( >=net-libs/webkit-gtk-1.6:3 )"
DEPEND="${RDEPEND}
@@ -33,8 +37,7 @@ pkg_setup() {
DOCS="AUTHORS ChangeLog NEWS README"
if use python; then
- python_set_active_version 2
- python_pkg_setup
+ python-single-r1_pkg_setup
fi
}
@@ -69,10 +72,5 @@ src_configure() {
cmake-utils_src_configure
}
-pkg_postinst() {
- use python && python_mod_optimize ${PN}.py
-}
-
-pkg_postrm() {
- use python && python_mod_cleanup ${PN}.py
-}
+# Note 2: build system doesn't compile Python files.
+# TODO: Introduce a public function to do that.
--
1.8.0
[gentoo-dev] [python-single-r1 2/3] PYTHON_SINGLE_TARGET code for profiles.
--- gx86/profiles/base/make.defaults | 3 ++- gx86/profiles/desc/python_single_target.desc | 15 +++ 2 files changed, 17 insertions(+), 1 deletion(-) create mode 100644 gx86/profiles/desc/python_single_target.desc diff --git a/gx86/profiles/base/make.defaults b/gx86/profiles/base/make.defaults index ece143d..b3ae3bc 100644 --- a/gx86/profiles/base/make.defaults +++ b/gx86/profiles/base/make.defaults @@ -16,7 +16,7 @@ USE_EXPAND_VALUES_USERLAND="BSD GNU" # Env vars to expand into USE vars. Modifying this requires prior # discussion on gentoo-...@gentoo.org. -USE_EXPAND="APACHE2_MODULES APACHE2_MPMS CALLIGRA_FEATURES ENLIGHTENMENT_MODULES FOO2ZJS_DEVICES MISDN_CARDS FRITZCAPI_CARDS FCDSL_CARDS VIDEO_CARDS DVB_CARDS LIRC_DEVICES INPUT_DEVICES LINGUAS USERLAND KERNEL ELIBC CROSSCOMPILE_OPTS ALSA_CARDS ALSA_PCM_PLUGINS LCD_DEVICES CAMERAS NETBEANS_MODULES QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS SANE_BACKENDS RUBY_TARGETS PHP_TARGETS NGINX_MODULES_HTTP NGINX_MODULES_MAIL XFCE_PLUGINS XTABLES_ADDONS GPSD_PROTOCOLS COLLECTD_PLUGINS DRACUT_MODULES OFED_DRIVERS GRUB_PLATFORMS FFTOOLS PYTHON_TARGETS CURL_SSL OPENMPI_FABRICS OPENMPI_RM OPENMPI_OFED_FEATURES LIBREOFFICE_EXTENSIONS VOICEMAIL_STORAGE" +USE_EXPAND="APACHE2_MODULES APACHE2_MPMS CALLIGRA_FEATURES ENLIGHTENMENT_MODULES FOO2ZJS_DEVICES MISDN_CARDS FRITZCAPI_CARDS FCDSL_CARDS VIDEO_CARDS DVB_CARDS LIRC_DEVICES INPUT_DEVICES LINGUAS USERLAND KERNEL ELIBC CROSSCOMPILE_OPTS ALSA_CARDS ALSA_PCM_PLUGINS LCD_DEVICES CAMERAS NETBEANS_MODULES QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS SANE_BACKENDS RUBY_TARGETS PHP_TARGETS NGINX_MODULES_HTTP NGINX_MODULES_MAIL XFCE_PLUGINS XTABLES_ADDONS GPSD_PROTOCOLS COLLECTD_PLUGINS DRACUT_MODULES OFED_DRIVERS GRUB_PLATFORMS FFTOOLS PYTHON_TARGETS CURL_SSL OPENMPI_FABRICS OPENMPI_RM OPENMPI_OFED_FEATURES LIBREOFFICE_EXTENSIONS VOICEMAIL_STORAGE PYTHON_SINGLE_TARGET" # USE_EXPAND variables whose contents are not shown in package manager # output. Changes need discussion on gentoo-dev. @@ -123,3 +123,4 @@ BOOTSTRAP_USE="cxx unicode" # Mike Gilbert (15 May 2012) # Default target(s) for python-r1.eclass PYTHON_TARGETS="python2_7 python3_2" +PYTHON_SINGLE_TARGET="python2_7" diff --git a/gx86/profiles/desc/python_single_target.desc b/gx86/profiles/desc/python_single_target.desc new file mode 100644 index 000..dd70918 --- /dev/null +++ b/gx86/profiles/desc/python_single_target.desc @@ -0,0 +1,15 @@ +# Copyright 1999-2012 Gentoo Foundation. +# Distributed under the terms of the GNU General Public License v2 +# $Header: $ + +# This file contains descriptions of PYTHON_SINGLE_TARGET USE_EXPAND flags. + +python2_5 - Build for Python 2.5 only +python2_6 - Build for Python 2.6 only +python2_7 - Build for Python 2.7 only +python3_1 - Build for Python 3.1 only +python3_2 - Build for Python 3.2 only +python3_3 - Build for Python 3.3 only +jython2_5 - Build for Jython 2.5 only +pypy1_8 - Build for PyPy 1.8 only +pypy1_9 - Build for PyPy 1.9 only -- 1.8.0
Re: [gentoo-dev] gstreamer eclass review
Le mercredi 21 novembre 2012 à 16:27 +0100, Tomáš Chvátal a écrit : > Hi Gilles, > > > The eclass itself looks fine, I would just ask if you would not mind > to use the bash += syntax rather than VAR="VAR something" as it is > shorter and easier to read. Sure, I'm not a fan of +=, it seems alien to shell for me, but if this is preferred, I have no problem changing it. -- Gilles Dartiguelongue Gentoo signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: An apology for some of my earlier comments
On Tue, Nov 20, 2012 at 10:58:21PM -0500, Richard Yao wrote: > Dear Greg, > > The eudev project has suffered a fair number of psychological attacks > against project members. I know that you are a strong supporter of > systemd. When you emailed gentoo-dev@, I assumed that you were trying to > harm the project and treated you as such. After seeing your responses to > people on Google+, I have realized that you are a person of greater > integrity than I had assumed and I must apologize for my defensive > behavior. Thanks for the apology, I appreciate it, and accept it. Good luck with your eudev effort. greg k-h
Re: [gentoo-dev] [PATCH python-r1] Move common utility functions to python-utils-r1.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/11/12 10:17 AM, Gilles Dartiguelongue wrote: > Le mercredi 21 novembre 2012 à 08:54 -0500, Ian Stakenvicius a > écrit : >> On 21/11/12 04:43 AM, Michał Górny wrote: >>> Moved: python_export, getters, python_domodule, python_doscript >>> and the necessary internal functions. No global-scope >>> variables, no phase functions. [ Snip! ] >> >> So remind me again, in 10 words or less, why these shouldn't all >> stay in python-r1.eclass? ie, what use case do we have for >> using python-utils-r1 but not python-r1 (or vice-versa, depending >> on which one inherits the other)? > > From "[gentoo-dev] python-r1.eclass: the masterplan (dirty RFC)" > email: > > Le lundi 12 novembre 2012 à 15:43 +0100, Michał Górny a écrit : >> 1) splitting common functions into python-utils-r1. >> >> The python-utils-r1 eclass would provide means to work with >> specific Python packages like portage. Unlike python-r1, it would >> not export IUSE or require any specific USE flags. >> >> I'm not insisting on this nor giving it a very high priority. It >> is a straightforward change since python-r1 will inherit the new >> eclass anyway. > > Ahh ok, so only very specific tools for very specific use cases. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlCs85UACgkQ2ugaI38ACPCxHwD9FvHW2Ke/lcsTDomAIOpEqreH Vo6YDYUeDTm2GlBhA4cA/1yG0Fkh+7MNBZc31naOAvL7rh51Xhj8KxHHDuPsfKyC =qsUS -END PGP SIGNATURE-
Re: [gentoo-dev] gstreamer eclass review
Hi Gilles, The eclass itself looks fine, I would just ask if you would not mind to use the bash += syntax rather than VAR="VAR something" as it is shorter and easier to read. Cheers Tom
Re: [gentoo-dev] [PATCH python-r1] Move common utility functions to python-utils-r1.
Le mercredi 21 novembre 2012 à 08:54 -0500, Ian Stakenvicius a écrit : > On 21/11/12 04:43 AM, Michał Górny wrote: > > Moved: python_export, getters, python_domodule, python_doscript and > > the necessary internal functions. No global-scope variables, no > > phase functions. [ Snip! ] > > So remind me again, in 10 words or less, why these shouldn't all stay > in python-r1.eclass? ie, what use case do we have for using > python-utils-r1 but not python-r1 (or vice-versa, depending on which > one inherits the other)? >From "[gentoo-dev] python-r1.eclass: the masterplan (dirty RFC)" email: Le lundi 12 novembre 2012 à 15:43 +0100, Michał Górny a écrit : > 1) splitting common functions into python-utils-r1. > > The python-utils-r1 eclass would provide means to work with specific > Python packages like portage. Unlike python-r1, it would not export > IUSE or require any specific USE flags. > > I'm not insisting on this nor giving it a very high priority. It is > a straightforward change since python-r1 will inherit the new eclass > anyway.
Re: [gentoo-dev] [PATCH python-r1] Move common utility functions to python-utils-r1.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/11/12 04:43 AM, Michał Górny wrote: > Moved: python_export, getters, python_domodule, python_doscript and > the necessary internal functions. No global-scope variables, no > phase functions. [ Snip! ] So remind me again, in 10 words or less, why these shouldn't all stay in python-r1.eclass? ie, what use case do we have for using python-utils-r1 but not python-r1 (or vice-versa, depending on which one inherits the other)? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlCs3RIACgkQ2ugaI38ACPBDlgEAq70QL+M5jDtM8zcUJs4y0bkp fDpQaPIzy6KCvM0e6S8A/iCB2yTSimQimegtIVwUE9RrLLSyifd+IljGP/6xvksB =Kebg -END PGP SIGNATURE-
[gentoo-dev] [PATCH python-r1] Move common utility functions to python-utils-r1.
Moved: python_export, getters, python_domodule, python_doscript
and the necessary internal functions. No global-scope variables,
no phase functions.
---
gx86/eclass/python-r1.eclass | 409 +-
gx86/eclass/python-utils-r1.eclass | 434 +
2 files changed, 440 insertions(+), 403 deletions(-)
create mode 100644 gx86/eclass/python-utils-r1.eclass
diff --git a/gx86/eclass/python-r1.eclass b/gx86/eclass/python-r1.eclass
index 84dc50f..6cf4200 100644
--- a/gx86/eclass/python-r1.eclass
+++ b/gx86/eclass/python-r1.eclass
@@ -23,6 +23,11 @@
# Please note that this eclass is mostly intended to be extended
# on-request. If you find something you used in other eclasses missing,
# please don't hack it around and request an enhancement instead.
+#
+# Also, please note that python-r1 will always inherit python-utils-r1
+# as well. Thus, all the functions defined and documented there
+# can be used in the packages using python-r1, and there is no need ever
+# to inherit both.
case "${EAPI}" in
0|1|2|3)
@@ -36,7 +41,7 @@ case "${EAPI}" in
;;
esac
-inherit multilib
+inherit python-utils-r1
# @ECLASS-VARIABLE: _PYTHON_ALL_IMPLS
# @INTERNAL
@@ -181,160 +186,6 @@ _python_set_globals
# ${WORKDIR}/foo-1.3-python2_6
# @CODE
-# @ECLASS-VARIABLE: PYTHON
-# @DESCRIPTION:
-# The absolute path to the current Python interpreter.
-#
-# Set and exported only in commands run by python_foreach_impl().
-#
-# Example value:
-# @CODE
-# /usr/bin/python2.6
-# @CODE
-
-# @ECLASS-VARIABLE: EPYTHON
-# @DESCRIPTION:
-# The executable name of the current Python interpreter.
-#
-# This variable is used consistently with python.eclass.
-#
-# Set and exported only in commands run by python_foreach_impl().
-#
-# Example value:
-# @CODE
-# python2.6
-# @CODE
-
-# @ECLASS-VARIABLE: PYTHON_SITEDIR
-# @DESCRIPTION:
-# The path to Python site-packages directory.
-#
-# Set and exported on request using python_export().
-#
-# Example value:
-# @CODE
-# /usr/lib64/python2.6/site-packages
-# @CODE
-
-# @FUNCTION: python_export
-# @USAGE: [] ...
-# @DESCRIPTION:
-# Set and export the Python implementation-relevant variables passed
-# as parameters.
-#
-# The optional first parameter may specify the requested Python
-# implementation (either as PYTHON_TARGETS value, e.g. python2_7,
-# or an EPYTHON one, e.g. python2.7). If no implementation passed,
-# the current one will be obtained from ${EPYTHON}.
-#
-# The variables which can be exported are: PYTHON, EPYTHON,
-# PYTHON_SITEDIR. They are described more completely in the eclass
-# variable documentation.
-python_export() {
- debug-print-function ${FUNCNAME} "${@}"
-
- local impl var
-
- case "${1}" in
- python*|jython*)
- impl=${1/_/.}
- shift
- ;;
- pypy-c*)
- impl=${1}
- shift
- ;;
- pypy*)
- local v=${1#pypy}
- impl=pypy-c${v/_/.}
- shift
- ;;
- *)
- impl=${EPYTHON}
- [[ ${impl} ]] || die "python_export: no impl nor
EPYTHON"
- ;;
- esac
- debug-print "${FUNCNAME}: implementation: ${impl}"
-
- for var; do
- case "${var}" in
- EPYTHON)
- export EPYTHON=${impl}
- debug-print "${FUNCNAME}: EPYTHON = ${EPYTHON}"
- ;;
- PYTHON)
- export PYTHON=${EPREFIX}/usr/bin/${impl}
- debug-print "${FUNCNAME}: PYTHON = ${PYTHON}"
- ;;
- PYTHON_SITEDIR)
- local dir
- case "${impl}" in
- python*)
- dir=/usr/$(get_libdir)/${impl}
- ;;
- jython*)
- dir=/usr/share/${impl}/Lib
- ;;
- pypy*)
-
dir=/usr/$(get_libdir)/${impl/-c/}
- ;;
- esac
-
- export
PYTHON_SITEDIR=${EPREFIX}${dir}/site-packages
- debug-print "${FUNCNAME}: PYTHON_SITEDIR =
${PYTHON_SITEDIR}"
- ;;
- *)
- die "python_export: unknown variable ${var}"
- esac
- done
-}
-
-# @FUNCTION: python_get_PYTH
