Randy McMurchy wrote:
> DJ Lucas wrote these words on 08/28/05 01:55 CST:
>
>>Randy McMurchy wrote:
>>
>>
From what I can tell from the information you provided (following all
>>>relevant links), this is a tough bug to follow. I stopped reading
>>>when it was starting to dwell on the specs of
Hi,
Would anyone mind if we inserted a sed after the ./config in OpenSSL to
remove all the deprecated warnings?
sed -i 's:mcpu:mtune:' {Configure,Makefile}
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the abov
Michael Kipper wrote:
> Hello,
>
> Appologies if this is in the wrong group, but I figured this would be the
> forum to ask this question.
>
> I've build an LFS system which is essentially entirely 64-bit, for my
> Athlon64. However, there are a few occasions where i686 support is
> required, spe
That's what we do in cross-lfs.
http://www.linuxfromscratch.org/lfs/view/cross-lfs
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS User # 2577
Registered Linux User # 299986
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscrib
Hello,
Appologies if this is in the wrong group, but I figured this would be the
forum to ask this question.
I've build an LFS system which is essentially entirely 64-bit, for my
Athlon64. However, there are a few occasions where i686 support is
required, specifically for GRUB, and more recently
Bruce Dubbs wrote these words on 08/28/05 18:39 CST:
> Seems reasonable to me. Want to take a stab at it?
>
> It should go in the "Important Information" chapter, but I don't know if
> it should be a new section or a subsection of "Notes on Building Software".
I think a sub-section would be mos
Richard A Downing wrote:
> Perhaps I should make it clear, I am asking for a clear definition of
> the term 'Recommended' (as applied to dependencies) in the book.
>
> I don't criticise the rejection of the bug at all. Just the fact that
> it relies on knowledge that is only documented in the m
On Sun, Aug 28, 2005 at 10:48:29PM +0100, Richard A Downing wrote:
>
> Perhaps I should make it clear, I am asking for a clear definition of
> the term 'Recommended' (as applied to dependencies) in the book.
I agree with Randy's vision of what recommended should mean as well as
your recommendatio
On Sun, Aug 28, 2005 at 01:20:51PM -0500, Bruce Dubbs wrote:
> Basically, the old style of options for commands like ps and tar are
> deprecated. The book should be teaching good style.
>
Thanks for the clear pointer, Bruce.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: h
On Sun, Aug 28, 2005 at 09:44:41AM -0600, Jeremy Huntwork wrote:
> For the glibc-linuxthreads package we use 'tar -xjvf' and for the
> bash-docs package we use 'tar -zxf'. Should we continue to use verbosity
OK, I just noticed something else. (Surprised I didn't catch it
before...)
One of the pac
On Sun, Aug 28, 2005 at 10:48:29PM +0100, Richard A Downing wrote:
> Perhaps I should make it clear, I am asking for a clear definition of
> the term 'Recommended' (as applied to dependencies) in the book.
>
> I don't criticise the rejection of the bug at all. Just the fact that
> it relies on k
Richard A Downing wrote:
> BZ #1564
>
> Randy states the following:
> quote
>
> Closing this bug as invalid. PCRE is on the recommended dependency list.
> If a builder chooses not to follow our recommendations, then whatever
> happens is on the builder.
>
> Recommended = Do it
>
> The only reas
BZ #1564
Randy states the following:
quote
Closing this bug as invalid. PCRE is on the recommended dependency list.
If a builder chooses not to follow our recommendations, then whatever
happens is on the builder.
Recommended = Do it
The only reason it is in recommeneded instead of reqiured is f
Hi, I have problem with perl. After `make`, a get:
../../miniperl "-I../../lib" "-I../../lib" "-I../../lib" "-I../../lib"
Errno_pm.PL Errno.pm
cp Errno.pm ../../lib/Errno.pm make[1]: Leaving
directory `/zrodla/perl-5.8.7/ext/Errno' make: [extras.make] Error 1
(ignored)
and after `make test`:
On 8/28/05, Doug Ronne <[EMAIL PROTECTED]> wrote:
> echo "ac_cv_prog_EMACS=" >> config.cache before the start does the
> trick.
silly me. That doesn't do it.
export EMACS="no" does it.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe:
Whenever I try to install gettext on a machine that has emacs on it, I
get a lisp error. If I use EMACS="" or disable emacs or without emacs
nothing happens. The gettext-tools directory Makefile still ends up
with EMACS=emacs. However, an
echo "ac_cv_prog_EMACS=" >> config.cache before the star
Andrew Benton wrote:
> Isn't the - thing to do with compatibility with BSD?
Take a look at `info tar`. Basically it says that:
"On the other hand, this old style syntax makes it difficult to match
option letters with their corresponding arguments, and is often
confusing."
and
"Old options
Randy McMurchy wrote:
Andrew Benton wrote these words on 08/28/05 12:27 CST:
But this would work
tar xfC somefile.tar.gz /somewhere
Thanks for the lesson Andrew!
It was just a lucky guess. Isn't the - thing to do with compatibility with BSD?
--
http://linuxfromscratch.org/mailman/listinf
Andrew Benton wrote these words on 08/28/05 12:27 CST:
> But this would work
>
> tar xfC somefile.tar.gz /somewhere
Thanks for the lesson Andrew! I have always been under the misguided
impression that the argument to the parameter must follow the parameter.
Meaning -f required the somefile.tar.
Randy McMurchy wrote:
This works:
tar xf somefile.tar.gz -C /somewhere
This would not work:
tar xf somefile.tar.gz C /somewhere
So, perhaps it is for consistency sake more than technical.
But this would work
tar xfC somefile.tar.gz /somewhere
--
http://linuxfromscratch.org/mailman/listin
Jeremy Huntwork wrote these words on 08/28/05 11:20 CST:
> Indeed. But I had thought that there had been a technically correct
> reason for including that. Anyone care to refresh my memory?
Bruce usually summarizes this one up really well. As you Jeremy,
I've forgotten the exact details, but ther
On Sun, Aug 28, 2005 at 06:18:39PM +0200, Keith Moore wrote:
> Jeremy Huntwork wrote:
>
> > Thanks for the comment, Randy. Makes sense to me. If no one has any
> > objections, then, I'll change both commands to be 'tar -xf'.
>
> Not to be totally pedantic, but the leading '-' is also unnecessary.
Jeremy Huntwork wrote:
> Thanks for the comment, Randy. Makes sense to me. If no one has any
> objections, then, I'll change both commands to be 'tar -xf'.
Not to be totally pedantic, but the leading '-' is also unnecessary.
KM
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http
On Sun, Aug 28, 2005 at 10:53:32AM -0500, Randy McMurchy wrote:
> I believe the -v option should not be used on either. My philosophy
> is that if something is being untarred to a final resting place
> (i.e., somewhere in /usr), then use it as this creates a log of the
> installed files. However, i
Jeremy Huntwork wrote these words on 08/28/05 10:44 CST:
> For the glibc-linuxthreads package we use 'tar -xjvf' and for the
> bash-docs package we use 'tar -zxf'. Should we continue to use verbosity
> for one and not the other?
I believe the -v option should not be used on either. My philosophy
Hey All,
Had a question about the use of tar commands in the LFS book. It is a
trivial matter, and probably doesn't make a bit of difference, but I was
interested in people's opinions anyway.
Currently, in the LFS book, tar is used twice (at leas in the gcc4 book
- haven't checked development). O
Randy McMurchy wrote:
DJ Lucas wrote these words on 08/28/05 01:55 CST:
Randy McMurchy wrote:
From what I can tell from the information you provided (following all
relevant links), this is a tough bug to follow. I stopped reading
when it was starting to dwell on the specs of ISO standards.
DJ Lucas wrote these words on 08/28/05 01:55 CST:
> Randy McMurchy wrote:
>
>>>From what I can tell from the information you provided (following all
>>relevant links), this is a tough bug to follow. I stopped reading
>>when it was starting to dwell on the specs of ISO standards.
>>
>>I'd sure like
28 matches
Mail list logo
