Rich Freeman posted on Mon, 29 Apr 2013 19:12:37 -0400 as excerpted:
> This whole thing seems best chalked up to well-intending people making
> omissions (maybe), and the virtue of competent developers who don't just
> blindly follow the spec when it doesn't make sense.
Actually, much as it's wid
On Wed, 3 Apr 2013 18:36:07 +0200
Michał Górny wrote:
> On Wed, 3 Apr 2013 11:14:37 +0200
> Michał Górny wrote:
>
> > Therefore, I ask you: how should we name the new (and simpler) patch
> > applying function which will be provided in EAPI 6?
>
> My propositions:
>
> - apply_patches ...
> - a
On Sat, 6 Apr 2013 20:08:43 +0200
Michał Górny wrote:
> Hello,
>
> As far as I'm aware, we don't really have much of a patch maintenance
> policy in Gentoo. There a few loose rules like «don't put awfully big
> files into FILESDIR» or the common sense «use unified diff», but no
> complete and cl
On Wed, 24 Apr 2013 00:24:13 +0800
Ben de Groot wrote:
>On 23 April 2013 11:58, Ryan Hill wrote:
> > On the other hand, you applied infinality, so you're not on my favorite
> > people
> > list either. :P
> We'll need to agree to disagree then. Anyway, no one was taking care of
> freetype
> an
On 04/30/13 01:12, Rich Freeman wrote:
> On Mon, Apr 29, 2013 at 6:27 PM, Ciaran McCreesh
> wrote:
>> What ultimately got approved by the Council, and what implementers
>> should be following, is the wording which ended up in PMS.
>>
> I can't speak for everywhere, but even in the highly regulated
On Mon, Apr 29, 2013 at 6:27 PM, Ciaran McCreesh
wrote:
> What ultimately got approved by the Council, and what implementers
> should be following, is the wording which ended up in PMS.
>
I can't speak for everywhere, but even in the highly regulated
environment I work in, an error in a specifica
On Tue, 30 Apr 2013 00:22:23 +0200
Ulrich Mueller wrote:
> > On Mon, 29 Apr 2013, Ciaran McCreesh wrote:
> >> In the discussions that led to inclusion of the feature in EAPI 4,
> >> it was implicit that it would be possible to override the default.
> >> This can only work if "$@" goes after al
> On Mon, 29 Apr 2013, Ciaran McCreesh wrote:
>> In the discussions that led to inclusion of the feature in EAPI 4, it
>> was implicit that it would be possible to override the default. This
>> can only work if "$@" goes after all default options.
> But that wasn't got approved by the Council
On Mon, 29 Apr 2013 22:53:30 +0200
Ulrich Mueller wrote:
> > As you can see in the bug, we're not discussing anything related to
> > EAPI 0 behaviour, so this argument is irrelevant. We're discussing a
> > change in a later EAPI, where the change had nothing to say about
> > ordering.
>
> In the
> On Mon, 29 Apr 2013, Ciaran McCreesh wrote:
> On Mon, 29 Apr 2013 14:36:41 -0400
> Mike Frysinger wrote:
>> portage has always inserted implicit args before the args given by
>> the ebuild to econf. PMS omitting the ordering information is
>> simply an oversight to be clarified, not functio
On Mon, Apr 29, 2013 at 3:28 PM, Mike Frysinger wrote:
>
> claiming breakage is a red herring. i'll wager that clarifying PMS to match
> realistic intentions and the largest PM won't break a single package.
> appending args over the econf args is asinine.
If many packages actually break with the
On Monday 29 April 2013 15:17:40 Ciaran McCreesh wrote:
> On Mon, 29 Apr 2013 21:09:36 +0200 Michał Górny wrote:
> > > As you can see in the bug, we're not discussing anything related to
> > > EAPI 0 behaviour, so this argument is irrelevant. We're discussing
> > > a change in a later EAPI, where t
On Mon, 29 Apr 2013 21:09:36 +0200
Michał Górny wrote:
> > As you can see in the bug, we're not discussing anything related to
> > EAPI 0 behaviour, so this argument is irrelevant. We're discussing
> > a change in a later EAPI, where the change had nothing to say about
> > ordering.
>
> There's a
On Mon, 29 Apr 2013 19:49:17 +0100
Ciaran McCreesh wrote:
> On Mon, 29 Apr 2013 14:36:41 -0400
> Mike Frysinger wrote:
> > On Monday 29 April 2013 01:55:49 Michał Górny wrote:
> > > Now, what are your thoughts? Shall we fix PMS to explicitly state
> > > the argument order or implement ugly hacks
On Mon, 29 Apr 2013 14:36:41 -0400
Mike Frysinger wrote:
> On Monday 29 April 2013 01:55:49 Michał Górny wrote:
> > Now, what are your thoughts? Shall we fix PMS to explicitly state
> > the argument order or implement ugly hacks in ebuilds?
>
> portage has always inserted implicit args before the
On Monday 29 April 2013 01:55:49 Michał Górny wrote:
> Now, what are your thoughts? Shall we fix PMS to explicitly state
> the argument order or implement ugly hacks in ebuilds?
portage has always inserted implicit args before the args given by the ebuild
to econf. PMS omitting the ordering info
On Mon, 29 Apr 2013 16:14:51 +0900
heroxbd wrote:
> KEYWORDS="~hppa-hpux ~m68k-mint ~ppc-aix ~x64-solaris ~x86-interix["]
>
> KEYWORDS_ARCH="~alpha ~amd64 ~arm ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64
> ~s390 ~sh ~sparc ~x86"
Regardless of your chance of success in making the extra complexity
manage
On Sun, Apr 28, 2013 at 11:33 PM, Ryan Hill wrote:
> On Thu, 25 Apr 2013 17:12:05 +0200
> Peter Stuge wrote:
>
>> Diego Elio Pettenò wrote:
>> > The correct one should be xslt and that's it..
>>
>> Can you please motivate your opinion? Saying "that's it" is quite hostile.
>
> Terse maybe. Blunt.
Hi Ben,
Ben de Groot writes:
> To me this looks to be needlessly complex.
There is an alternative way to do this:
@-linux
to mean "the ebuild works on every keyworded arch on Prefix with Linux
kernel".
Cheers,
Benda
Dearr Fabian,
Fabian Groffen writes:
>> Furthermore if the ebuild has "amd64" keyword, it will certainly
>> build on amd64-linux too.
>
> Somewhat likely, but absolutely not true.
Sorry, the original phrase was vague. I meant, if an ebuild is keyworded
"amd64" and "x86-linux", it will certainly
On 29 April 2013 06:55, Michał Górny wrote:
> Hi,
>
> As you haven't expected at all, the PMS is a specific spec which
> doesn't document much of common sense. Therefore, the way econf is
> currently declared leaves the freedom of adding its arguments anywhere
> in the ./configure invocation [1].
On 29 April 2013 15:14, heroxbd wrote:
>
> Dear all,
>
> In GLEP22[1], reasonable defaults has been introduced to prevent the
> explosion of keywords. With the growth of Gentoo Prefix, however, a
> substantial amount of keywords are introduced. Among them, duplex
> information exists. For example,
Hi,
On 29-04-2013 16:14:51 +0900, heroxbd wrote:
> In GLEP22[1], reasonable defaults has been introduced to prevent the
> explosion of keywords. With the growth of Gentoo Prefix, however, a
> substantial amount of keywords are introduced. Among them, duplex
> information exists. For example, an eb
Dear all,
In GLEP22[1], reasonable defaults has been introduced to prevent the
explosion of keywords. With the growth of Gentoo Prefix, however, a
substantial amount of keywords are introduced. Among them, duplex
information exists. For example, an ebuild keyworded x86-linux(Gentoo
Prefix on x86 l
24 matches
Mail list logo
