On Sat, 16 Aug 2014, William Hubbs wrote:
The initial proposal is to change this behaviour so that the PMS
default phase functions call all matching phase functions from
inherited eclasses in sequence.
I strongly oppose this change, because I feel it will make our
entire tree very
Dnia 2014-08-17, o godz. 10:32:14
Kent Fredric kentfred...@gmail.com napisał(a):
So if you could sculpt it to be broader by default and have less scope for
developer error, that'd be an improvement.
--- code start --
ECLASS_EXCLUDE=foo_src_unpack bar_src_unpack
inherit foo bar baz
---
On 8/17/14, 12:32 AM, Kent Fredric wrote:
Collison systems I've seen usually do one of two things:
- In the event of a collision, demand the consumer resolve the problem by
redefining the function the collision occurs on in terms of its composite
parts. ( which is basically what we already
Dnia 2014-08-17, o godz. 09:06:04
Paweł Hajdan, Jr. phajdan...@gentoo.org napisał(a):
On 8/17/14, 12:32 AM, Kent Fredric wrote:
Collison systems I've seen usually do one of two things:
- In the event of a collision, demand the consumer resolve the problem by
redefining the function the
On 8/17/14, 9:18 AM, Michał Górny wrote:
Dnia 2014-08-17, o godz. 09:06:04
Paweł Hajdan, Jr. phajdan...@gentoo.org napisał(a):
The warning would make the problem more visible to ebuild writers. Then
we already have a solution that works, i.e. explicitly defining the
phase function in the
On 17 August 2014 19:03, Michał Górny mgo...@gentoo.org wrote:
So if you could sculpt it to be broader by default and have less scope
for
developer error, that'd be an improvement.
--- code start --
ECLASS_EXCLUDE=foo_src_unpack bar_src_unpack
inherit foo bar baz
--- code end
On Sun, Aug 17, 2014 at 2:54 AM, Ulrich Mueller u...@gentoo.org wrote:
On Sat, 16 Aug 2014, William Hubbs wrote:
My counter proposal to this is that we stop calling eclass phase
functions automatically, and to minimize the amount of boilerplating
we would have to do, we use a variable, such
All,
I spoke with mgorny on IRC and found out what his concerns are about our
current eclasses.
First, he thinks we should get rid of base.eclass.
I know there is work going on to get rid of it, but I haven't really
looked into the status much yet. I do agree though, we shouldn't have a
On 7/29/14 6:49 PM, Michał Górny wrote:
Dnia 2014-07-23, o godz. 19:48:17
Paweł Hajdan, Jr. phajdan...@gentoo.org napisał(a):
Looks like www-client/chromium is going to start using c++11 seriously
and require gcc-4.8+, see thread
On Sun, Aug 17, 2014 at 11:38 AM, William Hubbs willi...@gentoo.org wrote:
The other concern he mentioned was indirectly inherited eclasses being
able to override phase functions.
So, while I'm not sure whether getting rid of the ability to inherit
phase functions is practical/good/etc, I do
Hi guys,
In preparation for moving Qt5 to gentoo-x86 (finally!), please review
the attached eclass that is inherited by every Qt5 ebuild.
If you want to get an idea about how the ebuild code looks like, see
any ebuild in the dev-qt category of our overlay that inherits the
eclass:
2014-08-17 22:38 GMT+04:00 Davide Pesavento p...@gentoo.org:
Hi guys,
In preparation for moving Qt5 to gentoo-x86 (finally!), please review
the attached eclass that is inherited by every Qt5 ebuild.
If you want to get an idea about how the ebuild code looks like, see
any ebuild in the
2014-08-17 22:56 GMT+04:00 Maxim Koltsov maksbo...@gentoo.org:
For the record: I /think/ that an eclass for packages supporting both qt4
and qt5 (using multibuild.eclass) /might/ be useful. Looking forward to
hearing Qt team opinion.
I second this opinion (especially after porting a few
On Sun, Aug 17, 2014 at 8:56 PM, Maxim Koltsov maksbo...@gentoo.org wrote:
For the record: I /think/ that an eclass for packages supporting both qt4
and qt5 (using multibuild.eclass) /might/ be useful. Looking forward to
hearing Qt team opinion.
Maybe. But you'll have to convince me. We
On 08/16/14 05:32, Pacho Ramos wrote:
El lun, 04-08-2014 a las 18:03 -0400, Anthony G. Basile escribió:
Hi everyone,
The ppc and ppc64 team members just had a meeting. One of our main
issues was reconstituting those teams because they were in a state of
disorganization. We've come up with a
I got this odd message from the kernel on one of my MIPS machines last
night. Looks like a warning that went into the kernel back in April of
2013. Anyone aware if this is the result of an old userland program that we
might need to check in to?
[1073405.34] Bits 55-60 of /proc/PID/pagemap
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2014-08-17 23h59 UTC.
Removals:
virtual/python-argparse 2014-08-11 21:39:48 mgorny
virtual/python-unittest22014-08-11 21:40:11 mgorny
Additions:
Use a dedicated array variable to add EAPI-conditional arguments to
the configure script instead of prepending them to the command
parameters.
---
bin/phase-helpers.sh | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh
index
On Sun, 17 Aug 2014 20:37:10 +0200
Michał Górny mgo...@gentoo.org wrote:
Fix the off-by-one error in construction of supported EAPI list that
resulted in EAPI 5 being considered unsupported.
---
pym/portage/__init__.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Fix the off-by-one error in construction of supported EAPI list that
resulted in EAPI 5 being considered unsupported.
---
pym/portage/__init__.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pym/portage/__init__.py b/pym/portage/__init__.py
index fdbc4a8..18b2599 100644
---
Dnia 2014-08-17, o godz. 11:44:55
Brian Dolbec dol...@gentoo.org napisał(a):
Hmm, I thought EAPI was suppose to be a string...
from portage/const.py:
EAPI = 5
which is clearly an integer.
It generally is. However, the Council-defined EAPIs match integers
so far and
Make the eapi_is_supported() function use the generated list of
supported EAPIs rather than partial lists and integer comparison.
---
pym/portage/__init__.py | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/pym/portage/__init__.py b/pym/portage/__init__.py
index
22 matches
Mail list logo
