Rich Freeman posted on Thu, 30 Aug 2012 20:38:11 -0400 as excerpted:
> My main concern is doing bumps all the time just for their own sake.
Yes. That's why I didn't tackle that side at all. But I've seen the
"PM's can never drop support for an EAPI once adopted" thing before, and
while there'
On Thu, Aug 30, 2012 at 7:58 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Ciaran McCreesh posted on Thu, 30 Aug 2012 21:11:02 +0100 as excerpted:
> Some minimum time/versions (say six months) before a PM drops support for
> it, on PM upgrades it starts warning about the coming drop of EAPI-X
> suppor
Mike Frysinger posted on Thu, 30 Aug 2012 19:46:21 -0400 as excerpted:
> On Thu, Aug 30, 2012 at 6:39 PM, Michał Górny wrote:
>> On Wed, 29 Aug 2012 18:18:20 -0400 Mike Frysinger wrote:
>>> On Wed, Aug 29, 2012 at 6:14 PM, Michał Górny wrote:
>>> > On Wed, 29 Aug 2012 18:05:19 -0400 Mike Frysinger
Ciaran McCreesh posted on Thu, 30 Aug 2012 21:11:02 +0100 as excerpted:
> On Thu, 30 Aug 2012 16:05:52 -0400 Michael Mol
> wrote:
>> Compile a list of existing ebuilds which depend on old EAPIs, and
>> you've got a TODO list. (eclasses, I don't know; I don't know if
>> eclasses explicitly express
On Thu, Aug 30, 2012 at 6:39 PM, Michał Górny wrote:
> On Wed, 29 Aug 2012 18:18:20 -0400 Mike Frysinger wrote:
>> On Wed, Aug 29, 2012 at 6:14 PM, Michał Górny wrote:
>> > On Wed, 29 Aug 2012 18:05:19 -0400 Mike Frysinger wrote:
>> >> On Wed, Aug 29, 2012 at 6:02 PM, Michał Górny wrote:
>> >> > On
On Thu, 30 Aug 2012 18:36:02 -0400
"Rick \"Zero_Chaos\" Farina" wrote:
> For things which are currently actually using adns, I believe
> migrating USE=adns to USE=libadns to allow users to specifically pick
> the (afaik deprecated) library.
I think you wanted to say 'things which are supporting
It's very simple. People will just ignore this if they disagree and
leave any "bump to EAPI-latest already" bugs unresolved forever.
On Wed, 29 Aug 2012 18:18:20 -0400
Mike Frysinger wrote:
> On Wed, Aug 29, 2012 at 6:14 PM, Michał Górny wrote:
> > On Wed, 29 Aug 2012 18:05:19 -0400 Mike Frysinger wrote:
> >> On Wed, Aug 29, 2012 at 6:02 PM, Michał Górny wrote:
> >> > On Wed, 29 Aug 2012 17:50:16 -0400 Mike Frysinger wrote:
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/30/2012 06:18 PM, Michał Górny wrote:
> On Mon, 27 Aug 2012 23:11:54 +0200
> Michał Górny wrote:
>
>> Both of the flags (except for gift AFAICS) refer to asynchronous DNS
>> resolution. Could we join them into one flag? I think we should retain
On Mon, 27 Aug 2012 23:11:54 +0200
Michał Górny wrote:
> Both of the flags (except for gift AFAICS) refer to asynchronous DNS
> resolution. Could we join them into one flag? I think we should retain
> 'adns', move appropriate 'ares' flags to it and modify the description
> to make it less library
On Thu, Aug 30, 2012 at 3:44 PM, Thomas Sachau wrote:
> Andreas K. Huettel schrieb:
>> Am Donnerstag, 30. August 2012, 12:59:07 schrieb hasufell:
>>> Could you elaborate what the reasons FOR it are (not that I don't know
>>> any, but you brought it up) since this will add work for every developer
On Thu, 30 Aug 2012 16:05:52 -0400
Michael Mol wrote:
> Compile a list of existing ebuilds which depend on old EAPIs, and
> you've got a TODO list. (eclasses, I don't know; I don't know if
> eclasses explicitly express EAPI compatibility in metadata) Once that
> list is cleared, yes, you can assum
On Thu, Aug 30, 2012 at 3:47 PM, Thomas Sachau wrote:
> Michael Mol schrieb:
>> On Thu, Aug 30, 2012 at 9:14 AM, Rich Freeman wrote:
>>> On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius wrote:
The primary benefit to the policy that dev's should bump EAPI when
bumping ebuilds is s
Michael Mol schrieb:
> On Thu, Aug 30, 2012 at 9:14 AM, Rich Freeman wrote:
>> On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius wrote:
>>>
>>> The primary benefit to the policy that dev's should bump EAPI when
>>> bumping ebuilds is so that older inferior EAPIs can be deprecated and
>>> eventual
Andreas K. Huettel schrieb:
> Am Donnerstag, 30. August 2012, 12:59:07 schrieb hasufell:
>> Could you elaborate what the reasons FOR it are (not that I don't know
>> any, but you brought it up) since this will add work for every developer
>> to check a) how the behavior of the new EAPI impacts the
On Thu, Aug 30, 2012 at 3:41 AM, Michał Górny wrote:
> On Wed, 29 Aug 2012 19:12:01 -0400 Mike Frysinger wrote:
>> On Wed, Aug 29, 2012 at 6:37 PM, Ciaran McCreesh wrote:
>> > On Wed, 29 Aug 2012 18:18:20 -0400 Mike Frysinger wrote:
>> >> does it actually ? are DEPEND variables not allowed to be
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 30/08/12 09:14 AM, Rich Freeman wrote:
> On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius
> wrote:
>>
>> The primary benefit to the policy that dev's should bump EAPI
>> when bumping ebuilds is so that older inferior EAPIs can be
>> deprecated
On Thu, Aug 30, 2012 at 9:14 AM, Rich Freeman wrote:
> On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius wrote:
>>
>> The primary benefit to the policy that dev's should bump EAPI when
>> bumping ebuilds is so that older inferior EAPIs can be deprecated and
>> eventually removed from the tree.
>
Am Donnerstag, 30. August 2012, 12:59:07 schrieb hasufell:
> Could you elaborate what the reasons FOR it are (not that I don't know
> any, but you brought it up) since this will add work for every developer
> to check a) how the behavior of the new EAPI impacts the current ebuild
> and b) how the b
On Thu, Aug 30, 2012 at 9:07 AM, Ian Stakenvicius wrote:
> I think you may miss the meaning of "should". It's not the same as
> "must".
Is it a policy or not? If it is a policy we can ignore at our own
discretion, then by all means pass it, and we can all do whatever we
like, as we already are.
On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius wrote:
>
> The primary benefit to the policy that dev's should bump EAPI when
> bumping ebuilds is so that older inferior EAPIs can be deprecated and
> eventually removed from the tree.
What is the benefit from removing the old EAPIs?
>
> Take, f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 30/08/12 09:04 AM, Rich Freeman wrote:
> On Thu, Aug 30, 2012 at 8:58 AM, Ian Stakenvicius
> wrote:
>> If you are rewriting a full ebuild as your solution, and the
>> ebuild you start with is EAPI<4 , then Markos would appreciate it
>> if you cha
On Thu, Aug 30, 2012 at 8:58 AM, Ian Stakenvicius wrote:
> If you are rewriting a full ebuild as your solution, and the ebuild
> you start with is EAPI<4 , then Markos would appreciate it if you
> changed the ebuild to be EAPI=4 (or whatever the latest EAPI is) in
> addition to the fix. Otherwise
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 30/08/12 08:30 AM, Rich Freeman wrote:
> On Thu, Aug 30, 2012 at 7:29 AM, Johannes Huber
> wrote:
>>
>> EAPI 0 is more readable than EAPI 4? No benefit for maintainer?
>> No benefit for user who wants to read the ebuild? Realy?
>
> Then why mak
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 30/08/12 08:37 AM, Michael Mol wrote:
> On Thu, Aug 30, 2012 at 7:29 AM, Johannes Huber
> wrote:
>
> [snip]
>
>>> Developers have only a limited amount of time, and this will
>>> eat into it. The result is likely to not be new shiny ebuilds
>>
On Thu, Aug 30, 2012 at 7:29 AM, Johannes Huber wrote:
[snip]
>> Developers have only a limited amount of time, and this will eat into
>> it. The result is likely to not be new shiny ebuilds that use the new
>> EAPIs, but rather old rusty ones that still use the old EAPI but also
>> which conta
On Thu, Aug 30, 2012 at 7:29 AM, Johannes Huber wrote:
>
> EAPI 0 is more readable than EAPI 4? No benefit for maintainer? No benefit for
> user who wants to read the ebuild? Realy?
Then why make it a policy?
If as you say there is a benefit to the maintainer, then you won't
have to hit them ove
> Could you elaborate what the reasons FOR it are (not that I don't know
> any, but you brought it up) since this will add work for every developer
> to check a) how the behavior of the new EAPI impacts the current ebuild
> and b) how the behvaior of inherited eclasses change depending on EAPI.
My
> I can't say I'm a big fan of this. This requires forcing changes to
> ebuilds that offer no actual benefit to either the maintainer or the
> end-users (changes that actually have some benefit to either are
> likely to be made anyway). The PM maintainers have chimed in that
> there is no benefit
On 08/30/2012 12:28 PM, Johannes Huber wrote:
> Hello gentoo devs,
>
> From last council meeting summary:
> [snip]
>> Open floor
>> ==
>> scarabeus suggested the change "dev should use latest eapi when bumping"
>> to "dev must use latest eapi when bumping if not forbidden by eclasses".
>>
On Thu, Aug 30, 2012 at 6:28 AM, Johannes Huber wrote:
>> scarabeus suggested the change "dev should use latest eapi when bumping"
>> to "dev must use latest eapi when bumping if not forbidden by eclasses".
>> He was asked to bring it up on the mailing lists, to get a better
>> definition of when
Hello gentoo devs,
>From last council meeting summary:
[snip]
> Open floor
> ==
> scarabeus suggested the change "dev should use latest eapi when bumping"
> to "dev must use latest eapi when bumping if not forbidden by eclasses".
> He was asked to bring it up on the mailing lists, to get a
Tobias Klausmann posted on Thu, 30 Aug 2012 09:03:59 +0200 as excerpted:
> On Thu, 30 Aug 2012, Duncan wrote:
>> Now, for worst-case comparison, on the same machine, what's the
>> respective times for a full systemd build? (I'm not saying actually
>> merge it, just configure/compile, plus see the
On Wed, 29 Aug 2012 15:17:48 -0700
Diego Elio Pettenò wrote:
> On 29/08/2012 15:16, Michał Górny wrote:
> >>> > > Also, some people are probably going to try to get some
> >>> > > pkgconf support directly into gcc, in form of '-something
> >>> > > libfoo' to make it grab everything magically, I t
On 8/28/2012 4:05 PM, Diego Elio Pettenò wrote:
On 28/08/2012 15:36, Mart Raudsepp wrote:
static-libs is for installing static libraries IN ADDITION to shared
libraries, not instead.
USE=static is for what you have in mind there.
PE is not the same as ELF so on Windows you either build one or t
On Wed, 29 Aug 2012 19:12:01 -0400
Mike Frysinger wrote:
> On Wed, Aug 29, 2012 at 6:37 PM, Ciaran McCreesh wrote:
> > On Wed, 29 Aug 2012 18:18:20 -0400 Mike Frysinger wrote:
> >> does it actually ? are DEPEND variables not allowed to be
> >> expanded in pkg_* src_* funcs ?
> >
> > Nope. We don
On Thu, Aug 30, 2012 at 1:12 AM, Mike Frysinger wrote:
> On Wed, Aug 29, 2012 at 6:37 PM, Ciaran McCreesh wrote:
>> On Wed, 29 Aug 2012 18:18:20 -0400 Mike Frysinger wrote:
>>> does it actually ? are DEPEND variables not allowed to be expanded in
>>> pkg_* src_* funcs ?
>>
>> Nope. We don't guara
Hi!
On Thu, 30 Aug 2012, Duncan wrote:
> Now, for worst-case comparison, on the same machine, what's the
> respective times for a full systemd build? (I'm not saying actually
> merge it, just configure/compile, plus see the next paragraph.)
I think my first set of numbers illustrates that: ju
38 matches
Mail list logo
