Hi All,
I wanted to open this up to the entire community for further comments
(especially for those that may not watch the alfs-discuss list). A
question was brought up on alfs-discuss today that I thought deserves some
attention.
As far as I am aware, historically, ALFS as a project was
On Tue, 9 Aug 2005, Ken Moffat wrote:
I plan to look at dhcpcd in a few minutes
Well, the good news is it seems to be maintained again (a 2.0.0 version
at berlios.de incorporating recent patches from debian and gentoo).
The bad news is the layout of the source has been tidied up, moving the
Jeremy Huntwork wrote these words on 08/09/05 12:17 CST:
I am anxious to hear the entire LFS community's thoughts, so please, if
you have an opinion about this, speak up.
I have an automated procedure for building LFS which uses Bash scripts
as well. Probably many do. And though these scripts
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeremy Huntwork wrote:
Or should ALFS endeavor to host various build
methods/implementations?
+1 to that
I prefer to have a choice on how my system is built, be that by XML,
Makefiles, or Bash scripting. I am for the idea of having many build
This is what the hard part is. Keeping those things pointed out
above in sync with LFS. nALFS has a team which does this already.
For every other automated build method, someone must ensure that
these things take place.
Right. One solution to that which I am interested in pursuing a bit more
Randy McMurchy wrote:
Even if you pass the --disable-docs parameter to configure, when
you try to execute the 'make -C doc install' command shown in the
instructions, it fails with an error message that says it cannot
find pdfjadetex.
This sounds similar to the module-init-tools bug which was
Jeremy Huntwork wrote:
The difficulty becomes how to use those raw text files to intelligently
and accurately script the build.
One idea that immediately springs to mind is that we have a tool that
not only extracts/dumps the commands (i.e. XSL), but instead of/as well
as dumping the
Jeremy Huntwork wrote:
Or should ALFS endeavor to host various build
methods/implementations?
I think it would be best. We have a few lfs book in development now, so
maybe in the future the user could have a choice between normal lfs,
hlfs, etc etc. Don't know if that is really feasible,
On Tue, Aug 09, 2005 at 06:51:16PM +0100, Matthew Burgess wrote:
I'd then write handlers for each of those events that would result in
me having exactly the same Makefiles that I have now, but with the
massive benefit of being automatically generated/maintained. This
processing is inspired
On Tue, 09 Aug 2005 13:38:02 -0400 (EDT), Jeremy Huntwork
[EMAIL PROTECTED] wrote:
extracting the commands from the book's XML source ... Manuel has created
a XSL stylesheet that can extract all the commands and dump them into text
files.
diy-linux seems to be doing this too.
This could be put
Hi all,
I have been trying for a few weeks now to build LFS on my Athlon64 to no
success. The problem is, there is the main LFS book, which is designed for
x86 builds, and there is the cross book, which is designed for
something-to-x86_64 builds. I'm building from FC4 x86_64 to x86_64.
Has
Has anyone done this successfully? And maybe documented it?
Just did an x86_64 using GCC 4.0.1 and the vanilla LFS
6.0 book, actually, in just under 48 hours.
Works beautifully with the exception of glibc, for
which I had to have GCC 3.4.4 on hand (though I hear that's
been
Folks,
I've currently got a TODO list with some 16 items on it. Although some
of these really are personal LFS-related tasks I'd like to tackle, the
majority of them are reminders of/pointers to emails to do with bugs
that need to be addressed in the book. In order that everyone has
Archaic wrote these words on 08/09/05 16:04 CST:
Groovy. BTW, just taking a quick peek at my buildscript for strace (I
can't remember how long it was that I wrote it), strace is a cmmi
package.
Yes, I believe it is. But the point of this page is not so much to
provide build instructions as it
On Tue, Aug 09, 2005 at 04:10:22PM -0500, Randy McMurchy wrote:
Yes, I believe it is. But the point of this page is not so much to
provide build instructions as it is a place where you can find out
what is available and where the hell to download stuff from without
having to spend time
Archaic wrote these words on 08/09/05 16:14 CST:
Understood. But since the discussion of gdb instruction came up, I
thought it might be relevant to the discussion since a page for strace
would require very minimal maintenance.
Yeah, I kind of thought my message before this was rather blunt.
I
On 8/8/05, DJ Lucas [EMAIL PROTECTED] wrote:
DJ Lucas wrote:
Okay..I'm not sure how (if) this affects the LSB function for pidofproc,
And I did break it in a rather obvious way. Attached should be a
working patch against lfs-bootscripts-3.2.2. I've tested it to the best
of the amount
Matthew Burgess wrote these words on 08/09/05 15:59 CST:
In the future, can I request that before sending such emails, you
consider entering them into bugzilla instead.
Good plan. It *is* frustrating for folks (I've been there) to submit
what you think is a good idea on the mailing list, only
On Tue, Aug 09, 2005 at 03:16:42PM -0400, Michael Kipper wrote:
What I'm probably looking to do it to build a clean x86_64 toolset, using
FC4's gcc-4.0.1 to build a clean gcc-3.4.4 toolchain, and then using the
clean toolchain to build LFS.
Divide and conquer. The first problem is using
Jeremy Huntwork wrote:
Hi All,
I wanted to open this up to the entire community for further comments
(especially for those that may not watch the alfs-discuss list). A
question was brought up on alfs-discuss today that I thought deserves some
attention.
Thank you for doing so.
As far
And I did break it in a rather obvious way. Attached should be a
working patch against lfs-bootscripts-3.2.2. I've tested it
to the best
of the amount of time availible, but it should be correct. Alexander,
Archaic, Randy and anyone else who has seen the issue, I'd
appreciate if
you
Jeremy Huntwork wrote:
Hi All,
I wanted to open this up to the entire community for further comments
(especially for those that may not watch the alfs-discuss list). A
question was brought up on alfs-discuss today that I thought deserves some
attention.
My current LFS build was through
Well, I didn't have the problem before... However, I am now
experiencing
the following problem after applying your patch:
/etc# init.d/spamd stop
Stopping spamd... [ FAIL ]
It was running, and it DID stop it, but reported a failure.
Then I tried starting it again:
/etc#
Unless you have a reason to use static libraries, I'd just move them
out of the way (after confirming exactly what it installed,
of course).
If you do have a reason to use them, rebuild *binutils* following the
chapter 6 LFS instructions.
Ok great. :) Thank you ever so much, Ken. :)
Ok, without the patch, DJ, I am experiencing a problem, where I try to stop
an already stopped process, and it pretends to work. :) However, it really
doesn't, of course, since the process isn't actually running. And you
already have seen what the patch did to me. :)
Dave
PS Sorry
David Fix wrote:
Well, I didn't have the problem before... However, I am now
experiencing
the following problem after applying your patch:
/etc# init.d/spamd stop
Stopping spamd... [ FAIL ]
It was running, and it DID stop it, but reported a failure.
Then I tried starting it again:
/etc#
DJ Lucas wrote these words on 08/09/05 21:12 CST:
Okay, does the spamd script that you use set PIDFILE?
Because I'm the one that started this thread by reporting what I
felt was an error in the functions, I am curious if anyone else has
seen the issue I see. I would hate the DJ is fighting
Okay, does the spamd script that you use set PIDFILE?
-- DJ Lucas
Nope... I just copied from some of the other bootscripts... However, I had
the same problems with samba, which I'd done completely according to the
book. Here is what /etc/rc.d/init.d/spamd looks like:
#! /bin/sh
.
Randy McMurchy wrote:
Hi all,
I believe I've run across a bug in the LFS Bootscripts. It appears to
me that if the concerned script (I've only tested BLFS scripts, but I
suppose I could kill the sysklog stuff and try it) is not started, and
you issue a
/etc/rc.d/init.d/script status
29 matches
Mail list logo
