Jim Gifford wrote:
> Enough on that subject,
OK. Time to move on.
> As far as LFS Dev privs, thanx but no thanx. You can delete them, not to
> mention, someone changed by password on me a while back, because they
> were afraid when CLFS moved away to it's own servers. I have no interest
> i
Bruce Dubbs wrote:
> Jeremy's request is reasonable, Jim. I don't think there was ever any
> thought
> of not giving proper attribution to either Greg or CLFS.
>
> Please give us a break here. The changes are reasonably large and everything
> wasn't perfect on the first commit. All this will
On Dec 6, 2008, at 11:49 PM, Bruce Dubbs wrote:
> William Harrington wrote:
>
>> It's a community endeavor and each project with it's own goal. Each
>> project
>> may borrow from another, and each project needs to give credit to
>> the source.
>> If any part of the source is used credit needs
William Harrington wrote:
> It's a community endeavor and each project with it's own goal. Each project
> may borrow from another, and each project needs to give credit to the source.
> If any part of the source is used credit needs to be given. It's a black and
> white line.
William,
While I
Enough!
If someone is going to borrow someone's work credit needs to be made.
I don't care the degree of the final product.
Impressing people cause of the work they claim they do without credit
to the author is worse
than throwing 3 strikes in a row at a bowling alley with Uncle
Knicknak's a
Jim Gifford wrote:
> Jeremy Huntwork wrote:
>> Greg Schafer wrote:
>>
>>> the Acknowledgments page will suffice. "... Technical Writer and Architect
>>> of the Next Generation 64-bit-enabling Build Method" or similar.
>>>
>> I'll give you a day or so to decide on the exact wording you prefe
Jeremy Huntwork wrote:
> Greg Schafer wrote:
>
>> the Acknowledgments page will suffice. "... Technical Writer and Architect
>> of the Next Generation 64-bit-enabling Build Method" or similar.
>>
>
> I'll give you a day or so to decide on the exact wording you prefer, or
> for someone else
On Dec 6, 2008, at 6:19 PM, Gerard Beekmans wrote:
>> Or compress them. Maybe make them only available to subscribed
>> members. I wanted to grab the last two months of the blfs-support
>> mailing list archive.
>> Maybe someone can email me the files.
>
> Compressing is an option but would also
Greg Schafer wrote:
> the Acknowledgments page will suffice. "... Technical Writer and Architect
> of the Next Generation 64-bit-enabling Build Method" or similar.
I'll give you a day or so to decide on the exact wording you prefer, or
for someone else to offer a suggestion. Then I'll add this in
> I'll have to looking into the Python source. I didn't see a
> configuration item to turn that on or off at will. Granted, I admit I
That should be taken care of now. The archive pages will re-generate
themselves when new messages to the lists start to arrive. The template
was updated to not
Greg Schafer wrote:
> Jeremy Huntwork wrote:
>
>> Knock it off. I don't come to DIY and disparage your work.
>
> Huh? Get over yourself dude. You've *always* taken things so personally.
> Grow a thick skin.
I'm not personally bothered in the least.
> Remember I'm trying to support *you* impleme
> Or compress them. Maybe make them only available to subscribed
> members. I wanted to grab the last two months of the blfs-support
> mailing list archive.
> Maybe someone can email me the files.
Compressing is an option but would also require some Mailman
modifications, or a helper script
On Dec 6, 2008, at 4:58 PM, Olaf wrote:
> Gerard Beekmans wrote:
>> Part of the archives are currently disabled due to excessive
>> bandwidth
>> consumption. A robots.txt file was installed to prevent search
>> engines
>> from keep downloading all the archived messages all the time. There
>
> Any (easy) way to to remove the "Downloadable version" from the archive
> list overview?
I imagine it's easy. I mean, we got the source code, right :)
I'll have to looking into the Python source. I didn't see a
configuration item to turn that on or off at will. Granted, I admit I
didn't look
Jeremy Huntwork wrote:
> Knock it off. I don't come to DIY and disparage your work.
Huh? Get over yourself dude. You've *always* taken things so personally.
Grow a thick skin.
Remember I'm trying to support *you* implementing *my* work. Watch your
tone and focus on the task at hand. Thanks.
Reg
Greg Schafer wrote:
> No. You've also omitted perhaps the most interesting feature of the whole
> thing - the ability to migrate from a 32-bit system to a 64-bit system. As
> it currently stands, you're forcing folks to start from a 64-bit system if
> they want 64-bit. Useless.
Greg, c'mon. You kn
Greg Schafer wrote:
> The other thing you've omitted is proper attribution. A simple "Thanks,
> me" is not good enough for something this big. The LFS changelog is not
> perpetual. You of all people should know how much time and effort goes
> into engineering this stuff. Some extra words next to my
Gerard Beekmans wrote:
> Part of the archives are currently disabled due to excessive bandwidth
> consumption. A robots.txt file was installed to prevent search engines
> from keep downloading all the archived messages all the time. There were
> months it incurred hundreds of gigs in server uplo
Jeremy Huntwork wrote:
> With revision 8755, the new build method from DIY is in place with the
> exception of support for multilib. (More on that in a second.)
No. You've also omitted perhaps the most interesting feature of the whole
thing - the ability to migrate from a 32-bit system to a 64-bi
Howdy,
Part of the archives are currently disabled due to excessive bandwidth
consumption. A robots.txt file was installed to prevent search engines
from keep downloading all the archived messages all the time. There were
months it incurred hundreds of gigs in server uploads.
Trying to downloa
Randy McMurchy wrote:
> I originally read this and thought, 'I've never had any trouble
> accessing the archives'. Now I see others posting about problems
> with the archives.
>
> I can read any of the archives just fine, and always have been
> able to. What exactly is supposed to be wrong?
>
R
Jim Gifford wrote:
> I just started to play around with extlinux, just started to do my
> testing, it does come premade already, but looks like it could be
> built with a standard compiler. I'll give feedback as I progress.
extlinux looks different (...obviously! ;-) ), but it may work fairly
wel
Bryan,
I just started to play around with extlinux, just started to do my
testing, it does come premade already, but looks like it could be built
with a standard compiler. I'll give feedback as I progress.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscrat
On Mon, Dec 01, 2008 at 11:28:25PM -0600, DJ Lucas wrote:
> DJ Lucas wrote:
> > *(September 8, 2008)* FFmpeg is undergoing major changes in its API/ABI.
> > The last valid revision for libavcodec version 51 is r15261.
> >
> > Guess we should go with this version for BLFS. Anybody tried it yet?
>
Hi all,
I'm running a little behind schedule here, so thought I'd pass on the patch
series I'm currently building from on top of trunk. All the patches are at
http://www.linuxfromscratch.org/~matthew/patches/ and the various updated
fixes-patches are there too, for those that don't want to pul
Jeremy Huntwork wrote:
> Can we please put aside the egos and pointing fingers and work together
> to reach the common goal?
Absolutely. More than anything, I got a chuckle this morning
reading this thread and ended up posting something that was
actually just me thinking out loud.
I apologize f
Jim Gifford wrote:
> As far as udev rules, CLFS has made the move to use the rules that
> have been included for over a year with no issues at all.
Great! :-)
That (well: the fact that you've seen no issues, at least) means we can
very likely do the same: drop udev-config entirely and go with ud
Jim Gifford wrote:
> Randy McMurchy wrote:
>>>
>> Too bad that they don't practice what they preach.
>>
>>
> Gee this what your looking for http://cblfs.cross-lfs.org/index.php/License
>
> I see credit given? You owe an apology.
C'mon guys. This is the type of stuff that creates the rift
Charles wrote:
> Hi LFS and CLFS developers,
>
> As an ardent follower of these projects, I'd be very glad to see the
> two projects be one. In my opinion, they are gaining the same result
> by different techniques. If DIY is trying some cross compiling and LFS
> may go after it, then what's left
Randy McMurchy wrote:
> Jim Gifford wrote:
>
>
>> I also hope anything from what people have done towards the LFS's 7.0
>> goal, that the appropriate credit is giving.
>>
>
> This is funny.
>
> They copy hundreds of BLFS pages (verbatim, mind you) into
> the work at http://cblfs.cross-lfs.
On Dec 6, 2008, at 10:18 AM, Randy McMurchy wrote:
> Dan Nicholson wrote:
>> On Wed, Dec 3, 2008 at 12:37 PM, William Harrington <[EMAIL PROTECTED]
>> > wrote:
>>> Hello Everybody,
>>>
>>> Is there any way to get some of the archives from the mailing
>>> lists? They are all error 403 right
Dan Nicholson wrote:
> On Wed, Dec 3, 2008 at 12:37 PM, William Harrington <[EMAIL PROTECTED]> wrote:
>> Hello Everybody,
>>
>> Is there any way to get some of the archives from the mailing
>> lists? They are all error 403 right now.
>
> I could be wrong, but I think Gerard disabled the arch
Jim Gifford wrote:
> I also hope anything from what people have done towards the LFS's 7.0
> goal, that the appropriate credit is giving.
This is funny.
They copy hundreds of BLFS pages (verbatim, mind you) into
the work at http://cblfs.cross-lfs.org/index.php/Main_Page
and don't mention anywhe
Hi,
I have added the new variables to LFS/master.sh. This will only
impact LFS and should not affect the building of earlier books.
If there are any problems let me know.
regards
George
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq
Hi LFS and CLFS developers,
As an ardent follower of these projects, I'd be very glad to see the
two projects be one. In my opinion, they are gaining the same result
by different techniques. If DIY is trying some cross compiling and LFS
may go after it, then what's left to the name CLFS? I think i
Jeremy Huntwork wrote:
> Can we resolve any actual differences between the projects (and
> individuals making up the projects) and put aside any perceived disputes
> and work together in a more unified manner again? If so, what are we
> willing to do to be more unified? What possibilities are t
On Dec 6, 2008, at 12:03 AM, Jim Gifford wrote:
David Miller constantly gets on his soapbox about this
on the Sparc Realm of linux.
I don't disagree per se -- I've given up on pure64 for desktop builds
for the moment -- but to be fair x86 has a lot more to gain running
standard apps in 6
Jim Gifford wrote:
> It seems now that LFS is ready to go into the world that CLFS has been
> in for a while. There seems to be a lot of discussions, that are going
> to be a duplication of work, and no one from LFS reaching out to the
> CLFS team for input on what issues we have seen and what y
Matthew Burgess wrote:
> Oh, how trivial! Thanks muchly, the build had only gotten part way through
> gcc-pass1, so I didn't lose too time thanks to your quick reply!
Glad to help. :) Looking forward to seeing how the build goes.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FA
On Sat, 06 Dec 2008 07:37:38 -0500, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Matthew Burgess wrote:
>> On Fri, 05 Dec 2008 15:58:24 -0500, Jeremy Huntwork
> <[EMAIL PROTECTED]> wrote:
>>
>>> Another side note, jhalfs can't currently handle the new build method
>>> becuase it hard-codes the buil
Matthew Burgess wrote:
> On Fri, 05 Dec 2008 15:58:24 -0500, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
>
>> Another side note, jhalfs can't currently handle the new build method
>> becuase it hard-codes the build user's .bashrc file. A slight tweak in
>> jhalfs to match what is now in Chapter 4 s
On Fri, 05 Dec 2008 15:58:24 -0500, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Another side note, jhalfs can't currently handle the new build method
> becuase it hard-codes the build user's .bashrc file. A slight tweak in
> jhalfs to match what is now in Chapter 4 should take care of it. CCing
>
On Fri, Dec 05, 2008 at 06:54:51PM -0800, Bryan Kadzban wrote:
> Ken Moffat wrote:
> > Last time this was discussed, the general view seemed to be that
> > pure64 was a step far enough. Care to remind me what the advantages
> > of multilib builds are ?
>
> For me: Flash. Either "standard" flash
Jim Gifford wrote:
> It seems now that LFS is ready to go into the world that CLFS has been
> in for a while. There seems to be a lot of discussions, that are going
> to be a duplication of work, and no one from LFS reaching out to the
> CLFS team for input on what issues we have seen and what y
44 matches
Mail list logo
