Re: [gentoo-dev] Patch for python.eclass
On Sun, 24 Oct 2010 23:47:56 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: Usage of new EAPIs in the tree is not allowed before council approval. python.eclass doesn't use any EAPIs, it only provides support for ebuilds, which use given EAPIs (without EAPI=4). I forgot to say that this patch doesn't introduce usage of any feature absent in EAPI=3 and present in current draft of EAPI=4, but changes API of python.eclass in EAPI=4. For all we know, EAPI 4 may be completely changed next week and then allowed in the tree the week after. Then people looking at your eclass will incorrectly assume that it supports the approved EAPI 4. EAPI 4's current state used to be closed, and approved subject to Portage implementation, but due to the huge delays in that there have been a number of things since then that the Council has voted on that no-one has provided PMS patches or even approximate wording for. Unless you've been keeping very close track of that, you don't even know what EAPI 4 is likely to contain, let alone what it eventually will contain... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Extending EAPI=4
I would like to request that 2 additional features are added to EAPI=4.
These features will be needed for further development of python.eclass.
1. Support for . characters in names of USE flags
2. Support for use.unsatisfiable and package.use.unsatisfiable files in profiles
These files would have the same syntax as use.mask and package.use.mask,
respectively.
These files would indicate that it's allowed for dependencies conditional on
USE flags specified
in these files to be unsatisfiable. It would allow for stable packages to have
optional
dependencies on packages, which cannot be stabilized yet. This feature would be
a better
replacement for possibility of masking of USE flags only on stable systems,
which was considered
in the past.
Example dependencies:
DEPEND=python_abis_2.4? ( dev-lang/python:2.4 )
python_abis_2.5? ( dev-lang/python:2.5 )
python_abis_2.6? ( dev-lang/python:2.6 )
python_abis_2.7? ( dev-lang/python:2.7 )
python_abis_3.1? ( dev-lang/python:3.1 )
python_abis_3.2? ( dev-lang/python:3.2 )
RDEPEND=${DEPEND}
python_abis_2.7, python_abis_3.1 and python_abis_3.2 USE flags would be
specified in use.unsatisfiable
file until relevant versions of Python are stabilized on all architectures.
Without this feature,
some USE flags would have to be masked, so unstable users couldn't easily test
many packages with
new versions of Python.
Another example: dev-vcs/subversion[kde] depends on =kde-base/kdelibs-4.
dev-vcs/subversion is
stable on arm and ppc64, but kde-base/kdelibs is unstable on these
architectures, which causes
that currently kde USE flag of dev-vcs/subversion is masked in arm and ppc64
profiles, which
causes that users of ~arm or ~ppc64 would have to manually unmask this USE flag
in
/etc/portage/profile/package.use.mask to be able to install dev-vcs/subversion
with kde USE flag
enabled. With this feature, users wouldn't need to edit
/etc/portage/profile/package.use.mask.
use.unsatisfiable and package.use.unsatisfiable files would cause that
`repoman` would treat
given USE flags in the same way as masked USE flags. These files wouldn't
affect behavior of
`emerge`:
- If user has enabled given USE flag specified in use.unsatisfiable or
package.use.unsatisfiable
and if optional dependencies controlled by this USE flag are already
installed or satisfiable,
then `emerge` will allow to install given package.
- If user has enabled given USE flag specified in use.unsatisfiable or
package.use.unsatisfiable
and if optional dependencies controlled by this USE flag cannot be satisfied
(with current
settings of ACCEPT_KEYWORDS, /etc/portage/package.keywords etc.), then
`emerge` will print
informative error message telling e.g. about a dependency masked by ~${ARCH}
keyword.
I have a patch, which adds support for these features in Portage, so inclusion
of these features
in EAPI=4 wouldn't delay EAPI=4.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Support for Python 3
I would like to suggest that setting Python 3.1 as main active version of Python be officially supported and recommended for Gentoo developers since 2010-12-01. Majority of packages supporting only Python 2.* have been prepared to work correctly in situation when Python 3.* is set as main active version of Python. I would like to encourage other developers to work on fixing remaining packages. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Extending EAPI=4
On Mon, 25 Oct 2010 15:24:23 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 1. Support for . characters in names of USE flags If you do this, you'll have to either convert everything using Python ABIs to EAPI 4 immediately, or have two sets of flag names. Won't users get confused if they have to set both python_abis_3_2 (for EAPI 4 packages) and python_abis_3.2 (for EAPI 4 packages)? And won't developers have a hard time getting [use] deps right for them? 2. Support for use.unsatisfiable and package.use.unsatisfiable files in profiles As far as I can see, this one's a repoman thing, and has little to no impact on PMS since it doesn't require behaviour changes from the package mangler itself. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Support for Python 3
В Пнд, 25/10/2010 в 15:37 +0200, Arfrever Frehtes Taifersar Arahesis пишет: I would like to suggest that setting Python 3.1 as main active version of Python be officially supported and recommended for Gentoo developers since 2010-12-01. Majority of packages supporting only Python 2.* have been prepared to work correctly in situation when Python 3.* is set as main active version of Python. How many packages left? -- Peter.
Re: [gentoo-dev] Extending EAPI=4
2010-10-25 15:42:00 Ciaran McCreesh napisał(a): On Mon, 25 Oct 2010 15:24:23 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 1. Support for . characters in names of USE flags If you do this, you'll have to either convert everything using Python ABIs to EAPI 4 immediately, or have two sets of flag names. Won't users get confused if they have to set both python_abis_3_2 (for EAPI 4 packages) and python_abis_3.2 (for EAPI 4 packages)? There won't be any such USE flags for EAPI 4. I'm planning to use e.g. REQUIRED_USE, which isn't available in EAPI 4. And won't developers have a hard time getting [use] deps right for them? Appropriate dependencies will be automatically generated by python.eclass. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Extending EAPI=4
2010-10-25 15:56:50 Ulrich Mueller napisał(a): On Mon, 25 Oct 2010, Arfrever Frehtes Taifersar Arahesis wrote: 1. Support for . characters in names of USE flags Are you aware that this would break existing programs that do regexp matching on USE flags? I suggest this feature in a new EAPI to avoid this problem. (No program should parse anything from future EAPIs.) -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Extending EAPI=4
On Mon, 25 Oct 2010 15:56:50 +0200 Ulrich Mueller u...@gentoo.org wrote: On Mon, 25 Oct 2010, Arfrever Frehtes Taifersar Arahesis wrote: 1. Support for . characters in names of USE flags Are you aware that this would break existing programs that do regexp matching on USE flags? The current implementation of the useq() function in portage is probably the most prominent example. That's already a can of worms, since @ is allowed in use flag names. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdemu: metadata.xml ChangeLog cdemu-1.3.0.ebuild
On 14:24 Sun 24 Oct , William Hubbs wrote: Hi all, On Thu, Oct 21, 2010 at 12:45:01PM +0300, Eray Aslan wrote: On 21.10.2010 10:30, Peter Volkov wrote: Nothing there applies here, since this USE flag has nothing to do with archs/profiles... which will force some users to use double negative (-nocdemud, i.e. no no cdemud) which is rather convulated and should be avoided imho. While at it, we should try to make the wording on the devmanual clearer, that it only applies to arches/profiles I realize I'm a little lateon this thread, so this is more just for the record I guess. I don't like no* use flags either, for the same reason that was given above. -no* is a double negative and it should be avoided. Agreed. The argument that it's removing a feature is an implementation detail that users don't and shouldn't have to care about at all. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgp3pDlIrCqP7.pgp Description: PGP signature
Re: [gentoo-dev] Support for Python 3
On Mon, Oct 25, 2010 at 7:07 PM, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: I would like to suggest that setting Python 3.1 as main active version of Python be officially supported and recommended for Gentoo developers since 2010-12-01. Majority of packages supporting only Python 2.* have been prepared to work correctly in situation when Python 3.* is set as main active version of Python. I would like to encourage other developers to work on fixing remaining packages. I do not think this is a useful expenditure of developer time. There's absolutely no hurry to start using Python 3 since 99.9% of upstreams do not have officially supported ports yet. We can revisit this when the upstreams of half the packages in-tree start using Python 3 by default (this will probably take more than a year). -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdemu: metadata.xml ChangeLog cdemu-1.3.0.ebuild
В Пнд, 25/10/2010 в 09:07 -0500, Donnie Berkholz пишет: On 14:24 Sun 24 Oct , William Hubbs wrote: I don't like no* use flags either, for the same reason that was given above. -no* is a double negative and it should be avoided. Agreed. The argument that it's removing a feature is an implementation detail that users don't and shouldn't have to care about at all. Ok, renamed :) -- Peter.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: python.eclass
On 10/25/2010 02:54 PM, Arfrever Frehtes Taifersar Arahesis (arfrever) wrote: arfrever10/10/25 11:54:19 Modified: python.eclass Log: Set IUSE in EAPI =4. Rename _parse_PYTHON_DEPEND() to _python_parse_PYTHON_DEPEND() and unset it after its using. Ban NEED_PYTHON variable. Add python_abi_depend(). Fix exporting of python_pkg_setup() in EAPI =4. Please revert these until council has approved EAPI 4 for main tree usage or risk the consequences. There is no guarantee that IUSE will be in EAPI 4 although it's likely. If you want such pre-emptive actions in the main tree you should seek our approval first. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Support for Python 3
Please, just, no. Projects and people are just not ready, yet. And even Python experts at #python tell to stay away from Py3, last time I checked. -- Fabio Erculiani
Re: [gentoo-dev] Extending EAPI=4
Implementing a feature to just satisfy your tiny, corner-case (how many people would take benefit out of it?) use case is just against any software engineering best practice, and it's a good path towards bloat and complexity. I think people can understand python_abis_2_5 well enough, besides being happy that their app will KEEP working. -- Fabio Erculiani
Re: [gentoo-dev] Extending EAPI=4
2010-10-25 16:43:43 Fabio Erculiani napisał(a): Implementing a feature to just satisfy your tiny, corner-case (how many people would take benefit out of it?) use case is just against any software engineering best practice, and it's a good path towards bloat and complexity. I think people can understand python_abis_2_5 well enough, besides being happy that their app will KEEP working. 2_5 is very ugly and unacceptable. python.eclass already uses 2.5 (e.g. in RESTRICT_PYTHON_ABIS). -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Extending EAPI=4
2010-10-25 16:03:01 Ciaran McCreesh napisał(a): On Mon, 25 Oct 2010 15:56:18 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 2010-10-25 15:42:00 Ciaran McCreesh napisał(a): On Mon, 25 Oct 2010 15:24:23 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 1. Support for . characters in names of USE flags If you do this, you'll have to either convert everything using Python ABIs to EAPI 4 immediately, or have two sets of flag names. Won't users get confused if they have to set both python_abis_3_2 (for EAPI 4 packages) and python_abis_3.2 (for EAPI 4 packages)? There won't be any such USE flags for EAPI 4. Ok, that answers that objection. In that case I'd not be opposed to . being allowed *provided*: - Portage explicitly enforces it not being allowed anywhere else, including in profiles that aren't marked as eapi 4 Portage already allows some characters in some places in EAPI=0 regardless of PMS :) . Anyway I don't care. - The . isn't legal as the first character in a flag name. (Paludis has been using [.foo=bar] and the like in user eapi contexts to allow fancy queries on metadata. It would be a shame to have to change that syntax just for some hypothetical possible use of . in use flag names that looks really really weird anyway.) No objection. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Support for Python 3
2010-10-25 16:37:38 Fabio Erculiani napisał(a): Please, just, no. Projects and people are just not ready, yet. And even Python experts at #python tell to stay away from Py3, last time I checked. #python channel isn't maintained by Python upstream developers. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: python.eclass
On Mon, 25 Oct 2010 17:13:00 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: The attached patch could be applied if EAPI=4 doesn't contain support for . in IUSE. Should I apply this patch now? You should stop guessing what will or will not be in EAPI 4 and just not commit anything EAPI 4 related until EAPI 4 is approved. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: python.eclass
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said:
2010-10-25 16:31:41 Petteri Räty napisał(a):
On 10/25/2010 02:54 PM, Arfrever Frehtes Taifersar Arahesis (arfrever)
wrote:
arfrever10/10/25 11:54:19
Modified: python.eclass
Log:
Set IUSE in EAPI =4.
Rename _parse_PYTHON_DEPEND() to _python_parse_PYTHON_DEPEND() and
unset it after its using.
Ban NEED_PYTHON variable.
Add python_abi_depend().
Fix exporting of python_pkg_setup() in EAPI =4.
Please revert these until council has approved EAPI 4 for main tree
usage or risk the consequences. There is no guarantee that IUSE will be
in EAPI 4 although it's likely. If you want such pre-emptive actions in
the main tree you should seek our approval first.
python.eclass doesn't support EAPI=4 due to:
if ! has ${EAPI:-0} 0 1 2 3; then
die API of python.eclass in EAPI=\${EAPI}\ not established
fi
The attached patch could be applied if EAPI=4 doesn't contain support for
. in IUSE.
Should I apply this patch now?
No, you should remove anything that relates to EAPI 4. Please do so as
soon as possible.
Thanks,
--
Mark Loeser
email - halcy0n AT gentoo DOT org
email - mark AT halcy0n DOT com
web - http://www.halcy0n.com
signature.asc
Description: Digital signature
Re: [gentoo-dev] Extending EAPI=4
Am 25.10.2010 16:43, schrieb Fabio Erculiani: Implementing a feature to just satisfy your tiny, corner-case (how many people would take benefit out of it?) use case is just against any software engineering best practice, and it's a good path towards bloat and complexity. I think people can understand python_abis_2_5 well enough, besides being happy that their app will KEEP working. You are wrong at this part. Supporting dots in USE flags is not just a corner case for python packages. I planned to suggest the same for a future EAPI, when i got my planned features for multilib-portage done (which will then natively support the installation of packages for multiple versions of those different lang packages (like python, ruby, php...). While it might be possible to read and understand, that 2_5 is intended to be 2.5, it is much easier to understand and read, if you just write 2.5. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Extending EAPI=4
On 10/25/2010 04:24 PM, Arfrever Frehtes Taifersar Arahesis wrote: I would like to request that 2 additional features are added to EAPI=4. These features will be needed for further development of python.eclass. 1. Support for . characters in names of USE flags Ideally we should have consistency across languages so if we go down this road then for example ruby should eventually support it too. Ruby people: can you provide your input. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Extending EAPI=4
Il giorno lun, 25/10/2010 alle 19.23 +0300, Petteri Räty ha scritto: Ideally we should have consistency across languages so if we go down this road then for example ruby should eventually support it too. Ruby people: can you provide your input. We don't really care since we use the Ruby basename, which is dot-free, whatever the reason for that, may even be historical. I don't think our users mind if it's ruby18 or ruby1.8… beside maybe the Funtoo guys since Daniel decided to go with ruby1.9 breaking the previous series of ruby16, ruby18 and ruby19. But especially since _our_ system of dependencies is already in place, we most certainly have no intention on going on to change it on all the packages, so the '.' is totally useless for our scope. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
Re: [gentoo-dev] Extending EAPI=4
On 10/25/2010 06:23 PM, Petteri Räty wrote: On 10/25/2010 04:24 PM, Arfrever Frehtes Taifersar Arahesis wrote: I would like to request that 2 additional features are added to EAPI=4. These features will be needed for further development of python.eclass. 1. Support for . characters in names of USE flags Ideally we should have consistency across languages so if we go down this road then for example ruby should eventually support it too. Ruby people: can you provide your input. PHP could potentially benefit from this, we currently (see php-ext-source-r2.eclass) have to use - instead of the dot. But to my eyes the ugliness is acceptable. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Support for Python 3
On Mon, 25 Oct 2010 15:37:41 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: I would like to suggest that setting Python 3.1 as main active version of Python be officially supported and recommended for Gentoo developers since 2010-12-01. Majority of packages supporting only Python 2.* have been prepared to work correctly in situation when Python 3.* is set as main active version of Python. I would like to encourage other developers to work on fixing remaining packages. I don't see a reason to do so until issue #9561 is fixed [1]. Right now this means, that packages may fail to install randomly due to locale settings. [1] http://bugs.python.org/issue9561 -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/mpfc/files: mpfc-1.3.7-INT_MAX.patch
On Monday 25 October 2010 06:06:15 Samuli Suominen (ssuominen) wrote: ssuominen10/10/25 09:06:15 Added:mpfc-1.3.7-INT_MAX.patch Log: Missing include limits.h, required by recent linux-headers for cdrom.h and INT_MAX. Fix installation with recent coreutils wrt #335449 by Diego E. Pettenò. [...] #include stdio.h +#include limits.h /* cdrom.h and INT_MAX */ #include linux/cdrom.h #include errno.h #include string.h Am I missing something obvious or is it just hiding a bug in the linux headers? I see no usage of INT_MAX in the patched .c file... This comes to my mind too: http://blog.flameeyes.eu/2009/02/04/brace-for-impact A.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/mpfc/files: mpfc-1.3.7-INT_MAX.patch
Il giorno lun, 25/10/2010 alle 18.50 -0300, Alexis Ballier ha scritto: Am I missing something obvious or is it just hiding a bug in the linux headers? I see no usage of INT_MAX in the patched .c file... Upstream seem not to care about fixing that; we used to have a patch to fix linux-headers, but Mike dropped it with 2.6.35 to stay as close to upstream as possible. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/mpfc/files: mpfc-1.3.7-INT_MAX.patch
On Monday 25 October 2010 19:06:45 Diego Elio Pettenò wrote: Il giorno lun, 25/10/2010 alle 18.50 -0300, Alexis Ballier ha scritto: Am I missing something obvious or is it just hiding a bug in the linux headers? I see no usage of INT_MAX in the patched .c file... Upstream seem not to care about fixing that; we used to have a patch to fix linux-headers, but Mike dropped it with 2.6.35 to stay as close to upstream as possible. so now we prefer poor workarounds in dozens of packages to fixing the real bug in a single one in order to stay as close as possible to an unresponsive upstream? nice A. PS: What to do if there is a clever upstream for another package refusing to add such a workaround ? Carry the patch over and over ? This sounds very selfish.
Re: [gentoo-dev] Support for Python 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25-10-2010 13:37, Arfrever Frehtes Taifersar Arahesis wrote: I would like to suggest that setting Python 3.1 as main active version of Python be officially supported and recommended for Gentoo developers since 2010-12-01. Majority of packages supporting only Python 2.* have been prepared to work correctly in situation when Python 3.* is set as main active version of Python. I would like to encourage other developers to work on fixing remaining packages. Until we're certain that will not cause automatic weekly stages and cds to fail to build again, please don't. I'm willing to do local work to test this to ensure the stages and cds build and work correctly, but I'm likely going to need some help from the python team. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMxiSWAAoJEC8ZTXQF1qEPLTAP/iRywtI4OSfuRW+17jjvYG8q JCAEiuWWFpfgYaB4foM7QCDUSLos1WcIcHPtgUGKwQmNxnCEMot71OhDItTIAjlN 0AMAETA618aSH04HQRvA/WrS4XPB9HDB94UrIl102+AXtH3lM2O5lURqQg2/Tyz+ btU22n4Pa09ZxV9sefNvGws5ZZegL0PsBgpeGzNetI7jcGCidlbXzBqCh9M6a9K+ qJwxYtMsGgD2K/vWX4sNFrz7Eg4qw3OyrA+ylBlJ5FUzFOi0vjP3QsgATy7vXYva DUKdUEJIBAZRjFZA+CW++yXl7BMG4XEv/fqLXBRcWlgasyUZmN4eXDfgMupVg8zy kVt6we7rudc577uUsRnOoc4xdfV+LTmbBXaeAuQhFVr9/Rdf96AhowZhmV5caLix HTeQfvBpfNFtsU0VZz88JJuoFc5+vnPVyjtWHqH8bMVLKVo/EFg3L1Hl7GhmAdCD rsxAHdBRgQOIlSEV6XhfxZxL08KKkBMV1gUw7WbUk8WjB2tr3GBNAiXlZ7X/5ivG 1D8tFXjieEjsiC+5rpB+F4qolyYdezMfeT5mj2edd4OlJLps+tL/L30ADYwobEgF PJ1Gq0XqSP1LV9Nzl++zMwbquGd9jY8+kGIh1Grmfg+FFIjCzE6LrMlQ6FJnOFkK id+5MZovphHFMSR32ZKa =mEfL -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: python.eclass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 25-10-2010 15:13, Arfrever Frehtes Taifersar Arahesis wrote:
2010-10-25 16:31:41 Petteri Räty napisał(a):
On 10/25/2010 02:54 PM, Arfrever Frehtes Taifersar Arahesis (arfrever)
wrote:
arfrever10/10/25 11:54:19
Modified: python.eclass
Log:
Set IUSE in EAPI =4.
Rename _parse_PYTHON_DEPEND() to _python_parse_PYTHON_DEPEND() and unset
it after its using.
Ban NEED_PYTHON variable.
Add python_abi_depend().
Fix exporting of python_pkg_setup() in EAPI =4.
Please revert these until council has approved EAPI 4 for main tree
usage or risk the consequences. There is no guarantee that IUSE will be
in EAPI 4 although it's likely. If you want such pre-emptive actions in
the main tree you should seek our approval first.
python.eclass doesn't support EAPI=4 due to:
if ! has ${EAPI:-0} 0 1 2 3; then
die API of python.eclass in EAPI=\${EAPI}\ not established
fi
The attached patch could be applied if EAPI=4 doesn't contain support for
. in IUSE.
Should I apply this patch now?
Arfrever,
as others have noted, no ebuild or eclass may be committed to the tree
using or supporting an EAPI until it has been approved as an official
EAPI by the Council.
Please revert any bits about this ASAP.
@python:
If Arfrever isn't around to do it, please take the initiative.
@QA:
If neither Arfrever nor python are around to do it, please use your
privileges to revert this commit.
- --
Regards,
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJMxiZUAAoJEC8ZTXQF1qEPXBsP/RtuxnGcaAc+Kl7if4ioUloY
zkW8ZvBC8AKRujH7Gedz0kHIqYtn1d+xjT3o5yJMaHDQJXBYOQezkGUk6HcjKNgr
OzXpbsfxZvX8WP1FwfU/Ks9C8oRBEAzzof9Nq1ddVIcmB4dWpVzaBcXjGEqk5IXR
z8lkUACw3TU6BZAQcrPAhvkcTN8qRYym8kEgc0lENJQt8J4kIhQQkiI4SdvZd+Uw
7bHIdq6Mf4DbfwC1Tk3vbZelzdEcyD4EbIqSsulkkatpJqTZtRdVldlHRj+vbcm0
iK2A1fG01mI8I8m26czxBheIAupBcEI4RkdcN9S3kxOi1736bIvjlKnU/FriGfU4
IpUEzKgDNSYmfGwgvqrMz8W8nXLUuBCBHa13//foN9zHqj8FNB/nJs6TjrV7nbrU
LiWoGwkbSJZppwT3TN2zYavyl9W/BoQnAYQFkETwv60p9CdyPT8ah1347x9WDi0O
93XD8i7F+L23malLc46Dv6okZg+f7zrWMi1TAudU15LcSH0zRvg8TCN9l3Gb9xZM
q2FxSslIGeIRczfgFCmMMQswuvnB95MZVhf9KyugCtzl7FphAFh6As+V2oHd+PrE
J5wBJBCq+qqkkioUIsxMtLaaspgptZsSgmNIyjZ04/rgwMLxH8t8u9aapnHEvuyx
BbCtSXcbdr2vHVo3cuOG
=RhDb
-END PGP SIGNATURE-
[gentoo-dev] Google Code-In: 13-18 year olds in open source
Hi all, Based on our participation in the Summer of Code, Google invited us to apply for their revived program for 13-18 year olds called Google Code-In [1-2]. The basic idea is that students will complete a series of small tasks rather than one huge project, and the tasks don't even have to be related (or even involve programming!). One really neat feature about GCI is that projects can be anything -- documentation, translation, coding, research, whatever. If you've been feeling that your ideas are left out by GSoC, this is your chance. After talking with a few devs, there seemed to be a lot of interest in us getting involved. The application deadline is very soon -- this Friday! We need a good ideas list by then if we're going to apply. I created a draft ideas page [3]; please fill it in by the end of the day on this Thursday. We're looking for tasks that would take a student 13-18 years old roughly 1-3 days to complete. Ideas might include writing man pages, translating a few webpages, perhaps some relatively straightforward bugfixes, etc. More general ideas are on our ideas page and the GCI homepage. Because tasks are so short, mentoring will not be a major burden, so don't let that hold you back. I look forward to seeing all your cool ideas! 1. http://code.google.com/opensource/gci/2010-11/index.html 2. http://code.google.com/opensource/gci/2010-11/faqs.html 3. http://en.gentoo-wiki.com/wiki/Google_Code_In_2010_ideas -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpWxGpta4w8G.pgp Description: PGP signature
