Re: LFS Future Braindump

On Thu, May 29, 2008 at 9:47 AM, Randy McMurchy
<randy <at> linuxfromscratch.org> wrote:
> Christian Wurst wrote these words on 05/28/08 06:55 CST:
>> Well, I disagree here. The FAQ is very technical in nature, and thus
>> takes some time to understand what the package does.
>
> I snipped your explanation and somewhat dismissed it when I read
> your first sentence. You must have not even visited the URL I
> offered above, otherwise there would be no way you would say that
> it is too technical.

I did, but after re-reading what I wrote I have to say that it was a
bad choice of words, I'm sorry for that. I didn't mean to criticise
the FAQ in any way. It would have been better if I wrote "too long and
technical in nature for the short description I'd like to see in
BLFS".

I liked what Guy Dalziel wrote, especially:
> What if we could do both, present a couple of sentences
> in brief about what the package does and then put a
> 'more..' link after it that leads to a page of a more
> detailed nature, perhaps the wiki would suit the
> purpose nicely.

These couple of sentences should be as understandable to the average
user as possible. I think we can assume the average user knows what a
filesystem or a database is, but we shouldn't assume that he knows
what a X.500 directory service is. This is why I wrote that I think
the FAQ is "too technical".

PPP-2.4.4

minor nits with ppp;

typo: missing 'l'

all examples fail: /etc/ppp/peers will not exist on a new installation.

attached an 'svn diff'

I apologize not fixing this myself.

---
David Jensen

--

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

SGMLSpm-1.03ii

With coreutils-6.10 SGMLSpm-1.03ii installation fails installation.
It attempts chmod on the dangling symlink installed
in /usr/share/doc/perl5/SGMLSpm.  Currently we are deleting it after
installation, this no longer works.

Attached an svn diff to delete it before installation.

---
David Jensen

--

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

X.Org scripted installation / Proprietary ATI driver

Hi everyone!
Sorry to just intrude this list. I just have a tiny suggestion to make and one
question:

First of all,  the scripted X build is a great thing. I am doing a build at
the moment and experienced only two little problems:
The book suggests to create a working directory for the X install.
If you save the base script (the one provided in the introduction)
in this directory, extend it for the other sections and save it with
another name (at least this is what I did) and save the wget
lists and patches in the same directory (which is, I think what
most users will do, because the script creates the subdirs),
then the installation of the X libraries will fail.
Sorry for this sentence.
This is because the script searches for the patches in the
$workdir/libs directory, while they really reside in the $workdir
directory. Could you add a hint or change the patch commands
to a ../.. at the beginning?
Also, if I use the script as-is, it only starts after hitting Ctrl-C
to end the newly spawned console. But this could just be me
being to dumb to realize some error I made. However, it makes
error tracking more difficult because the script doesn't stop
after an error and you have to consult the build logs.

OK, now to my question: Are there any intentions to add
the proprietary drivers of ATI / NVIDIA to BLFS? I was
experiencing several problems with the ATI driver, so
I thought I could perhaps write a hint for it if you
have no intentions to add it to the book.

Re: X.Org scripted installation / Proprietary ATI driver

Philipp Christian Loewner wrote:

I don't have time now for an in depth analysis of your comments, but we will. 
Thanks for the feedback.

> OK, now to my question: Are there any intentions to add
> the proprietary drivers of ATI / NVIDIA to BLFS? 

No.  I don't ever see us adding anything about proprietary drivers, other than a 
potential comment that they exist, to BLFS.

    -- Bruce
--

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

Re: X.Org scripted installation / Proprietary ATI driver

Philipp Christian Loewner wrote:
> First of all,  the scripted X build is a great thing. I am doing a build at
> the moment and experienced only two little problems:
> The book suggests to create a working directory for the X install.
> If you save the base script (the one provided in the introduction)
> in this directory...
>   
There is the first problem, it is only an example of commands meant to 
be run interactively.  It is not a script.  If you want to poke and prod 
it into a script or scripts, you are on your own, but...
> and save the wget
> lists and patches in the same directory (which is, I think what
> most users will do, because the script creates the subdirs),
> then the installation of the X libraries will fail.
>   
...I hadn't thought about it this way.  I usually save the patches in 
the newly created directories (so they are already there for the next 
build).  The patches my need a little text around them (or change the 
commands as you suggested).

> Also, if I use the script as-is, it only starts after hitting Ctrl-C
> to end the newly spawned console....However, it makes error tracking more difficult because the script
doesn't stop after an error and you have to consult the build logs.
>   
This is again because it is not a script, but commands meant to be 
entered interactively.  The first command (bash -e) creates an 
environment that exits on error.  You need to do the same with your 
script if you want it to exit by modifying the shebang (interpreter 
line) appropriately.

Re: X.Org scripted installation / Proprietary ATI driver

OK, I finally got that. So I just misinterpreted the
book at that passages.

Just to clear things up, I thought you would create
an enviroment that exits on errors so you wouldn't
mistakenly continue the build despite errors that cause
trouble afterwards. This seemed to me like a good
script-behaviour.
But of course, I didn't think about
the same need when manually entering a for loop
that scrolls by errors very fast.

Thanks for making that clear to me... I tend to look
at things like that only from my perspective without
questioning my understanding of the author's intention.

 - Philipp
_______________________________________________________________________
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220

--

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

Re: X.Org scripted installation / Proprietary ATI driver

On Wednesday 11 June 2008 05:46:56 Philipp Christian Loewner wrote:
> OK, I finally got that. So I just misinterpreted the
> book at that passages.
> 
> Just to clear things up, I thought you would create
> an enviroment that exits on errors so you wouldn't
> mistakenly continue the build despite errors that cause
> trouble afterwards. This seemed to me like a good
> script-behaviour.
> But of course, I didn't think about
> the same need when manually entering a for loop
> that scrolls by errors very fast.
> 
> Thanks for making that clear to me... I tend to look
> at things like that only from my perspective without
> questioning my understanding of the author's intention.
> 

You can base on following script (attach.). 

Bests,

  - ptr

--

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html

Re: X.Org scripted installation / Proprietary ATI driver

Philipp Christian Loewner wrote:
> OK, I finally got that. So I just misinterpreted the
> book at that passages.
>   
If it is not easy to understand then there is still a problem with the 
text that surrounds the commands.  BLFS does not endorse scripting the 
build commands, but it was argued for this one little example in the 
book because of the repetition.  Imagine typing (or even copy and 
pasting) the same commands 250+ times.    I think 'to script' was a 
bad choice of words, where I should have used 'to partially automate'.

Currently the book has :
====
Additionally, because of the large number of repetitive commands, you 
are encouraged to script the build. For most sections, you can use a 
script with commands similar to the following, to compile and install 
all packages in a wget file list:
====

Perhaps this text is easier to understand and explains the purpose a 
little better:
====
Additionally, because of the large number of repetitive commands, you 
are encouraged to partially automate the build.  The commands below (or 
similar) can be entered at the command line to compile each group of 
packages (proto, libs, apps, drivers).  The wiki links on each group's 
page contain specific commands to compile the entire group of packages, 
based on the content of the wget files.
====

PDF files in */downloads/ compressed - removed uncompressed versions

In an effort to save a large amount of bandwidth I've compressed the PDF 
files that haven't been compressed yet and removed the uncompressed 
files in the download sections. This'll conserve some bandwidth and 
associated charges that go along with it.

In the last few days alone the server has uploaded several gigabytes 
worth of LFS and BLFS PDF files.

Gerard
--

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