On Thu, 15 Dec 2005, Ken Moffat wrote:
I seem to recall that in repeated standard LFS i686 builds, these same
binaries can in fact differ, without anybody ever quite knowing why - this is
why Greg's ICA, at least last time I looked, did -three- builds to compare
which bytes always dif
On Fri, 16 Dec 2005, Dan Nicholson wrote:
On 12/16/05, Ken Moffat <[EMAIL PROTECTED]> wrote:
< snip everything >
Ken, I seemed to have offended you and I'm sorry that happened. I
really don't mean to bad mouth the way you've tested or the tool
you've created to
On Fri, 16 Dec 2005, Dan Nicholson wrote:
On 12/16/05, Ken Moffat <[EMAIL PROTECTED]> wrote:
Just seemed that you were taking offense to my suggestions or you
assumed I was taking shots at your tool. If not, then that's good
because I didn't mean either.
Great
As pertain
On Sun, 18 Dec 2005, Jeremy Huntwork wrote:
There are 4 lines that, to me, stand out:
unexpected FAIL: /usr/bin/libtool is different
unexpected FAIL: /usr/bin/vim differs after stripping and processing
unexpected FAIL:
/usr/include/c++/4.0.2/i686-pc-linux-gnu/bits/stdc++.h.gch/O0g.gch is
differ
On Fri, 23 Dec 2005, Greg Schafer wrote:
On Wed, 21 Dec 2005 11:34:22 -0800, Jim Gifford wrote:
I posted a solution in lfs-support. Here is it
In my testing with Cross-LFS, I have found that this works
echo "dummy1:x:1000:" >> /etc/group
echo "dummy:x:1000:1000:::/bin/bash" >> /etc/passwd
cd
On Fri, 23 Dec 2005, Greg Schafer wrote:
Ken Moffat wrote:
'su' from /tools. Neither CLFS nor LFS suppress this in the first
build of coreutils.
WARNING: insufficient access; not installing su
NOTE: to install su, run 'make install-root' as root
Sorry, you are r
On Fri, 23 Dec 2005, Dan Nicholson wrote:
I haven't done any research yet, but I'm attaching the ICA report for
1v2. With the exception of farce-extras (too big to move around), you
can see the results in http://students.washington.edu/dbnichol/lfs/ .
I'm going out of town in the morning, so
[Taking this part to clfs where other people might find it useful.
Please drop lfs-dev from any replies]
On Tue, 27 Dec 2005, Dennis J Perkins wrote:
Most of the BLFS packages that I have built so far compile fine. Emacs
says it doesn't recognize the architecture.
Head to your favourite ge
On Wed, 28 Dec 2005, Andrew Benton wrote:
Hello world,
It seems that XFree86-4.5.0 has issues with coreutils-5.92.
Do you mean 5.92 ? LFS-svn has been on 5.93 for a few weeks, and some
of the behaviour is definitely different between the two versions.
Ken
--
das eine Mal als Trag�die, d
On Tue, 27 Dec 2005, Dan Nicholson wrote:
bison, perl, vim - for me, these differ between my second and third
builds, but not for my third and fourth, nor for the first and second -
I guess this is the whole point of ICA and the build will be assumed
guilty unless an explanation can be produced.
On Sun, 1 Jan 2006, Bernard Leak wrote:
Dear List,
in what is (or was a few days ago!) the 'live' LFS Book
(LFS-BOOK-SVN-20051223), I can't get the test-suite for
6.50, Module-Init-Utils to run *at all*. Ignoring the test result,
everything seems to build, but I haven't dared ins
On Mon, 2 Jan 2006, Chris Staub wrote:
Note: this would also necessitate removing "more" from the chap. 5
util-linux, but AFAIK nothing in chap. 6 needs it - it's just there for the
user's convenience (though I never need it myself).
IMHO removing more is a bad idea. Anyway, what's the big
On Thu, 5 Jan 2006, Archaic wrote:
On Thu, Jan 05, 2006 at 06:32:44PM -0500, Jeremy Huntwork wrote:
If no one else gets to it, among other things, I'll be looking at this
later tonight. And then I'll do what I can to get it in ASAP. Any
objections?
None here. Though I haven't had a chance to
I decided to run farce on the svn book, because it looked as if some of
the issues I was seeing in CLFS were also present in LFS. Here are my
results for LFS svn-20060103 ICA, built from svn-20050902, kernel
2.6.13.
(this is with the first toolchain linked againist /tools as recently
discover
On Thu, 5 Jan 2006, Dan Nicholson wrote:
On 1/5/06, Ken Moffat <[EMAIL PROTECTED]> wrote:
Files that differ, but with same code:
e2fsck, fsck.ext2, fsck.ext3 (the same file, by three names)
I can't figure out this bugger. Maybe the objdump -S can help.
The 'same
On Fri, 6 Jan 2006, Bryan Kadzban wrote:
Or actually, the Perl documentation[1] says it's part of the system that
allows programs to find out how Perl was configured. The command in the
string is supposed to "produce the text of the /etc/hosts file", but I'm
not sure what purpose that would ne
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, but the differences are gone now.
Da
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, 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).
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 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
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
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:
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
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
On Mon, 9 Jan 2006, Dan Nicholson wrote:
I'm pretty sure the perl, vim and nscd differences are time stamp
related. Ken, farce does quite a bit more analysis than Greg's ICA
functions. Would you mind looking at these results and commenting on
differences between the ICA report and the farce re
On Tue, 10 Jan 2006, Ken Moffat wrote:
On Mon, 9 Jan 2006, Dan Nicholson wrote:
I'm pretty sure the perl, vim and nscd differences are time stamp
related.
What you could also do is copy one of the filelist- files, edit it to
*only* reference these three files (and give it a second
On Tue, 10 Jan 2006, Ken Moffat wrote:
So, at the moment I have
an aberrant build of perl in the first run of the fourth cycle, and at the
moment I can't replicate it.
Latest attempt to build this was fine, so I'll have to mark my problem
as "unconfirmed". Looks
On Tue, 10 Jan 2006, Dan Nicholson wrote:
Seems OK to me. Is this what you're seeing?
No, I'm seeing differences specific to groff-1.18.1, but actually these
aren't to do with date/time (unlike the 3 regexps I put into 001-6 for
this version of groff). Stuff like
failure in /usr/share/do
On Tue, 10 Jan 2006, Dan Nicholson wrote:
Ken, the same thing has happened to me with perl. Sometimes a
difference is reported. sometimes not. For both farce and ICA, IIRC.
It's the single reason why I keep moving gettext around in my builds
even though it comes after perl in both cases. I th
On Tue, 10 Jan 2006, Ken Moffat wrote:
No, I'm seeing differences specific to groff-1.18.1, but actually these
aren't to do with date/time (unlike the 3 regexps I put into 001-6 for this
version of groff). Stuff like
failure in /usr/share/doc/groff/1.18.1/meintro.ps...
1590,1592
On Sun, 8 Jan 2006, Ken Moffat wrote:
I'll look at reversing this and kicking gccbug into shape.
Done
--
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
On Sun, 8 Jan 2006, Greg Schafer wrote:
Hmmm, AFAICS there is no easy way to fool configure into doing what we
need. This is the best I can come up with for now. After running
configure, do this:
echo '#define YYENABLE_NLS 1' >> config.h
I can confirm it fixes the ICA problem.
Indeed it does
On Mon, 9 Jan 2006, Dan Nicholson wrote:
http://students.washington.edu/dbnichol/lfs/lfs-alpha-20060108-reports/ica/REPORT.1V2
http://students.washington.edu/dbnichol/lfs/lfs-alpha-20060108-reports/farce/1v2/farce-differ
http://students.washington.edu/dbnichol/lfs/lfs-alpha-20060108-reports/farc
On Sat, 14 Jan 2006, Randy McMurchy wrote:
And I suppose what is most interesting to me, though I haven't (and
probably never will) researched it, is if this file truly belongs in
/usr/share.
Is the file not architecture dependent? Can this same file be used
by all machines, no matter the platf
On Wed, 11 Jan 2006, Dan Nicholson wrote:
On 1/11/06, Ken Moffat <[EMAIL PROTECTED]> wrote:
My gut feeling is that cleaning the toolchain might remove a lot of
differences (ar archives, and programs linked statically) which (at
least in lfs-svn) show up between the first and second
On Mon, 16 Jan 2006, David Mascall wrote:
I wonder why this only occurs under jhalfs ? I cant find any reports of this
error from people building current SVN non-jhalfs.
This has been in the book for a little over a week. First, discount
anybody who doesn't run the testsuites at all. Secon
On Mon, 16 Jan 2006, Richard A Downing wrote:
I did have a certificate saying that I can program this beasty in
assembler, but have never done so in anger. The certificate's date is
interesting - 1976 I think. I also do Intel 4040. Hasn't cosmic-ray
bombardment done for them yet? :-)
I th
Hopefully, these are my last ICA results before looking at a toolchain
which doesn't initially link to /tools. The book is from 20060110 with
mktemp back where it used to be, a sed for gccbug, and Greg's change to
bison. Built three times, without locales or testsuites, all except the
first
On Mon, 16 Jan 2006, Tushar Teredesai wrote:
On 1/16/06, Ken Moffat <[EMAIL PROTECTED]> wrote:
libhistory.so.5 (symlink, points to .old after in-place rebuild)
libreadline.so.5 (ditto)
Shouldn't the link point to the .so.5 library? I don't remember seeing
that problem eve
On Mon, 16 Jan 2006, Ken Moffat wrote:
On Mon, 16 Jan 2006, Tushar Teredesai wrote:
On 1/16/06, Ken Moffat <[EMAIL PROTECTED]> wrote:
libhistory.so.5 (symlink, points to .old after in-place rebuild)
libreadline.so.5 (ditto)
Shouldn't the link point to the .so.5 libra
On Tue, 17 Jan 2006, Dan Nicholson wrote:
Seems to me like this whole issue with the .old libraries for readline
should just be eliminated. It's the only package that does this. DIY
has
sed -i.bak '/MV.*old/d' Makefile
Well, when it works, it looks good (update in place, decide you don't
801 - 843 of 843 matches
Mail list logo
