Re: [gentoo-portage-dev] [PATCH] depgraph._too_deep: fix logic when deep is True (bug 566024)

2015-12-09 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/12/15 07:52, Zac Medico wrote:
> When deep is True and depth is an int, the method is intended to 
> return False
What a time to be alive, people.

I almost can't believe languages can be this bad.

ACK; go ahead & push.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWaAKnAAoJENQqWdRUGk8ByZkP/28WswKkctKzu9RdSSFYtnsI
vK8sGRqziFiYqM4DV0ugwQS3oLJXrsuXO/hR5nx49ezD8mnPumhGcU0me5lpfM9e
PIBoQEUyS6/JsfA89mz8vkUQmPyA9e/YzrvQRuxaqfMJNeHnRQ+Y3qr11kBkTXvD
64mA7ww8rf0Kp3BxlKYy/LlsQsZ7XrSYsFevIVJad5q/e6Xi9t/09+/9fV9tbNBz
9gZEKA3OaHoxlAgdaT0RyNAYClXx5o8RtsDXDZ6zEn+R24BfQux/pC3x7LK2dmvS
mSuTekAJXK/N4cSmEwFn1GXoQbfWDzBXk/g6YZVU/9XJzmEPy8Xt4XNN+jYHubl1
czcUekigcv89BESP2uCLcsblWnriaMAjDkcBLjIphK/O74buDSBZZfqa8gP7hZ3l
/15jUTfR9u4q11dM5ilwPKVQco+At5/se1up/xcPNjezQz85LFq+ww6GIR2wJoQd
sd3WJg93CLJ2utms6POo3e6chIG8R18siyA3hKHUqSIRQ1jefOB3W1Df1isnhiUr
//rWMm/hJjvODSfdjQ36UBlqhN9UI3lq6skm1TvcctHqNVyKCr8Oe3sc2kXnZRLP
qnxuSTlHQy6WPfl0RIFtlgBQELJIbs+wtYNAokskcVr4kDNjXYbPQeDmLYUZmVEW
F5W8qYAYZrC+q+q8Q5xu
=Ur3F
-END PGP SIGNATURE-



Re: [gentoo-dev] [PATCH] readme.gentoo.eclass EAPI 6 support

2015-12-09 Thread Ulrich Mueller
> On Wed, 9 Dec 2015, Michał Górny wrote:

>> AFAICS there are no particular EAPI 6 features this eclass could
>> make use of, so we can simply add 6 to the case pattern.

> We could use EAPI 6 as an opportunity to fix the API and stop
> overriding src_install() randomly.

I'm not fond of cluttering the eclass with so-called EAPI conditionals
that have nothing to do with the EAPI in question. If the eclass's API
is changed, making a new revision of the eclass is much cleaner.

Ulrich


pgpT_NKKHGknG.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH 02/13] python-utils-r1.eclass: Reorder implementations to semi-ascending order

2015-12-09 Thread Michał Górny
On Tue, 8 Dec 2015 09:19:57 +0100
Patrice Clement  wrote:

> Sunday 06 Dec 2015 20:03:21, Michał Górny wrote :
> > Reorder the Python implementations to ascending version order, with
> > CPython listed first and other implementations in descending preference.
> > 
> > The previous ordering has been used for two reasons:
> > 
> > 1. There were packages which supported Python 3.x or PyPy partially but
> > their documentation builds or test functions required CPython 2.x.
> > The specific ordering caused python_export_best (the predecessor of
> > python_setup) to use CPython 2.x for those tasks. This is now replaced
> > by explicit implementation restrictions in python_setup.
> > 
> > 2. PyPy setup runs were usually slower than CPython, and CPython 3.x
> > runs were often slower due to 2to3 calls. Combined with parallel build
> > runs, this ordering caused slower builds to start earlier and sometimes
> > resulted in more efficient use of threads. However, nowadays we no
> > longer do parallel builds.
> > 
> > Therefore, it seems reasonable to finally reorder the implementations
> > into a more intuitive order.
> > ---
> >  eclass/python-utils-r1.eclass | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> > index 0bce6a9..3ea23a8 100644
> > --- a/eclass/python-utils-r1.eclass
> > +++ b/eclass/python-utils-r1.eclass
> > @@ -41,10 +41,10 @@ inherit toolchain-funcs
> >  # @DESCRIPTION:
> >  # All supported Python implementations, most preferred last.
> >  declare -g -r _PYTHON_ALL_IMPLS=(
> > -   jython2_5 jython2_7
> > -   pypy pypy3
> > -   python3_3 python3_4 python3_5
> > python2_7
> > +   python3_3 python3_4 python3_5
> > +   pypy pypy3
> > +   jython2_5 jython2_7
> >  )
> >  
> >  # @FUNCTION: _python_impl_supported
> > -- 
> > 2.6.3
> > 
> >   
> 
> Michal,
> 
> While at it, please delete jython2_5 from this list since jython versions < 
> 2.7 are in
> the process of being purged from Portage. 
> 
> See https://bugs.gentoo.org/show_bug.cgi?id=552452

Will do, also from profiles.

-- 
Best regards,
Michał Górny



pgpjGth7yOPdW.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCHES] python-r1 suite clean up & impl reorder

2015-12-09 Thread Michał Górny
On Sun,  6 Dec 2015 20:03:19 +0100
Michał Górny  wrote:

> Hi,
> 
> Here's another patchset. Mostly fixups inspired by multilib-build.eclass
> changes with a few little additions.
> 
> Changes:
> 
> 1. eclass-set variables are now read-only,
> 2. 'unset -f' is used to unset temporary & local functions,
> 3. implementations are reordered for sane order.
> 
> I've tested this with a few dozen random distutils-r1, python-r1,
> python-any-r1 and python-single-r1 packages. However, for
> the implementation reorder a larger tinderbox run would be appreciated.
> 
> As explained in the commit, the reorder may influence files installed by
> a package, and implementation selected by python_setup(). This should
> not cause issues for correctly written ebuilds, and should help us find
> those that are not correctly written ;-).
> 
> In other words, we're finally considering Python 3.x preferred over
> Python 2.x.

Merged now.

-- 
Best regards,
Michał Górny



pgp_Penjh5Hf2.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCHES] multilib-build & multilib-minimal EAPI 6 patchset

2015-12-09 Thread Michał Górny
On Sun,  6 Dec 2015 19:57:45 +0100
Michał Górny  wrote:

> Hi, everyone.
> 
> Here's a patchset for review. Changes:
> 
> 1. eclass-generated variables are read-only,
> 2. missing error checks (||die) added,
> 3. 'unset -f' used to wipe local and temporary functions from the env,
> 4. deprecated function QA warnings turned into bans for EAPI 6,
> 5. eutils inherit fixes/updates.
> 
> Please review. I've tested it on a set of randomly selected packages.

Applied after following ulm's suggestions.

-- 
Best regards,
Michał Górny



pgpWvj6IYuFDF.pgp
Description: OpenPGP digital signature


[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/gegl/

2015-12-09 Thread Sebastian Pipping
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09.12.2015 07:41, Michał Górny wrote:
> On Tue,  8 Dec 2015 21:54:44 + (UTC) "Sebastian Pipping"
>  wrote:
> 
>> commit: a1ea06b430e14f68b5b7bf1947a681215157c034 Author:
>> Sebastian Pipping  gentoo  org> AuthorDate: Tue
>> Dec  8 21:49:31 2015 + Commit: Sebastian Pipping >  gentoo  org> CommitDate: Tue Dec  8 21:54:00 2015
>> + URL:
>> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a1ea06b4
>> 
>> media-libs/gegl: Fix ffmpeg/libav dependency (bug #567638)
>> 
>> Package-Manager: portage-2.2.26
>> 
>> media-libs/gegl/gegl-0.3.4.ebuild | 10 ++ 1 file changed,
>> 6 insertions(+), 4 deletions(-)
>> 
>> diff --git a/media-libs/gegl/gegl-0.3.4.ebuild
>> b/media-libs/gegl/gegl-0.3.4.ebuild index 764b6c9..c2b9409
>> 100644 --- a/media-libs/gegl/gegl-0.3.4.ebuild +++
>> b/media-libs/gegl/gegl-0.3.4.ebuild @@ -18,7 +18,7 @@ if [[ ${PV}
>> == ** ]]; then SRC_URI="" else 
>> SRC_URI="http://download.gimp.org/pub/${PN}/${PV:0:3}/${P}.tar.bz2;
>>
>> 
- - KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~sparc ~x86
~amd64-fbsd ~amd64-linux ~arm-linux ~x86-linux ~ppc-macos ~x64-macos
~x86-macos ~x64-solaris ~x86-solaris"
>> +KEYWORDS="~alpha ~amd64 ~arm ~hppa ~mips ~ppc ~ppc64 ~x86
>> ~amd64-fbsd ~amd64-linux ~arm-linux ~x86-linux ~ppc-macos
>> ~x64-macos ~x86-macos ~x64-solaris ~x86-solaris"
> 
> ...which change is put silently under 'dependency fix' with no
> explicit warning, and effectively breaks ~ia64 reverse
> dependencies:
> 
> https://qa-reports.gentoo.org/output/gentoo-ci/42f623e/output.html#med
ia-gfx/gimp

There
> 
is

https://bugs.gentoo.org/show_bug.cgi?id=567824

for that now.  If I don't hear from ia64 and/or sparc until tomorrow
night, I will drop those keywords from Gimp as well.  If it's more
urgent, I'm happy with anyone else doing that before me.  I hope
that's okay for everyone.  Else, please let me know.

Best,



Sebastian

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlZoxEkACgkQsAvGakAaFgBvmACfRDY19JxNYqClQaYfVREJevp/
GzAAoMHIWJGN39fyNgvL8+RCxvaKbl36
=1w1B
-END PGP SIGNATURE-