On Thursday 28 May 2009 07:46:36 Tiziano Müller wrote:
> And here is why (I'm only looking at the non-degenerated case with valid
> metadata, ignoring overlays which some consider a corner case (I don't
> understand that argument, but that's another thing)):
overlays tend to come without metadata
В Чтв, 14/05/2009 в 03:32 +0300, Mart Raudsepp пишет:
> Project maintainer-wanted
> =
Mart, I think that it's good idea to create such project but with a
different goals. I think currently maintainer-wanted alias is missed by
most developers: new packages are assigned there
Am Dienstag, den 19.05.2009, 19:01 +0200 schrieb Ulrich Mueller:
> > On Mon, 18 May 2009, Ciaran McCreesh wrote:
>
> > On Mon, 18 May 2009 06:59:36 +0200
> > Ulrich Mueller wrote:
> >> AFAICS, there _is_ an ambiguity. You can have the following two
> >> ebuilds in the tree, simultaneously:
>
On 11-03-2009 18:26:33 -0400, Mike Frysinger wrote:
> > > as for the ebuilds, those lines should be dropped completely. ive been
> > > dropping them in newer versions of the packages rather than going back
> > > and deleting them all by hand ...
> >
> > Aha, that explains why this recently started
Am Donnerstag, den 28.05.2009, 09:23 +0200 schrieb Patrick Lauer:
> On Thursday 28 May 2009 07:46:36 Tiziano Müller wrote:
>
> > And here is why (I'm only looking at the non-degenerated case with valid
> > metadata, ignoring overlays which some consider a corner case (I don't
> > understand that a
> On Thu, 28 May 2009, Tiziano Müller wrote:
>> ${PORTDIR}/app-misc/foo/foo-1a_live.ebuild
>> ${PORTDIR}/app-misc/foo-1a/foo-1a-live.ebuild
> you probably mean:
> ${PORTDIR}/app-misc/foo-1a/foo-1a.live.ebuild
No, I mean what I had written, namely to use an underscore as
separator, i.e., "_li
2009/5/28 Ulrich Mueller :
>> On Thu, 28 May 2009, Tiziano Müller wrote:
>
>>> ${PORTDIR}/app-misc/foo/foo-1a_live.ebuild
>>> ${PORTDIR}/app-misc/foo-1a/foo-1a-live.ebuild
>
>> you probably mean:
>> ${PORTDIR}/app-misc/foo-1a/foo-1a.live.ebuild
>
> No, I mean what I had written, namely to use a
On Wed, 2009-05-27 at 12:46 +, Ferris McCormick wrote:
> On Tue, 2009-05-26 at 20:57 +0200, Tiziano Müller wrote:
> > This is your friendly reminder! Same bat time (typically the 2nd & 4th
> > Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
> > irc.freenode.net) !
> >
>
We've discussed it and ulm will be next in line for council since
dberkholz retiring.
We shared a place with ulm on the list.
Good luck ulm, thanks, Samuli
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Piotr Jaroszyński wrote:
> 2009/5/28 Ulrich Mueller :
>>> On Thu, 28 May 2009, Tiziano Müller wrote:
${PORTDIR}/app-misc/foo/foo-1a_live.ebuild
${PORTDIR}/app-misc/foo-1a/foo-1a-live.ebuild
>>> you probably mean:
>>> ${PORTDIR}/app-misc/f
2009/5/28 Marijn Schouten (hkBst) :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Piotr Jaroszyński wrote:
>> 2009/5/28 Ulrich Mueller :
On Thu, 28 May 2009, Tiziano Müller wrote:
> ${PORTDIR}/app-misc/foo/foo-1a_live.ebuild
> ${PORTDIR}/app-misc/foo-1a/foo-1a-live.ebuild
>
Hi,
As far as I can see, the basic problem with EAPI is that in EAPI 0 it
isn't specified how to specify the EAPI for an ebuild to be known at
pre-filename-parse-, pre-source- and post-source-time.
Ancient PM do not assume that there might be ebuilds they do not
understand. They only know how to d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2009.05.28 06:46, Tiziano Müller wrote:
[snip]
> I did some analysis on that. The result is that the the performance
> penalty of not having the EAPI not in the filename depends on various
> factors. But it is for sure that there is a performance pe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 28 May 2009 18:56:00 +0100
Roy Bamford wrote:
> As I understand this, it may add six seconds to an emerge world while
> the dep tree is calculated. Lets say it takes an hour to do emerge
> world, the time has increased from 3600 seconds to 3
On Thu, 28 May 2009 08:28:12 +0200
Patrick Lauer wrote:
> - Try to avoid subjective statements. Statements like "C++ feels
> better" don't add anything to the discussion and are objectively
> wrong for me, so they have no place in a technical discussion
You mean like "EAPI in the filename feels b
On Thursday 28 May 2009 20:04:18 Ciaran McCreesh wrote:
> On Thu, 28 May 2009 18:56:00 +0100
>
> Roy Bamford wrote:
> > As I understand this, it may add six seconds to an emerge world while
> > the dep tree is calculated. Lets say it takes an hour to do emerge
> > world, the time has increased fro
On Thu, May 28, 2009 at 11:14 AM, Ciaran McCreesh
wrote:
> On Thu, 28 May 2009 08:28:12 +0200
> Patrick Lauer wrote:
>> - Try to avoid subjective statements. Statements like "C++ feels
>> better" don't add anything to the discussion and are objectively
>> wrong for me, so they have no place in a
On Thu, 28 May 2009 20:30:44 +0200
Patrick Lauer wrote:
> > Interactive time is important. If it were adding those extra
> > seconds to the build, no-one would care. But it's not. It's adding
> > them to when the user's sitting at the screen waiting for results.
>
> So how about we improve the st
On Thursday 28 May 2009 20:14:57 Ciaran McCreesh wrote:
> On Thu, 28 May 2009 08:28:12 +0200
>
> Patrick Lauer wrote:
> > - Try to avoid subjective statements. Statements like "C++ feels
> > better" don't add anything to the discussion and are objectively
> > wrong for me, so they have no place in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2009.05.28 19:36, Alec Warner wrote:
[snip]
>
> The community could of course just deny the features that require
> glep55 (no bash4, no global scope changes, etc..) I guess the
> community is doing that by default anyway by repeated discussing th
On Thu, 28 May 2009 20:49:54 +0200
Patrick Lauer wrote:
> Now you may still think (subjective thing, that) that glep55 is the
> best solution. And I, with the same subjectivity, think it isn't.
GLEP 55 shows that other solutions require either a design-enforced
performance penalty or remove the a
Alec Warner wrote:
>> No, it's entirely objective. GLEP 55 clearly shows how the filename
>> based options are objectively better than anything else.
>
> But the decision will not be based entirely on objective merits
> (although I will concede that EAPI in filename is the 'best' technical
> choic
You know, usually snipping away everything else is a bit evil because it
removes context, but in this case I just want to point out one or two little
pieces ...
I almost feel bad for writing so many emails to this list.
On Thursday 28 May 2009 20:48:45 Ciaran McCreesh wrote:
> > For example a r
On Thu, 28 May 2009 21:19:35 +0200
Patrick Lauer wrote:
> You know, usually snipping away everything else is a bit evil because
> it removes context, but in this case I just want to point out one or
> two little pieces ...
Because you know fine well I'm right, but want to carry on trying to
derai
2009/5/28 Joe Peterson :
> Alec Warner wrote:
>>> No, it's entirely objective. GLEP 55 clearly shows how the filename
>>> based options are objectively better than anything else.
>>
>> But the decision will not be based entirely on objective merits
>> (although I will concede that EAPI in filename
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2009.05.28 20:26, Ciaran McCreesh wrote:
[snip]
> > I think I have pointed you a few times at objective statements
> > disagreeing with your subjective opinion. I hate repeating myself.
>
> And yet you keep ignoring the part where GLEP 55 demonstr
On Thu, 28 May 2009 12:42:02 -0700
Josh Saddler wrote:
> GLEP55 has not effectively shown that there *is* a problem, otherwise
> we wouldn't have had months of discussion on that topic.
Uh. Did you miss the part where we need global scope changes in ebuilds?
--
Ciaran McCreesh
signature.asc
D
On Thursday 28 May 2009 21:26:43 Ciaran McCreesh wrote:
> On Thu, 28 May 2009 21:19:35 +0200
>
> Patrick Lauer wrote:
> > You know, usually snipping away everything else is a bit evil because
> > it removes context, but in this case I just want to point out one or
> > two little pieces ...
>
> Bec
On Thu, 28 May 2009 21:46:48 +0200
Patrick Lauer wrote:
> > And just how do you plan to enforce that? What measures will you
> > take to ensure that there's no way for developers or users to
> > modify the repository?
> I can think of many simple methods. Like a tarball with a checksum.
...which
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 28 May 2009 20:42:30 +0100
Roy Bamford wrote:
> I don't see any objective measurements of performace in GLEP 55
> either. perhaps you could point me to a version and pargraph in GLEP
> that details these benchmarks ?
It's not a question of be
On Thursday 28 May 2009 21:52:49 Ciaran McCreesh wrote:
> On Thu, 28 May 2009 21:46:48 +0200
>
> Patrick Lauer wrote:
> > > And just how do you plan to enforce that? What measures will you
> > > take to ensure that there's no way for developers or users to
> > > modify the repository?
> >
> > I ca
On Thu, 28 May 2009 22:56:46 +0200
Patrick Lauer wrote:
> So, basically, we can't do anything, because the universe might
> spontaneously decide to cease to exist. Quite scary, that.
No. What we do is don't design a fragile solution. We design a solution
that can handle users doing what we reaso
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2009.05.28 20:54, Ciaran McCreesh wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Thu, 28 May 2009 20:42:30 +0100
> Roy Bamford wrote:
> > I don't see any objective measurements of performace in GLEP 55
> > either. perhaps you coul
On Thu, 28 May 2009 08:28:12 +0200
Patrick Lauer wrote:
> This is becoming a rather lengthy email ping pong, but as people seem to be
> unable to discuss things I had to highlight a few issues there.
I'm sorry to be rude, but ever consider that the reason people keep repeating
things to you is
Ciaran McCreesh posted
20090528191457.21ab4...@snowcone, excerpted below, on Thu, 28 May 2009
19:14:57 +0100:
> No, it's entirely objective. GLEP 55 clearly shows how the filename
> based options are objectively better than anything else.
Now that's just being facetious.
--
Duncan - List repl
35 matches
Mail list logo
