On 9 March 2012 06:30, Jeroen Roovers wrote:
> On Thu, 8 Mar 2012 17:14:58 +
> Ciaran McCreesh wrote:
>
>> Having a different, special rule for something that looks exactly like
>> lots of other things that do not have that different, special rule is
>> hardly hair splitting. This rule would
El vie, 09-03-2012 a las 21:15 +0100, Pacho Ramos escribió:
> El vie, 09-03-2012 a las 22:02 +0200, Samuli Suominen escribió:
> > On 03/09/2012 09:48 PM, Pacho Ramos wrote:
> > > El vie, 09-03-2012 a las 16:57 +0100, Michał Górny escribió:
> > >> On Fri, 09 Mar 2012 09:02:23 +0100
> > >> Pacho Ramo
El vie, 09-03-2012 a las 22:02 +0200, Samuli Suominen escribió:
> On 03/09/2012 09:48 PM, Pacho Ramos wrote:
> > El vie, 09-03-2012 a las 16:57 +0100, Michał Górny escribió:
> >> On Fri, 09 Mar 2012 09:02:23 +0100
> >> Pacho Ramos wrote:
> >>
> >>> El dom, 04-03-2012 a las 13:56 +0100, Pacho Ramos
On 03/09/12 13:56, Zac Medico wrote:
> On 03/09/2012 10:33 AM, Michael Orlitzky wrote:
>> On 03/09/12 13:02, James Broadhead wrote:
>>> On 9 March 2012 17:31, Michael Orlitzky wrote:
At any rate, I'm now convinced that we all want GLEP 55, but with a
different name.
>>>
>>> I think that
On 03/09/2012 09:48 PM, Pacho Ramos wrote:
El vie, 09-03-2012 a las 16:57 +0100, Michał Górny escribió:
On Fri, 09 Mar 2012 09:02:23 +0100
Pacho Ramos wrote:
El dom, 04-03-2012 a las 13:56 +0100, Pacho Ramos escribió:
El dom, 04-03-2012 a las 13:51 +0100, Pacho Ramos escribió:
El dom, 04-03
El vie, 09-03-2012 a las 16:57 +0100, Michał Górny escribió:
> On Fri, 09 Mar 2012 09:02:23 +0100
> Pacho Ramos wrote:
>
> > El dom, 04-03-2012 a las 13:56 +0100, Pacho Ramos escribió:
> > > El dom, 04-03-2012 a las 13:51 +0100, Pacho Ramos escribió:
> > > > El dom, 04-03-2012 a las 13:47 +0100,
On Fri, 09 Mar 2012 10:56:03 -0800
Zac Medico wrote:
> Every software product has an end of life. I think if a system hasn't
> been updated in the last 2 years or so, then it's fair to assume that
> it will never be updated. So, all relevant versions of portage should
> simply show a warning messa
On Fri, 09 Mar 2012 11:49:44 -0500
Michael Orlitzky wrote:
> >> isnt the whole point of the proposal to get eapi without sourcing ?
> >>
> >> so that we can use new bash features at local or global scope
> >> without risking that people with an old bash get syntax errors
> >> trying to get the eap
On Fri, Mar 9, 2012 at 12:47 PM, Zac Medico wrote:
> Anyway, lets focus on our main goal, which is to decide on a way to
> obtain the EAPI _without_ sourcing the ebuild.
Agreed. Plus, an approach that either uses the filename or something
like a comment line is also going to be much more flexibl
On 03/09/2012 10:33 AM, Michael Orlitzky wrote:
> On 03/09/12 13:02, James Broadhead wrote:
>> On 9 March 2012 17:31, Michael Orlitzky wrote:
>>> At any rate, I'm now convinced that we all want GLEP 55, but with a
>>> different name.
>>
>> I think that moving the data to the filename is probably a
On 03/09/12 13:02, James Broadhead wrote:
> On 9 March 2012 17:31, Michael Orlitzky wrote:
>> At any rate, I'm now convinced that we all want GLEP 55, but with a
>> different name.
>
> I think that moving the data to the filename is probably a better
> approach than semi- or repeat parsing, but I
On 03/09/2012 10:24 AM, Alexis Ballier wrote:
> On Fri, 9 Mar 2012 18:02:51 +
> James Broadhead wrote:
>
>> On 9 March 2012 17:31, Michael Orlitzky wrote:
>>> At any rate, I'm now convinced that we all want GLEP 55, but with a
>>> different name.
>>
>> I think that moving the data to the fil
On Fri, 9 Mar 2012 18:02:51 +
James Broadhead wrote:
> On 9 March 2012 17:31, Michael Orlitzky wrote:
> > At any rate, I'm now convinced that we all want GLEP 55, but with a
> > different name.
>
> I think that moving the data to the filename is probably a better
> approach than semi- or re
On 03/09/12 12:47, Zac Medico wrote:
>
> Ulrich is talking about extensions which require a newer version of
> bash. These kinds of extensions are quite common and don't cause
> "massive breaking" because people simply have to upgrade bash in order
> to use the new extensions, and their old script
On 9 March 2012 17:31, Michael Orlitzky wrote:
> At any rate, I'm now convinced that we all want GLEP 55, but with a
> different name.
I think that moving the data to the filename is probably a better
approach than semi- or repeat parsing, but I prefer preserving the
.ebuild extension, and think
On Fri, 09 Mar 2012 12:31:24 -0500
Michael Orlitzky wrote:
> On 03/09/12 12:11, Ulrich Mueller wrote:
> >> On Fri, 09 Mar 2012, Michael Orlitzky wrote:
> >
> >>> What if bash starts to parse the script completely and barfs at
> >>> 'syntax error' before it starts executing stuff?
> >
> >> I
On 03/09/2012 09:31 AM, Michael Orlitzky wrote:
> On 03/09/12 12:11, Ulrich Mueller wrote:
>>> On Fri, 09 Mar 2012, Michael Orlitzky wrote:
>>
What if bash starts to parse the script completely and barfs at
'syntax error' before it starts executing stuff?
>>
>>> It doesn't parse the s
On 03/09/12 12:11, Ulrich Mueller wrote:
>> On Fri, 09 Mar 2012, Michael Orlitzky wrote:
>
>>> What if bash starts to parse the script completely and barfs at
>>> 'syntax error' before it starts executing stuff?
>
>> It doesn't parse the script completely, it executes line-by-line, so
>> we c
> On Fri, 09 Mar 2012, Michael Orlitzky wrote:
>> What if bash starts to parse the script completely and barfs at
>> 'syntax error' before it starts executing stuff?
> It doesn't parse the script completely, it executes line-by-line, so
> we can bail out early.
How can you tell that this beh
On 03/09/2012 08:49 AM, Michael Orlitzky wrote:
> The point was to be able to get the EAPI without crashing if the ebuild
> uses newer features. If you can get the EAPI without sourcing, that
> obviously accomplishes the goal. But there are other goals, too, like
> not limiting the syntax of the EA
On 03/09/12 11:29, Michał Górny wrote:
>
> What if bash starts to parse the script completely and barfs at 'syntax
> error' before it starts executing stuff?
>
It doesn't parse the script completely, it executes line-by-line, so we
can bail out early.
This returns 1:
exit 1
QWE*$)@#$%IT@$
On 03/09/12 10:58, Zac Medico wrote:
> On 03/09/2012 07:51 AM, Alexis Ballier wrote:
>> On Fri, 09 Mar 2012 07:41:09 -0800
>> Zac Medico wrote:
>>
>>> On 03/09/2012 07:21 AM, Michael Orlitzky wrote:
The advantage that the eapi function has over a comment is that
it's not magic -- it's ju
On 03/09/2012 08:33 AM, Eray Aslan wrote:
> On Fri, Mar 09, 2012 at 08:15:11AM -0800, Zac Medico wrote:
>> They may or may not have issues. Our goal is to minimize our
>> vulnerability to these kinds of issues as much as possible. Being able
>> to obtain the ebuild EAPI without the expense of sourc
On Fri, Mar 09, 2012 at 08:15:11AM -0800, Zac Medico wrote:
> They may or may not have issues. Our goal is to minimize our
> vulnerability to these kinds of issues as much as possible. Being able
> to obtain the ebuild EAPI without the expense of sourcing it is one
> small step toward this goal.
E
On Fri, 09 Mar 2012 00:35:14 -0500
Michael Orlitzky wrote:
> On 03/09/2012 12:04 AM, Michał Górny wrote:
> >>
> >> This is of course isomorphic to requiring a specific EAPI=4 format,
> >> but does allow you to do stupid things like x=`seq 4 4`; eapi $x;
> >> if you want.
> >
> > What advantage do
On 03/09/2012 07:52 AM, Ian Stakenvicius wrote:
> On 09/03/12 10:41 AM, Zac Medico wrote:
>> On 03/09/2012 07:21 AM, Michael Orlitzky wrote:
>>> The advantage that the eapi function has over a comment is that
>>> it's not magic -- it's just normal bash syntax. So we've
>>> addressed that issue at a
On Fri, Mar 9, 2012 at 16:57, Michał Górny wrote:
> For net-zope, I'd prefer dropping it. We decided to get rid of Zope,
> removed almost all relevant packages, so there's no point in keeping
> the herd.
+1.
Cheers,
Dirkjan
On 03/09/2012 07:51 AM, Alexis Ballier wrote:
> On Fri, 09 Mar 2012 07:41:09 -0800
> Zac Medico wrote:
>
>> On 03/09/2012 07:21 AM, Michael Orlitzky wrote:
>>> The advantage that the eapi function has over a comment is that
>>> it's not magic -- it's just normal bash syntax. So we've addressed
>>
On Fri, 09 Mar 2012 09:02:23 +0100
Pacho Ramos wrote:
> El dom, 04-03-2012 a las 13:56 +0100, Pacho Ramos escribió:
> > El dom, 04-03-2012 a las 13:51 +0100, Pacho Ramos escribió:
> > > El dom, 04-03-2012 a las 13:47 +0100, Pacho Ramos escribió:
> > > > Even if they have some people in their mail
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/03/12 10:41 AM, Zac Medico wrote:
> On 03/09/2012 07:21 AM, Michael Orlitzky wrote:
>> The advantage that the eapi function has over a comment is that
>> it's not magic -- it's just normal bash syntax. So we've
>> addressed that issue at a smal
On Fri, 09 Mar 2012 07:41:09 -0800
Zac Medico wrote:
> On 03/09/2012 07:21 AM, Michael Orlitzky wrote:
> > The advantage that the eapi function has over a comment is that
> > it's not magic -- it's just normal bash syntax. So we've addressed
> > that issue at a small performance cost (we're reall
# /home/ssuominen/gentoo-x86/profiles/package.mask:
# Samuli Suominen (09 Mar 2012)
# Fails to build with GCC-4.6 wrt #380767. A lot has changed
# in new version wrt #388543. Other bugs #354323, #354863,
# and #407183.
# Unless fixed, removal in 30 days.
app-pda/syncevolution
On 03/09/2012 07:21 AM, Michael Orlitzky wrote:
> The advantage that the eapi function has over a comment is that it's not
> magic -- it's just normal bash syntax. So we've addressed that issue at
> a small performance cost (we're really only sourcing the ebuild up to
> 'exit').
Also consider the
On 03/09/12 10:05, Zac Medico wrote:
>>
>> Surely we can source one or two lines of the ebuild safely, like the
>> example shows?
>
> Why would we though, when sourcing is a relatively costly operation, and
> there are much more efficient ways to get the EAPI?
There do not seem to be any that peo
On 03/09/2012 06:42 AM, Michael Orlitzky wrote:
> On 03/09/12 00:51, Zac Medico wrote:
>> On 03/08/2012 09:35 PM, Michael Orlitzky wrote:
>>> The function can do any crazy thing you want.
>>
>> We don't need a function. We need to know the EAPI before we source the
>> ebuild, and a function doesn't
On 03/09/12 00:51, Zac Medico wrote:
> On 03/08/2012 09:35 PM, Michael Orlitzky wrote:
>> The function can do any crazy thing you want.
>
> We don't need a function. We need to know the EAPI before we source the
> ebuild, and a function doesn't give us that.
Surely we can source one or two lines
* Zac Medico schrieb am 08.03.12 um 17:30 Uhr:
> On 03/08/2012 01:42 AM, Marc Schiffbauer wrote:
> > * Ulrich Mueller schrieb am 08.03.12 um 08:27 Uhr:
> >> Such constructs also cannot be used with any of the other proposed
> >> solutions. And in fact, nobody is using such things in practice.
> >>
El dom, 04-03-2012 a las 13:56 +0100, Pacho Ramos escribió:
> El dom, 04-03-2012 a las 13:51 +0100, Pacho Ramos escribió:
> > El dom, 04-03-2012 a las 13:47 +0100, Pacho Ramos escribió:
> > > Even if they have some people in their mail aliases, looks like herds
> > > are empty. If nobody volunteers
El mar, 06-03-2012 a las 11:46 +0100, Pacho Ramos escribió:
> I usually read messages in /var/log/portage/elog/summary.log to simply
> warn me about "es es_ES" LINGUAS not being supported by that package.
> That comes from eutils.eclass inside strip-linguas:
> ewarn "Sorry, but ${PN} does not suppo
39 matches
Mail list logo
