Re: [lfs-support] Chapter 5 questions

2012-05-05 Thread Philippe Delavalade
HI.

Le samedi 05 mai à 01:02, Bruce Dubbs a écrit :
 Qrux wrote:
 
  If LFS is just a source code project, then to some extent you can say that
  prose style or organization is irrelevant.  It's not, because it's often
  repeated that it's a book, as well.  So, style is important, because
  organization can aid understanding.
 
 The descriptions and the organization is important, but it satisfies most 
 users.
 We probably go through this discussion two are three time a year.  Each time 
 it's a single user that doesn't quite get it (you got it without problem). 
 Since we have over 23000 registered users, I'd say that the vast majority get 
 value from the book as it is.  I'm not willing to make major changes for a 
 vocal 
 few.  We will have to agree to disagree and move on.

I would like to say that the book is nearly perfect ; it seems to me that
people having troubles with it have not read it like a book (from the
beginning and without skiping paragraphs or sections) or people having no
sufficient knowledges about linux. The LFS book is not a magazine where you
can pick up informations from a page or another.

When I was a young mathematic student, and when I read a book on a new
topic for me, I didn't skipped theorems or proofs ; that should have been
the best way to misunderstand.

Another point is : if some people complain about the book (and often
because they are not in the audience of the book), is it a good reason to
modify every thing ? I don't think so. The best is to try to help those
people on the list even if it is not always easy :-)

-- 
Ph. Delavalade
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-05 Thread Simon Geard
On Fri, 2012-05-04 at 10:34 -0700, Qrux wrote:
 Would it be hard to put an unpack_warning entity before each of the
 Phase 1 builds (all 2 or 3), or even the Phase 2 builds (those
 same 2 or 3)?

Hard? No. But would it be productive to do so? If the reader hasn't
understood the basic instructions by the time they finish the first
package build, they *shouldn't* be going any further. Our goal isn't to
produce something that people can follow without any idea what they're
doing.

Simon.


signature.asc
Description: This is a digitally signed message part
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-05 Thread Simon Geard
On Sat, 2012-05-05 at 17:19 +1200, Gordon Findlay wrote:
 In my perception the book currently assumes that the audience is
 people with some (considerable) understanding of the command-line, and
 OS concepts in general (for example the fact that 'source directory'
 might have different meanings depending on context).

Very much so. Like myself when I started on LFS years ago - I felt I'd
learned everything I could from using a distro, and wanted to know how
things worked behind the scenes. Others will have different motivations,
but the assumption is certainly that a) people are aiming to learn
something, and b) they're already experienced Linux users who know how
to compile packages from sources.

 And the purpose of the book (again, my perception) is educational, so
 the explanations about the tool-chain modifications and how
 cross-compilation works are not extras, but an integral part of the
 book.  The aim is to learn, not just to get to the end.

Absolutely. As far as I'm concerned, the primary purpose of LFS is to
educate readers about such things - learning about tool-chains and all
the other components of a Linux system by building one from parts. That
you actually have a working system at the end is secondary. Encouraging
users to skip those parts is entirely counterproductive, to my way of
thinking.

Simon.



signature.asc
Description: This is a digitally signed message part
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-04 Thread Scott Robertson
 I started reading 7.0, and I was doing OK until about Chapter 5.  Until I

 realized that some of my directories didn't seem right.  Somehow I ended up
 with just a sources directory on the LFS partition.  I'm not a hardened
 expert in Linux yet, but I do have some knowledge and I have alot of
 experience with computers in general.  Am I required to be an expert to do
 this?  This is my first attempt at LFS. I am trying to learn Linux at a
 deeper level.

 We try to give you a vehicle for learning.

Do you?  There seems to be an awful lot of hostility on here for newcomers.
I'm not questioning the entire LFS philosophy, I just think the book has a 
couple 
of things the average newcomer might not understand. If you guys are so hostile 
to newcomers,
then maybe you should just flat out tell them not to be here.
Overall I was impressed by the book, but then I come on here for some 
CLARIFICATION 
of a few things and I am labeled as stupid and a troublemaker who didn't read 
anything 
and knows nothing about Linux.  That's some way to greet people who are 
interested in your project
and trying to understand the book.


 I guess what threw me was in
 Section 5.4, it says: The Binutils documentation recommends building
 Binutils outside of the source directory in a dedicated build directory: As
 I mentioned in one of my previous e-mails to the group, I wasn't too sure
 what this meant.  I didn't understand what ...outside of the source
 directory... meant.  I thought if it was truly outside the source
 directory, then where does it go? 

Do you know what the source directory is?  Do you know what it means to be 
'in' 
a directory?

Yes, I know what it means to be 'in' a directory.  But do you not see from a 
newcomers
perspective that you seem to use source directory in more ways than one?

$LFS/sources and (for example) $LFS/sources/binutils-x.x could BOTH be referred 
to as source directories.

And when you say to build (again for example) the binutils-build directory 
OUTSIDE of the source directory, 
that can have more than one meaning.  It could mean to build it outside of the 
$LFS/sources directory
OR it could mean to build it outside of the $LFS/sources/binutils-x.x SOURCE 
directory, 

So for example, depending on one's interpretation of source directory, the 
binutils-build directory could be in either:
$LFS/sources/binutils-build/    OR
$LFS/binutils-build/   
because the second one would indeed be outside the source directory


 As it stands, I think it can be confusing when to run
 things as root and when to run them as lfs user as the book doesn't always
 say.  

Yes it does.  It's not repeated every page though.
 
Under section 2.3 the very first thing one does (other than version-check.sh in 
the Preface)
is create the file system using the mke2fs command.  Where does it say you need 
to be root for that?
I'm just saying maybe not everyone knows that you need to be root in order for 
that to work.  Wouldn't it be worthwhile to simply add two words to clarify on 
page 15?

To create an ext3 file system on the LFS partition, run the following [AS 
ROOT]:
mke2fs -jv /dev/xxx

I haven't read the entire book, maybe things change later on, 
but it seems like you should mention this.



 Also, I think it can be a little confusing as to what directory I am supposed
 to be in when running the commands sometimes, as that is very important too.

What part of:

For each package:

1. Using the tar program, extract the package to be built. In Chapter 5, 
ensure 
you are the lfs user when extracting the package.
2. Change to the directory created when the package was extracted.
3. Follow the book's instructions for building the package.

do you not understand?

Wow, again with the hostility.  Let's say hypothetically that I have to 
uncompress the binutils-x.x file.
It may not be immediately obvious where one is supposed to be when issuing the 
command:
mkdir -v ../binutils-build
cd ../binutils-build

Couldn't the book simply clarify (briefly) where the binutils directory should 
be to clarify it for new users?


 Are you guys aware that a fairly substantial number of the web links in the
 book no longer work?  I made a list and tried to send it to lfs-dev, but that
 was before I realized that I had to join it first, so not sure if anyone
 received it.

You are using a book that was published in September.  Links change.  It's up 
to 
you to find new ones.  The books are like RFCs.  Once published, we do not 
change that version.

I never said I had a problem downloading packages.  But it is good to know 
(now) 
that you do not revise released books.  I was referring to some homepage links 
which 
the lfs-dev list has verified.


 I also tried e-mailing lfs-support-ow...@linuxfromscratch.org about a week
 ago to get some help, but never heard back from anyone.  

That's the mailman internal address.  You have the right address now.

That is the e-mail address given at the bottom of:

Re: [lfs-support] Chapter 5 questions

2012-05-04 Thread Eleanore Boyd
On 5/4/2012 5:34 AM, Scott Robertson wrote:
 I started reading 7.0, and I was doing OK until about Chapter 5.  Until I
 realized that some of my directories didn't seem right.  Somehow I ended up
 with just a sources directory on the LFS partition.  I'm not a hardened
 expert in Linux yet, but I do have some knowledge and I have alot of
 experience with computers in general.  Am I required to be an expert to do
 this?  This is my first attempt at LFS. I am trying to learn Linux at a
 deeper level.
 We try to give you a vehicle for learning.
 Do you?  There seems to be an awful lot of hostility on here for newcomers.
 I'm not questioning the entire LFS philosophy, I just think the book has a 
 couple
 of things the average newcomer might not understand. If you guys are so 
 hostile to newcomers,
 then maybe you should just flat out tell them not to be here.
 Overall I was impressed by the book, but then I come on here for some 
 CLARIFICATION
 of a few things and I am labeled as stupid and a troublemaker who didn't read 
 anything
 and knows nothing about Linux.  That's some way to greet people who are 
 interested in your project
 and trying to understand the book.


 I guess what threw me was in
 Section 5.4, it says: The Binutils documentation recommends building
 Binutils outside of the source directory in a dedicated build directory: As
 I mentioned in one of my previous e-mails to the group, I wasn't too sure
 what this meant.  I didn't understand what ...outside of the source
 directory... meant.  I thought if it was truly outside the source
 directory, then where does it go?
 Do you know what the source directory is?  Do you know what it means to be 
 'in'
 a directory?
 Yes, I know what it means to be 'in' a directory.  But do you not see from a 
 newcomers
 perspective that you seem to use source directory in more ways than one?

 $LFS/sources and (for example) $LFS/sources/binutils-x.x could BOTH be 
 referred to as source directories.

 And when you say to build (again for example) the binutils-build directory 
 OUTSIDE of the source directory,
 that can have more than one meaning.  It could mean to build it outside of 
 the $LFS/sources directory
 OR it could mean to build it outside of the $LFS/sources/binutils-x.x SOURCE 
 directory,

 So for example, depending on one's interpretation of source directory, the 
 binutils-build directory could be in either:
 $LFS/sources/binutils-build/OR
 $LFS/binutils-build/  
 because the second one would indeed be outside the source directory


 As it stands, I think it can be confusing when to run
 things as root and when to run them as lfs user as the book doesn't always
 say.
 Yes it does.  It's not repeated every page though.
   
 Under section 2.3 the very first thing one does (other than version-check.sh 
 in the Preface)
 is create the file system using the mke2fs command.  Where does it say you 
 need to be root for that?
 I'm just saying maybe not everyone knows that you need to be root in order for
 that to work.  Wouldn't it be worthwhile to simply add two words to clarify 
 on page 15?

 To create an ext3 file system on the LFS partition, run the following [AS 
 ROOT]:
 mke2fs -jv /dev/xxx

 I haven't read the entire book, maybe things change later on,
 but it seems like you should mention this.



 Also, I think it can be a little confusing as to what directory I am 
 supposed
 to be in when running the commands sometimes, as that is very important too.
 What part of:
 For each package:
 1. Using the tar program, extract the package to be built. In Chapter 5, 
 ensure
 you are the lfs user when extracting the package.
 2. Change to the directory created when the package was extracted.
 3. Follow the book's instructions for building the package.
 do you not understand?
 Wow, again with the hostility.  Let's say hypothetically that I have to 
 uncompress the binutils-x.x file.
 It may not be immediately obvious where one is supposed to be when issuing 
 the command:
 mkdir -v ../binutils-build
 cd ../binutils-build

 Couldn't the book simply clarify (briefly) where the binutils directory 
 should be to clarify it for new users?


 Are you guys aware that a fairly substantial number of the web links in the
 book no longer work?  I made a list and tried to send it to lfs-dev, but 
 that
 was before I realized that I had to join it first, so not sure if anyone
 received it.
 You are using a book that was published in September.  Links change.  It's 
 up to
 you to find new ones.  The books are like RFCs.  Once published, we do not
 change that version.
 I never said I had a problem downloading packages.  But it is good to know 
 (now)
 that you do not revise released books.  I was referring to some homepage 
 links which
 the lfs-dev list has verified.


 I also tried e-mailing lfs-support-ow...@linuxfromscratch.org about a week
 ago to get some help, but never heard back from anyone.
 That's the mailman internal address.  You have the right 

Re: [lfs-support] Chapter 5 questions

2012-05-04 Thread Simon Geard
On Fri, 2012-05-04 at 03:34 -0700, Scott Robertson wrote:
 Under section 2.3 the very first thing one does (other than version-check.sh 
 in the Preface)
 is create the file system using the mke2fs command.  Where does it say you 
 need to be root for that?
 I'm just saying maybe not everyone knows that you need to be root in order 
 for 
 that to work.  Wouldn't it be worthwhile to simply add two words to clarify 
 on page 15?

It might, but see - this is why we emphasise that a certain amount of
knowledge is required. We assume that if you're doing an LFS build, you
don't need to be told that formatting a partition must be done as root.

Please understand - we're not trying to be rude or hostile. We can, and
do, make changes to improve the book's instructions, when we find that
people are mislead by poor wording or lack of explanation. 

But well... the instructions you're having difficulty with are ones that
many others have been successfully using for many years now. If you're
having this much difficulty with them, it does suggest to us that a lack
of Linux/Unix experience is a factor.

 It may not be immediately obvious where one is supposed to be when issuing 
 the command:
 mkdir -v ../binutils-build
 cd ../binutils-build

Remember the bit change to the directory created when the package was
extracted, followed by follow the book's instructions for building the
package. That tells you exactly where you should be when running that
command.

Re-read that page General Compilation Instructions - it really is
very, very important, and we've spent an awful lot of effort making
those instructions as clear as possible.

Simon.


signature.asc
Description: This is a digitally signed message part
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-04 Thread Fernando de Oliveira
On 04-05-2012 08:23, Eleanore Boyd wrote:
 On 5/4/2012 5:34 AM, Scott Robertson wrote:


[...]


 Now, have you tried this solution: untar the package, go into the 
 unpacked directory, then do copy+paste operations to make sure you don't 
 inadvertently screw something up? Then all you have to do is make sure 
 you replace certain pieces with the appropriate value for the new 
 system. Tends to work like a charm. (Then again, I have a fascination 
 with progress scrolling up the screen, and progress bars moving...)

 Elly

Scott,

Elly is right. Read the printed copy, but copy and paste from the web or from a 
locally saved copy. You can try to understand everything, but after some 
machines built, will discover that many things, including commands, variables, 
configurations, command arguments, were not clear at first sight.

With the exception of those who originally built the LFS project from scratch - 
LFSFS :-), the ones  who replied to this thread, myself included, have, at some 
stage been newcomers to LFS. I had difficulties, but they were exactly due to 
lack of the required experience. I have always had good support. Eleanore, a 
high school student working during a computer class and after school on such 
things as LFS, if I am not mistaken, could even be considered a newcomer, as I 
only remember her posts since March 2012, although with much better linux 
background than myself, when newcomer: this is not a shame for me, but it is a 
honour for her.

If we people were rude, you could just be ignored, at least in this thread. But 
we think that discussion is good and hope you have patience with us, as we have 
had with you (and others have had with me!).

(Mis)quoting what Bruce recently said: try to be on the technical side and 
remember that faces are not visible in written communication, so a relevant 
part of information about corporal language is missing, which could be 
misleading.

This is a place for technical discussions, so let us do it peacefully.

Finally, thank you for giving this wonderful people the opportunity to show 
their generous and kind personalities.

-- 
[]s,
Fernando
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-04 Thread Bruce Dubbs
Scott Robertson wrote:

 What part of:
 
 For each package:
 
 1. Using the tar program, extract the package to be built. In Chapter 5, 
 ensure 
 you are the lfs user when extracting the package.
 2. Change to the directory created when the package was extracted.
 3. Follow the book's instructions for building the package.
 
 do you not understand?
 
 Wow, again with the hostility.  

The reason it sounds hostile is because we spend a lot of time trying to 
explain 
and users regularly skip the explanations.  Whether you skipped reading them or 
not, your questions indicate that you did not understand them.

If you follow the instructions literally, they work.  Making inferences and 
adding things not in the book is where users run into problems.

   -- Bruce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-04 Thread Qrux

On May 4, 2012, at 8:42 AM, Bruce Dubbs wrote:

 Scott Robertson wrote:
 
 What part of:
 ...
 do you not understand?
 
 Wow, again with the hostility.  
 
 The reason it sounds hostile is because we spend a lot of time trying to 
 explain 
 and users regularly skip the explanations.  Whether you skipped reading them 
 or 
 not, your questions indicate that you did not understand them.
 
 If you follow the instructions literally, they work.  Making inferences and 
 adding things not in the book is where users run into problems.

Easy.  :)

* * *

Scott, please try to understand that LFS is put together by a volunteer corp of 
programmers and admins, not professional writers.  So, there will be parts of 
the book that are INCREDIBLY important to read, and parts of the book that are 
more optional in nature.  So, try to understand that the point of feedback 
that sounds like: What part of XYZ don't you understand? is a reminder 
(though not a particularly nice one) that the problem is likely some assumption 
you are making, and that much closer attention needs to be paid 
somewhere--though, in general, that where is not well-marked.

That having been said, LFS is a deeply technical project.  It's a bit like 
instructions to build your own particle accelerator, not an Ikea cabinet.  Yes, 
you'll need to read--then reread--every word, and assume that everything is 
important.

* * *

LFS devs, writers, and editors, please try to understand that the LFS can read 
like a list of GPS coordinates given at 1mm spacings without altitude and 
annotations.  If I follow it *exactly*, and assume no errors in the readings or 
the map, and I make the same set of assumptions as you, then I'll get there.  
But, if I miss by just a tiny bit, instead of walking along a ridge, I fall off 
the cliff.  Having been around a bit to see users struggle and struggle and 
struggle with the implied directions in Chapter 5 about unpacking stuff, 
(esp. when the rest of time you're repeating to people to follow the book 
VERBATIM), it seems that there could be more warning there.

Having said that, I recognize that the editors are professional techies--not 
professional writers.  At least, I hope not.  :)  If 1 out of every 10 
map-users falls off the cliff, is it worth thinking about how to annotate the 
map instead of insisting that people just stop falling over the cliff?  Most of 
the people who fall over don't seem to be saying the book is wrong (some do, 
but just have Ken gently accost at those people with obscure classical 
references...by the time he's done, they'll just think they've been given a 
Swedish massage in a part of their brain they never knew they had).

Does anyone know a technical writer that might be able to offer some time to 
address that one glaring issue?

The message that gets repeated over and over is that LFS is not a distro, but a 
book.  Well, then it's in an interesting category of being both a tech project 
but also a book.  When a written metaphor is weak, we don't usually tell 
readers to change their mental models (unless you're Joyce); we just get a red 
pen and write constipated thinking in the margins.  Surely there's some room 
to say that the book needs better writing, even if the instructions are 
technically correct.

Q


-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-04 Thread Bruce Dubbs
Qrux wrote:

 LFS devs, writers, and editors, please try to understand that the LFS can
 read like a list of GPS coordinates given at 1mm spacings without altitude
 and annotations.  If I follow it *exactly*, and assume no errors in the
 readings or the map, and I make the same set of assumptions as you, then I'll
 get there.  But, if I miss by just a tiny bit, instead of walking along a
 ridge, I fall off the cliff.  Having been around a bit to see users struggle
 and struggle and struggle with the implied directions in Chapter 5 about
 unpacking stuff, (esp. when the rest of time you're repeating to people to
 follow the book VERBATIM), it seems that there could be more warning there.

Computers are like that.  Get one bit wrong and the whole thing fails.

What more do you want?  5.3 gives explicit instructions.  5.4 is binutils and
the very first thing is a note to go back and ensure you understand 5.3.

What we are not going to do is put on every page:

tar -xf package.tar.xz
cd package
.
cd ..
rm -rf package package-build

The users need to learn to think about what needs to be done, not just 
copy/paste without understanding.

Also some users are just not ready for LFS.  Section iv says:  Building an LFS 
system is not a simple task. It requires a certain level of existing knowledge 
of Unix system administration in order to resolve problems and correctly 
execute 
the commands listed. In particular, as an absolute minimum, you should already 
have the ability to use the command line (shell) to copy or move files and 
directories, list directory and file contents, and change the current 
directory. 
It is also expected that you have a reasonable knowledge of using and 
installing 
Linux software.

   -- Bruce

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-04 Thread Qrux

On May 4, 2012, at 10:15 AM, Bruce Dubbs wrote:

 Qrux wrote:
 
 LFS devs, writers, and editors, please try to understand that the LFS can
 read like a list of GPS coordinates given at 1mm spacings without altitude
 and annotations.  If I follow it *exactly*, and assume no errors in the
 readings or the map, and I make the same set of assumptions as you, then I'll
 get there.  But, if I miss by just a tiny bit, instead of walking along a
 ridge, I fall off the cliff.  Having been around a bit to see users struggle
 and struggle and struggle with the implied directions in Chapter 5 about
 unpacking stuff, (esp. when the rest of time you're repeating to people to
 follow the book VERBATIM), it seems that there could be more warning there.
 
 Computers are like that.  Get one bit wrong and the whole thing fails.
 
 What more do you want?  5.3 gives explicit instructions.  5.4 is binutils and
 the very first thing is a note to go back and ensure you understand 5.3.
 
 What we are not going to do is put on every page:
 
 tar -xf package.tar.xz
 cd package
 .
 cd ..
 rm -rf package package-build

Would it be hard to put an unpack_warning entity before each of the Phase 1 
builds (all 2 or 3), or even the Phase 2 builds (those same 2 or 3)?

It's about signposts.  You know.  Like the ones with the squiggly road to 
indicate curves ahead.  Yes, speed limits, if rigorous observed will work most 
of time (though not always, like when HWY 17 was first built, with incorrectly 
counter-banked turns).  So, a bit more information, with a warning sign, can 
help, when there's a confusing situation.

I didn't say the instructions were wrong.  I said signposts--or better 
writing--could be used.  Writing means many things.  In this case, you seem to 
be focusing on the words themselves.  But what about structure?  A little 
repetition goes a long way.

 The users need to learn to think about what needs to be done, not just 
 copy/paste without understanding.

As a proxy example of ambiguity, do you not see the...confusion...some might 
experience when in your previous email, you said:

 If you follow the instructions literally, they work.  Making inferences and 
 adding things not in the book is where users run into problems.

Think!  Don't infer!

I'm saying it could use more clarity.  You're saying that you're not 
technically wrong.  Those two can exist at the same time.

Q



-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-04 Thread Anand Arumugam
On Fri, May 4, 2012 at 12:48 PM, Qrux qrux@gmail.com wrote:

 On May 4, 2012, at 8:42 AM, Bruce Dubbs wrote:

 Scott Robertson wrote:

 What part of:
 ...
 do you not understand?

 Wow, again with the hostility.

 The reason it sounds hostile is because we spend a lot of time trying to 
 explain
 and users regularly skip the explanations.  Whether you skipped reading them 
 or
 not, your questions indicate that you did not understand them.

 If you follow the instructions literally, they work.  Making inferences and
 adding things not in the book is where users run into problems.

 Easy.  :)

 * * *

 Scott, please try to understand that LFS is put together by a volunteer corp 
 of programmers and admins, not professional writers.  So, there will be parts 
 of the book that are INCREDIBLY important to read, and parts of the book that 
 are more optional in nature.  So, try to understand that the point of 
 feedback that sounds like: What part of XYZ don't you understand? is a 
 reminder (though not a particularly nice one) that the problem is likely some 
 assumption you are making, and that much closer attention needs to be paid 
 somewhere--though, in general, that where is not well-marked.

 That having been said, LFS is a deeply technical project.  It's a bit like 
 instructions to build your own particle accelerator, not an Ikea cabinet.  
 Yes, you'll need to read--then reread--every word, and assume that everything 
 is important.

 * * *

 LFS devs, writers, and editors, please try to understand that the LFS can 
 read like a list of GPS coordinates given at 1mm spacings without altitude 
 and annotations.  If I follow it *exactly*, and assume no errors in the 
 readings or the map, and I make the same set of assumptions as you, then I'll 
 get there.  But, if I miss by just a tiny bit, instead of walking along a 
 ridge, I fall off the cliff.  Having been around a bit to see users struggle 
 and struggle and struggle with the implied directions in Chapter 5 about 
 unpacking stuff, (esp. when the rest of time you're repeating to people to 
 follow the book VERBATIM), it seems that there could be more warning there.

 Having said that, I recognize that the editors are professional techies--not 
 professional writers.  At least, I hope not.  :)  If 1 out of every 10 
 map-users falls off the cliff, is it worth thinking about how to annotate the 
 map instead of insisting that people just stop falling over the cliff?  Most 
 of the people who fall over don't seem to be saying the book is wrong (some 
 do, but just have Ken gently accost at those people with obscure classical 
 references...by the time he's done, they'll just think they've been given a 
 Swedish massage in a part of their brain they never knew they had).

 Does anyone know a technical writer that might be able to offer some time to 
 address that one glaring issue?

 The message that gets repeated over and over is that LFS is not a distro, but 
 a book.  Well, then it's in an interesting category of being both a tech 
 project but also a book.  When a written metaphor is weak, we don't usually 
 tell readers to change their mental models (unless you're Joyce); we just get 
 a red pen and write constipated thinking in the margins.  Surely there's 
 some room to say that the book needs better writing, even if the instructions 
 are technically correct.

        Q


@Qrux.Qed: You have said it nicely... you do have a very valid point
on how to present the information...
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-04 Thread Bruce Dubbs
Qrux wrote:

 The users need to learn to think about what needs to be done, not just 
 copy/paste without understanding.
 
 As a proxy example of ambiguity, do you not see the...confusion...some might
 experience when in your previous email, you said:
 
 If you follow the instructions literally, they work.  Making inferences and
  adding things not in the book is where users run into problems.
 
 Think!  Don't infer!
 
 I'm saying it could use more clarity.  You're saying that you're not
 technically wrong.  Those two can exist at the same time.

But what you are asking for is more instructions, not more clarity.

If we add the unpack instructions for the first 10 packages, someone will 
complain when they get to package 11.

Repetition is not the same as clarity.

Section vi. It is also expected that you have a reasonable knowledge of using 
and installing Linux software.:

Section 3.1. Downloaded packages and patches will need to be stored somewhere 
that is conveniently available throughout the entire build. A working directory 
is also required to unpack the sources and build them. $LFS/sources can be used 
both as the place to store the tarballs and patches and as a working directory.

Section 5.3. General Compilation Instructions  For each package: Using the tar 
program, extract the package to be built. In Chapter 5, ensure you are the lfs 
user when extracting the package. Change to the directory created when the 
package was extracted.

How do we clarify that?  Repeat it for every package?  If there is something 
unclear, I'll change it, but I can't read it for the users.

We did add to 5.4: Go back and re-read the notes in the previous section. 
Understanding the notes labeled important will save you a lot of problems 
later.

Note that we did add a similar note to 5.5. GCC-4.7.0 - Pass 1.

   -- Bruce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-04 Thread Qrux

On May 4, 2012, at 1:53 PM, Bruce Dubbs wrote:

 Qrux wrote:
 
 The users need to learn to think about what needs to be done, not just 
 copy/paste without understanding.
 
 As a proxy example of ambiguity, do you not see the...confusion...some might
 experience when in your previous email, you said:
 
 If you follow the instructions literally, they work.  Making inferences and
 adding things not in the book is where users run into problems.
 
 Think!  Don't infer!
 
 I'm saying it could use more clarity.  You're saying that you're not
 technically wrong.  Those two can exist at the same time.
 
 But what you are asking for is more instructions, not more clarity.

I said several things.  The first is that there is some potential for ambiguity 
in statements like:

Think, but don't infer.

Then, as a practical approach, I suggested repetition--after I suggested more 
signposts that warn of potential pitfalls.  Don't latch on.  It was just an 
example.  You seem to be entrenched in the idea that if you need signposts, 
you're (careless|stupid|lazy).  That's not always the case.

One solution is to keep saying: Reread Section 5.

I'm exploring other solutions, because I think it's silly to insist that the 
book is well-written when, for every single release, many people are confused 
by how to begin Chapter 5.  I didn't have an issue.  But I can certainly 
understand how others might.

 Section vi. It is also expected that you have a reasonable knowledge of 
 using 
 and installing Linux software.:
 
 Section 3.1. Downloaded packages and patches will need to be stored 
 somewhere 
 that is conveniently available throughout the entire build. A working 
 directory 
 is also required to unpack the sources and build them. $LFS/sources can be 
 used 
 both as the place to store the tarballs and patches and as a working 
 directory.
 
 Section 5.3. General Compilation Instructions  For each package: Using the 
 tar 
 program, extract the package to be built. In Chapter 5, ensure you are the 
 lfs 
 user when extracting the package. Change to the directory created when the 
 package was extracted.
 
 How do we clarify that?  Repeat it for every package?  If there is something 
 unclear, I'll change it, but I can't read it for the users.

If you always have the same issue at the same point in the book, you might come 
to the conclusion that it's a hard part, and only (careful|smart|hard-working) 
people will understand.  You could also conclude that it's a confusing part 
(perhaps also hard), and while we need people to be able to read, we can also 
provide a warning here that highlights the relative importance of this 
statement.

The point is, there is plenty of prose in the book.  I could completely skip 
every word of Section i, Section ii, Section iii, Section iv, and Section v, 
and successfully build the book.  In fact, I've done exactly that, and had no 
issue.

But, then, you want me to read Section vi and take it as gospel?  Are you 
starting to understand what I mean about signposts?  There is nothing special 
about the appearance of Section iv.  Do you see how that might relate to 
organization of the information, and not the content?

 We did add to 5.4: Go back and re-read the notes in the previous section. 
 Understanding the notes labeled important will save you a lot of problems 
 later.

And, while the unpacking instructions in 5.3 are indeed marked as important, 
do you also see that Sections 5.1 and 5.2 are completely irrelevant to the 
explicit directions?  You know how some text books often have sections which 
are only meant to be read in an advanced course?  Well, 5.2 is exactly like 
that.  But, why strew information all across the book?  Chapter 5 is the 
backbone to the entire thing.  But it starts with a somewhat irrelevant section 
(5.1), and an advanced section (5.2).  Then, you want people to know that the 
Important part of (5.3) is *actually* important?

Here's something Important from 5.2:


Before continuing, be aware of the name of the working platform, often 
referred to as the target triplet. A simple way to determine the name of the 
target triplet is to run the config.guess script that comes with the source for 
many packages. Unpack the Binutils sources and run the script: ./config.guess 
and note the output. For example, for a modern 32-bit Intel processor the 
output will likely be i686-pc-linux-gnu.

Also be aware of the name of the platform's dynamic linker, often referred to 
as the dynamic loader (not to be confused with the standard linker ld that is 
part of Binutils). The dynamic linker provided by Glibc finds and loads the 
shared libraries needed by a program, prepares the program to run, and then 
runs it. The name of the dynamic linker for a 32-bit Intel machine will be 
ld-linux.so.2. A sure-fire way to determine the name of the dynamic linker is 
to inspect a random binary from the host system by running: readelf -l name of 
binary | grep 

Re: [lfs-support] Chapter 5 questions

2012-05-04 Thread Eleanore Boyd
On 5/4/2012 4:45 PM, Qrux wrote:
 On May 4, 2012, at 1:53 PM, Bruce Dubbs wrote:

 Qrux wrote:

 The users need to learn to think about what needs to be done, not just
 copy/paste without understanding.
 As a proxy example of ambiguity, do you not see the...confusion...some might
 experience when in your previous email, you said:

 If you follow the instructions literally, they work.  Making inferences and
 adding things not in the book is where users run into problems.
 Think!  Don't infer!

 I'm saying it could use more clarity.  You're saying that you're not
 technically wrong.  Those two can exist at the same time.
 But what you are asking for is more instructions, not more clarity.
 I said several things.  The first is that there is some potential for 
 ambiguity in statements like:

   Think, but don't infer.

 Then, as a practical approach, I suggested repetition--after I suggested more 
 signposts that warn of potential pitfalls.  Don't latch on.  It was just an 
 example.  You seem to be entrenched in the idea that if you need signposts, 
 you're (careless|stupid|lazy).  That's not always the case.

 One solution is to keep saying: Reread Section 5.

 I'm exploring other solutions, because I think it's silly to insist that the 
 book is well-written when, for every single release, many people are confused 
 by how to begin Chapter 5.  I didn't have an issue.  But I can certainly 
 understand how others might.

 Section vi. It is also expected that you have a reasonable knowledge of 
 using
 and installing Linux software.:

 Section 3.1. Downloaded packages and patches will need to be stored 
 somewhere
 that is conveniently available throughout the entire build. A working 
 directory
 is also required to unpack the sources and build them. $LFS/sources can be 
 used
 both as the place to store the tarballs and patches and as a working 
 directory.

 Section 5.3. General Compilation Instructions  For each package: Using the 
 tar
 program, extract the package to be built. In Chapter 5, ensure you are the 
 lfs
 user when extracting the package. Change to the directory created when the
 package was extracted.

 How do we clarify that?  Repeat it for every package?  If there is something
 unclear, I'll change it, but I can't read it for the users.
 If you always have the same issue at the same point in the book, you might 
 come to the conclusion that it's a hard part, and only 
 (careful|smart|hard-working) people will understand.  You could also conclude 
 that it's a confusing part (perhaps also hard), and while we need people to 
 be able to read, we can also provide a warning here that highlights the 
 relative importance of this statement.

 The point is, there is plenty of prose in the book.  I could completely skip 
 every word of Section i, Section ii, Section iii, Section iv, and Section v, 
 and successfully build the book.  In fact, I've done exactly that, and had no 
 issue.

 But, then, you want me to read Section vi and take it as gospel?  Are you 
 starting to understand what I mean about signposts?  There is nothing special 
 about the appearance of Section iv.  Do you see how that might relate to 
 organization of the information, and not the content?

 We did add to 5.4: Go back and re-read the notes in the previous section.
 Understanding the notes labeled important will save you a lot of problems 
 later.
 And, while the unpacking instructions in 5.3 are indeed marked as 
 important, do you also see that Sections 5.1 and 5.2 are completely 
 irrelevant to the explicit directions?  You know how some text books often 
 have sections which are only meant to be read in an advanced course?  Well, 
 5.2 is exactly like that.  But, why strew information all across the book?  
 Chapter 5 is the backbone to the entire thing.  But it starts with a somewhat 
 irrelevant section (5.1), and an advanced section (5.2).  Then, you want 
 people to know that the Important part of (5.3) is *actually* important?

 Here's something Important from 5.2:

 
 Before continuing, be aware of the name of the working platform, often 
 referred to as the target triplet. A simple way to determine the name of the 
 target triplet is to run the config.guess script that comes with the source 
 for many packages. Unpack the Binutils sources and run the script: 
 ./config.guess and note the output. For example, for a modern 32-bit Intel 
 processor the output will likely be i686-pc-linux-gnu.

 Also be aware of the name of the platform's dynamic linker, often referred 
 to as the dynamic loader (not to be confused with the standard linker ld that 
 is part of Binutils). The dynamic linker provided by Glibc finds and loads 
 the shared libraries needed by a program, prepares the program to run, and 
 then runs it. The name of the dynamic linker for a 32-bit Intel machine will 
 be ld-linux.so.2. A sure-fire way to determine the name of the dynamic linker 
 is to inspect a random binary from the host system 

Re: [lfs-support] Chapter 5 questions

2012-05-04 Thread Bruce Dubbs
Qrux wrote:

 One solution is to keep saying: Reread Section 5.

5.3?

 I'm exploring other solutions, because I think it's silly to insist that the
 book is well-written when, for every single release, many people are confused
 by how to begin Chapter 5.  I didn't have an issue.  But I can certainly
 understand how others might.

The problem is that some users are trying to build LFS before they have 
sufficient background.  You obviously do have the background, but it's not 
appropriate for others who have basically never used a shell to start LFS until 
they have developed more experience.  The first clue is when users refer to 
folders instead of directories.

 If you always have the same issue at the same point in the book, you might
 come to the conclusion that it's a hard part, and only
 (careful|smart|hard-working) people will understand.  You could also conclude
 that it's a confusing part (perhaps also hard), and while we need people to
 be able to read, we can also provide a warning here that highlights the
 relative importance of this statement.
 
 The point is, there is plenty of prose in the book.  I could completely skip
 every word of Section i, Section ii, Section iii, Section iv, and Section v,
 and successfully build the book.  In fact, I've done exactly that, and had no
 issue.

Yes, you could, but as I said, you have the appropriate background.  I think 
everyone needs to read vi and vii.

 But, then, you want me to read Section vi and take it as gospel?  Are you
 starting to understand what I mean about signposts?  There is nothing special
 about the appearance of Section iv.  Do you see how that might relate to
 organization of the information, and not the content?

Speaking of understanding, what does that mean?

 We did add to 5.4: Go back and re-read the notes in the previous section.
  Understanding the notes labeled important will save you a lot of problems
 later.
 
 And, while the unpacking instructions in 5.3 are indeed marked as
 important, do you also see that Sections 5.1 and 5.2 are completely
 irrelevant to the explicit directions?  You know how some text books often
 have sections which are only meant to be read in an advanced course?  Well,
 5.2 is exactly like that.  But, why strew information all across the book?
 Chapter 5 is the backbone to the entire thing.  But it starts with a somewhat
 irrelevant section (5.1), and an advanced section (5.2).  Then, you want
 people to know that the Important part of (5.3) is *actually* important?
 
 Here's something Important from 5.2:

[deleted quote]

I can agree that the section of 5.2 could be changed to a note.

There are 3 important sections in chapter 5, and 6 in chapter 6.

 I'd argue that it's not important at all.  Maybe to someone who's taking LFS
 and working on a derivative work.  Or to someone who's messing about with the
 toolchain.
 
 But, put simply: it's pretty hard to separate the complete irrelevance of
 5.2-Important from the absolute necessity of 5.3-Important.  This is an
 issue of poorly structured book organization--not the information intended to
 be conveyed in the book.

Is the extent of the changes you think are needed to just relabel one section?

   -- Bruce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-04 Thread Qrux

On May 4, 2012, at 3:23 PM, Bruce Dubbs wrote:

 But, why strew information all across the book?
 Chapter 5 is the backbone to the entire thing.  But it starts with a somewhat
 irrelevant section (5.1), and an advanced section (5.2).  Then, you want
 people to know that the Important part of (5.3) is *actually* important?
 
 Here's something Important from 5.2:
 
 [deleted quote]
 
 I can agree that the section of 5.2 could be changed to a note.
 
 There are 3 important sections in chapter 5, and 6 in chapter 6.
 
 I'd argue that it's not important at all.  Maybe to someone who's taking LFS
 and working on a derivative work.  Or to someone who's messing about with the
 toolchain.
 
 But, put simply: it's pretty hard to separate the complete irrelevance of
 5.2-Important from the absolute necessity of 5.3-Important.  This is an
 issue of poorly structured book organization--not the information intended to
 be conveyed in the book.
 
 Is the extent of the changes you think are needed to just relabel one section?

If LFS is just a source code project, then to some extent you can say that 
prose style or organization is irrelevant.  It's not, because it's often 
repeated that it's a book, as well.  So, style is important, because 
organization can aid understanding.

Which is to say, I think you missed my point about Sections (i) through (v).  I 
didn't say (vi) or (vii), which I agree are more important, if not misplaced.  
But, (i) through (v) are pretty much irrelevant to a user.  Why not just start 
at (vi)?  Sure, the original creator should get a foreword, but then jump to 
the stuff that matters.  Then, go straight into the build bits.  All the 
motivation stuff--which, while fine for the start, should not be in the same 
(section|chapter) whatever as the irrelevant information.  That should be 
canned into an appendix, or the *actually* important bits (e.g. vi and vii) 
moved into a different part of the book.

As for the rest of what I said, sure...you could boil it down to:

* Get rid of 5.1 and 5.2, or maybe move them into 4.x as a footnote.

* The start of 5 should be: You'd better start paying attention, right 
the frak now.

* Followed immediately by Important FOR USERS: Here's how to unpack 
stuff...blah blah blah

So, yes, you could take what I've said and do some minor edits, but that feels 
like CSS decorating a web page.  Alternatively, you could consider making 
changes to the organization of the book as it impacts readability.  
Traditionally, editors do that.  In this case, you and Matt are more the 
technical reviewers.  I assume that neither of you are writers...If so, then I 
apologize, but I still stand by my analysis.  I'm saying the organization of 
the prose bits needs work.  Which is different from Well, dude--spit it out.  
You want the red to be redder and the 'Important' to be a larger point-size? 
which seems to be more of what you're after.

Q



-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-04 Thread Bruce Dubbs
Qrux wrote:

 If LFS is just a source code project, then to some extent you can say that
 prose style or organization is irrelevant.  It's not, because it's often
 repeated that it's a book, as well.  So, style is important, because
 organization can aid understanding.

The descriptions and the organization is important, but it satisfies most users.
We probably go through this discussion two are three time a year.  Each time 
it's a single user that doesn't quite get it (you got it without problem). 
Since we have over 23000 registered users, I'd say that the vast majority get 
value from the book as it is.  I'm not willing to make major changes for a 
vocal 
few.  We will have to agree to disagree and move on.

   -- Bruce


-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-04 Thread Anand Arumugam
On Fri, May 4, 2012 at 7:02 PM, Bruce Dubbs bruce.du...@gmail.com wrote:
 Qrux wrote:

 If LFS is just a source code project, then to some extent you can say that
 prose style or organization is irrelevant.  It's not, because it's often
 repeated that it's a book, as well.  So, style is important, because
 organization can aid understanding.

 The descriptions and the organization is important, but it satisfies most 
 users.
 We probably go through this discussion two are three time a year.  Each time
 it's a single user that doesn't quite get it (you got it without problem).
 Since we have over 23000 registered users, I'd say that the vast majority get
 value from the book as it is.  I'm not willing to make major changes for a 
 vocal
 few.  We will have to agree to disagree and move on.


Just because not many emails or voices out their opinion(s) like @Qrux
has done, doesn't mean that they get it. They may not be able to put
forth their thoughts like @Qrux has done.

LFS is a fantastic resource, but like @Qrux is saying, there is room
for improvement to make it even better.

If some information on how to contribute in terms of improving the
content or presentation style in the How to contribute
(http://www.linuxfromscratch.org/lfs/contribute.html) page will be
helpful and I would like to pitch in whatever ways I can.

cheers...
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-04 Thread Gordon Findlay
On Sat, May 5, 2012 at 3:28 PM, Anand Arumugam anand.aru...@gmail.comwrote:

 On Fri, May 4, 2012 at 7:02 PM, Bruce Dubbs bruce.du...@gmail.com wrote:
  Qrux wrote:
 
  If LFS is just a source code project, then to some extent you can say
 that
  prose style or organization is irrelevant.  It's not, because it's often
  repeated that it's a book, as well.  So, style is important, because
  organization can aid understanding.
 
  The descriptions and the organization is important, but it satisfies
 most users.
  We probably go through this discussion two are three time a year.  Each
 time
  it's a single user that doesn't quite get it (you got it without
 problem).
  Since we have over 23000 registered users, I'd say that the vast
 majority get
  value from the book as it is.  I'm not willing to make major changes for
 a vocal
  few.  We will have to agree to disagree and move on.
 

 Just because not many emails or voices out their opinion(s) like @Qrux
 has done, doesn't mean that they get it. They may not be able to put
 forth their thoughts like @Qrux has done.

 LFS is a fantastic resource, but like @Qrux is saying, there is room
 for improvement to make it even better.

 If some information on how to contribute in terms of improving the
 content or presentation style in the How to contribute
 (http://www.linuxfromscratch.org/lfs/contribute.html) page will be
 helpful and I would like to pitch in whatever ways I can.

 cheers...
 --
 http://linuxfromscratch.org/mailman/listinfo/lfs-support
 FAQ: http://www.linuxfromscratch.org/lfs/faq.html
 Unsubscribe: See the above information page


Before deciding how to change the book, shouldn't contributors  be clear
about (a) the purpose and (b) the audience of the book?

It seems to me that there is a mismatch here: people have different views
about the audience and purpose, so differ in their perceptions of the book.

In my perception the book currently assumes that the audience is people
with some (considerable) understanding of the command-line, and OS concepts
in general (for example the fact that 'source directory' might have
different meanings depending on context). If that is to remain the
audience, there needs to be a method for coping with people outside the
audience who happen to wander in - just as my local bar has a procedure for
dealing with under-age people who wander in.

And the purpose of the book (again, my perception) is educational, so the
explanations about the tool-chain modifications and how cross-compilation
works are not extras, but an integral part of the book.  The aim is to
learn, not just to get to the end.

What that coping procedure should be is a second debate.

Slainte
Gordon
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-03 Thread Tony Sauri
On Thu, 03 May 2012 16:52, Scott Robertson wrote:
 Hello,

 Can someone explain what the directory structure is supposed to look like
 in Chapter 5?

 1. Where does the Binutils folder/directory go? Where does the GCC folder
 go? That's all the further I have gotten so far.  I think I will probably
 want to know where all the folders go.   I created a separate partition for
 LFS, and put the folders there, is that right, or not? Or is it supposed to
 go into the /mnt/lfs folder? Or somewhere else?


At Chapter 3.1 Packages and Patchws Introduction.
 $LFS/sources can be used both as the place to store the tarballs and patches 
and as a working directory. By using this directory, the required elements 
will be located on the LFS partition and will be available during all stages 
of the building process.

To create this directory, execute the following command, as user root, before 
starting the download session:

mkdir -v $LFS/sources

and 

At Chapter 5.3 General Compilation Instructions

 Important

To re-emphasize the build process:

   1.  Place all the sources and patches in a directory that will be 
accessible from the chroot environment such as /mnt/lfs/sources/. Do not put 
sources in /mnt/lfs/tools/.
   2.  Change to the sources directory.
   3.  For each package:
 1.Using the tar program, extract the package to be built. 
In Chapter 5, ensure you are the lfs user when extracting the package.
 2.Change to the directory created when the package was 
extracted.
 3. Follow the book's instructions for building the package.
 4.Change back to the sources directory.
 5.Delete the extracted source directory and any 
package-build directories that were created in the build process unless 
instructed otherwise.


 2.  Can someone also explain permissions?  Who is supposed to have
 permissions on what?  What permissions are supposed to be on the Binutils
 and GCC directories?  root?  lfs? 

 And what are they supposed to be? read, write and execute?

At Chapter 4.3 Adding thge LFS User
When logged in as user root, making a single mistake can damage or destroy a 
system. Therefore, we recommend building the packages in this chapter as an 
unprivileged user. You could use your own user name, but to make it easier to 
set up a clean working environment, create a new user called lfs as a member 
of a new group (also named lfs) and use this user during the installation 
process. As root, issue the following commands to add the new user:

At Chapter 4.4 Setting up the Environment
Setting the user file-creation mask (umask) to 022 ensures that newly created 
files and directories are only writable by their owner, but are readable and 
executable by anyone (assuming default modes are used by the open(2) system 
call, new files will end up with permission mode 644 and directories with 
mode 755).



 3.  What directory am I supposed to be in when I execute the commands?  As
 I said, I have an LFS partition, so am I supposed to be in /media/LFS?  Or
 more like /mnt/lfs? Or somewhere else?

See answer above or to spell it out:
$LFS/sources/binutils-x.xx

 4. Also, what does the two dots and slash mean?    ../(some command) 

 How does that factor into it?



On Thu, 03 May 2012 18:39, Scott Robertson wrote:
 1) I don't think that is true.  The manual contradicts itself.  On the one
 hand it tells you to put stuff in $LFS/tools, but then it specifically
 recommends NOT putting things in there during the initial compilation
 process.  It also tells people to create an LFS partition and suggests that
 it be used, but doesn't say how or when (at least as far as I've gotten).
 It also seems to contradict itself by telling people to uncompress the
 tar.bz2 files, but then proceeds as if they were not uncompressed, so
 clearly there are some contradictory logic errors in the manual.

It clearly says that the COMPILED programes go into $LFS/tools at 4.2 Creating 
the $LFS/tools directory:

All programs compiled in Chapter 5  will be installed under $LFS/tools to keep 
them separate from the programs compiled in Chapter 6. The programs compiled 
here are temporary tools and will not be a part of the final LFS system. By 
keeping these programs in a separate directory, they can easily be discarded 
later after their use. This also prevents these programs from ending up in 
the host production directories (easy to do by accident in Chapter 5).

In 5.3 General Compilation Instructions: 

Place all the sources and patches in a directory that will be accessible from 
the chroot environment such as /mnt/lfs/sources/. Do not put sources 
in /mnt/lfs/tools/.

This is not a contradiction.


..sending me 4 unhelpful e-mails 

Dont know where you get the 4 messages from ... I only sent 2 but both were 
addressed to you personally and the list.  This is a standard practice with 
list server mail which I believe is to 

Re: [lfs-support] Chapter 5 questions

2012-05-03 Thread Fernando de Oliveira
--- Em qui, 3/5/12, Scott Robertson escreveu:

 De: Scott Robertson 
 Assunto: [lfs-support] Chapter 5 questions
 Para: lfs-support lfs-support@...
 Data: Quinta-feira, 3 de Maio de 2012, 1:53
 Hello,
 
 Can someone explain what the directory structure is supposed
 to look like in Chapter 5?
 
 1. Where does the Binutils folder/directory go? Where does
 the GCC folder go? That's all the further I have gotten so
 far.  I think I will probably want to know where all the
 folders go.   I created a separate partition for LFS, and
 put the folders there, is that right, or not?
 Or is it supposed to go into the /mnt/lfs folder? Or
 somewhere else?

The separate partition for LFS is supposed to be mount at /mnt/lfs, by default. 
You can always change, but why? It is easear using that:

So, in Chapter 2.4: 
Quote
export LFS=/mnt/lfs

Next, create the mount point and mount the LFS file system by running:

mkdir -pv $LFS
mount -v -t ext3 /dev/xxx $LFS

Replace xxx with the designation of the LFS partition./UnQuote

In chapter 5, you are building tools in $LFS/tools directory. Everything 
should be owned by lfs user: $LFS/{tools,source}/{,*}, to avoid the risk of 
braking the host system when issuing commands which are dangerous as root.



So, You should not have /media/LFS, but /mnt/lfs.




[]s,
Fernando
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-03 Thread Fernando de Oliveira
Forgot to mention:

You might thank Philippe Delavalade and Tony Sauri, as they are trying to be 
helpful with good correct information they have written to you.

In the beginning, we all have these doubts, some find their own way through and 
this list has volunteers who are part of LFS/BLFS books others not, non if them 
is being paid to help others.

The book has great consistency, many build it using tools which automatize the 
build process, which fail at the minimum inconsistency.

Welcome to the list and hope, after some initial difficulties, you will enjoy 
this book.


[]s,
Fernando
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-03 Thread Eleanore Boyd
On 5/3/2012 1:40 AM, Scott Robertson wrote:
 (snip)

 2) Why are you here if you aren't going to be of any help?  I'm not coming 
 here with no experience with Linux.  I've also noticed several problems with 
 the manual, so clearly this is a work in progress.  You, Tony, apparently 
 can't even be bothered to get it right yourself the first time...sending me 4 
 unhelpful e-mails only to say you won't help. 

 (snip)
To repeat what others might or might not have said, WE CAN'T HELP if 
you're going to ask a question, then turn around and say that our answer 
is wrong. We don't care if you have prior experience in Linux; if you 
ask questions like that, you're going to sound like a beginner. And, to 
me at least, if you're going to complain about this being a work in 
progress, get out of Linux. The whole thing is nothing more than a work 
in progress. Even Windows is a work in progress, if you want to argue.

Now, either FOLLOW the book EXACTLY, or go somewhere else.

Elly
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-03 Thread Scott Robertson
Ahh, ok, yes thank you, that is more what I am looking for.   So you can have 
the Binutils-xx AND Binutils-build in the same /mnt/lfs/sources directory.  I 
know everyone disagrees with me, but I still think that isn't clear given that 
quote on page 35 recommending that Binutils be built outside the sources 
directory.  But maybe it is just a wording issue.  I guess in essence, there 
are two sources directories:  

/mnt/lfs/sources AND /mnt/lfs/sources/Binutils-xx


So the GCC directory is similar in that it goes in /mnt/lfs/sources/GCC-4.x  is 
that right?   I don't think the book explicitly says it, but I guess you are 
supposed to uncompress the GCC-4.x tar file into the GCC-4.x directory first, 
right?  And then the GMP, MPFR and MPC packages go into the GCC-4.x directory? 
So the folder structure  would be:

/mnt/lfs/sources/GCC-4.x/

/mnt/lfs/sources/GCC-4.x/GMP
/mnt/lfs/sources/GCC-4.x/MPFR
/mnt/lfs/sources/GCC-4.x/MPC

and then you put the gcc-4.x-cross_compile-1.patch into the 
/mnt/lfs/sources/GCC-4.x directory right?

Then you create the GCC-Build directory.  So that would be   
/mnt/lfs/sources/GCC-Build
so you would have:
/mnt/lfs/sources/GCC-4.x  and
/mnt/lfs/sources/GCC-Build

is that right?








- Original Message -
From: Philippe Delavalade philippe.delaval...@orange.fr
To: Scott Robertson scottrobertso...@yahoo.com
Cc: lfs-support@linuxfromscratch.org
Sent: Thursday, May 3, 2012 4:20 AM
Subject: Re: [lfs-support] Chapter 5 questions

Le jeudi 03 mai à 09:47, Scott Robertson a écrit :
 Page 35 of the book specifically says:
 
 The Binutils documentation recommends building Binutils outside of the 
 source directory in a dedicated build directory:
 
 mkdir -v ../binutils-build
 cd ../binutils-build
 
 
 Should I just disregard that and put it inside the sources directory?  If I 
 follow the directions, I am not supposed to put the binutils-build directory 
 inside the sources directory? If I don't put it in the sources directory, 
 then where is the binutils-build directory supposed to go?  Can someone 
 explain what the full path is supposed to be?
 Is it supposed to be /mnt/lfs/sources/binutils-build  or something else? 
Is the binutils-build directory inside the lfs/sources directory or outside
of it?

Well, first, reply on the list and don't top post.

For your question, there is a general sources directory : $LFS/sources ; and
each package has is own source directory, the one obtained when untaring.

So, for binutils, you have the file binutils-xx.tar.bz2 in $LFS/sources ;
after
tar -xvf binutils-xx.tar.bz2
you obtain a subdirectory binustils-xx in which you enter ;
you are in $LFS/sources/binutils-xx which is the source directory for
binutils ;
then you create ../binutils-build which is in $LFS/sources ;
then cd ../binutils-build and you are in $LFS/sources/binutils-build. And
so on.

In $LFS/sources you have the two directories binutils-xx and
binutils-build.

When binutils is built, you go in £LFS/sources with cd .. and then you
have to delete those two directories with
rm -vfr binutils-xx and rm -vfr binutils-build ; the 'f' is possibly 
unmandatory.

I hope I'm clear but English is not my native language :-)

-- 
Ph. Delavalade
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-03 Thread Fernando de Oliveira
Please, make sure you are reading the latest stable LFS7.1:

Stable LFS Errata: http://www.linuxfromscratch.org/lfs/errata/stable

Stable LFS: http://www.linuxfromscratch.org/lfs/view/stable/

Below, reproduced from General Compilation Instructions of Chapter 5, which 
can found in:

http://www.linuxfromscratch.org/lfs/view/stable/chapter05/generalinstructions.html

read Important:

Quote[...]


  Finally, one last important item must be emphasized:


  
  
Important
  
  
Before issuing the build instructions for a package, the
package should be unpacked as user lfs, and a cd into the 
created
directory should be performed. The build instructions assume
that the bash shell is in use./UnQuote


This is just for building the tools. In next chapter, there are other 
instructions.

Most respectfully, some advice follows.

This book has been tested by many people, users and developers, for many years. 
Of course, there might be flaws, but not so many. When we start first time, the 
great amount of information is difficult to keep in mind and re-reading is 
essential, otherwise the time wasted will be enourmous.

[]'s
Fernando
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-03 Thread Philippe Delavalade
Le jeudi 03 mai à 15:16, Scott Robertson a écrit :
 Ahh, ok, yes thank you, that is more what I am looking for.   So you can have 
 the Binutils-xx AND Binutils-build in the same /mnt/lfs/sources directory.  I 
 know everyone disagrees with me, but I still think that isn't clear given 
 that quote on page 35 recommending that Binutils be built outside the sources 
 directory.  But maybe it is just a wording issue.  I guess in essence, there 
 are two sources directories:  
 
 /mnt/lfs/sources AND /mnt/lfs/sources/Binutils-xx
 
 
 So the GCC directory is similar in that it goes in /mnt/lfs/sources/GCC-4.x  
 is that right?   I don't think the book explicitly says it, but I guess you 
 are supposed to uncompress the GCC-4.x tar file into the GCC-4.x directory 
 first, right?  And then the GMP, MPFR and MPC packages go into the GCC-4.x 
 directory? So the folder structure  would be:
 
 /mnt/lfs/sources/GCC-4.x/

Yes and this will repeat for every package in chapter 5 and then in chapter
6.


 
 /mnt/lfs/sources/GCC-4.x/GMP
 /mnt/lfs/sources/GCC-4.x/MPFR
 /mnt/lfs/sources/GCC-4.x/MPC

Thats' right but you should have understood this by reading the commands
:-)

 
 and then you put the gcc-4.x-cross_compile-1.patch into the
 /mnt/lfs/sources/GCC-4.x directory right?

No. Use the patch if it is required by the book (I think it's not the case
now but I'm not sure because I don't know what version of the book your are
following).

Nevertheles, when a patch is needed, you have not to copy it in the source
directory of the package.

 
 Then you create the GCC-Build directory.  So that would be   
 /mnt/lfs/sources/GCC-Build
 so you would have:
 /mnt/lfs/sources/GCC-4.x  and
 /mnt/lfs/sources/GCC-Build
 
 is that right?

Yes except that case is sensitive and that it is gcc and not GCC, gcc-build
and not GCC-Build.

-- 
Ph. Delavalade
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-03 Thread Ken Moffat
On Thu, May 03, 2012 at 04:15:57PM +0200, Philippe Delavalade wrote:
 Le jeudi 03 mai à 15:16, Scott Robertson a écrit :
  
  So the GCC directory is similar in that it goes in 
  /mnt/lfs/sources/GCC-4.x  is that right?   I don't think the book 
  explicitly says it, but I guess you are supposed to uncompress the GCC-4.x 
  tar file into the GCC-4.x directory first, right?  And then the GMP, MPFR 
  and MPC packages go into the GCC-4.x directory? So the folder structure  
  would be:
  
  /mnt/lfs/sources/GCC-4.x/
 
 Yes and this will repeat for every package in chapter 5 and then in chapter
 6.

 Actually, the phrase 'uncompress the GCC-4.x tar file into the
GCC-4.x directory' can be interpreted in more than one way.

 Scott probably meant it correctly, but just in case - you should be
in /mnt/lfs/sources and extract the tarball there (tar -xvf for any
recent version of tar), do NOT first create a directory - probably
wouldn't cause any damage, but would be unnecessary.

 Also note that I'm suggesting tar -xvf because sometimes the
directory name might not be exactly the same as the tarball name.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-03 Thread Bruce Dubbs
Scott Robertson wrote:
 1) I don't think that is true.  The manual contradicts itself.  On the one
 hand it tells you to put stuff in $LFS/tools, but then it specifically
 recommends NOT putting things in there during the initial compilation
 process.  It also tells people to create an LFS partition and suggests that
 it be used, but doesn't say how or when (at least as far as I've gotten). It
 also seems to contradict itself by telling people to uncompress the tar.bz2
 files, but then proceeds as if they were not uncompressed, so clearly there
 are some contradictory logic errors in the manual.

Have you read section 5.3?  Is there something there you don't understand?

   -- Bruce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-03 Thread Scott Robertson
Hi,

You are one of the main guys, right?  I think I am going to have to re-read 
some things. I downloaded the 7.0 PDF before 7.1 came out and actually printed 
it out (7.0) so I am kind of locked into 7.0 as I don't want to print out the 
whole 7.1, but I am trying to check it as well.  

I started reading 7.0, and I was doing OK until about Chapter 5.  Until I 
realized that some of my directories didn't seem right.  Somehow I ended up 
with just a sources directory on the LFS partition.  I'm not a hardened 
expert in Linux yet, but I do have some knowledge and I have alot of experience 
with computers in general.  Am I required to be an expert to do this?  This is 
my first attempt at LFS. I am trying to learn Linux at a deeper level.


I think I have a fair understanding of things, except for a few things.  As I 
said, I have a sources directory on the LFS partition that I created, but I 
don't have a /lfs/tools directory there, so i got a little confused.  I am 
basically trying to figure out what directory structure I am supposed to have 
without the $LFS.  I could be wrong, but I don't get the feeling that the book 
explains precisely what the directory structure is supposed look like by the 
time you get through with 5.4 or so.  I guess what threw me was in Section 5.4, 
it says:
The Binutils documentation recommends building Binutils outside of the source 
directory in a dedicated build directory:
As I mentioned in one of my previous e-mails to the group, I wasn't too sure 
what this meant.  I didn't understand what ...outside of the source 
directory... meant.  I thought if it was truly outside the source directory, 
then where does it go?  But I think I realize now that Binutils-xx is called a 
source directory and /lfs/sources is also called a sources directory.  

And again, if it is truly outside the source directory, then there might be 
permissions problems.  As it stands, I think it can be confusing when to run 
things as root and when to run them as lfs user as the book doesn't always 
say.  I can generally figure it our based on the error messages though.  

Also, I think it can be a little confusing as to what directory I am supposed 
to be in when running the commands sometimes, as that is very important too.



Changing course: 

Are you guys aware that a fairly substantial number of the web links in the 
book no 
longer work?  I made a list and tried to send it to lfs-dev, but that 
was before I realized that I had to join it first, so not sure if anyone 
received it.  


I also tried e-mailing lfs-support-ow...@linuxfromscratch.org about a 
week ago to get some help, but never heard back from anyone.  I guess 
maybe that e-mail address isn't monitored.  I tried proceeding without 
help, but came up against a wall.  As a last ditch effort, I e-mailed 
Gerard Beekmans personally and he told me to sign up for the lfs-support list, 
which is where I am at now.

I think I am used to a more traditional Sign up for a login account, login,  
and then post to a forum format rather than people e-mailing each other, but I 
think I am getting the idea now.



-Scott






- Original Message -
From: Bruce Dubbs bruce.du...@gmail.com
To: LFS Support List lfs-support@linuxfromscratch.org
Cc: 
Sent: Thursday, May 3, 2012 11:20 AM
Subject: Re: [lfs-support] Chapter 5 questions

Scott Robertson wrote:
 1) I don't think that is true.  The manual contradicts itself.  On the one
 hand it tells you to put stuff in $LFS/tools, but then it specifically
 recommends NOT putting things in there during the initial compilation
 process.  It also tells people to create an LFS partition and suggests that
 it be used, but doesn't say how or when (at least as far as I've gotten). It
 also seems to contradict itself by telling people to uncompress the tar.bz2
 files, but then proceeds as if they were not uncompressed, so clearly there
 are some contradictory logic errors in the manual.

Have you read section 5.3?  Is there something there you don't understand?

   -- Bruce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-03 Thread Scott Robertson
Yes, thanks for clearing that up.  The packages are (as far as I can tell) all 
compressed with either a bz2 or gz extension, which means they are compressed.  
They are also tar'd, but it is my understanding that tar isn't a compressed 
format.  So I think technically they have to be uncompressed and then untar'd, 
although that happens at the same time and almost instantly.  I also know not 
to actually create the directory first.  

I am also aware that everything is case sensitive, if I am referring to things 
in a case-insensitive way, rest assured I am aware that the case(s) may change.




- Original Message -
From: Ken Moffat k...@linuxfromscratch.org
To: LFS Support List lfs-support@linuxfromscratch.org
Cc: 
Sent: Thursday, May 3, 2012 11:27 AM
Subject: Re: [lfs-support] Chapter 5 questions

On Thu, May 03, 2012 at 04:15:57PM +0200, Philippe Delavalade wrote:
 Le jeudi 03 mai à 15:16, Scott Robertson a écrit :
  
  So the GCC directory is similar in that it goes in 
  /mnt/lfs/sources/GCC-4.x  is that right?   I don't think the book 
  explicitly says it, but I guess you are supposed to uncompress the GCC-4.x 
  tar file into the GCC-4.x directory first, right?  And then the GMP, MPFR 
  and MPC packages go into the GCC-4.x directory? So the folder structure  
  would be:
  
  /mnt/lfs/sources/GCC-4.x/
 
 Yes and this will repeat for every package in chapter 5 and then in chapter
 6.

Actually, the phrase 'uncompress the GCC-4.x tar file into the
GCC-4.x directory' can be interpreted in more than one way.

Scott probably meant it correctly, but just in case - you should be
in /mnt/lfs/sources and extract the tarball there (tar -xvf for any
recent version of tar), do NOT first create a directory - probably
wouldn't cause any damage, but would be unnecessary.

Also note that I'm suggesting tar -xvf because sometimes the
directory name might not be exactly the same as the tarball name.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-03 Thread Bruce Dubbs
Scott Robertson wrote:

Please don't top post on the LFS lists.

 I started reading 7.0, and I was doing OK until about Chapter 5.  Until I
 realized that some of my directories didn't seem right.  Somehow I ended up
 with just a sources directory on the LFS partition.  I'm not a hardened
 expert in Linux yet, but I do have some knowledge and I have alot of
 experience with computers in general.  Am I required to be an expert to do
 this?  This is my first attempt at LFS. I am trying to learn Linux at a
 deeper level.

We try to give you a vehicle for learning.

 I think I have a fair understanding of things, except for a few things.  As I
 said, I have a sources directory on the LFS partition that I created, but I
 don't have a /lfs/tools directory there, so i got a little confused.  

Section 2.3 tells you how to format a new partition.  At the end of section 2.4 
you should only have /mnt/lfs/lost+found/

Section 3.1 creates $LFS/sources and shows you how to populate it.  Be sure to 
read the 2nd paragraph if you are using 7.0 because urls change.

Section 4.2 creates mkdir -v $LFS/tools

Section 5.3 gives the overview of what you are going to do to build the 
packages.

I am
 basically trying to figure out what directory structure I am supposed to have
 without the $LFS.  I could be wrong, but I don't get the feeling that the
 book explains precisely what the directory structure is supposed look like by
 the time you get through with 5.4 or so.  

That's probably because you don't really have much of a Linux background.  It 
appears to me from your basic questions that you need some experience as 
expressed in section vi. Prerequisites.  (we know that the middle link is dead).

Try https://www.linux.com/learn/new-user-guides instead.

 I guess what threw me was in
 Section 5.4, it says: The Binutils documentation recommends building
 Binutils outside of the source directory in a dedicated build directory: As
 I mentioned in one of my previous e-mails to the group, I wasn't too sure
 what this meant.  I didn't understand what ...outside of the source
 directory... meant.  I thought if it was truly outside the source
 directory, then where does it go? 

Do you know what the source directory is?  Do you know what it means to be 'in' 
a directory?

 But I think I realize now that Binutils-xx
 is called a source directory and /lfs/sources is also called a sources
 directory.
 
 And again, if it is truly outside the source directory, then there might be
 permissions problems.  As it stands, I think it can be confusing when to run
 things as root and when to run them as lfs user as the book doesn't always
 say.  

Yes it does.  It's not repeated every page though.

 I can generally figure it our based on the error messages though.
 
 Also, I think it can be a little confusing as to what directory I am supposed
 to be in when running the commands sometimes, as that is very important too.

What part of:

For each package:

1. Using the tar program, extract the package to be built. In Chapter 5, ensure 
you are the lfs user when extracting the package.
2. Change to the directory created when the package was extracted.
3. Follow the book's instructions for building the package.

do you not understand?

 Are you guys aware that a fairly substantial number of the web links in the
 book no longer work?  I made a list and tried to send it to lfs-dev, but that
 was before I realized that I had to join it first, so not sure if anyone
 received it.

You are using a book that was published in September.  Links change.  It's up 
to 
you to find new ones.  The books are like RFCs.  Once published, we do not 
change that version.


 
 I also tried e-mailing lfs-support-ow...@linuxfromscratch.org about a week
 ago to get some help, but never heard back from anyone.  

That's the mailman internal address.  You have the right address now.

 I think I am used to a more traditional Sign up for a login account, login,
 and then post to a forum format rather than people e-mailing each other, but
 I think I am getting the idea now.

http://www.linuxfromscratch.org/mail.html gives the mailing lists and links to 
where you need to go to sign up.

   -- Bruce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-03 Thread Rick Shelton
On Thu, May 3, 2012 at 1:30 PM, Bruce Dubbs bruce.du...@gmail.com wrote:
 Scott Robertson wrote:

 I think I have a fair understanding of things, except for a few things.  As I
 said, I have a sources directory on the LFS partition that I created, but I
 don't have a /lfs/tools directory there, so i got a little confused.

... [ and there was other stuff about directories ] ...

The book talks about $LFS/sources or $LFS/tools and such. This is
a more formalized way to reference those directories because the value
of the LFS environment variable may vary, as long as that value is
used consistently throughout a build.
LFS users on the mailing lists talk about /mnt/lfs/sources and such.
This is like simplifying to the de facto standard. The specific path
/mnt/lfs is understood to be whatever you named your top-level build
directory.

So just remember that the discussions on the mailing lists sometimes
elaborate the value of the LFS environment variable.

Confusion about what the book is describing is one thing. But during
the first pass (or two or three) through the LFS book, it is a good
idea to follow the instructions to the letter. At least until you feel
confident with the process.

The LFS project has been around since 1999. Over-thinking the
instructions at this stage of the project's maturity should only be
done by professionals. Or at least only the LFS devs. ;)

Just use the recommended values from the book. Read the book carefully
but don't over-think it. Stick to the one version. Ask one question at
a time.
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-03 Thread Tony Sauri
On Fri, 04 May 2012 01:26, Scott Robertson wrote:
 No hard feelings mate? 

None here and no offence taken at anty time.

I am really pleased to see that you now understand the directory structure and 
by now should be weel on the way with the Chapter 5 compiles.

To give you a little forwarning of the areas where things can go wrong you may 
like to consider the following:

A) Host System Requirements:
http://www.linuxfromscratch.org/lfs/view/stable/prologue/hostreqs.html

If in your haste to start the LFS Build you skipped this section I urge you to 
pause your activity and run the version-check.sh script.

If your system is not fully compatable some issues can (will) emerge as you 
progress through the build.

B) 6.4. Entering the Chroot Environment
http://www.linuxfromscratch.org/lfs/view/stable/chapter06/chroot.html

On this page you will find an important note on the precautions to take if you 
have to interrupt your build and exit the chroot for any reason such as a 
system reboot.

C)  FInally and this is not actually covered in the book.
You will be investing considerable time into the build and it is all too easy 
to go wrong requiring a restart right back to the begining.  Some people take 
this on the chin as part of the price of the project.

I like to make and keep backups of the LFS partition after every couple of 
compiles and at least after the really long ones so that I have conveneint 
restart points in the event of a disaster.

Once again good luck with your build ... I hope you find it an enjoyable 
project.

Regards

Tony



-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


[lfs-support] Chapter 5 questions

2012-05-02 Thread Scott Robertson
Hello,

Can someone explain what the directory structure is supposed to look like in 
Chapter 5?

1. Where does the Binutils folder/directory go? Where does the GCC folder go? 
That's all the further I have gotten so far.  I think I will probably want to 
know where all the folders go.   I created a separate partition for LFS, and 
put the folders there, is that right, or not?
Or is it supposed to go into the /mnt/lfs folder? Or somewhere else?


2.  Can someone also explain permissions?  Who is supposed to have permissions 
on what?  What permissions are supposed to be on the Binutils and GCC 
directories?  root?  lfs?  

And what are they supposed to be? read, write and execute?

3.  What directory am I supposed to be in when I execute the commands?  As I 
said, I have an LFS partition, so am I supposed to be in /media/LFS?  Or more 
like /mnt/lfs? Or somewhere else?

4. Also, what does the two dots and slash mean?    ../(some command)  

How does that factor into it?



Thank in advance, 

Scott

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Chapter 5 questions

2012-05-02 Thread Tony Sauri

On Thu, 03 May 2012 17:23, Tony Sauri wrote:

 The answers to all your questions (except the last) are contained in
 paragraphs 2, 3 and 4.

Make that Chapters 2, 3 and 4

Tony
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page