> I mean no offense to you Gerard, but I get the feeling you said the
> above simply to keep the peace on this thread. Supporting other "fancy"
I don't really take offense. And yes I said it in part to keep the
peace, as well. It sort of seems necessary...things feel volatile. Looks
like a lot
Jim Gifford wrote:
> We know that, but we didn't want to increase the size of our book any
> more than we did. You know that, but again your trying to make yourself
> look good, and me to look bad. What happened to being civil and talking
> things out, which is why this thread is started. You kn
Jeremy Huntwork wrote:
> Jim Gifford wrote:
>
>> and now your trying to get it in the mainline. To quote yourself your
>> not a "hardcore developer", but your trying to influence the direction
>> of LFS to meet your needs.
>>
>
> Oh, lol. You're taking Justin's words and applying them to
Jim Gifford wrote:
> The bottom line Jeremy is that we could of worked with you on it, we
> could of explained some of the reasons why we do things. But instead
> your being on the defensive, you must have some to be ashamed of.
What could I possibly be ashamed of? This is really just ridiculous
Jeremy Huntwork wrote:
> Jim Gifford wrote:
>
>> We were?? I sure wasn't and neither was Ryan. Your trying to design the
>> chroot method of CLFS into LFS for other architectures, now your
>> stepping into an area I would consider us the experts in. So why go
>> their without cooperation wit
On Sun, Oct 21, 2007 at 06:13:36PM -0600, Gerard Beekmans wrote:
> > of the differences in the build methods. I'm all for LFS having support
> > for other architectures, but they need to have the resources available
>
>
> I'm only intending to support x86_64 type stuff as it's the main stream
Jeremy Huntwork wrote:
> Jim Gifford wrote:
>
>> and now your trying to get it in the mainline. To quote yourself your
>> not a "hardcore developer", but your trying to influence the direction
>> of LFS to meet your needs.
>>
>
> Oh, lol. You're taking Justin's words and applying them to
Jim Gifford wrote:
> and now your trying to get it in the mainline. To quote yourself your
> not a "hardcore developer", but your trying to influence the direction
> of LFS to meet your needs.
Oh, lol. You're taking Justin's words and applying them to me. Nice! :)
I'm definitely not worthy of a
Gerard Beekmans wrote:
>> of the differences in the build methods. I'm all for LFS having support
>> for other architectures, but they need to have the resources available
>
>
> I'm only intending to support x86_64 type stuff as it's the main stream
> new computer systems these days. I definit
Jim Gifford wrote:
> No Greg the issue is that we have had some support questions related to
> this new branch, and the normal fixes we provide will not work because
> of the differences in the build methods. I'm all for LFS having support
> for other architectures, but they need to have the res
Jim Gifford wrote:
> We were?? I sure wasn't and neither was Ryan. Your trying to design the
> chroot method of CLFS into LFS for other architectures, now your
> stepping into an area I would consider us the experts in. So why go
> their without cooperation with CLFS.
Why do I need to personal
> of the differences in the build methods. I'm all for LFS having support
> for other architectures, but they need to have the resources available
I'm only intending to support x86_64 type stuff as it's the main stream
new computer systems these days. I definitely do not plan on doing
anythin
> besides x86_64? It seems like you created a branch to play around with,
> and now your trying to get it in the mainline. To quote yourself your
> not a "hardcore developer", but your trying to influence the direction
> of LFS to meet your needs.
Don't worry Jim, such a thing will never happen
Greg Schafer wrote:
> Umm, not sure why the CLFS guys are apparently getting their knickers in a
> knot. The issue is very plain and simple:
>
> - CLFS mostly uses *CROSS* compilation
> - LFS always uses *NATIVE* compilation
>
> If someone wants to build for ppc then why should they have to res
Justin R. Knierim wrote:
> It is
> clear that supporting multiple arches is becoming more and more useful.
> CLFS is a sub project of LFS and already has working and tested
> implementations for so many arches, with 32bit, 64bit and multilib.
> These are not all useful at this time in the ma
> LFS?" I know Jeremy is a great guy and does good research, but in my
> opinion not contacting CLFS devs _is_ re-inventing the wheel. Is it so
> hard to email one of us to ask for opinions or ideas?
Allow me to clarify it again, then. Right now, LFS isn't doing anything
yet (not taking into
Jeremy Huntwork wrote:
> Justin R. Knierim wrote:
>
>> I know I am not a hardcore developer in either lfs or clfs, so my voice
>> isn't one of much authority, but if I could throw out my opinion. It is
>> clear that supporting multiple arches is becoming more and more useful.
>> CLFS is a s
Alexander E. Patrakov wrote:
> Jim Gifford wrote:
>
>> Alex, I've been trying to search for this thread, but don't seem to find
>> it anywhere on the lfs-dev list, could you provide a link to it.
>>
>>
>
> The issue report is here:
> http://www.linuxfromscratch.org/pipermail/lfs-dev/20
Justin R. Knierim wrote:
> I know I am not a hardcore developer in either lfs or clfs, so my voice
> isn't one of much authority, but if I could throw out my opinion. It is
> clear that supporting multiple arches is becoming more and more useful.
> CLFS is a sub project of LFS and already has
Jim Gifford wrote:
> Alex, I've been trying to search for this thread, but don't seem to find
> it anywhere on the lfs-dev list, could you provide a link to it.
>
The issue report is here:
http://www.linuxfromscratch.org/pipermail/lfs-dev/2007-August/059894.html
The suggestion (approved by G
Alexander E. Patrakov wrote:
> Justin R. Knierim wrote:
>
>> I cannot say much about your first point, I have not heard of this
>> issue. Has a ticket been submitted?
>>
>
> No, sorry.
>
>
>> This topic though is about LFS, not CLFS XML. Even if LFS must
>> re-invent the wheel, surel
Justin R. Knierim wrote:
> I cannot say much about your first point, I have not heard of this
> issue. Has a ticket been submitted?
No, sorry.
> This topic though is about LFS, not CLFS XML. Even if LFS must
> re-invent the wheel, surely contacting those who have already invented
> it would
Alexander E. Patrakov wrote:
> We do need to reinvent the wheel, since there are known bugs in CLFS
> (e.g., the installed File is not used by the configure script of
> Cross-Binutils), and because their overly complicated XML has stopped at
> least two persons (Jeremy and me) from contributing
Justin R. Knierim wrote:
> I know Jeremy is a great guy and does good research, but in my opinion not
> contacting CLFS devs _is_ re-inventing the wheel.
We do need to reinvent the wheel, since there are known bugs in CLFS
(e.g., the installed File is not used by the configure script of
Cross-B
Gerard Beekmans wrote:
> Obviously, no. You'd have been the first person I'd have gotten in touch
> with. I haven't mapped out the plan of attack yet - which is why I
> haven't brought up on this list. That Trac ticket Jeremy put up was done
> at my request. I was checking out the status of both
25 matches
Mail list logo
