[gentoo-dev] dev-lang/python-2.6* unmask
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello guys,
~ As some of you may know, Python-2.6 was launched on Oct 1st, 2008
and have been sitting in the tree since Oct 5th. That is the official
production version of the Python programming language. That means,
python-2.5 is, according to the Python Project, officially old.
~ However, 2.6 version in the tree has been masked because some
packages are affected by some minor changes in the language. We added a
tracker bug [0] to keep maintainers informed of bugs/errors in their
packages regarding the transition from 2.5 to 2.6. This tracker was
opened on June 30th 2008 and still has opened bugs.
~ The Python team has lay off a plan to unmask Python-2.6 in a
month. In order to do so, we ask for your collaboration on fixing the
bugs still opened in that tracker so we can unmask it safely. The
majority of the bugs listed in there are "relatively" easy to fix and if
you don't have the time to do it, please, don't hesitate to ask for our
help, we'll be glad to give you a hand closing some of them (we just
need a "clear" from the team or dev to do so)
~ Although those opened bugs are blocking the tracker already,
I'll provide you with a compiled list so you don't even have to open a
browser or open a shell to run bugz ;).
~ KDE Team:
~http://bugs.gentoo.org/show_bug.cgi?id=239233 - [PATCH]
kde-base/superkaramba-3.5.10 should support dev-lang/python:2.6
~http://bugs.gentoo.org/show_bug.cgi?id=253582 - [PATCH]
kde-base/dcoppython-3.5.10 fails with python-2.6
~Java Team:
~http://bugs.gentoo.org/show_bug.cgi?id=239479 - [PATCH]
dev-java/javatoolkit fails with python-2.6
~http://bugs.gentoo.org/show_bug.cgi?id=246780 -
dev-java/ant-core-1.7.1-r2 fails to build with dev-lang/python:2.6
~CJK Team:
~http://bugs.gentoo.org/show_bug.cgi?id=255210 -
app-i18n/skim-1.4.5-r2 build fails with Python 2.6
~ SCI Team:
~http://bugs.gentoo.org/show_bug.cgi?id=258219 -
dev-python/numpy-1.2.1 - selftest bugs though required for python-2.6
compatibility
~Caster:
~http://bugs.gentoo.org/show_bug.cgi?id=243802 -
app-office/taskcoach calls object.__init__ with arguments, which fails
in python-2.6
~ Lack:
~ http://bugs.gentoo.org/show_bug.cgi?id=246786 -
Version bump: dev-python/gdata-1.2.4
~ Proaudio:
~ http://bugs.gentoo.org/show_bug.cgi?id=251003 -
[PATCH] media-libs/aubio-0.3.2-r1 not compatible with dev-lang/python-2.6
~ Matsuu:
~ http://bugs.gentoo.org/show_bug.cgi?id=258364 -
sys-devel/distcc-3.1{,-r1} explictly compiles with python-2.5 even with
python-2.6 selected
~ Thanks a lot for your help, we'll be waiting to hear from you.
~ Best regards,
[0] http://bugs.gentoo.org/show_bug.cgi?id=230205 - [TRACKER] Python-2.6
incompatible packages
Jesus Rivero (Neurogeek)
Gentoo Python Team
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmqOmgACgkQdIssYB9vBoNryQCeICf6jUcfVdlhNEHRlKdPrK/d
VO8AnjCRDgbO/9zWw+Z2vBWt7egyrAYb
=8Xvr
-END PGP SIGNATURE-
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Kumba wrote: I was talking to Alec last night in -dev (yes, I'm still alive), and I tossed out the idea of using metadata.xml instead of mangling the ebuild filename or even sticking it as the first line in the ebuild (as a hashbang or something gentoo-specific, for example). Fleshing out more (And to solicit more thought on this idea -- insane?). Using mips-sources as an example: # ls -l /usr/portage/sys-kernel/mips-sources/*.ebuild total 116K -rw-r--r-- 1 root root 19K Jan 9 04:10 mips-sources-2.6.20.18.ebuild -rw-r--r-- 1 root root 18K Jan 9 04:10 mips-sources-2.6.27.10.ebuild -rw-r--r-- 1 root root 18K Feb 23 16:43 mips-sources-2.6.28.7.ebuild Would, to specify them as EAPI=2 in metadata.xml, be encoded as (just an example -- suggest other formats): pv = specifies the package version ver = eapi version. Better names for these values? Suggest! I didn't want to re-use 'api' or anything. Maybe ? Anyways, after commiting to gentoo-x86 CVS, a backend script, similar to or the same as whatever parses out the tags will run and extract this data, and update /usr/portage/profiles/eapi.list (example name). /usr/portage/profiles/eapi.list will resemble something like this: sys-kernel/mips-sources-2.6.20.18:2 sys-kernel/mips-sources-2.6.27.10:2 sys-kernel/mips-sources-2.6.28.7:2 Upon installing the package by whatever package manager (portage is my example), it will process this eapi.list, much like it does use.desc and use.local.desc, and therefore know all it needs to know, then it can source the ebuild and use whatever logic it needs to follow that specific EAPI. That is if my assumption is correct that the usr.desc/use.local.desc stuff is parsed prior to the ebuild itself being sourced. If not, well, I dunno then. I'm guessing here. The pros of this that I can see: - No changes to the current filename structure. Things stay the name, CVS history is retained because existing files aren't renamed (we're not on git just yet). - No special markers, comments, or bash vars inside the ebuild. Covers some of the other cons that were presented. - Older package managers won't read eapi.list, and can resume their default behavior of EAPI=0. Allows backwards compatibility. - Newer package managers will assume a non-entry in eapi.list to equal EAPI=0, so there won't be a big rush to update every package/metadata in the tree. Allows for slow, controlled adoption. Cons that I can see: - metadata.xml gets updated more frequently because specific versions can get cited (workaround idea, see below) - Backend has to do extra work (minimal? Can infra comment on the feasibility of this?) I'm suggesting this mostly because both ideas of embedding the EAPI value in the filename and inside the ebuild seem like ugly workarounds. Others are also noting other problems with both of these approaches. EAPI also feels more like a metadata-type thing anyways. I mean, if we're already storing local USE flags in it, why not EAPI stuff? I'm a tad behind on the whole discussion, I know, but why not toss the idea out there. Some other thoughts on the first con, of metadata being updated more frequently -- we allow the use of wildcards: Would mark every ebuild in the directory for a given EAPI value (EAPI=2 in this case) Marks every ebuild version lower than 2.6 as EAPI=1. Basically, the wildcard modifiers Portage currently understands would apply. Or we could limit it to a subset of these wildcards (say, *, <, >, <=, and >=). Obviously, tools like repoman would need to be able to read metadata as well (can it? I don't know) and make sure that the versions specified in the 'pv' value exist in the directory before commit. Either by specific value or by expanding the wildcard notation and then cross-referencing the files listed in the directory and with CVS/git/whatever. But to be honest, none of the ideas, even my own, seems like "the best" idea. I think of mine as less intrusive to the tree and less visible to the end users and the package managers, but maybe there's other options not thought of yet? -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Sat, 28 Feb 2009 19:39:36 + Robert Bridge wrote: > I have been thinking about this specific option. I will admit I don't > know if this has already been noted, but would this create the > possibility of multiple ebuilds with the same $C/$P-$PV? GLEP 55 forbids it. Note that it's already possible to have multiple equal versions of the same thing (1.0_alpha0 equals 01.0_alpha-r0), and it's already illegal. None of this is altered by any of the proposals. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Petteri Räty wrote: > 2) EAPI in file extension > - Allows changing global scope and the internal format of the ebuild > a) .ebuild- > - ignored by current Portage > b) ..ebuild > - current Portage does not work with this > c) .. > - ignored by current Portage I have been thinking about this specific option. I will admit I don't know if this has already been noted, but would this create the possibility of multiple ebuilds with the same $C/$P-$PV? Currently the filesystem enforces the uniqueness of that tuple, will that uniqueness be allowed to lapse? (i.e. allow multiple ebuilds for the same $C/$P-$PV with different EAPIs?) If not, how is anyone proposing to enforce the uniqueness here? Just a silly thought... RobbieAB
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Samstag, 28. Februar 2009, Peter Volkov wrote:
> В Втр, 24/02/2009 в 16:14 +0200, Serkan Kaba пишет:
> > lucene-contrib eclass in java-experimental [1] sets EAPI to 1 to use
> > slot deps. And I think that's a valid usage.
> >
> > 1:
> > http://overlays.gentoo.org/proj/java/browser/java-experimental/eclass/luc
> >ene-contrib.eclass
>
> It's better (the only way...) to die in case an ebuild sets lower EAPI,
> like kde4-functions.eclass does:
>
> case ${EAPI} in
> 2) : ;;
> *) die "No way! EAPI older than 2 is not supported." ;;
> esac
I still dislike die in global scope, why not do it like autotools.eclass?
It does:
DEPEND="INCORRECT-WANT_AUTOCONF-SETTING-IN-EBUILD"
Regards
Matthias
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
В Втр, 24/02/2009 в 16:14 +0200, Serkan Kaba пишет:
> lucene-contrib eclass in java-experimental [1] sets EAPI to 1 to use
> slot deps. And I think that's a valid usage.
>
> 1:
> http://overlays.gentoo.org/proj/java/browser/java-experimental/eclass/lucene-contrib.eclass
It's better (the only way...) to die in case an ebuild sets lower EAPI,
like kde4-functions.eclass does:
case ${EAPI} in
2) : ;;
*) die "No way! EAPI older than 2 is not supported." ;;
esac
--
Peter.
signature.asc
Description: Эта часть сообщения подписана цифровой подписью
Regarding live sources management proposals (Was: [gentoo-dev] Gentoo Council Reminder for February 26)
Ciaran McCreesh wrote: On Thu, 26 Feb 2009 21:40:26 +0100 Luca Barbato wrote: Be specific. Explain how this works when, say, 0.34.4 is current, you have a 0.34.5_live and 0.34.5 comes out. being live working as substitute for 0.34.5_preN (_live) component the appearance of 0.34.5 will be higher than those. If we consider the .live alternative you'd have 0.34.live that is shadowed only by 0.35.x So it doesn't work Right. I'd like to have more details on this point since it works the very same -scm does: the version component substituted gets higher than any other value when is resolved. That is pretty much the same you get with -scm, what happens is that in the case of live template you have portage installing 0.34.5_preN with revision informations and adding the template to the "live" set. No, with -scm the order works correctly. "works correctly" You are always not stating what correctly is in your opinion or why other solutions are broken. In my opinion is correct to mark a version component as it will be the higher within that boundary, so 1.2.live means 1.2.x when x is the highest value, no matter which are the others at that time. Using a timestamp to replace x is the simplest way to grant this property. How do I track an upstream who has a 0.34 branch (which is equal to or ahead of the most recent 0.34.x release), a 0.36 branch (which is equal to or ahead of the most recent 0.36.x release) and a master branch (which is ahead of any release) using the live property? the live property doesn't tell much about versioning so you could use as the "x" version component or .live or -scm, the live property just makes portage aware that the sources are live. This situation is one in those pkg-scm and pkg.live work better, but just for one branch. As you said you could address the problem using useflags, so you could by extension you can use the same way to address the single case in proposals not supporting the tip of a single non version branch as well: have the all the ebuilds in a package having IUSE=-live that if enabled triggers the live property and changes the src_uri to the live branch you desire. So if you do that, how does the package manager know that one version is less than another if a particular use flag is enabled, but greater than it if it is disabled? The same argument is valid about the case of more than one tip branch you'd like to follow, how pkg-scm[master] is higher than pkg-scm[pu]? With property live you just know that it was from a live sources, so you can consider it always new when it comes to resolve it and that pretty much gives you the same behavior you get out -scm as is detailed in the glep-54 With live template you know when you installed it and what you installed so you can re-emerge or update depending on what you want and you get at least the timestamp giving some more information. If you throw in the mix SLOT alteration depending on or not on useflags or timestamps then you may also archive the property of having multiple version installed within any proposed framework. (e.g SLOT="$branch") Still this is something could enjoy some more discussion. As I stated long ago the main issue with the glep you proposed are the lack of informations in the document. You can fill every detail in mailing list as you like but if the document remains this way it doesn't get more informative. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
> 2) EAPI in file extension > - Allows changing global scope and the internal format of the ebuild > a) .ebuild- > - ignored by current Portage This is the solution that solves most problems. Going with something else is just a way of doing it wrong for the sake of it. - ferdy pgpfhEMRKGC35.pgp Description: PGP signature
[gentoo-dev] Re: perl-module.eclass -- review - 2
* Torsten Veller :
> Please review the attached perl-module.eclass.
> Patch linked below.
Thanks Bo Ørsted Andresen for feedback
> Changes
> ~~~
- use emake
- more quoting
- call perlinfo only once
As I've not seen any ebuild doing the replacement in line 156,
I've added a temporary ewarn. If you hits you, tell me.
> git://github.com/tove/perl-eclass.git
> http://people.gentoo.org/tove/files/perl-module.eclass.diff
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/perl-module.eclass,v 1.112 2008/09/30
08:28:44 robbat2 Exp $
#
# Author: Seemant Kulleen
# @ECLASS: perl-module.eclass
# @MAINTAINER:
# p...@gentoo.org
# @BLURB: eclass for perl modules
# @DESCRIPTION:
# The perl-module eclass is designed to allow easier installation of perl
# modules, and their incorporation into the Gentoo Linux system.
inherit eutils base
case "${EAPI:-0}" in
0|1)
EXPORT_FUNCTIONS pkg_setup pkg_preinst pkg_postinst pkg_prerm
pkg_postrm src_compile src_install src_test src_unpack
;;
*)
EXPORT_FUNCTIONS src_unpack src_prepare src_configure
src_compile src_test src_install
;;
esac
DESCRIPTION="Based on the $ECLASS eclass"
LICENSE="${LICENSE:-|| ( Artistic GPL-2 )}"
[ -z "${SRC_URI}" -a -z "${MODULE_A}" ] && MODULE_A="${MY_P:-${P}}.tar.gz"
[ -z "${SRC_URI}" -a -n "${MODULE_AUTHOR}" ] && \
SRC_URI="mirror://cpan/authors/id/${MODULE_AUTHOR:0:1}/${MODULE_AUTHOR:0:2}/${MODULE_AUTHOR}/${MODULE_SECTION}/${MODULE_A}"
[ -z "${HOMEPAGE}" ] && \
HOMEPAGE="http://search.cpan.org/dist/${MY_PN:-${PN}}";
SRC_PREP="no"
SRC_TEST="skip"
PREFER_BUILDPL="yes"
PERL_VERSION=""
SITE_ARCH=""
SITE_LIB=""
VENDOR_LIB=""
VENDOR_ARCH=""
ARCH_LIB=""
pm_echovar=""
perlinfo_done=false
perl-module_src_unpack() {
base_src_unpack unpack
has "${EAPI:-0}" 0 1 && perl-module_src_prepare
}
perl-module_src_prepare() {
if [[ -n ${PATCHES} ]] ; then
base_src_unpack autopatch
fi
esvn_clean
}
perl-module_src_configure() {
perl-module_src_prep
}
perl-module_src_prep() {
[[ "${SRC_PREP}" = "yes" ]] && return 0
SRC_PREP="yes"
${perlinfo_done} || perlinfo
export PERL_MM_USE_DEFAULT=1
# Disable ExtUtils::AutoInstall from prompting
export PERL_EXTUTILS_AUTOINSTALL="--skipdeps"
if [[ "${PREFER_BUILDPL}" == "yes" && -f Build.PL ]] ; then
einfo "Using Module::Build"
perl Build.PL \
--installdirs=vendor \
--libdoc= \
--destdir="${D}" \
--create_packlist=0 \
--extra_linker_flags="${LDFLAGS}" \
${myconf} \
<<< ${pm_echovar} \
|| die "Unable to build! (are you using
USE=\"build\"?)"
elif [[ -f Makefile.PL ]] ; then
einfo "Using ExtUtils::MakeMaker"
perl Makefile.PL \
PREFIX=/usr \
INSTALLDIRS=vendor \
INSTALLMAN3DIR='none' \
DESTDIR="${D}" \
${myconf} \
<<< ${pm_echovar} \
|| die "Unable to build! (are you using
USE=\"build\"?)"
fi
if [[ ! -f Build.PL && ! -f Makefile.PL ]] ; then
einfo "No Make or Build file detected..."
return
fi
}
perl-module_src_compile() {
${perlinfo_done} || perlinfo
has "${EAPI:-0}" 0 1 && perl-module_src_prep
if [[ -f Build ]] ; then
./Build build || die "compilation failed"
elif [[ -f Makefile ]] ; then
#emake ${mymake} OPTIMIZE="${CFLAGS}" OTHERLDFLAGS="${LDFLAGS}"
|| die "compilation failed"
emake ${mymake} OTHERLDFLAGS="${LDFLAGS}" || die "compilation
failed"
fi
}
perl-module_src_test() {
if [[ "${SRC_TEST}" == "do" ]] ; then
${perlinfo_done} || perlinfo
if [[ -f Build ]] ; then
./Build test || die "test failed"
elif [[ -f Makefile ]] ; then
emake test || die "test failed"
fi
fi
}
perl-module_src_install() {
local f
${perlinfo_done} || perlinfo
[[ -z ${mytargets} ]] && mytargets="pure_install"
if [[ -f Build ]] ; then
./Build ${mytargets} || die
elif [[ -f Makefile ]] ; then
emake ${myinst} ${mytargets} || die
fi
# einfo "Cleaning out stray man files"
find "${D}" -type f -name "*.3pm" -delete
find "${D}"/usr/share/man -depth -type d -empty -delete 2>/dev/null
fixlocalpod
for f in
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
EAPI inside ebuild is the best solution. If we really have to put it inside filename, keep it out of extension, like 2) b) suggests. -- Peter.
