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 stat
Randy McMurchy wrote:
> 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 s
> 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
. /etc/
Randy McMurchy wrote:
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 ha
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 some
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 a
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 abo
> 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. :)
> 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#
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 throu
> 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
>
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.
> A
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 g
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, onl
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
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.
On 8/9/05, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> Why don't we just add GNU Ghostscript into the book as well?
Good idea.
> I
> realize this is additional maintenance, but what the heck, if there
> are *Editors* using a package, it will stay maintained.
True :-)
--
Tushar Teredesai
mai
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 G
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
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
visibil
> 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 co
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 anyo
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 b
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 ins
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,
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 command
Matthew Burgess wrote these words on 08/09/05 12:41 CST:
> I'd say workaround it for now by just installing the docs by hand, if my
> opinion counts for anything over here in BLFS land :)
That is exactly what has been done.
--
Randy
rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.
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
> 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 mo
-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
sy
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
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
fi
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 conceive
33 matches
Mail list logo
