[gentoo-dev] Suggestion: Globalness of some USE flags
I think that cairo, logrotate, openexr, udev and vnc USE flags should be global. These are now local USE flags. Do you agree to change their globalness? Jak zerwać z dziewczyną, która potrafi fruwać, przenosić góry i przebijać wzrokiem stalowe pancerze? Uma Thurman w komedii MOJA SUPER EKSDZIEWCZYNA. Już kinach! http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fmojasuperdziewczyna.htmlsid=857 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] SRC_URI behaviour
2013-06-15 17:51 Rich Freeman napisał(a): Plus, right now with Gentoo there is no way to set an overlay as being LOWER priority than the main tree - so that you can grab packages not supported in main from an overlay but still use the main packages when available. Portage has been supporting setting of priority in /etc/portage/repos.conf for about 2.7 years. $ cat /etc/portage/repos.conf [name_of_overlay] priority = -1001 (`emerge --info -v` shows repositories with their priorities.) -- Arfrever Frehtes Taifersar Arahesis
[gentoo-dev] Marking of deprecated USE flags
Some people want that repoman print warnings for ebuilds, whose effective IUSE contains deprecated USE flags (e.g. USE flags corresponding to old versions of Python/Ruby). I suggest that deprecation of USE flags be specified by (DEPRECATED) suffix in descriptions of given flags in profiles/use.desc and profiles/desc/*.desc files. Any opinions about syntax? Example: Index: profiles/desc/python_single_target.desc === RCS file: /var/cvsroot/gentoo-x86/profiles/desc/python_single_target.desc,v retrieving revision 1.5 diff -u -r1.5 python_single_target.desc --- profiles/desc/python_single_target.desc 5 Aug 2013 14:20:47 - 1.5 +++ profiles/desc/python_single_target.desc 9 Aug 2013 16:27:37 - @@ -4,14 +4,14 @@ # This file contains descriptions of PYTHON_SINGLE_TARGET USE_EXPAND flags. -python2_5 - Build for Python 2.5 only +python2_5 - Build for Python 2.5 only (DEPRECATED) 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_1 - Build for Python 3.1 only (DEPRECATED) python3_2 - Build for Python 3.2 only python3_3 - Build for Python 3.3 only -jython2_5 - Build for Jython 2.5 only +jython2_5 - Build for Jython 2.5 only (DEPRECATED) jython2_7 - Build for Jython 2.7 only -pypy1_9 - Build for PyPy 1.9 only +pypy1_9 - Build for PyPy 1.9 only (DEPRECATED) pypy2_0 - Build for PyPy 2.0 only pypy2_1 - Build for PyPy 2.1 only Index: profiles/desc/python_targets.desc === RCS file: /var/cvsroot/gentoo-x86/profiles/desc/python_targets.desc,v retrieving revision 1.9 diff -u -r1.9 python_targets.desc --- profiles/desc/python_targets.desc 5 Aug 2013 14:20:47 - 1.9 +++ profiles/desc/python_targets.desc 9 Aug 2013 16:27:37 - @@ -4,15 +4,15 @@ # This file contains descriptions of PYTHON_TARGETS USE_EXPAND flags. -python2_5 - Build with Python 2.5 +python2_5 - Build with Python 2.5 (DEPRECATED) python2_6 - Build with Python 2.6 python2_7 - Build with Python 2.7 -python3_1 - Build with Python 3.1 +python3_1 - Build with Python 3.1 (DEPRECATED) python3_2 - Build with Python 3.2 python3_3 - Build with Python 3.3 python3_4 - Build with Python 3.4 -jython2_5 - Build with Jython 2.5 +jython2_5 - Build with Jython 2.5 (DEPRECATED) jython2_7 - Build with Jython 2.7 -pypy1_9 - Build with PyPy 1.9 +pypy1_9 - Build with PyPy 1.9 (DEPRECATED) pypy2_0 - Build with PyPy 2.0 pypy2_1 - Build with PyPy 2.1 Index: profiles/desc/ruby_targets.desc === RCS file: /var/cvsroot/gentoo-x86/profiles/desc/ruby_targets.desc,v retrieving revision 1.3 diff -u -r1.3 ruby_targets.desc --- profiles/desc/ruby_targets.desc 23 Jun 2013 12:31:14 - 1.3 +++ profiles/desc/ruby_targets.desc 9 Aug 2013 16:27:37 - @@ -6,7 +6,7 @@ rbx - Build with Rubinius jruby - Build with JRuby -ree18 - Build with Ruby Enterprise Edition 1.8.x +ree18 - Build with Ruby Enterprise Edition 1.8.x (DEPRECATED) ruby18 - Build with MRI Ruby 1.8.x ruby19 - Build with MRI Ruby 1.9.x ruby20 - Build with MRI Ruby 2.0.x -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots
2013-09-26 17:04 Michael Palimaka napisał(a):
What about when the subslot of boost was equal to ${PV}? Was it really a
good idea to make everyone rebuild half their system for a bugfix
release, without even checking if the ABI changed?
It is wrong example due to 2 reasons:
1. Subslot of dev-libs/boost::gentoo was never equal to ${PV}.
2. Sonames of Boost libraries actually include full ${PV}, so rebuilding of
reverse dependencies
would be necessary after upgrade from Boost 1.54.0 to hypothetical 1.54.1.
Although upstream rarely releases X.Y.Z with Z != 0 (last was 1.46.1).
http://www.boost.org/users/history/
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
2009-03-08 10:43:44 Tiziano Müller napisał(a): Am Sonntag, den 08.03.2009, 00:08 -0800 schrieb Josh Saddler: Tiziano Müller wrote: Hi everyone With eapis 1 and 2 we introduced nice features but also a couple of new problems. One of them are the use dependencies when the package you depend on doesn't have the use flag anymore (see [1] for an example). So I think it's time for a short eapi bump with some distinct improvements: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ Is there a reason why we should ram through a new EAPI for something that *looks* like another Paludis supports this so let's make it a Portage standard proposal? Ok, first it's not about paludis,portage,pkgcore,whatever but about the ebuild-format. Paludis also fails if you have DEPEND=cat/foo[moo] in bar-0.1.ebuild but cat/foo doesn't have a moo USE flag. So, please let's focus on the problems we have and try to find a solution. Please fill in the blanks in the table if you know how portage has it implemented. And I used the word fast because people start to use use-dependencies on a larger scale leading to more problems like the one I described in the example. In fact, you could already say that for git the dep-tree is broken because newer subversion doesn't carry the dso USE flag anymore. http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-util/subversion/subversion-1.5.5.ebuild?view=markup contains: IUSE=apache2 berkdb debug doc +dso emacs extras java nls perl python ruby sasl vim-syntax +webdav-neon webdav-serf ^^^ (Subversion 1.6.* also has dso USE flag.) -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Request for testing of GnuTLS 2.7.*
GnuTLS =2.7.1 doesn't contain 'libgnutls-config' and 'libgnutls-extra-config' scripts so packages, which use them, usually fail to build. (Sometimes `configure` scripts disable support for GnuTLS without failing.) The list of packages depending on net-libs/gnutls is available at: http://tinderbox.dev.gentoo.org/misc/dindex/net-libs/gnutls If you maintain or use a package included in this list, please check if it can be built with =net-libs/gnutls-2.7.1. If a package fails to build with =net-libs/gnutls-2.7.1 and it hasn't been reported yet, please report a bug and make it block bug 253709 [1]. GnuTLS 2.8.0 will be released soon and we would like to unmask it without waiting too long. [1] https://bugs.gentoo.org/show_bug.cgi?id=253709 -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
I would like to suggest to include possibility of using of features of bash-4.0 (and older versions) in local scope of EAPI=3 ebuilds. I know that it's slightly late, but this change is very easy to implement (adjusting RDEPEND of new versions of package managers and updating PMS). -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
2009-05-17 18:37:32 Ciaran McCreesh napisał(a): On Sun, 17 May 2009 18:20:21 +0200 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote: I would like to suggest to include possibility of using of features of bash-4.0 (and older versions) in local scope of EAPI=3 ebuilds. I know that it's slightly late, but this change is very easy to implement (adjusting RDEPEND of new versions of package managers and updating PMS). No good, for two reasons. First, this is a global scope change Why do you think that it is a global scope change? and we can't make global scope changes to EAPIs using current mechanisms. EAPIs have to carry on using bash 3 until the EAPI mechanism is changed. IMHO ebuilds are allowed to set DEPEND==app-shells/bash-4.0 and use bash-4.0 features anyway, but it would be easier to just set appropriate EAPI in ebuilds. Second, by order of the Council, EAPI 3's feature list was locked several weeks ago. If we ignore that for one thing, it just means everyone else who had features that came along too late will start demanding we reconsider those too... IMHO addition of this feature would be acceptable. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] GLEP 55 updated
2009-05-17 20:57:25 Robert Buchholz napisał(a): On Sunday 17 May 2009, Piotr Jaroszyński wrote: Hello, I have just updated GLEP 55 [1], hopefully making it a bit clearer. Just FYI, my order of preference of solutions is: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change Judging from this list, fourth option present in the GLEP is unacceptable for you? 4. Easily fetchable EAPI inside the ebuild +1 -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: EAPI Changes
2009-05-17 22:51:50 Ryan Hill napisał(a):
On Sun, 17 May 2009 21:03:46 +0200
Tiziano Müller dev-z...@gentoo.org wrote:
So, unless you're doing a pkgmove
it's a dangerous thing since the PM can't reliably track reverse deps
when doing uninstalls since it has to use the vdb entry for that,
doesn't it?
Since when do we track reverse deps for uninstalls?
Portage supports `emerge --depclean ${package}` command which checks reverse
dependencies.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
2009-05-17 19:02:02 Piotr Jaroszyński napisał(a): 2009/5/17 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: 2009-05-17 18:37:32 Ciaran McCreesh napisał(a): On Sun, 17 May 2009 18:20:21 +0200 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote: I would like to suggest to include possibility of using of features of bash-4.0 (and older versions) in local scope of EAPI=3 ebuilds. I know that it's slightly late, but this change is very easy to implement (adjusting RDEPEND of new versions of package managers and updating PMS). No good, for two reasons. First, this is a global scope change Why do you think that it is a global scope change? I have updated the glep, see how it breaks [1]. [1] - http://dev.gentoo.org/~peper/glep-0055.html#use-newer-bash-features This error occurs only when there is no up-to-date cache for given ebuild. rsync users would see only the usual masked by: EAPI 3 message. Here's the updated version of my proposition: * bash-4.0 features are allowed in EAPI=3 (global scope and local scope). * bash-4.0 features temporarily shouldn't be used in gentoo-x86 repository until 1 month has passed since stabilization of =app-shells/bash-4.0* on all architectures. It will give Gentoo developers sufficient time to update app-shells/bash. (app-shells/bash used on system, which generates cache, also should be updated.) -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
2009-05-20 19:29:12 Piotr Jaroszyński napisał(a): 2009/5/20 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org: 2009-05-17 19:02:02 Piotr Jaroszyński napisał(a): 2009/5/17 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: 2009-05-17 18:37:32 Ciaran McCreesh napisał(a): On Sun, 17 May 2009 18:20:21 +0200 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote: I would like to suggest to include possibility of using of features of bash-4.0 (and older versions) in local scope of EAPI=3 ebuilds. I know that it's slightly late, but this change is very easy to implement (adjusting RDEPEND of new versions of package managers and updating PMS). No good, for two reasons. First, this is a global scope change Why do you think that it is a global scope change? I have updated the glep, see how it breaks [1]. [1] - http://dev.gentoo.org/~peper/glep-0055.html#use-newer-bash-features This error occurs only when there is no up-to-date cache for given ebuild. rsync users would see only the usual masked by: EAPI 3 message. Relying on cache being valid is doomed to fail. Among other things, what about overlays? People managing overlays can temporarily disallow using bash-4.0 features in their overlays or they can drop support for bash-3, but it is outside of scope of my proposition. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
2009-05-20 20:00:43 Ciaran McCreesh napisał(a): On Wed, 20 May 2009 19:12:56 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: This error occurs only when there is no up-to-date cache for given ebuild. rsync users would see only the usual masked by: EAPI 3 message. We always have to assume that there might not be an up to date cache. The Gentoo rsync mirrors do not always ship up to date cache, particularly if someone's just changed a widely used eclass. Users can wait an hour and run `emerge --sync` again. Anyway, Portage still allows to install other ebuilds (with lower EAPI) of given package, so this corner case doesn't need to slow down progress. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
2009-05-17 18:20:21 Arfrever Frehtes Taifersar Arahesis napisał(a): I would like to suggest to include possibility of using of features of bash-4.0 (and older versions) in local scope of EAPI=3 ebuilds. I know that it's slightly late, but this change is very easy to implement (adjusting RDEPEND of new versions of package managers and updating PMS). Zac Medico doesn't have objections to this proposition, so I hope that Council will approve it. From #gentoo-portage: [22:40:11] Arfrever zmedico: What is your opinion about allowing bash-4.0 features in EAPI=3? ... [22:55:03] zmedico Arfrever: that's fine with me ... [22:56:15] Arfrever zmedico: Could you respond to the thread on gentoo-dev mailing list about it? ... [22:56:59] tanderson I'd not mind seeing bash 4 in eapi 3; and I don't buy ciaran's argument that it'll open the door for all the other latecomers [22:57:20] igli takes out life-insurance on tanderson ;p [22:57:22] zmedico Arfrever: can you just respond for me and say zac says it's okay with him? :) [22:58:52] zmedico is migrating his thunderbird pop setup to use all imap and filters in gmial [22:58:55] zmedico *gmail [22:59:08] tanderson igli: disagreeing technically isn't something that can get you killed! You're notplaying the odds well my friend [22:59:23] Arfrever zmedico: OK. [22:59:34] zmedico Arfrever: thanks a lot :) -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Monthly Gentoo Council Reminder for June
2009-06-01 07:30:01 Mike Frysinger napisał(a):
This is your monthly friendly reminder ! Same bat time (typically
the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel
(#gentoo-council @ irc.freenode.net) !
If you have something you'd wish for us to chat about, maybe even
vote on, let us know ! Simply reply to this e-mail for the whole
Gentoo dev list to see.
Please vote on:
* Temporary unlocking of list of features of EAPI=3
* Allowing bash-4.0 features in EAPI=3 ebuilds
* Temporary disallowing of adding bash-4.0 features to ebuilds in
gentoo-x86 repository until ${TIME:-1 month} has passed since
stabilization of =app-shells/bash-4.0* on all architectures.
Details of this proposition were already discussed on:
http://archives.gentoo.org/gentoo-dev/msg_fac31baaca8de3fb39ba6209fced9362.xml
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] [RFC] [EAPI=3] Add approprietly prefixed values of IUSE_* variables to IUSE
I would like to suggest that values of IUSE_* variables (whose names end with
values of USE_EXPAND variable), after prefixing with lower-cased names of
appropriate variables included in USE_EXPAND, should be automatically added
to IUSE variable.
Example:
IUSE=abc
IUSE_LINGUAS=en fr +la pl ru
Effective IUSE would be abc linguas_en linguas_fr +linguas_la linguas_pl
linguas_ru.
Currently ebuilds need to manually add such flags to IUSE.
It's a zero-cost feature implemented in the attached patch, so including it
in EAPI=3 (after temporary unlocking of list of features of EAPI=3) wouldn't
delay implementing support for EAPI=3 in Portage.
--
Arfrever Frehtes Taifersar Arahesis
Index: bin/ebuild.sh
===
--- bin/ebuild.sh (revision 13786)
+++ bin/ebuild.sh (working copy)
@@ -1154,6 +1154,22 @@ debug-print-section() {
debug-print now in section $*
}
+expand_IUSE() {
+ if ! has ${EAPI:-0} 0 1 2 ; then
+ local var flag flag_prefix
+ for var in $USE_EXPAND ; do
+ for flag in $(eval echo \$IUSE_$var) ; do
+flag_prefix=
+if [[ ${flag:0:1} == [+-] ]] ; then
+ flag_prefix=${flag:0:1}
+ flag=${flag:1}
+fi
+IUSE=$IUSE $flag_prefix$(echo $var | LC_ALL=C tr [:upper:] [:lower:])_$flag
+ done
+ done
+ fi
+}
+
# Sources all eclasses in parameters
declare -ix ECLASS_DEPTH=0
inherit() {
@@ -1240,6 +1256,8 @@ inherit() {
#turn off glob expansion
set -f
+ expand_IUSE
+
# If each var has a value, append it to the global variable E_* to
# be applied after everything is finished. New incremental behavior.
[ ${IUSE-unset}!= unset ] export E_IUSE=${E_IUSE} ${IUSE}
@@ -1750,6 +1768,10 @@ _source_ebuild() {
# eclasses, they need to be unset before this process of
# interaction begins.
unset DEPEND RDEPEND PDEPEND IUSE
+ local var
+ for var in $USE_EXPAND ; do
+ unset IUSE_$var
+ done
source ${EBUILD} || die error sourcing ebuild
if [ ${EBUILD_PHASE} != depend ] ; then
@@ -1773,6 +1795,8 @@ _source_ebuild() {
unset ECLASS E_IUSE E_DEPEND E_RDEPEND E_PDEPEND
+ expand_IUSE
+
# alphabetically ordered by $EBUILD_PHASE value
local f valid_phases
case $EAPI in
Index: bin/isolated-functions.sh
===
--- bin/isolated-functions.sh (revision 13786)
+++ bin/isolated-functions.sh (working copy)
@@ -512,8 +512,8 @@ save_ebuild_env() {
abort_test abort_install dyn_prepare dyn_configure \
dyn_compile dyn_test dyn_install \
dyn_preinst dyn_help debug-print debug-print-function \
- debug-print-section inherit EXPORT_FUNCTIONS newdepend newrdepend \
- newpdepend do_newdepend remove_path_entry \
+ debug-print-section expand_IUSE inherit EXPORT_FUNCTIONS \
+ newdepend newrdepend newpdepend do_newdepend remove_path_entry \
save_ebuild_env filter_readonly_variables preprocess_ebuild_env \
source_all_bashrcs ebuild_main \
ebuild_phase ebuild_phase_with_hooks \
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] [EAPI=3] Add approprietly prefixed values of IUSE_* variables to IUSE
2009-07-05 13:36:24 David Leverton napisał(a):
On Sunday 05 July 2009 03:33:54 Arfrever Frehtes Taifersar Arahesis wrote:
I would like to suggest that values of IUSE_* variables (whose names end
with values of USE_EXPAND variable), after prefixing with lower-cased names
of appropriate variables included in USE_EXPAND, should be automatically
added to IUSE variable.
USE_EXPAND is set in the profiles, so it can't be used during metadata
generation.
OK. I think that the proposed new behavior could concern all IUSE_* variables
(maybe except IUSE_IMPLICIT).
It's a zero-cost feature implemented in the attached patch, so including it
in EAPI=3 (after temporary unlocking of list of features of EAPI=3)
wouldn't delay implementing support for EAPI=3 in Portage.
http://www.gentoo.org/proj/en/council/meeting-logs/20090409-summary.txt
Council can vote on changing of its previous decisions.
--
Arfrever Frehtes Taifersar Arahesis
Index: bin/ebuild.sh
===
--- bin/ebuild.sh (revision 13805)
+++ bin/ebuild.sh (working copy)
@@ -1182,6 +1182,24 @@
debug-print now in section $*
}
+expand_IUSE() {
+ if ! has ${EAPI:-0} 0 1 2 ; then
+ local var flag flag_prefix
+ for var in ${!IUSE_*} ; do
+ if [[ $var != IUSE_IMPLICIT ]] ; then
+for flag in ${!var} ; do
+ flag_prefix=
+ if [[ ${flag:0:1} == [+-] ]] ; then
+ flag_prefix=${flag:0:1}
+ flag=${flag:1}
+ fi
+ IUSE=$IUSE $flag_prefix$(echo ${var#IUSE_} | LC_ALL=C tr [:upper:] [:lower:])_$flag
+done
+ fi
+ done
+ fi
+}
+
# Sources all eclasses in parameters
declare -ix ECLASS_DEPTH=0
inherit() {
@@ -1268,6 +1286,8 @@
#turn off glob expansion
set -f
+ expand_IUSE
+
# If each var has a value, append it to the global variable E_* to
# be applied after everything is finished. New incremental behavior.
[ ${IUSE-unset}!= unset ] export E_IUSE=${E_IUSE} ${IUSE}
@@ -1785,6 +1805,12 @@
# eclasses, they need to be unset before this process of
# interaction begins.
unset DEPEND RDEPEND PDEPEND IUSE
+ local var
+ for var in ${!IUSE_*} ; do
+ if [[ $var != IUSE_IMPLICIT ]] ; then
+ unset $var
+ fi
+ done
source ${EBUILD} || die error sourcing ebuild
if [ ${EBUILD_PHASE} != depend ] ; then
@@ -1808,6 +1834,8 @@
unset ECLASS E_IUSE E_DEPEND E_RDEPEND E_PDEPEND
+ expand_IUSE
+
# alphabetically ordered by $EBUILD_PHASE value
local f valid_phases
case $EAPI in
Index: bin/isolated-functions.sh
===
--- bin/isolated-functions.sh (revision 13805)
+++ bin/isolated-functions.sh (working copy)
@@ -512,8 +512,8 @@
abort_test abort_install dyn_prepare dyn_configure \
dyn_compile dyn_test dyn_install \
dyn_preinst dyn_help debug-print debug-print-function \
- debug-print-section inherit EXPORT_FUNCTIONS newdepend newrdepend \
- newpdepend do_newdepend remove_path_entry \
+ debug-print-section expand_IUSE inherit EXPORT_FUNCTIONS \
+ newdepend newrdepend newpdepend do_newdepend remove_path_entry \
save_ebuild_env filter_readonly_variables preprocess_ebuild_env \
source_all_bashrcs ebuild_main \
ebuild_phase ebuild_phase_with_hooks \
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Re: Python 2.6.* stabilization plans
2009-05-18 06:47:56 Arfrever Frehtes Taifersar Arahesis napisał(a): I'm planning to request stabilization of Python 2.6.* in August. s/August/July/ I will also request stabilizations of other packages which need to be stabilized before Python 2.6.*. Please test various packages with Python 2.6.*. If you find a package which fails to build or doesn't work with Python 2.6.*, please report a bug and make it block bug #230205 [1]. [1] https://bugs.gentoo.org/show_bug.cgi?id=230205 -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Support for multiple ABIs (for Python modules etc.)
/${CATEGORY}/${PF}/ABIS):
python[2.6,3.1] ruby[1.9]
Names/syntax of specific variables etc. can be changed. Please write
constructive comments.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Support for multiple ABIs (for Python modules etc.)
2009-07-25 12:28:44 Arfrever Frehtes Taifersar Arahesis napisał(a):
I would like to present the plan of support for multiple ABIs. It should be
sufficient for
Python modules and might be also appropriate for some other ABI types (e.g.
for Ruby modules).
1. Portage will support repository-specific, profile-independent
${REPOSITORY}/profiles/settings
configuration files (filename can be changed). They will set some variables
(similarly to
make.defaults files). These variables shouldn't be overrideable by profiles,
eclasses, ebuilds
or by user's configuration files (e.g. /etc/portage/*). For future
compatibility these files
could also support lists/indexed arrays and dictionaries/associative
arrays/maps.
2. ${REPOSITORY}/profiles/settings will set ABI_TYPES and
${ABI_TYPE^^}_ABI_SUPPORTED_VALUES variables.
ABI_TYPES defines supported ABI types. ${ABI_TYPE^^}_ABI_SUPPORTED_VALUES
defines supported ABIs
for given ABI type.
Example (${REPOSITORY}/profiles/settings):
ABI_TYPES=python ruby ...
PYTHON_ABI_SUPPORTED_VALUES=2.4 2.5 2.6 3.0 3.1
RUBY_ABI_SUPPORTED_VALUES=1.8 1.9
3. make.defaults files will support
${ABI_TYPE^^}_ABI_FORCED_VALUES/${ABI_TYPE^^}_ABI_MASKED_VALUES
variables to force/mask specific ABIs in given profiles.
Example (make.defaults):
PYTHON_ABI_MASKED_VALUES=2.4 2.5
PYTHON_ABI_FORCED_VALUES=3.1
4. For convenience of developers ABI dependencies will be able to be
specified in explicit and
slightly implicit way. Ebuilds/eclasses, which support multiple ABIs, will
set USED_ABI_TYPES.
Ebuilds/eclasses will be able to set RESTRICT_${ABI_TYPE^^}_ABIS variables
which will support
'*' wildcard. USED_ABI_TYPES and RESTRICT_${ABI_TYPE^^}_ABIS variables should
be cumulative
(across eclasses and ebuild).
Example (ebuild):
USED_ABI_TYPES=python
# This package doesn't work yet with Python 2.6 and 3.*
RESTRICT_PYTHON_ABIS=2.6 3*
4.1. Implicitly specified ABI dependencies. During calculation of
dependencies of given package,
Portage will verify if all dependencies, which use given ABI type, have been
built with enabled
support for these ABIs, which are enabled for given package.
Example (ebuild):
# dev-python/bsddb3
USED_ABI_TYPES=python
RDEPEND==sys-libs/db-4.6
DEPEND=${RDEPEND}
dev-python/setuptools
doc? ( dev-python/sphinx )
Assuming that dev-python/setuptools and dev-python/sphinx set
USED_ABI_TYPES=python,
Portage will verify that, when user runs `USE_PYTHON=2.5 2.6 emerge
dev-python/bsddb3`,
dev-python/setuptools and dev-python/sphinx (when USE=doc is enabled)
are built with
enabled support for at least 2.5 and 2.6 Python ABIs. If they are
already installed
without support for e.g. 2.5 Python ABI, Portage will print appropriate
error message
(similarly to unsatisfied USE dependencies) and exit.
4.2. Explicitly specified ABI dependencies. {,P,R}DEPEND variables will
support specifying
ABI dependencies in explicit way. {,P,R}DEPEND variables will also support
ABI conditionals.
I suggest using {ABI_type[comma-delimited values]} syntax, but it can be
changed.
Example (ebuild):
DEPEND=category/package1{python[2.5,2.6],ruby[-1.8]}
RDEPEND={python[2.6]}? ( category/package2 )
Example (python.eclass):
DEPEND=
{python[2.4]}? ( dev-lang/python:2.4 )
{python[2.5]}? ( dev-lang/python:2.5 )
{python[2.6]}? ( dev-lang/python:2.6 )
{python[3.0]}? ( dev-lang/python:3.0 )
{python[3.1]}? ( dev-lang/python:3.1 )
RDEPEND=${RDEPEND}
5. 18th line of metadata cache files will contain the list of ABI types and
values supported
(i.e. not restricted by RESTRICT_${ABI_TYPE^^}_ABIS variables) by given
package.
Example (18th line of metadata cache file):
python[2.5,2.6,3.0,3.1] ruby[1.8,1.9]
Every change to ${REPOSITORY}/profiles/settings should probably invalidate
whole metadata
cache of given repository.
6. Portage will support USE_${ABI_TYPE^^} variables in /etc/make.conf to
specify which ABIs
should be enabled.
Portage will also allow to set USE_${ABI_TYPE^^} variables per-package etc.
Example (/etc/make.conf):
USE_PYTHON=2.5 2.6 3.1
USE_RUBY=1.8 1.9
7. Portage will set ${ABI_TYPE^^}_ABIS variables in ebuild environment.
${ABI_TYPE^^}_ABIS
should contain ABIs forced by ${ABI_TYPE^^}_ABI_FORCED_VALUES and these ABIs
enabled by user
in /etc/make.conf by USE_${ABI_TYPE^^} which aren't masked by
${ABI_TYPE^^}_ABI_MASKED_VALUES.
${ABI_TYPE^^}_ABIS variables won't contain ABIs restricted by
RESTRICT_${ABI_TYPE^^}_ABIS
variables. Eclasses/ebuilds will be able to change the values of
${ABI_TYPE^^}_ABIS variables
in ebuild phases. For example python.eclass will support ignoring of build
failures for Python
ABIs specified by user in FAILURE_TOLERANT_PYTHON_ABIS variable. Python ABIs
Re: [gentoo-dev] Support for multiple ABIs (for Python modules etc.)
2009-07-26 14:40:13 Marijn Schouten (hkBst) napisał(a): Arfrever Frehtes Taifersar Arahesis wrote: I would like to present the plan of support for multiple ABIs. It should be sufficient for Python modules and might be also appropriate for some other ABI types (e.g. for Ruby modules). In the context of which problem are you brainstorming? This proposition is intended to solve multiple problems, but Gentoo Python Project especially would like to have it available during transitions to new Python versions (e.g. Python 3.*). Python 3.1 will be added to the tree in the next week. Over 10 Python modules should work with Python 3, but the majority of packages doesn't work yet. We want to provide possibility of installing Python modules into site-packages directories of multiple Python versions (e.g. 2.6 and 3.1). In currently existing EAPIs we *will* support it, but without checking Python ABI dependencies during dependency calculation. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Support for multiple ABIs (for Python modules etc.)
2009-08-01 20:10:49 Ciaran McCreesh napisał(a):
On Sat, 25 Jul 2009 12:28:44 +0200
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote:
I would like to present the plan of support for multiple ABIs. It
should be sufficient for Python modules and might be also appropriate
for some other ABI types (e.g. for Ruby modules).
How do you plan to handle the intersection of ABIs? What if you have to
build or depend upon a Python module for both 32 and 64 bit ABIs, and
for both 2.5 and 2.6? What if you have a package that provides both
Ruby and Python code, where the two ABIs are independent rather than a
product?
The proposition already handles these cases. Please describe in more details
what you don't
understand.
4.1. Implicitly specified ABI dependencies. During calculation of
dependencies of given package, Portage will verify if all
dependencies, which use given ABI type, have been built with enabled
support for these ABIs, which are enabled for given package.
How do you say I need only a single ABI for this, even though it looks
like I need every ABI I'm built with? For example, if your Python
module, being built for 2.5 and 2.6, runs (but does not use in a
library sense) a Python program that comes as part of a Python package
that is buildable with multiple ABIs?
In such case a Python package, which is a dependency of another Python package,
shouldn't
be marked as supporting multiple Python ABIs. But anyway I suggest the
following syntax:
category/package_name{python[*]}
4.2. Explicitly specified ABI dependencies. {,P,R}DEPEND variables
will support specifying ABI dependencies in explicit way.
{,P,R}DEPEND variables will also support ABI conditionals. I suggest
using {ABI_type[comma-delimited values]} syntax, but it can be
changed.
I think we're trying to avoid introducing new special characters if we
can get away with using existing ones. You can overload [] and existing
conditionals if you're careful.
The syntax suggested by me looks better for this purpose.
Having said that, you can probably do everything you described slightly
less elegantly just using things that're already in EAPI 3.
Not everything.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Make 10.0 profiles EAPI-2 'compliant'
2009-08-12 20:41:30 Tomáš Chvátal napisał(a): Dne středa 12 Srpen 2009 19:58:05 Jeremy Olexa napsal(a): I am suggesting that the new 10.0 profiles be marked as EAPI-2 compliant. This involves setting the content of the 'eapi' file to 2 and bumping up the required portage version. This seems like progress to me. Often, developers are complaining that they can't use SLOT syntax in profiles (I know that is EAPI-1). Since, the only time we can bump EAPI syntax in profiles is upon a new directory creation, this seems like a good time to me. The new profiles are still in flux until the official stages/cd's are produced. Also, another good reason is: why not? I don't think any Gentoo user can avoid EAPI-2 up til now anyway. Any comments? No comments means it will be decided off-list. Timeframe: 1 week from now. -Jeremy Agreed. This is great idea. Also we should allow the stuff as directory thingus (portage already handles it right). package.mask/koffice-2 package.mask/live-gnome +1. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
2009-08-21 23:17:56 Ryan Hill napisał(a): On Fri, 21 Aug 2009 16:25:35 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 2009-08-13 07:55:22 Ryan Hill napisał(a): On Wed, 12 Aug 2009 19:46:56 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 12 Aug 2009 20:41:30 +0200 Tomáš Chvátal scarab...@gentoo.org wrote: Also we should allow the stuff as directory thingus (portage already handles it right). That's a seperate thing that needs EAPI control. You'll need to propose it for EAPI 4 if you want that. Why is that (seriously curious, not disagreeing)? Portage has supported this for quite a while now. Does the current PMS disallow it? Portage documentation has been properly fixed (and the fix will be released in next version) and this feature can now be used in 10.0 profiles. How does changing the portage documentation magically add this to the PMS? PMS developers are unwilling to fix many bugs in PMS. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI 3 and nonfatal die
2009-08-21 22:56:41 David Leverton napisał(a):
In EAPI 3, most commands and functions provided by the package
manager automatically call die if they fail. There's also a
new nonfatal function that can be used to suppress this
behaviour: by prefixing a function/command call with nonfatal,
the automatic die behaviour is suppressed during the executation
of that function/command.
The difficulty here is that it's not clear what nonfatal should
do to explicit die and assert calls. On the one hand, if
nonfatal does suppress these functions, then nonfatal can be
usefully used with eclass functions - silly hypothetical example:
# eclass
escons() {
scons $...@} || die scons failed
}
# ebuild
nonfatal escons || do_something_else
On the other hand, it could be risky to change the behaviour of
existing functions like that:
do_foo() {
cd foo || die cd failed
# something that would be dangerous if run in some other directory
}
If called as nonfatal do_foo and the cd failed, do_foo
/wouldn't/ return a failure code - it would proceed with the rest
of its body and wreak all manner of havoc.
One way around this would be to add either an option to die to
explicitly tell it to respect nonfatal, or an alternative die
function. This would allow eclasses to choose to respect
nonfatal when it's safe to do so, but without changing existing
behaviour. The disadvantage of this is that it would require
changes to all eclass functions that could potentially use it,
plus the slight ugliness of making them handle older EAPIs as
well.
Another option would be to make die respect nonfatal by default,
and add an option that doesn't. This wouldn't require changes to
eclasses that want the nonfatal behaviour, but it would require
some care to make sure that it was used when necessary. A
potential advantage of this over the previous solution is that if
the force option is implemented with an environment variable,
it can be used regardless of EAPI - the previous example could be
changed to something like
do_foo() {
cd foo || DIE_FORCE=1 die cd failed
# something that would be dangerous if run in some other directory
}
Does anyone have any opinions on which of the four options (#1
make die respect nonfatal, #2 make die always die, #3 add a new
die variant that respects nonfatal, #4 make regular die respect
nonfatal, and add a new variant that doesn't) we should go with?
I think that 'DIE_FORCE=1 die ${die_message}' (which was invented by me)
would be the
best option. It will allow to use nonfatal() with eclass functions with the
smallest
number of required changes in eclasses.
I would like to also notice that (not yet approved by Council) definition of
nonfatal()
in PMS was recently drastically changed without proper discussion with
developers of
other package managers. [1] was sent about 20 minutes after discussion about
nonfatal()
started in #gentoo-portage in about 2009-08-06 19:45 UTC.
(I'm attaching IRC log from #gentoo-portage (in UTC+02 timezone).)
I think that such drastic changes should be first discussed on gentoo-dev
mailing list.
[1]
http://archives.gentoo.org/gentoo-pms/msg_5ae501394eaeff148cfc349f84d960c9.xml
--
Arfrever Frehtes Taifersar Arahesis
### Log session started at 2009-08-06T13:57:20 ###
[13:57:20] Arfrever [n=arfre...@gentoo/developer/arfrever] has joined #gentoo-portage
[13:57:20] Channel topic is: This is not a help/support channel || Ebuild dev questions go to #gentoo-dev-help and usage questions go to #gentoo || Portage resources: http://www.gentoo.org/proj/en/portage/index.xml#doc_chap6
[13:57:20] Topic was set by zmedico on 2009-06-07T06:54:17
[13:57:20] pratchett.freenode.net [...@*] has set channel mode +tnc
[13:57:20] Channel was created at 2006-11-26T07:42:44
[14:07:37] scarabeus [n=sca...@gentoo/developer/scarabeus] has quit IRC: No Ping reply in 90 seconds.
[14:11:27] scarabeus [n=sca...@net-2-2.jaw.cz] has joined #gentoo-portage
[14:37:51] sping_ [n=sp...@e179008226.adsl.alicedsl.de] has joined #gentoo-portage
[14:54:07] reavertm [n=reave...@gentoo/contributor/reavertm] has quit IRC: Remote closed the connection
[15:05:30] few [n=...@gibbs.nat.uni-magdeburg.de] has joined #gentoo-portage
[15:05:34] few [n=...@gibbs.nat.uni-magdeburg.de] has quit IRC: Remote closed the connection
[15:05:50] few [n=...@gibbs.nat.uni-magdeburg.de] has joined #gentoo-portage
[15:06:05] few [n=...@gibbs.nat.uni-magdeburg.de] has quit IRC: Client Quit
[15:08:02] slonopotamus [n=slono...@83.149.10.164] has quit IRC: Read error: 110 (Connection timed out)
[15:08:10] FuzzyRay [n=pvar...@gentoo/developer/FuzzyRay] has joined #gentoo-portage
[15:21:01] noisebleed [n=noise...@piggy.inescn.pt] has quit IRC: Remote closed the connection
[15:41:22] sping_ [n=sp...@gentoo/user/sping] is now known as sping_afk
[16:07:53] ali_bush [n=alist...@gentoo/developer/alibush] has quit IRC
Re: [gentoo-dev] EAPI 3 and nonfatal die
2009-08-22 00:51:14 Ciaran McCreesh napisał(a): On Sat, 22 Aug 2009 00:40:04 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: I would like to also notice that (not yet approved by Council) definition of nonfatal() in PMS was recently drastically changed without proper discussion with developers of other package managers. [1] was sent about 20 minutes after discussion about nonfatal() started in #gentoo-portage in about 2009-08-06 19:45 UTC. (I'm attaching IRC log from #gentoo-portage (in UTC+02 timezone).) I think that such drastic changes should be first discussed on gentoo-dev mailing list. There was no change to the definition of nonfatal. There was a change regardless of what you think. There was a clarification of the wording after it became clear that there was room to misinterpret the intent of the original wording, and it went through the usual Council-mandated process for such a change. This sentence contradicts your first sentence. Additionally you had deceived Christian Faulhammer by not presenting negative consequences of your patch and your interpretation of original wording of definition of nonfatal(). -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
2009-08-22 21:39:47 Ciaran McCreesh napisał(a): On Sat, 22 Aug 2009 01:54:22 +0100 AllenJB gentoo-li...@allenjb.me.uk wrote: Could there be room for fast track EAPI's to be considered on some occasions - eg. in this case an EAPI-2.1 which is simply EAPI-2 with the package.* as directory in profiles feature included? It's a possibility, since it's zero cost for Portage and an easy one to word into the specification. Another possibly nicer option would be to add the feature into EAPI 3. However, if we're considering this, we'd have to be absolutely totally clear that this isn't a call to open up EAPI 3 for yet more changes. EAPI=3 can be opened also for other changes trivial to implement (e.g. allowing bash-4.0 features). -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
2009-08-23 02:34:08 Ciaran McCreesh napisał(a):
On Sat, 22 Aug 2009 17:26:24 -0700
Chip Parker infowo...@gmail.com wrote:
Since you have a habit of ignoring relevant bits of technical
opposition to some of your more insane schemes, I'll cite *again* the
relevant portion.
I showed you the relevant portion. /etc/make.profile means it is user
configuration, which in turn means PMS has absolutely nothing to say
about it. Anything done under /etc/make.profile is entirely up to the
package manager and is not covered by the specification.
/etc/make.profile is by default a symlink to appropriate profile directory
in ${PORTDIR}/profiles. Documentation of /etc/make.profile concerns also
all profile directories.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI 3 and nonfatal die
2009-08-22 01:43:54 Ciaran McCreesh napisał(a): On Sat, 22 Aug 2009 01:39:41 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: There was a clarification of the wording after it became clear that there was room to misinterpret the intent of the original wording, and it went through the usual Council-mandated process for such a change. This sentence contradicts your first sentence. No, it doesn't. it went through the usual Council-mandated process for such a change clearly contradicts There was no change. There was a change in wording to better convey the original intent. There was no change in behaviour. There was a change in behavior of 'nonfatal eclass_function_which_sometimes_calls_die'. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-dev-announce] Deprecation of Python 2.4
2009-08-30 11:14:53 Petteri Räty napisał(a): Arfrever Frehtes Taifersar Arahesis wrote: Python 2.4 is deprecated. There are plans to mask for removal it when remaining packages incompatible with Python 2.5 are fixed. (We will announce masking of Python 2.4 at least 1 month before masking it.) Please don't add new packages to the tree which work only with Python 2.4. If you want to add a package which depends on a Python module, which had been maintained separately in the past, but has been also included in Python 2.5, then don't add this Python module to the tree only for use with Python 2.4, but instead depend on Python =2.5. Where's the CC and Reply-To to gentoo-dev? Does removing python 2.4 have any effect on the upgrade path for old installations? sys-apps/portage-2.1.4.5 should work with Python 2.5 and probably also 2.6. sys-apps/portage-2.1.6.7 works with Python 2.5 and 2.6. =sys-apps/portage-2.1.6.13 works with Python 2.5 and 2.6 and doesn't work with Python 2.4. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Stabilization of Python 3.1
Stabilization of Python 3.1.* will be requested at the beginning of november. There was a suggestion to create a news item which would inform users that temporarily they shouldn't switch to Python 3 as their main interpreter. Python ebuilds don't automatically activate Python 3, so I'm not sure if the news item is required. What is your opinion about it? -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Stabilization of Python 3.1
2009-09-19 20:22:49 Tobias Klausmann napisał(a): Hi! Aside from the remarks made by others (and speaking as someone who maintains Python software), there is one reason for me to not switch Python 3 to stable yet: lack of compatibility. Software that runs with 3.x will not run with any 2.x version as of today It's possible (and not too hard) to write code which works with Python 3 and 2.6. It might be also possible to support older versions, but it would require many ugly exec() calls etc. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Stabilization of Python 3.1
2009-09-19 20:45:45 Nirbheek Chauhan napisał(a): On Sat, Sep 19, 2009 at 10:18 PM, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: Stabilization of Python 3.1.* will be requested at the beginning of november. There was a suggestion to create a news item which would inform users that temporarily they shouldn't switch to Python 3 as their main interpreter. Python ebuilds don't automatically activate Python 3, so I'm not sure if the news item is required. What is your opinion about it? Have any other distribution moved to purely using python-3.1? We won't move to purely using Python 3.1. Both Python 2 and 3 will be used. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Stabilization of Python 3.1
2009-09-19 20:20:10 AllenJB napisał(a): Dirkjan Ochtman wrote: On Sat, Sep 19, 2009 at 19:06, Alex Legler a...@gentoo.org wrote: What is the point of stabilizing it if users shouldn't use it as main interpreter? Just leave it in ~arch until it can be safely used. Making it easily available so that people can port stuff, so that the entire world may be able to use it as their main interpreter sooner? Seriously, it's out there, there's no reason to keep it from stable. Just prevent people from making python invoke 3.x and everything will be fine. Cheers, Dirkjan Yes, there is a very good reason: The sanity of the users and those who support them. As a user who has spent a lot of time on IRC and the forums supporting other users, I think I can safely say that stabilizing a version of python which is not supported by portage will end up in a nightmare scenario. At the very least portage, python-updater and eselect, if not the majority of the commonly used tools (whichever of gentoolkit, portage-utils, eix, etc use python), should support python 3.1 before it goes stable. python-updater and eselect are written in bash. portage-utils are written in C. eix is written in C++. perhaps add a block to eselect so that python-3.1 can't be selected as the system python interpreter until portage supports it. Users might want to sometimes temporarily switch to Python 3 to test some Portage-unrelated code. Anyway Portage will support Python 3 soon. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Stabilization of Python 3.1
2009-09-20 16:53:37 Jesús Guerrero napisał(a): On Sun, 20 Sep 2009 00:41:32 +0200, Dawid Węgliński c...@gentoo.org wrote: On Sunday 20 of September 2009 00:32:28 Dale wrote: ~arch is for testing ebuilds, not the upstream package So it would be OK to mark something stable even tho portage itself doesn't work with it? Sorry, this makes no sense to me. I run stable for the most part and having a package that portage depends on that is not stable just sounds a little like putting the cart before the horse. See some of the other replies as to why this is a not so good idea. Dale :-) :-) You mix it up. Portage works with python 3.1. If an user switches to python 3.1 as the main interpreter, it's possible that his own scripts won't work. Yes? # eselect python set 2 # emerge -s foo File /usr/bin/emerge, line 41 except PermissionDenied, e: ^ SyntaxError: invalid syntax Ummm, yes, it works *beautifully*, you see. Nothing else to add. I have fixed it today :) . http://sources.gentoo.org/viewcvs.py/portage?rev=14289view=rev Marking it stable sometine in november give's some time to ebuilds maintainers to fix their python based apps just like it's done with gcc stabilization. That's not the usual case. In Gentoo we have a serious policy of not marking as stable things until it has passed one month without any serious bug report about it. There wasn't any serious bug report about Python 3.1. IIRC the only problem was a (already fixed) build failure caused by non-UTF-8 characters in header of Berkeley DB. Stabilization of Python 3.1.1-r1 is planned over 1 month after its addition to the tree and about 3 months after addition of 3.1 slot to the tree. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Stabilization of Python 3.1
2009-09-20 17:56:46 Nirbheek Chauhan napisał(a): On Sun, Sep 20, 2009 at 9:16 PM, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: Some packages (whose older versions might be stable) might soon start requiring Python 3. Stabilization of these packages cannot be delayed due to the fact that some other packages don't work with Python 3. Are you seriously suggesting that you would knowingly break existing packages in the tree? Please stop spreading untrue information. Stabilization of Python 3 (and packages which depend on Python 3) wouldn't break any packages and wouldn't require to switch main Python interpreter to Python 3. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Stabilization of Python 3.1
2009-09-20 18:51:53 Robert Buchholz napisał(a): On Sunday 20 September 2009, Arfrever Frehtes Taifersar Arahesis wrote: Some packages (whose older versions might be stable) might soon start requiring Python 3. Stabilization of these packages cannot be delayed due to the fact that some other packages don't work with Python 3. Of course they can. That is exactly the reason I am using a distribution (instead of LFS), because I expect maintainers of packages to coordinate and define a working set of packages for me to use. This includes holding back updates, fast-tracking updates, forward- and backward-porting. Automatisms in updates and blindly following upstream removes that extra value we are there to provide. I agree. But Python 3.1 doesn't have more issues than Python 2.6, so the stabilization is reasonable. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Stabilization of Python 3.1
2009-09-20 19:25:55 Nirbheek Chauhan napisał(a): On Sun, Sep 20, 2009 at 9:37 PM, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: which depend on Python 3) wouldn't break any packages and wouldn't require to switch main Python interpreter to Python 3. Package X (stable) requires python-2 Package Y (stable) requires python-3 = User can't use both at the same time. Distribute/Setuptools will ensure that appropriate shebang is present in Python scripts. In other cases, we can easily modify shebangs in installed scripts. (A new function in python.eclass could be created for this purpose, but until now it isn't needed.) -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Stabilization of Python 3.1
2009-09-20 19:30:54 Nirbheek Chauhan napisał(a): On Sun, Sep 20, 2009 at 8:54 PM, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 2009-09-20 16:53:37 Jesús Guerrero napisał(a): # eselect python set 2 # emerge -s foo File /usr/bin/emerge, line 41 except PermissionDenied, e: ^ SyntaxError: invalid syntax Ummm, yes, it works *beautifully*, you see. Nothing else to add. I have fixed it today :) . http://sources.gentoo.org/viewcvs.py/portage?rev=14289view=rev This is silly. portage itself was broken with python-3.1 and you want to stabilize it? You should distinguish between Python version used by Portage and Python version used by packages which can be installed by Portage. Actually, how did you make portage work with both 2.x and 3.x at the same time? Portage doesn't yet work with Python 3, but it hopefully change soon. I would be very interested to know this since afaik no useful program can work with both python-3 and python-2 with the same code. It isn't hard to write code which works with both Python 2.6 and 3.*. Example: $ cat get_protocol.py #!/usr/bin/env python # It allows to use print() function in 2.6. from __future__ import print_function import sys try: # Python 3 from urllib.parse import urlparse as urllib_parse_urlparse except ImportError: # Python 2 from urlparse import urlparse as urllib_parse_urlparse if len(sys.argv) != 2: sys.stderr.write(This script requires 1 argument: URL\n) def get_protocol(url): return urllib_parse_urlparse(url)[0] print(Protocol:, get_protocol(sys.argv[1])) $ ./get_protocol.py http://www.example.com Protocol: http -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Stabilization of Python 3.1
2009-09-20 19:47:28 Nirbheek Chauhan napisał(a): On Sun, Sep 20, 2009 at 11:05 PM, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: Package X (stable) requires python-2 Package Y (stable) requires python-3 = User can't use both at the same time. Distribute/Setuptools will ensure that appropriate shebang is present in Python scripts. In other cases, we can easily modify shebangs in installed scripts. (A new function in python.eclass could be created for this purpose, but until now it isn't needed.) Oooh, this will lead to more phun! Package A (module, stable) requires python-3 However, A is a dependency of *both* X and Y Now what? Slotting? Install to both/all python prefixes? Or some other ugly solution? There is a difference between Python scripts and Python modules. Python scripts should have shebang and this shebang is used to decide which interpreter should be used when './script.py' is called. But it is possible to call Python scripts using 'pythonX.Y script.py' which will enforce using of pythonX.Y instead of interpreter specified in shebang in this script. When one Python script executes another Python script (using e.g. subprocess.Popen()) then both scripts will work correctly even when they have different shebangs. Python modules shouldn't have shebang. Python modules are intended to be imported from Python scripts or other Python modules. Any shebang in a Python module is ignored, when this module is imported using 'import' statement. The chance that well known and often used Python modules start unconditionally require Python 3 in the near future is small, but Python scripts can safely do it. For example PyQt4 supports both Python 2 and 3, but a useful script, which uses PyQt4, might require Python 3. Seriously, if you *really* *really* want python-3 stable, it should: 1) NOT show up in `eselect python` to set as the default interpreter When a user wants to work for an hour with a script requiring Python 3, and doesn't want to use e.g. Portage during this time, then it is reasonable to run 'eselect python set python3.1' once and be able to just use './script.py' instead of having to type 'python3.1 script.py' every time. Next this user can switch active Python back to 2.6. 2) NOT be a dependency of any package in stable It isn't implementable without having to change dependencies in hundreds of packages. There is nothing wrong in having Python 3 installed which would use small amount of disk space. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Stabilization of Python 3.1
2009-09-20 20:46:17 Nirbheek Chauhan napisał(a): On Sun, Sep 20, 2009 at 11:57 PM, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: There is a difference between Python scripts and Python modules. Yes, I'm well aware of the difference between them. [snip] Python modules shouldn't have shebang. Python modules are intended to be imported from Python scripts or other Python modules. Any shebang in a Python module is ignored, when this module is imported using 'import' statement. You forget that the search path for both installs is different, and hence modules installed for python-3 cannot be found/used by scripts using python-2; These modules can be installed for both Python 2 and 3 simultaneously. Seriously, if you *really* *really* want python-3 stable, it should: ... 2) NOT be a dependency of any package in stable It isn't implementable without having to change dependencies in hundreds of packages. There is nothing wrong in having Python 3 installed which would use small amount of disk space. You're twisting what I mean. You know what I mean -- packages *needing* python-3. So Seriously, if you *really* *really* want python-3 stable, it should: ... 2) NOT be a dependency of any package in stable is already met, because no stable package unconditionally needs Python 3. If it was otherwise, then the dependency tree of these stable packages would be broken. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] python-wrapper breaks init scripts
2009-10-04 20:32:17 Hanno Böck napisał(a): I just stepped over a problem with the new python-wrapper. If I interpreted the changelogs correctly, since eselect-python-20090801 /usr/bin/python is no longer a symlink, but a wrapper. Since eselect-python-20090804 /usr/bin/python is a symlink to a wrapper. I find this a questionable idea simply for the overhead it causes, but it seems that this breaks all init-scripts using start-stop-daemon for python scripts. Example: http://bugs.gentoo.org/show_bug.cgi?id=286191 (same issue happens with some self-written python daemons we're using on our servers) I don't know what the reasons were for the change from symlinks to a wrapper Ebuilds (usually through python.eclass) need to be able to set requested version of Python without changing /usr/bin/python symlink. This is performed by setting EPYTHON environment variable (E in the name of this variable is related to words ebuild and eclass). If this variable isn't set, then Python wrapper uses version of Python configured using `eselect python`. Otherwise it uses version of Python referenced by this variable. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Stabilization of Python 3.1
2009-09-20 20:46:17 Nirbheek Chauhan napisał(a): On Sun, Sep 20, 2009 at 11:57 PM, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: There is a difference between Python scripts and Python modules. Yes, I'm well aware of the difference between them. [snip] Python modules shouldn't have shebang. Python modules are intended to be imported from Python scripts or other Python modules. Any shebang in a Python module is ignored, when this module is imported using 'import' statement. You forget that the search path for both installs is different, and hence modules installed for python-3 cannot be found/used by scripts using python-2; which results in the dependency hell; which was the basis for my whole argument. When both Python 2 and Python 3 are installed, then Python modules, which support both Python 2 and Python 3, are automatically installed for both Python 2 and Python 3. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] [RFC] Improve policy of stabilizations
Some packages have new releases more than once a month and sometimes it's reasonable to not skip stabilization of any version. Given version of a package is usually no longer tested by users after release of a newer version, so I suggest the following change to the policy of stabilizations: Stabilization of given version of a package can be requested if this version has been in the tree for at least 10 days and a newer version of this package has been added to the tree. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Versioning of Python scripts
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] [--] file [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 '$1' failed
fi
if [[ ${respect_EPYTHON} == 1
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.
[gentoo-dev] PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
I would like to suggest introduction of support for PYTHON_DEPEND variable,
which
would be a better replacement for NEED_PYTHON variable. NEED_PYTHON variable
does not allow to specify that e.g. only versions of Python 2 are accepted.
(Eventually PYTHON_DEPEND variable will have to be set only in ebuilds of
packages
not supporting installation for multiple versions of Python.)
Suggested syntax:
PYTHON_DEPEND=[USE_flag?] X[:[Y][:[Z]]] [X[:[Y][:[Z
required_component, [optional_component]
X - Major version of Python ('2' or '3') or '*'.
Y - Minimal version of Python in the form of
${major_version}.${minor_version}.
Z - Maximal version of Python in the form of
${major_version}.${minor_version}.
It will be probably very rarely used.
Examples:
PYTHON_DEPEND=2
Dependency on any version of Python 2.
PYTHON_DEPEND=2:2.5
Dependency on Python 2.7, 2.6 or 2.5.
PYTHON_DEPEND=*:2.6
Dependency on Python 3.2, 3.1, 3.0, 2.7 or 2.6.
PYTHON_DEPEND=2:2.7 3:3.1
Dependency on Python 3.2, 3.1 or 2.7.
PYTHON_DEPEND=2:2.5:2.6
Dependency on Python 2.6 or 2.5.
PYTHON_DEPEND=2::2.6
Dependency on Python 2.6, 2.5 or 2.4.
PYTHON_DEPEND=python? 2
Dependency on any version of Python 2 when python USE flag is enabled.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
2010-01-10 19:41:55 Sebastian Pipping napisał(a):
On 01/10/10 09:29, Arfrever Frehtes Taifersar Arahesis wrote:
I would like to suggest introduction of support for PYTHON_DEPEND variable,
which
would be a better replacement for NEED_PYTHON variable. NEED_PYTHON variable
does not allow to specify that e.g. only versions of Python 2 are accepted.
(Eventually PYTHON_DEPEND variable will have to be set only in ebuilds of
packages
not supporting installation for multiple versions of Python.)
Suggested syntax:
PYTHON_DEPEND=[USE_flag?] X[:[Y][:[Z]]] [X[:[Y][:[Z
required_component, [optional_component]
X - Major version of Python ('2' or '3') or '*'.
Y - Minimal version of Python in the form of
${major_version}.${minor_version}.
Z - Maximal version of Python in the form of
${major_version}.${minor_version}.
It will be probably very rarely used.
Examples:
PYTHON_DEPEND=2
Dependency on any version of Python 2.
PYTHON_DEPEND=2:2.5
Dependency on Python 2.7, 2.6 or 2.5.
PYTHON_DEPEND=*:2.6
Dependency on Python 3.2, 3.1, 3.0, 2.7 or 2.6.
PYTHON_DEPEND=2:2.7 3:3.1
Dependency on Python 3.2, 3.1 or 2.7.
PYTHON_DEPEND=2:2.5:2.6
Dependency on Python 2.6 or 2.5.
PYTHON_DEPEND=2::2.6
Dependency on Python 2.6, 2.5 or 2.4.
PYTHON_DEPEND=python? 2
Dependency on any version of Python 2 when python USE flag is enabled.
While I don't object improvements or changes on that front at all:
- How are SUPPORT_PYTHON_ABIS and RESTRICT_PYTHON_ABIS affected
by NEED_PYTHON now and by PYTHON_DEPEND in the future?
They aren't and won't be. PYTHON_DEPEND is designed mainly for packages
not supporting installation for multiple Python versions.
- The proposed approach doesn't look intuitive to me from a quick
view, sorry: Neither the examples nor the grammar. I didn't give
it that much time to be fair, though.
IMHO it's sufficiently intuitive :) .
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
2010-01-10 21:56:01 Fabian Groffen napisał(a): On 10-01-2010 09:29:28 +0100, Arfrever Frehtes Taifersar Arahesis wrote: I would like to suggest introduction of support for PYTHON_DEPEND variable, which would be a better replacement for NEED_PYTHON variable. NEED_PYTHON variable does not allow to specify that e.g. only versions of Python 2 are accepted. (Eventually PYTHON_DEPEND variable will have to be set only in ebuilds of packages not supporting installation for multiple versions of Python.) Can you explain the intended use of this variable, and why normal DEPEND is not sufficient? PYTHON_DEPEND is intented to simplify specification of dependency on Python. PYTHON_DEPEND=2:2.5 is shorter than: DEPEND=|| ( =dev-lang/python-2.7* =dev-lang/python-2.6* =dev-lang/python-2.5* ) -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
2010-01-11 04:55:02 Sebastian Pipping napisał(a):
PYTHON_DEPEND=2:2.5:2.6
Dependency on Python 2.6 or 2.5.
The colon (':') has two different semantics here.
The colon is only separator of components, so it has the same semantic.
Each component has strictly defined meaning.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
2010-01-11 08:50:30 Fabian Groffen napisał(a):
On 11-01-2010 01:25:45 +0100, Arfrever Frehtes Taifersar Arahesis wrote:
Can you explain the intended use of this variable, and why normal DEPEND
is not sufficient?
PYTHON_DEPEND is intented to simplify specification of dependency on Python.
PYTHON_DEPEND=2:2.5 is shorter than:
DEPEND=|| ( =dev-lang/python-2.7* =dev-lang/python-2.6*
=dev-lang/python-2.5* )
So if there is enough space to express the dependency with the current
syntax, is it worth introducing a new shorthand for it then?
Some eclasses already support some shorthands for specification of some
dependencies (e.g. need_apache2() in depend.apache.eclass).
As maintainer of some packages depending on Python, I express interest in
possibility of brief specification of dependency on Python. I won't be
enforcing using of this variable for developers, who want to directly
specify dependencies in {,R}DEPEND.
Also for this example, why does 2:2.5 expand to 2.7, 2.6 and 2.5? I
would have expected 2.0 ... 2.5.
The first component ('2') specifies the group of accepted versions.
The second component ('2.5') specifies the minimal accepted version inside
this group. ('2:2.5' is identical to '2:2.5:'.)
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
2010-01-11 12:04:05 Gilles Dartiguelongue napisał(a): It looks like what you really want is a ranged dependencies. Dependencies specified in PYTHON_DEPEND can be expanded into ranged dependencies in EAPIs, which support ranged dependencies. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
2010-01-11 11:14:11 Maciej Mrozowski napisał(a): On Monday 11 of January 2010 01:25:45 Arfrever Frehtes Taifersar Arahesis wrote: 2010-01-10 21:56:01 Fabian Groffen napisał(a): On 10-01-2010 09:29:28 +0100, Arfrever Frehtes Taifersar Arahesis wrote: I would like to suggest introduction of support for PYTHON_DEPEND variable, which would be a better replacement for NEED_PYTHON variable. NEED_PYTHON variable does not allow to specify that e.g. only versions of Python 2 are accepted. (Eventually PYTHON_DEPEND variable will have to be set only in ebuilds of packages not supporting installation for multiple versions of Python.) Can you explain the intended use of this variable, and why normal DEPEND is not sufficient? PYTHON_DEPEND is intented to simplify specification of dependency on Python. PYTHON_DEPEND=2:2.5 is shorter than: DEPEND=|| ( =dev-lang/python-2.7* =dev-lang/python-2.6* =dev-lang/python-2.5* ) Doesn't that accidentally mean that dev-lang/python is improperly slotted and all 2.x releases should be slotted with :2? dev-lang/python is properly slotted. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
2010-01-11 11:14:40 Fabian Groffen napisał(a): On 11-01-2010 08:29:32 +, Duncan wrote: Fabian Groffen posted on Mon, 11 Jan 2010 08:50:30 +0100 as excerpted: On 11-01-2010 01:25:45 +0100, Arfrever Frehtes Taifersar Arahesis wrote: Can you explain the intended use of this variable, and why normal DEPEND is not sufficient? PYTHON_DEPEND is intented to simplify specification of dependency on Python. PYTHON_DEPEND=2:2.5 is shorter than: DEPEND=|| ( =dev-lang/python-2.7* =dev-lang/python-2.6* =dev-lang/python-2.5* ) So if there is enough space to express the dependency with the current syntax, is it worth introducing a new shorthand for it then? Also for this example, why does 2:2.5 expand to 2.7, 2.6 and 2.5? I would have expected 2.0 ... 2.5. Maybe the language isn't as intuitive then as Sebastian pointed out. Initially intuitive, perhaps not, but reasonably easy after reading the explanation: The first position is major python version, the second if present, minimal version (within that major), so it can be read as =version, the third if present, maximum version (within that major), so it can be read as =. Thus, the above 2:2.5 means major version 2, minimal version 2.5 (no maximum version within that major), so 2.5+. what's wrong with =2.5 3.0 then? It's too long and harder to parse. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] emerge -C eselect-python disaster
2010-01-24 22:15:17 Mike Frysinger napisał(a): On Sunday 24 January 2010 00:12:39 Benny Pedersen wrote: it removes python-wrapper and this remove python link from /usr/bin/python linked to /usr/bin/python-wrapper so all portage does not work after this, but i solved it with a quickpkg from another host sounds a bug that should be filed so it can be fixed There's already bug #268724. Anyway, app-admin/eselect-python probably will have to be added to system set for a suggested feature for EAPI=5. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Python-3.2-related changes
It is planned that ebuilds of Python 3.2 will automatically set Python 3.2 as
main active
version of Python. (Currently ebuilds of Python 3.1 do not automatically set
Python 3.1
as main active version of Python.) Final release of Python 3.2 is currently
scheduled on
2010-12-11, so you have over 10 months for adjusting of your ebuilds.
The following changes should be made in ebuilds of packages supporting only
Python 2:
- Dependency on Python 2 should be set correctly. You can specify it directly in
{,R}DEPEND or use PYTHON_DEPEND.
Example:
PYTHON_DEPEND=2
inherit python
- Miscellaneous actions should be executed with correct version of Python.
- In ebuilds of packages supporting installation for multiple versions of
Python,
please remember to disable installation for all versions of Python 3.
(Please do not use python_set_active_version() in ebuilds of these
packages.)
Example:
RESTRICT_PYTHON_ABIS=3.*
- In ebuilds of packages not supporting installation for multiple versions of
Python,
set active version of Python using python_set_active_version().
(Please avoid passing precisely specified Python ABI to
python_set_active_version().)
Example:
pkg_setup() {
python_set_active_version 2
}
(If given package currently cannot be installed for multiple versions of
Python,
but it is theoretically possible (e.g. this package installs .py files into
/usr/lib/pythonX.Y/site-packages and does not install any non-versioned
libraries
into /usr/lib), then please try to adjust ebuilds of this package to allow
installation for multiple versions of Python.)
It is recommended to have set a version of Python 3 as main active version of
Python
during testing of these changes to ensure that no required change has been
missed.
I consider filing bugs for not adjusted packages after some months (e.g in
summer).
(Please note that these changes are not required before stabilization of Python
3.1,
so stabilization of Python 3.1 will not be delayed.)
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Python-3.2-related changes
2010-02-05 17:40:00 Arfrever Frehtes Taifersar Arahesis napisał(a): I consider filing bugs for not adjusted packages after some months (e.g in summer). 1123 packages (440 in dev-python category) from 108 categories specify dev-lang/python or virtual/python in DEPEND or RDEPEND, so actually it might be better to start filing bugs in this month. If there are no objections, then I would like to file 1 bug per category (except dev-python category). -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Python-3.2-related changes
2010-02-05 17:40:00 Arfrever Frehtes Taifersar Arahesis napisał(a):
- Dependency on Python 2 should be set correctly. You can specify it directly
in
{,R}DEPEND or use PYTHON_DEPEND.
Example:
PYTHON_DEPEND=2
inherit python
It might be useful to provide another example:
If given package requires e.g. Python =2.6, but does not support Python 3,
then you can
set PYTHON_DEPEND=2:2.6.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Python-3.2-related changes
2010-02-08 01:20:22 Brian Harring napisał(a): On Sun, Feb 07, 2010 at 12:17:17PM -0800, Zac Medico wrote: I noticed that this generates a depedency like || ( =dev-lang/python-2.7* =dev-lang/python-2.6* ) which is very similar to the way that QT3VERSIONS works in qt3.eclass. One thing that is sub-optimal about these types of dependencies is that you end up with lots of installed packages that have out-dated dependencies when the next minor version of python is released (python-2.8 in this case). In the case of the python dependencies, it might be more optimal to use a version range like =dev-lang/python-2.6 dev-lang/python-3. Thing is, the first deps are valid- the deps you posted however aren't and cannot be used as you're proposing. Under || ( dev-lang/python:2.7 dev-lang/python:2.6 ) Having python:2.6 or python:2.7 merged satisfies it. Under =dev-lang/python:2.6 dev-lang/python:3.0 having || ( python:2.6 python:2.7 ) satisfies it, as does || ( python:2.4 python:2.5 ) || ( python:3.0 python:3.1 python:3.2 ) Literally, python:2.5 and python:3.1 merged would satisfy it, which is completely contrary to the intent and an unlikely scenario (several of my machines have such a deployment). I will improve handling of cases when minimal and maximal versions aren't specified. E.g. PYTHON_DEPEND=2 will be translated into dependency on =dev-lang/python-2*. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Python-3.2-related changes
2010-02-07 19:43:24 Markos Chandras napisał(a):
On Saturday 06 February 2010 13:03:11 Arfrever Frehtes Taifersar Arahesis
wrote:
2010-02-05 17:40:00 Arfrever Frehtes Taifersar Arahesis napisał(a):
- Dependency on Python 2 should be set correctly. You can specify it
directly in {,R}DEPEND or use PYTHON_DEPEND.
Example:
PYTHON_DEPEND=2
inherit python
It might be useful to provide another example:
If given package requires e.g. Python =2.6, but does not support Python 3,
then you can set PYTHON_DEPEND=2:2.6.
Could you please update the python documentation [1] or any other online
documentation you may find useful cause I am pretty sure your recommendations
in this e-mail will be lost over time.
Yes.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Python-3.2-related changes
2010-02-06 17:54:10 Mark Loeser napisał(a): Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said: 2010-02-05 17:40:00 Arfrever Frehtes Taifersar Arahesis napisał(a): I consider filing bugs for not adjusted packages after some months (e.g in summer). 1123 packages (440 in dev-python category) from 108 categories specify dev-lang/python or virtual/python in DEPEND or RDEPEND, so actually it might be better to start filing bugs in this month. If there are no objections, then I would like to file 1 bug per category (except dev-python category). Make trackers and make one bug per package. Its way too hard to follow a huge metabug with a bunch of packages listed in it. Average number of non-dev-python packages handled in 1 bug would be only 6.4, but I can create create 1 bug per package, if you still want it. Also, I think the concerns and suggestions that were brought up about the syntax of this new variable should be addressed first and not ignored. I will include examples in documentation of PYTHON_DEPEND to avoid misunderstanding of syntax of this variable. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Python-3.2-related changes
2010-02-06 13:14:41 Brian Harring napisał(a):
On Sat, Feb 06, 2010 at 12:03:11PM +0100, Arfrever Frehtes Taifersar Arahesis
wrote:
2010-02-05 17:40:00 Arfrever Frehtes Taifersar Arahesis napisał(a):
- Dependency on Python 2 should be set correctly. You can specify it
directly in
{,R}DEPEND or use PYTHON_DEPEND.
Example:
PYTHON_DEPEND=2
inherit python
It might be useful to provide another example:
If given package requires e.g. Python =2.6, but does not support Python 3,
then you can
set PYTHON_DEPEND=2:2.6.
We really need better syntax than that. Particular reason you're
jamming py2k and py3k all into one? Breaking it down into
PYTHON2K_DEPEND and PYTHON3K_DEPEND
There's no need for 2 variables when 1 variable is sufficient.
would involve lest magic in parsing
At least I was able to exercise my bash skills and find a bug in bash :) .
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Python-3.2-related changes
2010-03-01 06:13:19 Max Arnold napisał(a): On Mon, Mar 01, 2010 at 04:13:10AM +0100, Arfrever Frehtes Taifersar Arahesis wrote: (Please note that wrapper scripts generated by python_generate_wrapper_scripts() work with all versions of Python from 2.4 to 3.2, so shebangs in these scripts do not need any changes.) What is the recommended policy about using or not using wrapper scripts? They are to solve collisions between scripts installed with different Python versions, not to support Python 3. Maybe it also should be documented? I will document it. [1] http://www.gentoo.org/proj/en/Python/developersguide.xml What about merging (or at least linking) this documentation with Gentoo Development Guide? The latter one already contains distutils related chapter and probably it is a good idea to decribe python.eclass usage in another chapter or eclass reference. It's better to maintain our documentation separately. Gentoo Development Guide can contain URL to http://www.gentoo.org/proj/en/Python/developersguide.xml. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
Members of Gentoo Python Project have agreed to deprecate the following
functions
in EAPI =2:
- python_version()
- python_mod_exists()
- python_tkinter_exists()
- distutils_python_version()
- distutils_python_tkinter()
These functions are already banned in EAPI =3.
1. In this week, these functions will start printing deprecation warnings in
older EAPIs.
2. On 2010-07-01, these functions will start calling die().
(If any ebuilds in gentoo-x86 still call any of these functions on
2010-07-01,
then addition of calls to die() will be delayed.)
3. On 2011-01-01, these functions will be removed.
I will also send the announcement to gentoo-dev-announce mailing list to ensure
that developers not subscribed to gentoo-dev mailing list will notice the
deprecation.
The attached patch shows text of deprecation warnings.
--
Arfrever Frehtes Taifersar Arahesis
--- python.eclass
+++ python.eclass
@@ -1980,6 +1980,15 @@
die ${FUNCNAME}() cannot be used in this EAPI
fi
+ _python_set_color_variables
+
+ if [[ ${FUNCNAME[1]} != distutils_python_version ]]; then
+ ewarn
+ ewarn ${_RED}Deprecation Warning: ${FUNCNAME}() is deprecated and will be banned on 2010-07-01.${_NORMAL}
+ ewarn ${_RED}Use PYTHON() instead of python variable. Use python_get_*() instead of PYVER* variables.${_NORMAL}
+ ewarn
+ fi
+
[[ -n ${PYVER} ]] return 0
local tmpstr
python=${python:-${EPREFIX}/usr/bin/python}
@@ -2011,6 +2020,13 @@
die ${FUNCNAME}() cannot be used in this EAPI
fi
+ _python_set_color_variables
+
+ ewarn
+ ewarn ${_RED}Deprecation Warning: ${FUNCNAME}() is deprecated and will be banned on 2010-07-01.${_NORMAL}
+ ewarn ${_RED}Use USE dependencies and/or has_version() instead of ${FUNCNAME}().${_NORMAL}
+ ewarn
+
if [[ $# -ne 1 ]]; then
die ${FUNCNAME}() requires 1 argument
fi
@@ -2027,6 +2043,15 @@
die ${FUNCNAME}() cannot be used in this EAPI
fi
+ _python_set_color_variables
+
+ if [[ ${FUNCNAME[1]} != distutils_python_tkinter ]]; then
+ ewarn
+ ewarn ${_RED}Deprecation Warning: ${FUNCNAME}() is deprecated and will be banned on 2010-07-01.${_NORMAL}
+ ewarn ${_RED}Use PYTHON_USE_WITH=\xml\ and python_pkg_setup() instead of ${FUNCNAME}().${_NORMAL}
+ ewarn
+ fi
+
if ! $(PYTHON ${PYTHON_ABI}) -c from sys import version_info
if version_info[0] == 3:
import tkinter
--- distutils.eclass
+++ distutils.eclass
@@ -382,6 +382,13 @@
die ${FUNCNAME}() cannot be used in this EAPI
fi
+ _python_set_color_variables
+
+ ewarn
+ ewarn ${_RED}Deprecation Warning: ${FUNCNAME}() is deprecated and will be banned on 2010-07-01.${_NORMAL}
+ ewarn ${_RED}Use PYTHON() instead of python variable. Use python_get_*() instead of PYVER* variables.${_NORMAL}
+ ewarn
+
python_version
}
@@ -394,5 +401,12 @@
die ${FUNCNAME}() cannot be used in this EAPI
fi
+ _python_set_color_variables
+
+ ewarn
+ ewarn ${_RED}Deprecation Warning: ${FUNCNAME}() is deprecated and will be banned on 2010-07-01.${_NORMAL}
+ ewarn ${_RED}Use PYTHON_USE_WITH=\xml\ and python_pkg_setup() instead of ${FUNCNAME}().${_NORMAL}
+ ewarn
+
python_tkinter_exists
}
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Python 3.1: Stabilization and news item
All problems, which were blocking stabilization of Python 3, have been fixed. Stabilization of Python 3.1.2 is currently scheduled on 2010-04-19. I'm attaching the news item for Python 3.1. -- Arfrever Frehtes Taifersar Arahesis Title: Python 3.1 Author: Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org Content-Type: text/plain Posted: 2010-03-04 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: =dev-lang/python-3.1* Python 3 is a new major version of Python and is intentionally incompatible with Python 2. Many external modules have not been ported yet to Python 3, so currently Python 3.1 should not be set as main active version of Python. Setting Python 3.1 as main active version of Python is currently unsupported. When it will change, a separate news item will be created to notify users. 'eselect python COMMAND --python3 [ARGUMENTS]' can be used to manage configuration of active version of Python 3. Although Python 3.1 should not be set as main active version of Python, users should run python-updater after installation of Python 3.1. By default, modules, which support both Python 2 and Python 3, are installed for both active version of Python 2 and active version of Python 3, when both Python 2 and Python 3 are installed. It is recommended to use a UTF-8 locale to avoid potential problems. Especially C and POSIX locales are discouraged. If locale has not been explicitly set, then POSIX locale is used, so users should explicitly set locale. Problems occuring only with non-UTF-8 locales should be reported directly to upstream developers of given packages. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item
2010-03-08 22:28:16 William Hubbs napisał(a): On Fri, Mar 05, 2010 at 04:19:36PM -0800, Zac Medico wrote: No, it won't. To prove it, I've just tested with a stable stage3 containing portage-2.1.7.x. Here are the steps: 1) extract stable stage3 and chroot into it 2) mkdir /etc/portage echo dev-lang/python ~* /etc/portage/package.keywords 3) Run `emerge -pu --deep=1 portage`: These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] sys-apps/sandbox-1.6-r2 [2.2] [ebuild UD] app-shells/bash-4.0_p35 [4.0_p37] [ebuild U ] dev-lang/python-2.6.4-r1 [2.6.4] If you try `emerge -puD world` then you will see dev-lang/python-3.1.1-r1 pulled in by the unspecific dev-lang/python atoms in the cracklib and libxml2 dependencies. However, in portage-2.1.7.x (current stable), there is support for pseudo-version-ranges in dependencies. This allows you use a dependency like dev-lang/python-3 in a package that doesn't support python3, and that will prevent it from getting pulled into the According to this, we can fix all of the dependencies in the tree then stabilize python3 without having any issues, so I would vote for this route, because it still oinsures that the stable tree will work together. Almost everybody has at least 1 package installed which supports both Python 2 and Python 3 and depends on dev-lang/python without version specification, so Python 3 would be pulled into dependency graph, so fixing of dependencies doesn't need to block stabilization of Python 3. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
2010-03-18 20:20:02 Thomas Sachau napisał(a): Currently, some packages just depend on dev-lang/python. Arfrever claims it to be right It's correct only for packages (e.g. dev-python/setuptools), which support all versions of Python (including Python 3). Arfrever claims current portage behaviour is wrong I claim that Portage behavior is correct. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
2010-03-18 20:47:35 Thomas Sachau napisał(a): On 03/18/2010 08:33 PM, Arfrever Frehtes Taifersar Arahesis wrote: 2010-03-18 20:20:02 Thomas Sachau napisał(a): Currently, some packages just depend on dev-lang/python. Arfrever claims it to be right It's correct only for packages (e.g. dev-python/setuptools), which support all versions of Python (including Python 3). Can you tell us any benefit for the normal user, when you require him to install python-3* I don't require it. It's only a side effect of correct dependencies. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
2010-03-19 10:23:31 Dale napisał(a): Ciaran McCreesh wrote: On Fri, 19 Mar 2010 03:54:28 -0500 Dalerdalek1...@gmail.com wrote: Ciaran McCreesh wrote: On Thu, 18 Mar 2010 23:17:17 +0100 Ben de Grootyng...@gentoo.org wrote: Because it is extremely useless to the great majority of users. Most packages in the tree are useless to the great majority of users. Which is why most users don't install everything. I have about 1000 packages installed here. The packages installed are either something I use or a dependency of something I use. What exactly is this being installed for again? If nothing depends on it, there is no need to have it. It's being installed because it's a dependency of something you use. Replace Python with any other library and we wouldn't be having this discussion. OK. Right now, as you type this, what package depends on python-3 and won't work with python-2? Anything at all? If it is nothing, then why install it? Since python-3 is not what the system is using, it's not getting used even if it is installed. So as I mentioned in another reply, portage is installing something and it is just sitting there doing nothing. What is the point in that? I can add python2 USE flag (enabled by default) to some versions of dev-lang/python. With USE=-python2, Python 2 will not be required and Python 3 will be set as main active version of Python. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
2010-03-19 10:39:07 Petteri Räty napisał(a): On 19.3.2010 11.35, Arfrever Frehtes Taifersar Arahesis wrote: I can add python2 USE flag (enabled by default) to some versions of dev-lang/python. With USE=-python2, Python 2 will not be required and Python 3 will be set as main active version of Python. You should move to the same scheme that ruby uses. Then users can just disable the python_version_3 or whatever USE_EXPAND scheme is used. We are waiting on ABI dependencies (and extended support for multiple ABIs in package manager), which will provide some needed functionality. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
2010-03-19 11:13:48 Dale napisał(a): Ciaran McCreesh wrote: On Fri, 19 Mar 2010 04:23:31 -0500 Dalerdalek1...@gmail.com wrote: It's being installed because it's a dependency of something you use. Replace Python with any other library and we wouldn't be having this discussion. OK. Right now, as you type this, what package depends on python-3 and won't work with python-2? Anything at all? If it is nothing, then why install it? And that's where you're making the mistake: you're treating Python as being different from every other package. In every other case, you want things to be using the newest version of a slotted package where possible. Why aren't you complaining that you were forced to install gcc 4.3 and 4.1 when 3.4 worked just fine? Because, when I installed gcc 4.3, I could then unmerge the old gcc. That's why I didn't complain about that. With python, we still have to have the current version plus the new version which is not being used at all. Am I not correct in that? If the new python is installed, what exactly is going to use it? I used the new gcc. It worked fine. I unmerged the old one with no wasted space and one less package installed. This doesn't appear to be the case with python-3 tho. It's going to be installed and just sit there like a rock. Python 3 is used during installation of packages, which support Python 2 and Python 3 and support installation for multiple Python ABIs. You can directly execute scripts with -3.1 suffix (e.g. bpython-3.1 or coverage-3.1) to use Python 3.1 even when Python 2.* is set as main active version of Python. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Packages pulling in python-3*, also they dont require it
2010-03-20 13:51:37 Peter Hjalmarsson napisał(a): I have a question related to this: If I have package X which supports python2 and python 3, and I install it without python3 installed it will only install python2-files (i.e. /usr/lib/python2.x/*), right? What happens if I later install packages Y that is only python3, and relies on the python3 parts of package X? Can this happen and how will the PM handle that (reemerge package X installing the python3 parts or fail to compile package Y due to missing python module)? As the news item says, you should run python-updater after installation of Python 3.1. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Packages pulling in python-3*, also they dont require it
2010-03-20 01:51:44 Duncan napisał(a): So let's just recognize that it's not a perfect situation, create a news item saying that python-3 will soon (give a date) be unmasked, and suggest that users not needing it may wish to package.mask it themselves, with a link to documentation with specific instructions and a bit more detail on why they might wish to mask it and under what circumstances they might not. I'd suggest an unmasking date 30 days after the release of the news item. Python 3 is not masked. The discussion is about stabilization. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Packages pulling in python-3*, also they dont require it
2010-03-22 22:12:54 Jacob Godserv napisał(a): On Sat, Mar 20, 2010 at 10:11, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 2010-03-20 01:51:44 Duncan napisał(a): So let's just recognize that it's not a perfect situation, create a news item saying that python-3 will soon (give a date) be unmasked, and suggest that users not needing it may wish to package.mask it themselves, with a link to documentation with specific instructions and a bit more detail on why they might wish to mask it and under what circumstances they might not. I'd suggest an unmasking date 30 days after the release of the news item. Python 3 is not masked. The discussion is about stabilization. Duncan's comments still apply, though, right? What's against writing a news item about stabilizing Python? There is already a thread about news item: http://archives.gentoo.org/gentoo-dev/msg_814e67764c17f88bde94f22e9a392e4f.xml -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Python 3.1: Stabilization and news item
2010-03-04 19:38:12 Paweł Hajdan, Jr. napisał(a): On 3/4/10 7:22 PM, Arfrever Frehtes Taifersar Arahesis wrote: 'eselect python COMMAND --python3 [ARGUMENTS]' can be used to manage configuration of active version of Python 3. I'm confused by the above paragraph. I had to spend a longer while to see that it really means if you want to use eselect-python to manage your python3 configuration, pass the --python3 switch. Before that I wondered what is the meaning of COMMAND and ARGUMENTS. Would be nice to make it more clear. This paragraph is probably not needed for average users, so I will remove it. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Python 3.1: Stabilization and news item
I'm attaching updated news item, which will be committed soon. Stabilization has been delayed to 2010-04-21, but members of architecture projects can start testing now, to ensure that all potential problems have been found and fixed. -- Arfrever Frehtes Taifersar Arahesis Title: Python 3.1 Author: Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org Content-Type: text/plain Posted: 2010-03-23 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: =dev-lang/python-3.1* Python 3 is a new major version of Python and is intentionally incompatible with Python 2. Many external modules have not been ported yet to Python 3, so Python 2 still needs to be installed. You can benefit from having Python 3 installed without setting Python 3.1 as main active version of Python. Currently you should not set Python 3.1 as main active version of Python. When setting it becomes recommended, a separate news item will be created to notify users. Although Python 3.1 should not be set as main active version of Python, you should run python-updater after installation of Python 3.1. By default, modules, which support both Python 2 and Python 3, are installed for both active version of Python 2 and active version of Python 3, when both Python 2 and Python 3 are installed. It is recommended to use a UTF-8 locale to avoid potential problems. Especially C and POSIX locales are discouraged. If locale has not been explicitly set, then POSIX locale is used, so you should ensure that locale has been set. Problems occurring only with non-UTF-8 locales should be reported directly to upstream developers of given packages. See http://www.gentoo.org/doc/en/utf-8.xml for more information about UTF-8. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Python 3.1: Stabilization and news item
2010-03-23 20:28:38 Ben de Groot napisał(a): On 23 March 2010 20:13, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: I'm attaching updated news item, which will be committed soon. As mentioned in the other thread, this news item should mention that users who do not need python-3 should mask it locally to prevent it from being pulled into the dependency graph. Python maintainers do not recommend to mask Python 3. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Python 3.1: Stabilization and news item
2010-03-24 17:57:35 Joshua Saddler napisał(a): On Wed, 24 Mar 2010 17:43:56 +0100 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 2010-03-23 20:28:38 Ben de Groot napisał(a): As mentioned in the other thread, this news item should mention that users who do not need python-3 should mask it locally to prevent it from being pulled into the dependency graph. Python maintainers do not recommend to mask Python 3. But everyone else in Gentoo does, so . . . Some Gentoo developers/users, who aren't Python maintainers, said that they didn't object to have Python 3 installed. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Python 3.1: Stabilization and news item
2010-03-24 17:56:48 Ben de Groot napisał(a): On 24 March 2010 17:43, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 2010-03-23 20:28:38 Ben de Groot napisał(a): On 23 March 2010 20:13, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: I'm attaching updated news item, which will be committed soon. As mentioned in the other thread, this news item should mention that users who do not need python-3 should mask it locally to prevent it from being pulled into the dependency graph. Python maintainers do not recommend to mask Python 3. Are you saying that you are just going to brush aside all concerns that have been voiced about this issue? You will upset a lot of people if you do that. All valid concerns about text already included in the news item have been addressed. We don't need to include any unofficial recommendations. Proposed news item is better than no news item. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Python 3.1: Stabilization and news item
2010-03-24 18:32:37 Joshua Saddler napisał(a): On Wed, 24 Mar 2010 18:14:44 +0100 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 2010-03-24 17:57:35 Joshua Saddler napisał(a): On Wed, 24 Mar 2010 17:43:56 +0100 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: Python maintainers do not recommend to mask Python 3. But everyone else in Gentoo does, so . . . Some Gentoo developers/users, who aren't Python maintainers, said that they didn't object to have Python 3 installed. They're in the minority, judging by the replies in this thread. People, who don't object to given suggestions, less often reply to them. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item
2010-03-23 20:57:33 Jonathan Callen napisał(a): On 03/23/2010 03:13 PM, Arfrever Frehtes Taifersar Arahesis wrote: I'm attaching updated news item, which will be committed soon. A couple grammar issues: -modules, which support both Python 2 and Python 3, are installed for both -active version of Python 2 and active version of Python 3, when both Python 2 -and Python 3 are installed. +modules that support both Python 2 and Python 3 are installed for both the +active version of Python 2 and the active version of Python 3 when both +Python 2 and Python 3 are installed. I have locally applied these changes some hours ago, but I'm attaching updated news item so that it can be reviewed easier. If there are no additional, new suggestions, then the news item will be committed tomorrow. -- Arfrever Frehtes Taifersar Arahesis Title: Python 3.1 Author: Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org Content-Type: text/plain Posted: 2010-03-24 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: =dev-lang/python-3.1* Python 3 is a new major version of Python and is intentionally incompatible with Python 2. Many external modules have not been ported yet to Python 3, so Python 2 still needs to be installed. You can benefit from having Python 3 installed without setting Python 3.1 as main active version of Python. Currently you should not set Python 3.1 as main active version of Python. When setting it becomes recommended, a separate news item will be created to notify users. Although Python 3.1 should not be set as main active version of Python, you should run python-updater after installation of Python 3.1. By default, modules that support both Python 2 and Python 3 are installed for both the active version of Python 2 and the active version of Python 3 when both Python 2 and Python 3 are installed. It is recommended to use a UTF-8 locale to avoid potential problems. Especially C and POSIX locales are discouraged. If locale has not been explicitly set, then POSIX locale is used, so you should ensure that locale has been set. Problems occurring only with non-UTF-8 locales should be reported directly to upstream developers of given packages. See http://www.gentoo.org/doc/en/utf-8.xml for more information about UTF-8. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Python 3.1: Stabilization and news item
2010-03-24 18:51:48 Paweł Hajdan, Jr. napisał(a): On 3/24/10 6:35 PM, Ben de Groot wrote: All valid concerns about text already included in the news item have been addressed. We don't need to include any unofficial recommendations. I'll take that as a yes then, you are indeed disregarding the concerns and recommendations of your fellow Gentoo developers. CC'ing devrel because this is getting out of hand. I think it's a purely technical issue. The arguments against Python 3 are mostly in the form I don't feel it's ready. If it can't be resolved on the list (some people want Python 3, some don't), shouldn't the council decide? People, don't want Python 3, probably have already masked it. There is no reason to waste Council's time for decision on what sentence should be included in the news item. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Python 3.1: Stabilization and news item
2010-03-25 19:34:24 Roy Bamford napisał(a): On 2010.03.24 21:12, William Hubbs wrote: On Wed, Mar 24, 2010 at 09:36:52PM +0100, Ben de Groot wrote: On 24 March 2010 21:25, William Hubbs willi...@gentoo.org wrote: If we make it clear in the news item that python-3 cannot be used as the default python, so if users do not want it they should mask it, we have done our job imho. In other words, this is just a matter of informing users. We agree that this is the minimum that should be done. But our Python lead stubbornly refuses to honor this reasonable request. On the other hand, I can see his point as well. The news item makes it very clear that python-3 cannot be the default python and that python-2 needs to be installed. It could be argued that he is just assuming that users are intelligent enough to figure out that they need to mask python-3 if they do not want it on their systems. Basically this is a case of how much hand-holding do we want to do? William The case where Python-3 cannot be used as the default Python is transitory (it may be a long time). Gentoo Python Project will soon start supporting setting Python 3 as main active version of Python. Currently about 57% of our packages from dev-python category are prepared. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Python 3.1: Stabilization and news item
Arfrever Frehtes Taifersar Arahesis 2010-03-25 20:05:17 napisał(a): 2010-03-25 19:34:24 Roy Bamford napisał(a): The case where Python-3 cannot be used as the default Python is transitory (it may be a long time). Gentoo Python Project will soon start supporting setting Python 3 as main active version of Python. Currently about 57% of our packages from dev-python category are prepared. My script was wrong. More correct data: About 55% of packages in dev-python category belonging to python herd are prepared. 100% of packages in net-zope category belonging to python herd are prepared. About 60% of packages belonging to python herd are prepared. About 47% of packages in dev-python category not belonging to python herd are prepared. About 13% of packages not belonging to python herd are prepared. About 34% of all packages depending on Python are prepared. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Python 3.1: Stabilization and news item
2010-03-26 16:40:37 Brian Harring napisał(a): There really isn't a precedent since upgrades of this sort typically either have extremely locked down deps, or just plain don't happen till the vast majority of depndencies are updated. If in doubt, look at the past python upgrades- they've been delayed till all of the major consumers played nice w/ the targeted python version. Main active version of Python was automatically updated during previous Python upgrades, but it's not updated during installation of Python 3.1. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Python 3.1: Stabilization and news item
2010-03-26 16:43:57 Brian Harring napisał(a): On Fri, Mar 26, 2010 at 03:22:52PM +0100, Arfrever Frehtes Taifersar Arahesis wrote: Arfrever Frehtes Taifersar Arahesis 2010-03-25 20:05:17 napisał(a): 2010-03-25 19:34:24 Roy Bamford napisał(a): The case where Python-3 cannot be used as the default Python is transitory (it may be a long time). Gentoo Python Project will soon start supporting setting Python 3 as main active version of Python. Currently about 57% of our packages from dev-python category are prepared. My script was wrong. More correct data: About 55% of packages in dev-python category belonging to python herd are prepared. 100% of packages in net-zope category belonging to python herd are prepared. About 60% of packages belonging to python herd are prepared. About 47% of packages in dev-python category not belonging to python herd are prepared. About 13% of packages not belonging to python herd are prepared. About 34% of all packages depending on Python are prepared. I get the feeling your phrasing here is a bit misleading- 'support setting py3k as main active python' implies that the stats above are the # of pkgs in the tree supporting *using* a py3k interpretter. I'm betting you mean support multi-abi, meaning if you've got py2.6 and py3.1, it'll install into py2.6, while avoiding py3k. Fair bit of a difference. These numbers include packages which support installation for multiple Python ABIs and packages which call python_set_active_version(). -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Python 3.1: Stabilization and news item
2010-03-26 17:15:42 Brian Harring napisał(a): On Fri, Mar 26, 2010 at 05:04:28PM +0100, Arfrever Frehtes Taifersar Arahesis wrote: 2010-03-26 16:43:57 Brian Harring napisał(a): On Fri, Mar 26, 2010 at 03:22:52PM +0100, Arfrever Frehtes Taifersar Arahesis wrote: Arfrever Frehtes Taifersar Arahesis 2010-03-25 20:05:17 napisał(a): 2010-03-25 19:34:24 Roy Bamford napisał(a): The case where Python-3 cannot be used as the default Python is transitory (it may be a long time). Gentoo Python Project will soon start supporting setting Python 3 as main active version of Python. Currently about 57% of our packages from dev-python category are prepared. My script was wrong. More correct data: About 55% of packages in dev-python category belonging to python herd are prepared. 100% of packages in net-zope category belonging to python herd are prepared. About 60% of packages belonging to python herd are prepared. About 47% of packages in dev-python category not belonging to python herd are prepared. About 13% of packages not belonging to python herd are prepared. About 34% of all packages depending on Python are prepared. I get the feeling your phrasing here is a bit misleading- 'support setting py3k as main active python' implies that the stats above are the # of pkgs in the tree supporting *using* a py3k interpretter. I'm betting you mean support multi-abi, meaning if you've got py2.6 and py3.1, it'll install into py2.6, while avoiding py3k. Fair bit of a difference. These numbers include packages which support installation for multiple Python ABIs and packages which call python_set_active_version(). Bleh. So in other words a third of the pkgs that dep on python have the minimal basics for dealing w/ py3k landing. I'd question what percentile have proper locked deps also (stating they're py2k only), but that's a seperate discussion. That *still* doesn't answer the question of how many can be *ran* by py3k also. Note in the past when breakages of this sort have been unleashed, the percentile of prepared pkgs has been generally a helluva lot higher- having 90% prepared is one thing, but y'all aren't at that point and you've got 3 weeks (after what, 3 months?) to bring the percentile higher then a third? What's the minimal percentile you're aiming for prior to the unmasking? Python ebuilds will start automatically setting Python 3 as main active version of Python when all bugs blocking bug #308257 are fixed. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-dev-announce] Changes in python_mod_optimize(), python_mod_cleanup() and python_mod_compile()
2010-05-25 21:11:44 Petteri Räty napisał(a): On 05/25/2010 09:35 PM, Arfrever Frehtes Taifersar Arahesis wrote: - Not passing of paths to python_mod_optimize() and python_mod_cleanup() has been deprecated and will be disallowed on 2010-09-01. You should pass paths to Python modules to these functions. - python_mod_compile() has been deprecated and will be banned on 2010-09-01. You should use python_mod_optimize() instead of python_mod_compile(). 1. Messages to gentoo-dev-announce should also be posted to an on topic mailing lists I don't like crossposting. 2. What does disallowed and banned mean in this case? Plenty of ebuilds currently pass paths to python_mod_optimize. Ebuilds, which pass paths to python_mod_optimize() / python_mod_cleanup(), don't need any changes. Ebuilds, which don't pass paths to python_mod_optimize() or python_mod_cleanup(), should now pass paths to these functions. Only small minority of ebuilds don't pass paths to these functions. python_mod_optimize() without paths hasn't been doing anything for almost 2 years. python_mod_cleanup() without paths allows for silently incorrect behavior. Not passing of paths to python_mod_cleanup() is incorrect in many ebuilds. If you break the stable tree, you should have the wrath of more people than me. It can be done at the dates you say if the tree is in order by then. I'm not breaking anything. Deprecation warnings won't be changed into calls to die() until all ebuilds in gentoo-x86 are fixed. It's possible to deprecate and ban functions or their parts as it was discussed in Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2 thread [1]. [1] http://archives.gentoo.org/gentoo-dev/msg_7ad37800b8fa3041662068f70083cb56.xml -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
2010-05-27 16:33:39 Thomas Sachau napisał(a): Hi together, since i am not able to get any real argument or even discussion on IRC nor on this mailing list from Arfrever (main person behind those changes), i would like to raise the following points now on this mailing list as told on IRC, so he gets the chance to answer those points and to clear the issues: -major changes to python eclasses have been done without peer review on this mailing list. There weren't any major changes in python.eclass in last months. In r1.96:r1.100 I committed a set of minor changes. Some code was moved, which might cause false impression that there were some major changes: - MISCELLANEOUS FUNCTIONS section (with 8 functions) was moved to before FUNCTIONS FOR PACKAGES SUPPORTING INSTALLATION FOR MULTIPLE PYTHON ABIS section. - python_pkg_setup() function was moved to MISCELLANEOUS FUNCTIONS section. - A part of python_mod_cleanup() function was split to _python_clean_compiled_modules() function. python_mod_cleanup() now calls _python_clean_compiled_modules(). - 2 loops in python_mod_optimize() were divided and some code was reindented. This includes pulling in python-3* versions It's untruth. python.eclass or distutils.eclass don't enforce any particular version of Python. -A news item, which is only shown, once python-3* is installed. It is only shown _after_ installation of python-3. You might file an enhancement request for Portage to show news items before installation. -Arfrever also said, he would add a seperate news item, when python-3 gets stabilized. I never said it. The plan was to have 1 news item for all users, who have installed Python 3.1. Beside those points, one additional main issue is, that i and others dont seem to be able to have a discussion with Arfrever about this topics. I'm answering to new (unanswered), rational arguments about these topics. He says, he has no time for it or says, that he already had shown arguments, but cannot show any evidence or just stops responding without any note. There had been multiple threads about Python 3. Read e-mails written by me or Dirkjan Ochtman in the following threads: http://archives.gentoo.org/gentoo-dev/msg_115ce6fa1a09de286bf58db12df463c6.xml http://archives.gentoo.org/gentoo-dev/msg_814e67764c17f88bde94f22e9a392e4f.xml http://archives.gentoo.org/gentoo-dev/msg_2591c1b9a7e7b72383d3841bc05dc417.xml -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
2010-06-06 12:40:28 Thomas Sachau napisał(a): Additionally, it should define the supported slots, something like this: SUPPORTED_RUBY_SLOTS=1.8 1.9 or SUPPORTED_PYTHON_SLOTS=2.5 2.6 3.0 3.1 Now the package manager should take those vars and convert them to some expanded USE vars like: RUBY_SLOTS=1.8 1.9 or PYTHON_SLOTS=2.5 2.6 3.0 3.1 We are already working on automatic generation of USE flags in python.eclass (in newer EAPIs). -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Extending EAPI=4
I would like to suggest that EAPI=4 be reopened for ability of using dots in USE flag names, which was suggested in bug #311795. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
2010-06-06 15:54:23 Thomas Sachau napisał(a): Am 06.06.2010 15:44, schrieb Arfrever Frehtes Taifersar Arahesis: 2010-06-06 12:40:28 Thomas Sachau napisał(a): Additionally, it should define the supported slots, something like this: SUPPORTED_RUBY_SLOTS=1.8 1.9 or SUPPORTED_PYTHON_SLOTS=2.5 2.6 3.0 3.1 Now the package manager should take those vars and convert them to some expanded USE vars like: RUBY_SLOTS=1.8 1.9 or PYTHON_SLOTS=2.5 2.6 3.0 3.1 We are already working on automatic generation of USE flags in python.eclass (in newer EAPIs). And why do you want to implement such code in every eclass? Whats wrong with implementing it on the package manager side once and reusing it for every eclass/ebuild, which needs such code? We can accept such an implementation if it meets all our requirements. E.g. Python ebuilds must specify list of NOT supported Python ABIs (e.g. using whitespace-separated list of fnmatch patterns). When a new slot of Python is available, then updating one place (an eclass or a file in profiles) must be sufficient to add a USE flag to all ebuilds (which don't specify a range of not supported Python ABIs which would match the new Python ABI). -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/traits: traits-3.4.0.ebuild
2010-06-10 22:20:44 Nirbheek Chauhan napisał(a): On Fri, Jun 11, 2010 at 1:30 AM, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 2010-06-10 21:27:40 Jeremy Olexa napisał(a): I see no reason to *not* add a ChangeLog entry here. ChangeLog entries are not required for trivial changes. A trivial change is fixing a typo, or a manifest problem, a missing quotation mark, etc. Anything else is not trivial. Anything that changes how an ebuild functions, what it does, or the installed files (and/or their contents) is NOT a trivial change. This commit only removed some compiler warnings. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/traits: traits-3.4.0.ebuild
2010-06-10 22:16:23 Fabian Groffen napisał(a): On 10-06-2010 22:00:19 +0200, Arfrever Frehtes Taifersar Arahesis wrote: 2010-06-10 21:27:40 Jeremy Olexa napisał(a): I see no reason to *not* add a ChangeLog entry here. ChangeLog entries are not required for trivial changes. Apart from whether or not this is true, do I understand well that you consider masqueraded EAPI bumps as homepage updates as trivial changes too? (traitsbackendwx) If a change in EAPI doesn't require any other changes in ebuild, then it's a trivial change. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Testing of Python 2.7
Final release of Python 2.7 is currently scheduled on 2010-07-03. Snapshots of Python 2.7 are available in python overlay. Python 2.7 will be initially masked in gentoo-x86 after release. I would like to encourage Gentoo developers and users to install a snapshot of Python 2.7 and test miscellaneous packages with Python 2.7. Please file bugs in Gentoo bugzilla, after ensuring that they don't occur with Python 2.6. There are already 22 bugs filed, so don't file duplicates. (I currently discourage using Python 3.2.) -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/traits: traits-3.4.0.ebuild
2010-06-19 22:53:37 Mike Frysinger napisał(a): On Thursday, June 10, 2010 16:45:29 Arfrever Frehtes Taifersar Arahesis wrote: 2010-06-10 22:20:44 Nirbheek Chauhan napisał(a): On Fri, Jun 11, 2010 at 1:30 AM, Arfrever Frehtes Taifersar wrote: 2010-06-10 21:27:40 Jeremy Olexa napisał(a): I see no reason to *not* add a ChangeLog entry here. ChangeLog entries are not required for trivial changes. A trivial change is fixing a typo, or a manifest problem, a missing quotation mark, etc. Anything else is not trivial. Anything that changes how an ebuild functions, what it does, or the installed files (and/or their contents) is NOT a trivial change. This commit only removed some compiler warnings. mucking with CFLAGS without documentation is wrong. compiler warnings come and go, so a flag that was relevant one day could be completely extraneous the next. however, especially with strict aliasing, you arent just fixing warnings, you're changing optimization behavior of gcc to workaround broken C code. this obviously does not fall anywhere near the trivial mark. i see you still havent fixed this, so get on it already. a bug needs to be opened somewhere to get the package properly *fixed* This problem is probably caused by bugs in Python 2, which have been fixed in Python 3. $ echo 'a = True' test.pyx $ cython test.pyx $ gcc -O2 -Wall -I/usr/include/python3.1 -c test.c $ gcc -O2 -Wall -I/usr/include/python2.6 -c test.c test.c: In function ‘inittest’: test.c:479: warning: dereferencing type-punned pointer will break strict-aliasing rules test.c:479: warning: dereferencing type-punned pointer will break strict-aliasing rules test.c:479: warning: dereferencing pointer ‘_Py_TrueStruct.42’ does break strict-aliasing rules test.c:479: warning: dereferencing pointer ‘_Py_TrueStruct.42’ does break strict-aliasing rules test.c:479: note: initialized from here test.c:482: warning: dereferencing pointer ‘__pyx_t_1’ does break strict-aliasing rules test.c:482: warning: dereferencing pointer ‘__pyx_t_1’ does break strict-aliasing rules test.c:482: warning: dereferencing pointer ‘__pyx_t_1’ does break strict-aliasing rules test.c:482: warning: dereferencing pointer ‘__pyx_t_1’ does break strict-aliasing rules test.c:479: note: initialized from here -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/traits: traits-3.4.0.ebuild
2010-06-21 00:27:00 Mike Frysinger napisał(a): On Sunday, June 20, 2010 09:55:39 Arfrever Frehtes Taifersar Arahesis wrote: 2010-06-19 22:53:37 Mike Frysinger napisał(a): On Thursday, June 10, 2010 16:45:29 Arfrever Frehtes Taifersar wrote: 2010-06-10 22:20:44 Nirbheek Chauhan napisał(a): On Fri, Jun 11, 2010 at 1:30 AM, Arfrever Frehtes Taifersar wrote: 2010-06-10 21:27:40 Jeremy Olexa napisał(a): I see no reason to *not* add a ChangeLog entry here. ChangeLog entries are not required for trivial changes. A trivial change is fixing a typo, or a manifest problem, a missing quotation mark, etc. Anything else is not trivial. Anything that changes how an ebuild functions, what it does, or the installed files (and/or their contents) is NOT a trivial change. This commit only removed some compiler warnings. mucking with CFLAGS without documentation is wrong. compiler warnings come and go, so a flag that was relevant one day could be completely extraneous the next. however, especially with strict aliasing, you arent just fixing warnings, you're changing optimization behavior of gcc to workaround broken C code. this obviously does not fall anywhere near the trivial mark. i see you still havent fixed this, so get on it already. a bug needs to be opened somewhere to get the package properly *fixed* This problem is probably caused by bugs in Python 2, which have been fixed in Python 3. the new information you've provided here only reinforces the fact the current code is wrong. properly document the append-flags and properly restrict it to when python-2 is being used. I have added the comment to the ebuild. dev-python/traits supports only Python 2. considering python-2 is going to be in our lives for a while, how hard is it to backport the changes in question to the headers ? presumably it's struct/union/cast shuffling in the headers. I don't know what exactly would need to be backported. I suspect that Python developers would have backported the fix if it wasn't breaking backward compatibility. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Policy for late/slow stabilizations
2010-06-27 17:04:45 Markos Chandras napisał(a): Hi As many of you have already noticed, there are some arches that are quite slow on stabilizations. This leads to deprecated stabilizations e.g a package is stabilized after 60 days which makes that version of the specific package obsolete and not worth to stabilize anymore. I would suggest to introduce a new rule where a stabilization bug may close after 30 days. Arches that fail to stabilize it within this timeframe they will simply don't have this package stable for them. Moreover, slow arches introduce another problem as well. If a package is marked stabled for their arch, but this package is quite old, and they fail to stabilize a new version, we ( as maintainers ) can't drop the very old ( and obsolete ) version of this package because we somehow will break the stable tree for these arches. How should we act in this case? Keep the old version around forever just to say that hey, they do have a stable version for our exotic arch. Whilst I do understand that these arches are understaffed and they can't keep up with the increased stabilization load like x86/amd64 do, I still think that slow stabilization leads to an obsolete stable tree which I doesn't make sense to me after all. Thoughts? +1. The period of waiting might be extended to 60 days. This period should be counted from the first ignored stabilization request. Stabilizations of some packages are filed e.g. once per month and some architectures don't manage to stabilize older versions before stabilization requests of new versions. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/python-openid: python-openid-2.2.4.ebuild
2010-06-29 04:05:54 Jeremy Olexa napisał(a): On Mon, 28 Jun 2010 19:42:27 + (UTC), Arfrever Frehtes Taifersar Arahesis (arfrever) arfre...@gentoo.org wrote: arfrever10/06/28 19:42:27 Modified: python-openid-2.2.4.ebuild Log: Fix dependencies. (Portage version: HEAD/cvs/Linux x86_64) Is there any reason you are so non-verbose here? 'cvs log' or '$EDITOR ChangeLog' equally give us no information about your commit. You are making it hard on other devs in my opinion, I don't think intentionally, but can't you just use the ChangeLog more?? It was intermediate commit during my work on python-openid-2.2.5.ebuild. python-openid-2.2.4.ebuild has been mentioned in ChangeLog in final commit. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Minor changes in python.eclass and distutils.eclass
These minor changes in python.eclass and distutils.eclass have been already
reviewed on alias of Gentoo Python Project. It's recommended to be familiar
with internals of current code before trying to understand these minor changes.
Suggestions about indentation and quoting will be rejected.
--
Arfrever Frehtes Taifersar Arahesis
--- python.eclass
+++ python.eclass
@@ -161,9 +161,26 @@
_parse_PYTHON_DEPEND
elif [[ -n ${NEED_PYTHON} ]]; then
if ! has ${EAPI:-0} 0 1 2; then
- eerror Use PYTHON_DEPEND instead of NEED_PYTHON.
- die NEED_PYTHON cannot be used in this EAPI
+ eerror Use PYTHON_DEPEND variable instead of NEED_PYTHON variable.
+ die NEED_PYTHON variable cannot be used in this EAPI
fi
+
+ if [[ ${NOCOLOR:-false} =~ ^(false|no)$ ]]; then
+ _RED=$'\e[1;31m'
+ _NORMAL=$'\e[0m'
+ else
+ _RED=
+ _NORMAL=
+ fi
+
+ echo
+ echo ${_RED}*${_NORMAL} ${_RED}Deprecation Warning: NEED_PYTHON variable is deprecated and will be banned on 2010-10-01.${_NORMAL}
+ echo ${_RED}*${_NORMAL} ${_RED}Use PYTHON_DEPEND variable instead of NEED_PYTHON variable.${_NORMAL}
+ echo ${_RED}*${_NORMAL} ${_RED}The ebuild needs to be fixed. Please report a bug, if it has not been already reported.${_NORMAL}
+ echo
+
+ unset _BOLD _NORMAL
+
_PYTHON_ATOMS=(=dev-lang/python-${NEED_PYTHON})
DEPEND+=${DEPEND:+ }${_python_ato...@]}
RDEPEND+=${RDEPEND:+ }${_python_ato...@]}
@@ -243,6 +260,10 @@
fi
}
+_python_abi-specific_local_scope() {
+ [[ ${funcna...@]:2} =~ (_python_final_sanity_checks|python_execute_function|python_mod_optimize|python_mod_cleanup) ]]
+}
+
_python_initialize_prefix_variables() {
if has ${EAPI:-0} 0 1 2; then
if [[ -n ${ROOT} -z ${EROOT} ]]; then
@@ -254,10 +275,10 @@
fi
}
-unset PYTHON_SANITY_CHECKS
+unset PYTHON_SANITY_CHECKS_EXECUTED PYTHON_SKIP_SANITY_CHECKS
_python_initial_sanity_checks() {
- if [[ $(declare -p PYTHON_SANITY_CHECKS 2 /dev/null) != declare -- PYTHON_SANITY_CHECKS=* ]]; then
+ if [[ $(declare -p PYTHON_SANITY_CHECKS_EXECUTED 2 /dev/null) != declare -- PYTHON_SANITY_CHECKS_EXECUTED=* || ${funcna...@]:1} =~ (python_set_active_version|python_pkg_setup) -z ${PYTHON_SKIP_SANITY_CHECKS} ]]; then
# Ensure that /usr/bin/python and /usr/bin/python-config are valid.
if [[ $(readlink ${EPREFIX}/usr/bin/python) != python-wrapper ]]; then
eerror '${EPREFIX}/usr/bin/python' is not valid symlink.
@@ -273,7 +294,7 @@
}
_python_final_sanity_checks() {
- if ! _python_implementation [[ $(declare -p PYTHON_SANITY_CHECKS 2 /dev/null) != declare -- PYTHON_SANITY_CHECKS=* ]]; then
+ if ! _python_implementation [[ $(declare -p PYTHON_SANITY_CHECKS_EXECUTED 2 /dev/null) != declare -- PYTHON_SANITY_CHECKS_EXECUTED=* || ${funcna...@]:1} =~ (python_set_active_version|python_pkg_setup) -z ${PYTHON_SKIP_SANITY_CHECKS} ]]; then
local PYTHON_ABI=${PYTHON_ABI}
for PYTHON_ABI in ${PYTHON_ABIS-${PYTHON_ABI}}; do
# Ensure that appropriate version of Python is installed.
@@ -293,7 +314,7 @@
fi
done
fi
- PYTHON_SANITY_CHECKS=1
+ PYTHON_SANITY_CHECKS_EXECUTED=1
}
_python_set_color_variables() {
@@ -316,6 +337,14 @@
unset PYTHON_PKG_SETUP_EXECUTED
+_python_check_python_pkg_setup_execution() {
+ [[ ${funcna...@]:1} =~ (python_set_active_version|python_pkg_setup) ]] return
+
+ if ! has ${EAPI:-0} 0 1 2 3 [[ -z ${PYTHON_PKG_SETUP_EXECUTED} ]]; then
+ die python_pkg_setup() not called
+ fi
+}
+
# @FUNCTION: python_pkg_setup
# @DESCRIPTION:
# Perform sanity checks and initialize environment.
@@ -328,6 +357,10 @@
# Check if phase is pkg_setup().
[[ ${EBUILD_PHASE} != setup ]] die ${FUNCNAME}() can be used only in pkg_setup() phase
+ if [[ $# -ne 0 ]]; then
+ die ${FUNCNAME}() does not accept arguments
+ fi
+
if _python_package_supporting_installation_for_multiple_python_abis; then
_python_calculate_PYTHON_ABIS
export EPYTHON=$(PYTHON -f)
@@ -368,7 +401,7 @@
}
if _python_package_supporting_installation_for_multiple_python_abis; then
- python_execute_function -q python_pkg_setup_check_USE_flags
+ PYTHON_SKIP_SANITY_CHECKS=1 python_execute_function -q python_pkg_setup_check_USE_flags
else
python_pkg_setup_check_USE_flags
fi
@@ -388,6 +421,8 @@
# @DESCRIPTION:
# Convert shebangs in specified files. Directories can be specified only with --recursive option.
python_convert_shebangs() {
+ _python_check_python_pkg_setup_execution
+
local argument file files=() only_executables=0 python_version quiet=0 recursive=0
while (($#)); do
@@ -466,6 +501,7 @@
# @DESCRIPTION:
# Delete needless files in installation image.
python_clean_installation_image() {
+ _python_check_python_pkg_setup_execution
_python_initialize_prefix_variables
local file files=() quiet=0
@@ -538,15 +574,23 @@
# src_prepare, src_configure, src_compile, src_test, src_install.
if ! has ${EAPI:-0} 0 1; then
python_src_prepare() {
+ _python_check_python_pkg_setup_execution
