On Thursday 21 June 2012 03:00:39 Ciaran McCreesh wrote:
> In case you're not aware, the first time Gentoo did multilib, it was
> done as a series of random changes to Portage that no-one really
> thought through or understood. As you can see, that didn't work...
yes yes, it's very easy to throw r
On Thursday 21 June 2012 08:11:27 Homer Parker wrote:
> On Thu, 2012-06-21 at 08:00 +0100, Ciaran McCreesh wrote:
> > In case you're not aware, the first time Gentoo did multilib, it was
> > done as a series of random changes to Portage that no-one really
> > thought through or understood. As you c
On Wednesday 20 June 2012 16:25:30 Richard Yao wrote:
> Multilib (and/or multiarch) support
Thomas already has multilib documents put together for review. multiarch
doesn't make sense for us, and even if it did, there's no way it'd be spec-ed
out in a reasonable time frame for EAPI=5 (or even 6
On Wednesday 20 June 2012 16:39:42 Maxim Kammerer wrote:
> On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao wrote:
> > Multilib (and/or multiarch) support
>
> Sorry for a possibly ignorant question. Does multilib support include
> the ability to build Busybox against uclibc (on a glibc system)?
i'm
El sáb, 23-06-2012 a las 13:16 +0100, Ciaran McCreesh escribió:
> On Sat, 23 Jun 2012 14:11:28 +0200
> Pacho Ramos wrote:
> > Looks like you have now opted to use Brian's comment as a kind of
> > "shield" of similar and discuss only about multilib, even when this
> > thread was more general and we
On Sat, 23 Jun 2012 14:16:13 +0200
Pacho Ramos wrote:
> What we *also* need is to document this requirements to let people
> present that work directly instead of losing days figuring out what is
> needed or what not
The requirement is that the PMS team needs to be able to understand the
proposal
On Sat, 23 Jun 2012 14:11:28 +0200
Pacho Ramos wrote:
> Looks like you have now opted to use Brian's comment as a kind of
> "shield" of similar and discuss only about multilib, even when this
> thread was more general and we were talking to the problems shown in
> recent discussions (from forcing
El sáb, 23-06-2012 a las 12:59 +0100, Ciaran McCreesh escribió:
> On Sat, 23 Jun 2012 13:52:24 +0200
> Peter Stuge wrote:
> > Ciaran McCreesh wrote:
> > > bring this to the point where we can say something other than
> > > "huh?".
> >
> > You can accelerate by making one guess about each thing on
El sáb, 23-06-2012 a las 12:37 +0100, Ciaran McCreesh escribió:
> On Sat, 23 Jun 2012 13:38:09 +0200
> Peter Stuge wrote:
> > If you don't understand something of what thus far has been written,
> > then why not ask specific questions to fill those gaps, and move on?
>
> The multilib material isn
On Sat, 23 Jun 2012 13:52:24 +0200
Peter Stuge wrote:
> Ciaran McCreesh wrote:
> > bring this to the point where we can say something other than
> > "huh?".
>
> You can accelerate by making one guess about each thing on the list
> and asking for confirmation of your guess.
>
> It sounds silly, b
Ciaran McCreesh wrote:
> bring this to the point where we can say something other than "huh?".
You can accelerate by making one guess about each thing on the list
and asking for confirmation of your guess.
It sounds silly, but I realized that this actually happens all the
time offline - at least
On Sat, 23 Jun 2012 13:38:09 +0200
Peter Stuge wrote:
> If you don't understand something of what thus far has been written,
> then why not ask specific questions to fill those gaps, and move on?
The multilib material isn't at the point where specific questions can be
asked. Brian's description o
Ciaran McCreesh wrote:
> > Making constructive suggestions instead of others that can be
> > easily interpreted as whims is the way to go.
>
> Uh huh, and that's what I've been doing the whole time when I've
> been asking for a patch for PMS, a GLEP etc.
..
> requests for a better description we'r
On Sat, 23 Jun 2012 13:05:51 +0200
Pacho Ramos wrote:
> > http://archives.gentoo.org/gentoo-dev/msg_86b67d8ab51a24922a3d3be75d10f42b.xml
>
> That shows how things can be done and how shouldn't be done, it's not
> casual that you are always involved in this kind of discussions,
Yes, because I'm p
El sáb, 23-06-2012 a las 11:31 +0100, Ciaran McCreesh escribió:
> On Sat, 23 Jun 2012 12:24:32 +0200
> Pacho Ramos wrote:
> > As Peter explains, I think it is now clear enough what I was demanding
> > (about clarifying what is needed to get things in next EAPI to prevent
> > issues like Tommy is s
On Sat, 23 Jun 2012 12:24:32 +0200
Pacho Ramos wrote:
> As Peter explains, I think it is now clear enough what I was demanding
> (about clarifying what is needed to get things in next EAPI to prevent
> issues like Tommy is suffering to get multilib stuff done), but I star
> to think Ciaran thinks
El sáb, 23-06-2012 a las 12:24 +0200, Pacho Ramos escribió:
> El sáb, 23-06-2012 a las 11:53 +0200, Peter Stuge escribió:
> > Ciaran McCreesh wrote:
> > > What is hurting is people demanding features without specifying what
> > > the problem is
> >
> > Part of enabling progress is to show a strong
El sáb, 23-06-2012 a las 11:53 +0200, Peter Stuge escribió:
> Ciaran McCreesh wrote:
> > What is hurting is people demanding features without specifying what
> > the problem is
>
> Part of enabling progress is to show a strong will to communicate,
> with the goal of extracting common understanding
Ciaran McCreesh wrote:
> What is hurting is people demanding features without specifying what
> the problem is
Part of enabling progress is to show a strong will to communicate,
with the goal of extracting common understanding from discussion.
In any project based on volunteer effort you must sho
On Sat, 23 Jun 2012 09:53:37 +0200
Pacho Ramos wrote:
> Don't you see this way of handling things, with such and obscure way
> of getting things accepted for every EAPI is really hurting us?
What is hurting is people demanding features without specifying what
the problem is, how it will be solved
El jue, 21-06-2012 a las 11:27 +0200, Alec Warner escribió:
> On Thu, Jun 21, 2012 at 9:25 AM, Pacho Ramos wrote:
> > El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió:
> >> On Thu, 21 Jun 2012 08:08:55 +0200
> >> Pacho Ramos wrote:
> >> > Also, if I remember correctly, Tommy asked f
El jue, 21-06-2012 a las 19:15 +0800, Patrick Lauer escribió:
> On 06/21/12 15:25, Pacho Ramos wrote:
> > El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió:
> >> On Thu, 21 Jun 2012 08:08:55 +0200
> >> Pacho Ramos wrote:
> >>> Also, if I remember correctly, Tommy asked for this some m
El jue, 21-06-2012 a las 08:39 +0100, Ciaran McCreesh escribió:
> On Thu, 21 Jun 2012 09:25:10 +0200
> Pacho Ramos wrote:
> > Then, looks clear to me that the way to get things approved in newer
> > EAPIs is not clear enough as looks like a lot of devs (like me) don't
> > know them (for example, w
On Thu, Jun 21, 2012 at 4:26 PM, Homer Parker wrote:
>
> In the beginning there was a method...
>
> And now it needs revamped.. I see no problem with re-investigating the
> problem to make it better/easier/whatever.
>
++
I for one am happy to have had a working amd64 system for the
On Thu, 2012-06-21 at 14:20 +0100, Ciaran McCreesh wrote:
> On Thu, 21 Jun 2012 08:13:50 -0500
> Homer Parker wrote:
> > > And what did Gentoo get out of it?
> > >
> > > What I remember is Gentoo putting in lots of work randomly changing
> > > things until things worked, and ending up not knowing
On Thu, 21 Jun 2012 08:13:50 -0500
Homer Parker wrote:
> > And what did Gentoo get out of it?
> >
> > What I remember is Gentoo putting in lots of work randomly changing
> > things until things worked, and ending up not knowing what most of
> > those changes were or why they were done. The end re
On Thu, 2012-06-21 at 13:30 +0100, Ciaran McCreesh wrote:
> On Thu, 21 Jun 2012 07:11:27 -0500
> Homer Parker wrote:
> > On Thu, 2012-06-21 at 08:00 +0100, Ciaran McCreesh wrote:
> > > In case you're not aware, the first time Gentoo did multilib, it was
> > > done as a series of random changes to
On Thu, 21 Jun 2012 07:14:49 -0500
Homer Parker wrote:
> On Thu, 2012-06-21 at 09:24 +0200, justin wrote:
> > Won't it be a good thing, if you instead of showing all of us, that
> > you
> > can tell where people fail to present something in the right way,
> > help and guide them to write the neces
On Thu, 21 Jun 2012 07:11:27 -0500
Homer Parker wrote:
> On Thu, 2012-06-21 at 08:00 +0100, Ciaran McCreesh wrote:
> > In case you're not aware, the first time Gentoo did multilib, it was
> > done as a series of random changes to Portage that no-one really
> > thought through or understood. As you
On Thu, 2012-06-21 at 09:24 +0200, justin wrote:
> Won't it be a good thing, if you instead of showing all of us, that
> you
> can tell where people fail to present something in the right way, help
> and guide them to write the necessary things like PMS patches, GLEPs
> etc., so that we can proceed
On Thu, 2012-06-21 at 08:00 +0100, Ciaran McCreesh wrote:
>
> In case you're not aware, the first time Gentoo did multilib, it was
> done as a series of random changes to Portage that no-one really
> thought through or understood. As you can see, that didn't work...
No, but paved the way
On Thu, Jun 21, 2012 at 5:27 AM, Alec Warner wrote:
> There is this vague idea that you can just propose something; get
> consensus on the ML, everyone goes to implement it, and then it works
> just as designed. That is usually called the 'waterfall' model and its
> really hard to do correctly.
>
On Thu, 21 Jun 2012 19:15:02 +0800
Patrick Lauer wrote:
> > Then, looks clear to me that the way to get things approved in newer
> > EAPIs is not clear enough as looks like a lot of devs (like me)
> > don't know them (for example, when things to be added to EAPI need
> > also a GLEP and a PMS diff
On 06/21/12 15:25, Pacho Ramos wrote:
> El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió:
>> On Thu, 21 Jun 2012 08:08:55 +0200
>> Pacho Ramos wrote:
>>> Also, if I remember correctly, Tommy asked for this some months ago,
>>> you asked for what he sent some days ago and now you requ
On 21 June 2012 05:33, Alec Warner wrote:
> On Wed, Jun 20, 2012 at 10:25 PM, Richard Yao wrote:
>> Here is my wishlist for EAPI 5:
[...]
>> POSIX Shell compliance
>> There has been a great deal of work done to give the user full control
>> of what is on his system and there is more that w
On Thu, Jun 21, 2012 at 9:25 AM, Pacho Ramos wrote:
> El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió:
>> On Thu, 21 Jun 2012 08:08:55 +0200
>> Pacho Ramos wrote:
>> > Also, if I remember correctly, Tommy asked for this some months ago,
>> > you asked for what he sent some days ago
On Thu, 21 Jun 2012 09:25:10 +0200
Pacho Ramos wrote:
> Then, looks clear to me that the way to get things approved in newer
> EAPIs is not clear enough as looks like a lot of devs (like me) don't
> know them (for example, when things to be added to EAPI need also a
> GLEP and a PMS diff, also the
El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió:
> On Thu, 21 Jun 2012 08:08:55 +0200
> Pacho Ramos wrote:
> > Also, if I remember correctly, Tommy asked for this some months ago,
> > you asked for what he sent some days ago and now you require more and
> > more work to delay things
On 21/06/12 08:41, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 23:43:36 +0200
> Justin wrote:
>> On 20.06.2012 22:35, Ciaran McCreesh wrote:
>>> On Wed, 20 Jun 2012 16:25:30 -0400
>>> Richard Yao wrote:
Multilib (and/or multiarch) support
The current binaries cause a great deal of p
On Thu, 21 Jun 2012 08:08:55 +0200
Pacho Ramos wrote:
> Also, if I remember correctly, Tommy asked for this some months ago,
> you asked for what he sent some days ago and now you require more and
> more work to delay things to be implemented.
I still haven't seen a clear description of exactly w
On Wed, 20 Jun 2012 23:43:36 +0200
Justin wrote:
> On 20.06.2012 22:35, Ciaran McCreesh wrote:
> > On Wed, 20 Jun 2012 16:25:30 -0400
> > Richard Yao wrote:
> >> Multilib (and/or multiarch) support
> >>The current binaries cause a great deal of pain,
> >> particularly when a user does not wan
El mié, 20-06-2012 a las 23:43 +0200, Justin escribió:
> On 20.06.2012 22:35, Ciaran McCreesh wrote:
> > On Wed, 20 Jun 2012 16:25:30 -0400
> > Richard Yao wrote:
> >> Multilib (and/or multiarch) support
> >>The current binaries cause a great deal of pain, particularly
> >> when a user does no
On 20.06.2012 22:35, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 16:25:30 -0400
> Richard Yao wrote:
>> Multilib (and/or multiarch) support
>> The current binaries cause a great deal of pain, particularly
>> when a user does not want to upgrade something. I had this problem
>> with WINE and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/20/2012 05:12 PM, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 17:05:55 -0400 Richard Yao
> wrote:
The multilib-portage overlay already has this working.
>>>
>>> But there is no spec, nor is there a developer-centric
>>> description of i
On Wed, Jun 20, 2012 at 10:25 PM, Richard Yao wrote:
> Here is my wishlist for EAPI 5:
>
> Multilib (and/or multiarch) support
> Automated epatch_user support
> Parallel make checks
> POSIX Shell compliance
>
> Here are some explanations:
>
> Multilib (and/or multiarch) support
> The curren
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Jun 2012 17:05:55 -0400
Richard Yao wrote:
> >> The multilib-portage overlay already has this working.
> >
> > But there is no spec, nor is there a developer-centric description
> > of it.
>
> I missed this tibbit. I am not sure what you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Jun 2012 17:02:10 -0400
Richard Yao wrote:
> >> Lets address POSIX compliance in the ebuilds first. Then we can
> >> deal with the package managers.
> >
> > Why? It's highly doubtful the package manglers could switch shells
> > even if the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/20/2012 04:54 PM, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 16:50:33 -0400 Richard Yao
> wrote:
>> On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
>>> On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao
>>> wrote:
Multilib (and/or multiarch)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/20/2012 04:54 PM, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 16:50:33 -0400 Richard Yao
> wrote:
>> On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
>>> On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao
>>> wrote:
Multilib (and/or multiarch)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Jun 2012 16:50:33 -0400
Richard Yao wrote:
> On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
> > On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao
> > wrote:
> >> Multilib (and/or multiarch) support The current binaries cause a
> >> great deal
On 06/20/2012 04:39 PM, Maxim Kammerer wrote:
> On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao wrote:
>> Multilib (and/or multiarch) support
>
> Sorry for a possibly ignorant question. Does multilib support include
> the ability to build Busybox against uclibc (on a glibc system)?
It includes it n
On 06/20/2012 10:25 PM, Richard Yao wrote:
> Here is my wishlist for EAPI 5:
>
> Multilib (and/or multiarch) support
> Automated epatch_user support
> Parallel make checks
> POSIX Shell compliance
>
> Here are some explanations:
>
> Multilib (and/or multiarch) support
> The current binarie
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao
> wrote:
>> Multilib (and/or multiarch) support The current binaries cause a
>> great deal of pain, particularly when a user does not want to
>> upgrade so
On Wed, 20 Jun 2012 23:39:42 +0300
Maxim Kammerer wrote:
> On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao wrote:
> > Multilib (and/or multiarch) support
>
> Sorry for a possibly ignorant question. Does multilib support include
> the ability to build Busybox against uclibc (on a glibc system)?
No
On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao wrote:
> Multilib (and/or multiarch) support
Sorry for a possibly ignorant question. Does multilib support include
the ability to build Busybox against uclibc (on a glibc system)?
--
Maxim Kammerer
Liberté Linux: http://dee.su/liberte
On Wed, 20 Jun 2012 16:25:30 -0400
Richard Yao wrote:
> Multilib (and/or multiarch) support
> The current binaries cause a great deal of pain, particularly
> when a user does not want to upgrade something. I had this problem
> with WINE and glibc because I wanted to avoid the reverse memcpy(
Here is my wishlist for EAPI 5:
Multilib (and/or multiarch) support
Automated epatch_user support
Parallel make checks
POSIX Shell compliance
Here are some explanations:
Multilib (and/or multiarch) support
The current binaries cause a great deal of pain, particularly when a
user does not
57 matches
Mail list logo
