[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2014-08-17 23h59 UTC

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: dev-ha

[gentoo-dev] Bits 55-60 of /proc/PID/pagemap entries are about to stop being page-shift some time soon ?

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 e

Re: [gentoo-dev] Status of ppc and ppc64 teams.

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 p

Re: [gentoo-dev] [RFC] qt5-build.eclass

On Sun, Aug 17, 2014 at 8:56 PM, Maxim Koltsov 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 aren't planning on wri

Re: [gentoo-dev] [RFC] qt5-build.eclass

2014-08-17 22:56 GMT+04:00 Maxim Koltsov : > 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 libraries' ebuilds to mu

Re: [gentoo-dev] [RFC] qt5-build.eclass

2014-08-17 22:38 GMT+04:00 Davide Pesavento : > 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 catego

[gentoo-dev] [RFC] qt5-build.eclass

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: https://gi

Re: [gentoo-dev] rfc: eclass issues

On Sun, Aug 17, 2014 at 11:38 AM, William Hubbs 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 think we need to

Re: [gentoo-dev] gcc-4.8 may be needed in stable for www-client/chromium-38.x

On 7/29/14 6:49 PM, Michał Górny wrote: > Dnia 2014-07-23, o godz. 19:48:17 > ""Paweł Hajdan, Jr."" napisał(a): > >> Looks like www-client/chromium is going to start using c++11 seriously >> and require gcc-4.8+, see thread >>

[gentoo-dev] rfc: eclass issues

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 general-

Re: [gentoo-dev] rfc: calling all eclass phase functions by default

On Sun, Aug 17, 2014 at 2:54 AM, Ulrich Mueller 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 as E

Re: [gentoo-dev] rfc: calling all eclass phase functions by default

On 17 August 2014 19:03, Michał Górny 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

Re: [gentoo-dev] rfc: calling all eclass phase functions by default

On 8/17/14, 9:18 AM, Michał Górny wrote: > Dnia 2014-08-17, o godz. 09:06:04 > "Paweł Hajdan, Jr." 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 ebuild, possibly

Re: [gentoo-dev] rfc: calling all eclass phase functions by default

Dnia 2014-08-17, o godz. 09:06:04 "Paweł Hajdan, Jr." 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 collision o

Re: [gentoo-dev] rfc: calling all eclass phase functions by default

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 alrea

Re: [gentoo-dev] rfc: calling all eclass phase functions by default

Dnia 2014-08-17, o godz. 10:32:14 Kent Fredric 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 > > > --- code end -