Dan Nicholson wrote:
He sent this email [2] to the llh-announce list in November about being
swamped with work, but nothing's happened since then. Any more
information about this?
Nope, that's the last email I've received on the subject. I didn't spot
the fact that he sent it to the
Matthew Burgess wrote:
Dan Nicholson wrote:
He sent this email [2] to the llh-announce list in November about being
swamped with work, but nothing's happened since then. Any more
information about this?
Nope, that's the last email I've received on the subject. I didn't spot
the fact that
Hi!
Starting the Spanish translation update I noticed that the i18n patches
referenced in the book are yet hosted on the Alexander's home dir.
For consintency, and to allow patcheslist.xsl and jhalfs do well their job,
that patches must be placed into the Patches Project repository, and
On Fri, 6 Jan 2006 11:22:53 -0800
Dan Nicholson [EMAIL PROTECTED] wrote:
To both guys,
Thanks for all the hard work on the hardware issues. I promise it is
appreciated by others on the list whether they're vocal about it or
not. I don't think I'm alone when I say that I'm eager to see how
Hi all,
The new database package in the LFS SVN book is referenced as the
DB package. This is incorrect and should be fixed. The package is
known as, and is referenced by its maintainers as Berkeley DB.
And, because this package will also have to stay in the BLFS book,
and is referenced as
On 1/7/06, Greg Schafer [EMAIL PROTECTED] wrote:
snip the business
Wow, that's some serious analysis, dude. It also proves that my
earlier flex must be before bison is bogus. Seems that adding bison
back into Ch. 5 would do the trick, but maybe there's a better
solution. This has inspired me
Richard A Downing wrote these words on 01/07/06 08:52 CST:
Can someone point me to the discussion thread that decided this
change of man package?
Unfortunately, for these very reasons, there really was no discussion
of putting in UTF-8 in LFS trunk, it was more of a just do it. Not
that it is
Richard A Downing wrote:
Can someone point me to the discussion thread that decided this
change of man package? I want to review the reasons to make my own
decision on it.
There was no discussion thread. All reasons are explained in my
man-i18n.txt hint. I _really_ don't want to say Drop all
Archaic wrote:
I think you might be mistaking me with someone else. I don't recall
using anything called nvsound.
Sorry
--
Alexander E. Patrakov
Don't mail to [EMAIL PROTECTED]: the server is off until 2006-01-11
Use my GMail or linuxfromscratch address instead
--
Randy McMurchy wrote these words on 01/07/06 08:17 CST:
The new database package in the LFS SVN book is referenced as the
DB package. This is incorrect and should be fixed.
Thanks, Ken, for updating the BDB package. However, there are still
some references of DB: the title in section 6.27.1,
Richard A Downing wrote:
Can someone point me to the discussion thread that decided this
change of man package? I want to review the reasons to make my own
decision on it.
http://linuxfromscratch.org/pipermail/lfs-dev/2005-December/054909.html
That's not the thread that decided it, but
Jeremy Huntwork wrote these words on 01/07/06 12:39 CST:
I'm sure that slowed down a bunch of running cron jobs. When they
finally finish, belg should hopefully recover.
Does anyone periodically do system clean-up on Belg? Are there
cron jobs that are set up to do automated clean-up?
I
On Sat, 07 Jan 2006 20:09:47 +0500
Alexander E. Patrakov [EMAIL PROTECTED] wrote:
Richard A Downing wrote:
Can someone point me to the discussion thread that decided this
change of man package? I want to review the reasons to make my own
decision on it.
There was no discussion thread.
Ken Moffat wrote these words on 01/07/06 12:56 CST:
Disagree. 77.9 MiB on my first build, so yes, more than it says, but I
can't get near 94 (my understanding is that we use MB as an abbreviation
for MiB, I have 79804 KiB as the raw figure).
Hey I was just trying to be helpful. And
I noticed that this switch is in the LFS book for BerkyDB, I haven't
built that for some time (when something says it needs a DB that I'm
testing).
Does Man-DB need this? I'm amazed if it does - the rationale for
using it is that it's maintained and modern and handles all sorts of
UTF-8 stuff.
Richard A Downing wrote these words on 01/07/06 13:26 CST:
I noticed that this switch is in the LFS book for BerkyDB, I haven't
built that for some time (when something says it needs a DB that I'm
testing).
Does Man-DB need this? I'm amazed if it does - the rationale for
using it is that
On Sat, 07 Jan 2006 13:37:49 -0600
Randy McMurchy [EMAIL PROTECTED] wrote:
Richard A Downing wrote these words on 01/07/06 13:26 CST:
I noticed that this switch is in the LFS book for BerkyDB, I haven't
built that for some time (when something says it needs a DB that I'm
testing).
On Sat, Jan 07, 2006 at 08:55:34PM +, Richard A Downing wrote:
Recent kernels don't seem to support this configuartion switch any more.
Does this mean the FAQ needs adjusting?
CONFIG_DEVPTS_FS=y
It's there, but only if you select config for small systems or whatever
it is called.
On Sat, 7 Jan 2006, Randy McMurchy wrote:
Ken Moffat wrote these words on 01/07/06 12:56 CST:
Disagree. 77.9 MiB on my first build, so yes, more than it says, but I
can't get near 94 (my understanding is that we use MB as an abbreviation
for MiB, I have 79804 KiB as the raw figure).
Hey
On 1/7/06, Ken Moffat [EMAIL PROTECTED] wrote:
Thanks for doing the analysis. I suspect we are probably going to move
to something like Tushar's method documented towards the end of
http://bugs.linuxfromscratch.org/show_bug.cgi?id=1677
I kind of like Tushar's thing, although if you have to
On Fri, 6 Jan 2006, Chris Staub wrote:
Or replace creating with customizing.
Thanks, done.
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information
On Sat, 7 Jan 2006, Greg Schafer wrote:
I've just managed to reproduce this in a DIY build by dropping M4, Bison
and Flex from the temptools phase. Hmm, this is a bizarre one... check
out the following..
By retaining the finished Bison build dirs from each iteration and diffing
them, I was
Author: ken
Date: 2006-01-07 15:12:20 -0700 (Sat, 07 Jan 2006)
New Revision: 7256
Modified:
trunk/BOOK/chapter01/changelog.xml
trunk/BOOK/chapter06/chapter06.xml
Log:
Build mktemp earlier, for gcc's gccbug which now wraps mktemp in 'if [ yes =
yes ];' instead of 'if [ no = yes
On Sat, 7 Jan 2006, Jeremy Huntwork wrote:
Not to mention that order changes are being done in the alphabetical
branch so that we don't upset whatever we have working in trunk. Let's
focus ICA's and purity on the poorly named alphabetical branch and leave
trunk alone completely in this regard.
Ken Moffat wrote:
I'm not sure I fully understand your point, you seem to be saying that
gcc might be at risk from mktemp ?
Sorry, I guess I wasn't quite clear. What you've done is make a build
order change by inserting a questionable package smack-bang in the middle
of the toolchain
Greg Schafer wrote:
/* Define to 1 to internationalize bison runtime messages. */
-/* #undef YYENABLE_NLS */
+#define YYENABLE_NLS 1
Bingo! This looks like the culprit.
snip
I'll try and figure out a good fix tomorrow..
Hmmm, AFAICS there is no easy way to fool configure into doing
On Sun, 8 Jan 2006, Greg Schafer wrote:
While it won't hurt in this instance, IMHO the current toolchain sequence
should not be meddled with in this fashion. God only knows how many years
it's taken us to get it to its current state :-) I believe it also reduces
toolchain education by taking
Ken Moffat wrote:
But certainly, you'll probably want r7257 (move grep before libtool) to
fix a hardcoded '/tools' in the libtool script.
Yes, this is new as of libtool-1.5.22. I only noticed this yesterday
myself in my latest ICA run. The problem is triggered because the latest
libtool
28 matches
Mail list logo
