On 1/7/06, Ken Moffat <[EMAIL PROTECTED]> wrote:
> On Sun, 8 Jan 2006, Greg Schafer wrote:
>
> > PS. I'm really glad that Ken and Dan are applying ICA to LFS builds. It's
> > all good :-)
>
> /me wishes it was somebody else, or only Dan - this is all keeping me
> from cleaning up my ppc32 CLFS enou
On Sun, 8 Jan 2006, Greg Schafer wrote:
PS. I'm really glad that Ken and Dan are applying ICA to LFS builds. It's
all good :-)
/me wishes it was somebody else, or only Dan - this is all keeping me
from cleaning up my ppc32 CLFS enough to investigate an oops on my G5
(hardly anybody builds pp
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 ta
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 awa
Greg Schafer wrote:
> /* Define to 1 to internationalize bison runtime messages. */
> -/* #undef YYENABLE_NLS */
> +#define YYENABLE_NLS 1
>
> Bingo! This looks like the culprit.
> I'll try and figure out a good fix tomorrow..
Hmmm, AFAICS there is no easy way to fool configure into doing wh
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 seque
Ken Moffat wrote:
> But certainly, you'll probably want r7257 (move grep before libtool) to
> fix a hardcoded '/tools' in the libtool script.
Yes, that's probably fine. But really, if you're willing to spend time
running ICA's on anything, I'd rather it was focused on the alpha branch
so that we
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. T
On Sun, 8 Jan 2006, Greg Schafer wrote:
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 =
ye
Jeremy Huntwork wrote:
[snip]
Apologies for the poor trimming in the previous message.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Greg Schafer wrote:
>>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 ];'
> 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 [ n
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
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 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 ha
On Sat, 7 Jan 2006, Dan Nicholson wrote:
Hi,
Recently some discussion has come up that the binutils and gcc built
in Ch. 6 are linking to the glibc in /tools. This was brought up by
Greg Schafer in this post
http://linuxfromscratch.org/pipermail/lfs-dev/2006-January/054970.html
I've done som
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 I
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
Recent kernels don't seem to support this configuartion switch any more.
Does this mean the FAQ needs adjusting?
CONFIG_DEVPTS_FS=y
R.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Hi,
Recently some discussion has come up that the binutils and gcc built
in Ch. 6 are linking to the glibc in /tools. This was brought up by
Greg Schafer in this post
http://linuxfromscratch.org/pipermail/lfs-dev/2006-January/054970.html
I've done some analysis of the LFS build pre-utf8 and fou
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).
Randy McMurchy wrote:
> What is the harm in retaining it?
Alternatively, what's the benefit of dropping it?
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
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 t
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. An
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 per
On Sat, 7 Jan 2006, Randy McMurchy wrote:
Thanks, Ken, for updating the BDB package. However, there are still
some references of "DB": the title in section 6.27.1, the first
sentence of that same section, and the title in section 6.27.2.
Thanks for spotting those, I'll go back and dig around.
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 discuss
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 notic
Randy McMurchy wrote:
> Hi all,
>
> This isn't a -dev issue but I don't know where else to send this to.
> If anybody knows, please redirect it.
The server-admin list.
> Anyway, Belgarath is running horribly slow. It takes 2-3 minutes just
> to update a bug in BLFS bugzilla. Perhaps it has somet
Hi all,
This isn't a -dev issue but I don't know where else to send this to.
If anybody knows, please redirect it.
Anyway, Belgarath is running horribly slow. It takes 2-3 minutes just
to update a bug in BLFS bugzilla. Perhaps it has something to do with
the LFS render job that has been going on
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 i
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
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
--
http://linuxfromscratch.org/m
On Fri, Jan 06, 2006 at 09:26:36PM +0500, Alexander E. Patrakov wrote:
>
> It correctly names sound devices and assigns permissions. It restores
> ALSA volumes, or, if it looks like ALSA is not used at all, OSS volumes
> (specially for Archaic if he still uses the proprietary nvsound module).
I
Jeremy Huntwork wrote these words on 01/07/06 09:42 CST:
> There have been plenty of opportunities to speak up and say we should or
> shouldn't do this. There was even just a week ago a thread called 'UTF-8
> book is ready for merging'. That was prime opportunity for anyone to
> speak up and give
Randy McMurchy wrote:
> 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 m
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
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 i
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.
A quick archive search (+man-DB and then +man +Berkeley) didn't reveal
anything useful other than it's a better fit for a UTF-8 system. I can
see the
On 1/7/06, Greg Schafer <[EMAIL PROTECTED]> wrote:
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 to work on the
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 "B
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 s
Ken Moffat wrote:
> On Fri, 6 Jan 2006, Ken Moffat wrote:
>
>> On Thu, 5 Jan 2006, Dan Nicholson wrote:
>>
bison as Dan noted
>>>
>>> I think I've got this one figured out in the alphabetical builds.
>>> Circular dependencies between bison and flex. Requires adding bison
>>> to /tools, b
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
chapt
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
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 llh-anno
46 matches
Mail list logo
