Hi,
Here's a quick set of minor patches to python-r1 suite. It mostly
includes some fixes to issues I've noticed while working on something
bigger ;-).
The first patch merely fixes missing 'local' for a variable. The second
adds REQUIRED_USE to the python_setup() use example in python-r1.
The thi
---
eclass/python-any-r1.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/python-any-r1.eclass b/eclass/python-any-r1.eclass
index 69f7bb736d22..e4d2d46bc706 100644
--- a/eclass/python-any-r1.eclass
+++ b/eclass/python-any-r1.eclass
@@ -224,7 +224,7 @@ python_gen_a
Update the missed occurence of pattern matching with the new framework.
---
eclass/distutils-r1.eclass | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 1376326c9579..6078fb6d52b7 100644
--- a/eclass
Make the pattern matching code in _python_impl_matches() more lax,
allowing (accidental) mixing of PYTHON_COMPAT-style values with
EPYTHON-style values. This is trivial to do, and solves the problem
introduced by complexity-by-limitation of other eclasses -- where
patterns for dependency strings ar
---
eclass/python-r1.eclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/eclass/python-r1.eclass b/eclass/python-r1.eclass
index 8de0a851856c..809dc5f2b8e5 100644
--- a/eclass/python-r1.eclass
+++ b/eclass/python-r1.eclass
@@ -614,6 +614,7 @@ python_parallel_foreach_impl() {
# Example:
#
The function was (verbosely) deprecated in Dec 2014, and banned since
EAPI 6. It is no longer used by any ebuild in ::gentoo.
---
eclass/python-r1.eclass | 35 ---
1 file changed, 35 deletions(-)
diff --git a/eclass/python-r1.eclass b/eclass/python-r1.eclass
index
The variable was deprecated and the warning put in place in Dec 2014. It
is no longer used in any ebuild in ::gentoo.
---
eclass/distutils-r1.eclass | 9 -
1 file changed, 9 deletions(-)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 6078fb6d52b7..e79f86bab12d
Rewrite the python_*_all() phase running code to reuse python_setup
instead of hacking on top of python_foreach_impl. The resulting code
is a bit simpler but most importantly, it avoids duplication of code
from python-r1 and ensures that distutils-r1 common phases are directly
altered by changes in
Hi, everyone.
Here's a set of patches inspired by the recent Sphinx dependency
discussion. They make python-r1 (and therefore distutils-r1) capable
of any-of dependency logic similar to the one used in python-any-r1.
The basic goal is relatively simple -- to improve handling of pure
build-time de
Inline the logic needed to iterate over implementations directly into
python_setup instead of using python_foreach_impl. This is mostly NFC,
except that we iterate in reverse order now -- that is, we start at
the newest implementation and stop at the first one that works for us.
Previously we (impl
Provide an alternate mode for python_setup() that behaves similarly to
python-any-r1 eclass. If python_check_deps() function is declared
by the ebuild, the python_setup logic switches to accepting any
implementation that is in PYTHON_COMPAT, installed and satisfies
python_check_deps() independently
Add a python_gen_any_dep() function similar to the one in python-any-r1
to facilitate creating any-of dependencies for the new python_setup
syntax.
---
eclass/python-r1.eclass | 98 +
1 file changed, 98 insertions(+)
diff --git a/eclass/python-r1.ec
---
.../backports-unittest-mock/backports-unittest-mock-1.2.1.ebuild | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git
a/dev-python/backports-unittest-mock/backports-unittest-mock-1.2.1.ebuild
b/dev-python/backports-unittest-mock/backports-unittest-mock-1.2.1.ebuild
inde
Move the PYTHON_COMPAT_OVERRIDE warning from _python_obtain_impls()
to _python_validate_useflags(). Since the latter function is the only
point where the former is called, this is a purely cosmetic change at
the moment. However, it makes it possible to reuse the warning in
additional places without
---
app-portage/gentoopm/gentoopm-.ebuild | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/app-portage/gentoopm/gentoopm-.ebuild
b/app-portage/gentoopm/gentoopm-.ebuild
index a4529c98bc9b..220247442d2d 100644
--- a/app-portage/gentoopm/gentoopm-.ebuild
+++
Luke A. Guest wrote:
> Thoughts?
I can't comment on your strategy, but I do agree with and support
your goals of being able to use more Ada in Gentoo.
Thanks to you and others for your work on this! :)
//Peter
So here's the agenda. It's been mostly assembled by tamiko, who may
unfortunately not make it tonight. I'll try to stand in...
- a short hello :-)
- Outstanding CVEs for binutils, elfutils, gcc, and glibc [1]
* Who handled CVEs in the past?
* Who wants to take care of individual packages
On Wed, May 17, 2017 at 6:38 PM, Patrick Lauer wrote:
> For some strange reason I was listed there as maintainer, but since no one
> wanted to listen to my ideas I guess I wasn't. So now last person who
> touched it gets stuck with it.
>
For elasticsearch, you added yourself to the maintainers,
On Fri, May 19, 2017 at 6:38 PM, Patrick Lauer wrote:
>
> I "was" package maintainer and relied on these versions.
>
> If I as maintainer have no control over such things, why am I maintainer,
> and why do I need an overlay?
>
>
> ... that sounds exquisitely confused, I have no idea why this disc
On Fri, May 19, 2017 at 6:50 PM, Patrick Lauer wrote:
> I tried removing proxy-maint from metadata after multiple discussions
> failed. Extra happiness towards monsieurp "but the GH PR is over 3 days
> old, I have to commit" and gokturk "Yes I understand. I commit anyway"
>
> This has been an uph
On sob, 2017-05-20 at 21:57 +0200, Tomas Mozes wrote:
> On Fri, May 19, 2017 at 6:50 PM, Patrick Lauer wrote:
>
> > I tried removing proxy-maint from metadata after multiple discussions
> > failed. Extra happiness towards monsieurp "but the GH PR is over 3 days
> > old, I have to commit" and gokt
On 05/20/2017 10:46 PM, Michał Górny wrote:
> Tomas, please don't go this road. We all know Patrick does a shitty job
> as Gentoo developer, both technically and socially but you do not have
> to try to match him.
Was this comment really necessary?
--
Kristian Fiskerstrand
OpenPGP keyblock reach
On sob, 2017-05-20 at 22:51 +0200, Kristian Fiskerstrand wrote:
> On 05/20/2017 10:46 PM, Michał Górny wrote:
> > Tomas, please don't go this road. We all know Patrick does a shitty job
> > as Gentoo developer, both technically and socially but you do not have
> > to try to match him.
>
> Was this
On 05/20/2017 11:06 PM, Michał Górny wrote:
> On sob, 2017-05-20 at 22:51 +0200, Kristian Fiskerstrand wrote:
>> On 05/20/2017 10:46 PM, Michał Górny wrote:
>>> Tomas, please don't go this road. We all know Patrick does a shitty job
>>> as Gentoo developer, both technically and socially but you do
>
> Tomas, please don't go this road. We all know Patrick does...
Oh please cut it.
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)
signature.asc
Description: This is a digitally signed message part.
---
eclass/ssl-cert.eclass | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/eclass/ssl-cert.eclass b/eclass/ssl-cert.eclass
index 6bec347234d..bfe5291314c 100644
--- a/eclass/ssl-cert.eclass
+++ b/eclass/ssl-cert.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2014 Gentoo Found
On Fri, May 05, 2017 at 10:35:43AM -0500, William Hubbs wrote:
> All,
>
> here is the third (and hopefully final) draft of meson.eclass. I am
> leaving the code in for the cross support but commented so all I need to
> do later is add toolchain-funcs back to inherit and uncomment the code
> once I
When it'll be possible to start to use it?
On Sat, May 20, 2017 at 8:30 PM, Michał Górny wrote:
> Hi, everyone.
>
> Here's a set of patches inspired by the recent Sphinx dependency
> discussion. They make python-r1 (and therefore distutils-r1) capable
> of any-of dependency logic similar to the
28 matches
Mail list logo
