Am 06.06.19 um 17:28 schrieb Anthony G. Basile:
> Didn't we have some "archive" for old ebuilds? Maybe we can move
> it there.
What about an overlay for this purpose? Its like in real life they
come into life and leave the same way...
Despite that, I usually dig in the git repository when I
On 6/6/19 3:34 AM, Luca Barbato wrote:
> On 06/06/2019 09:05, Matt Turner wrote:
>> On Wed, Jun 5, 2019 at 11:39 PM Agostino Sarubbo wrote:
>>>
>>> On giovedì 6 giugno 2019 08:25:54 CEST Luca Barbato wrote:
Anybody has hardware to test it?
>>>
>>> I can do it on timberdoodle.
>>
>> The issue
On 06/06/2019 09:05, Matt Turner wrote:
On Wed, Jun 5, 2019 at 11:39 PM Agostino Sarubbo wrote:
On giovedì 6 giugno 2019 08:25:54 CEST Luca Barbato wrote:
Anybody has hardware to test it?
I can do it on timberdoodle.
The issue is that the package is for "OldWorld" Macs (like 20+ years
On Wed, Jun 5, 2019 at 11:39 PM Agostino Sarubbo wrote:
>
> On giovedì 6 giugno 2019 08:25:54 CEST Luca Barbato wrote:
> > Anybody has hardware to test it?
>
> I can do it on timberdoodle.
The issue is that the package is for "OldWorld" Macs (like 20+ years
old). We recently dropped the
On giovedì 6 giugno 2019 08:25:54 CEST Luca Barbato wrote:
> Anybody has hardware to test it?
I can do it on timberdoodle.
Agostino
On 06/06/2019 07:06, Andreas K. Huettel wrote:
Hi all,
for the package maintainers among you, here's the list of remaining EAPI=2
packages. Please help getting the number down to zero soon!!!
Cheers,
Andreas
sys-apps/powerpc-utils-1.1.3.18-r2
This is ancient in many different ways :)
Olivier Crête [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on Mon, 08
Dec 2008 19:43:42 -0500:
I'm not suggesting waiting any longer, just not pushing ebuilds into the
tree until we have a stable enough version of portage that handles them
(and if we do, then lets mark it as
warning from Userrel.
-Alec
[0] Subject: Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses
[1] http://www.gentoo.org/proj/en/council/coc.xml
Alec Warner [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted
below, on Fri, 10 Oct 2008 00:17:14 -0700:
Consider this your first and last warning from Userrel.
FWIW... at least on gmane, that appears as a response to aballier (gentoo
dev), with references headers indicating the same
On Fri, Oct 10, 2008 at 5:41 AM, Duncan [EMAIL PROTECTED] wrote:
Alec Warner [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted
below, on Fri, 10 Oct 2008 00:17:14 -0700:
Consider this your first and last warning from Userrel.
FWIW... at least on gmane, that appears as a response to
I don't quite see how that deals with an eclass calling econf in its
exported src_compile? Seems like EAPI versioning for eclasses (with
implicit 0 only) is more what you're after for that issue (so the PM
could suppress src_configure if src_compile is going to resolve to an
EAPI-0 eclass
Alexis Ballier wrote:
Indeed; different names could be given to different implementations of
the same thing, but that might completely kill the point of abstracting
it.
Maybe eclasses should die on unknown eapi; the fact is I really hate the
current way it's done when switching an ebuild to
On Tue, 07 Oct 2008 17:07:21 +0100
Steve Long [EMAIL PROTECTED] wrote:
It's illegal, according to PMS. It also won't work with Paludis,
since phase function definitions aren't made available until just
before that phase executes (there is a reason for this -- it
provides us with a way of
Ciaran McCreesh wrote:
On Sun, 5 Oct 2008 17:38:11 +0200
Ulrich Mueller [EMAIL PROTECTED] wrote:
By the way, do we really want to special case eapi-2 in every
eclass ? That's lot of code duplication and will get even worse
when we'll reach eapi-42. That would have been cool to have a pm
On Tue, Oct 07, 2008 at 05:07:21PM +0100, Steve Long wrote:
Ciaran McCreesh wrote:
On Sun, 5 Oct 2008 17:38:11 +0200
Ulrich Mueller [EMAIL PROTECTED] wrote:
By the way, do we really want to special case eapi-2 in every
eclass ? That's lot of code duplication and will get even worse
Carsten Lohrke [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on Sun, 14 Sep 2008
16:21:03 +0200:
What I do strongly oppose is changing the meaning of the '!' symbol, as
blockers, which should remain real blockers will not be adjusted by us,
when changing an ebuild to EAPI 2++
On Wed, 11 Jun 2008 14:20:03 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Santiago M. Mola wrote:
Upstream clearly states that a gmp build which tests have failed
shouldn't be used. I bet they deny support for users who fail to
follow that indication ;-)
gmp isn't a key component if you
On Wed, 11 Jun 2008 01:42:34 +0200
Bo Ørsted Andresen [EMAIL PROTECTED] wrote:
Err.. Maybe this could have been phrased better but then I did expect
you would look at the bug before commenting. The idea is to enable
tests by default in EAPI 2 and beyond and let them stay off by
default in EAPI
On Tue, 10 Jun 2008 23:16:04 -0600
Ryan Hill [EMAIL PROTECTED] wrote:
if people are just going to RESTRICT tests when they fail (and they
will, because it's a hell of a lot easier than actually fixing them),
what's the point of having a testsuite at all? and once a testsuite is
restricted,
19 matches
Mail list logo
