- Original Message -
From: Gilles Espinasse g@free.fr
To: LFS Developers Mailinglist lfs-dev@linuxfromscratch.org
Sent: Monday, October 27, 2008 11:55 PM
Subject: Re: ICA/Farce
- Original Message -
From: Ken Moffat k...@linuxfromscratch.org
To: LFS Developers
On Sun, Oct 26, 2008 at 2:00 PM, Greg Schafer [EMAIL PROTECTED] wrote:
I've never looked at jhalfs but I understand it implements my ICA
algorithms. My own scripts have been getting exceptionally clean
results lately now that the randomness in GCC builds has apparently gone
as of GCC 4.3.
On Mon, Oct 27, 2008 at 2:59 AM, TheOldFellow [EMAIL PROTECTED] wrote:
What I meant to say was that I, for one, would be grateful for any
additional documentation of the subject.
It's pretty straightforward, although I might butcher some of the terminology.
The main goal is to see if the
Selon Dan Nicholson [EMAIL PROTECTED]:
...
The actual implementation mostly involves preparing to diff/cmp, and
is probably better explained by the comments in gsbuild. Look at the
bottom of the functions file for do_ica_prep() and do_ica_work().
On Mon, Oct 27, 2008 at 06:51:38AM -0700, Dan Nicholson wrote:
On Sun, Oct 26, 2008 at 2:00 PM, Greg Schafer [EMAIL PROTECTED] wrote:
I've never looked at jhalfs but I understand it implements my ICA
algorithms. My own scripts have been getting exceptionally clean
results lately now that
On Mon, Oct 27, 2008 at 7:57 AM, Gilles Espinasse [EMAIL PROTECTED] wrote:
Instead to gunzip all .gz files, would it not better to submit patches that
add
-n when gzip run so the files in use will really be the same?
I should say I have made some patches like that but have not reported
Selon Ken Moffat [EMAIL PROTECTED]:
...
Archaic saw unresolved differences for x86 with gcc-4.1.2.
Actually, looking at his results (they're at ~/archaic) they look
pretty good - blkid.tab.old and locale-archive should probably now
be expected to differ, and they were the only differences
On Mon, Oct 27, 2008 at 06:36:07PM +0100, Gilles Espinasse wrote:
Selon Ken Moffat [EMAIL PROTECTED]:
...
Archaic saw unresolved differences for x86 with gcc-4.1.2.
Actually, looking at his results (they're at ~/archaic) they look
pretty good - blkid.tab.old and locale-archive should
On Mon, Oct 27, 2008 at 10:15:31AM -0700, Dan Nicholson wrote:
In farce, Ken had some
functions that would skip these stamps, but I don't recall how he
implemented that.
For gzipped files, just cmp -s -i 8 (the comment says bytes 4,5,6,7
are the timestamp, hopefully everything ahead of it
DJ Lucas wrote:
Hey guys. Is there any recent documentation on the expectations of
farce or ICA?
Docs? What docs :-)
Doing only 2 passes of chapter6
with both comparison methods checked. What are the advantages of 3 or
more passes?
Huh? ICA by definition is 3 passes. No ifs, buts or
Bruce Dubbs wrote these words on 10/26/08 16:32 CST:
Greg Schafer wrote:
I've never looked at jhalfs but I understand it implements my ICA
algorithms. My own scripts have been getting exceptionally clean
results lately now that the randomness in GCC builds has apparently gone
as of GCC 4.3.
Bruce Dubbs wrote:
Umm, no. jhalfs parses the xml of the book and creates a Makefile that
builds
by the LFS book. Actually, it is quite convenient.
ICA is in fact implemented as an optional feature of jhalfs. Which means
that when it's done building LFS by the book, it will try to build
Jeremy Huntwork wrote:
Bruce Dubbs wrote:
Umm, no. jhalfs parses the xml of the book and creates a Makefile that
builds
by the LFS book. Actually, it is quite convenient.
ICA is in fact implemented as an optional feature of jhalfs. Which means
that when it's done building LFS by the
Bruce Dubbs wrote:
Umm, no. jhalfs parses the xml of the book and creates a Makefile that
builds
by the LFS book. Actually, it is quite convenient.
Umm, yes. It's *VERY* convenient. I should know..
(Me wonders if Bruce realizes the whole build straight from the doc
concept in jhalfs is
Greg Schafer wrote:
DJ Lucas wrote:
Hey guys. Is there any recent documentation on the expectations of
farce or ICA?
Docs? What docs :-)
Doing only 2 passes of chapter6
with both comparison methods checked. What are the advantages of 3 or
more passes?
Huh? ICA
On Sun, Oct 26, 2008 at 08:45:40PM -0500, DJ Lucas wrote:
Anyway, I killed the build I was working on. Given the Ken's
description of current Farce, I'm not sure that both can run on the same
system and have meaningful results. I'd really like to do a sanity
check on the development
On Nov 26, 2007 10:53 PM, Greg Schafer [EMAIL PROTECTED] wrote:
(dredging up an old thread)
Dan Nicholson wrote:
On 3/19/07, Dan Nicholson [EMAIL PROTECTED] wrote:
So, it seems this difference is embedded in cc1 and can't be stripped
out after the build. I'm assuming that the original
(dredging up an old thread)
Dan Nicholson wrote:
On 3/19/07, Dan Nicholson [EMAIL PROTECTED] wrote:
So, it seems this difference is embedded in cc1 and can't be stripped
out after the build. I'm assuming that the original difference is just
debugging symbols like would normally be the case.
On 3/20/07, Dan Nicholson [EMAIL PROTECTED] wrote:
Attached are two patches to add the glibc branch update patch in Ch. 5
and force /usr/include to be used as the preferred system include
directory after the toolchain re-adjustment.
No comments, so I'm applying these.
--
Dan
--
On 3/19/07, Dan Nicholson [EMAIL PROTECTED] wrote:
So, it seems this difference is embedded in cc1 and can't be stripped
out after the build. I'm assuming that the original difference is just
debugging symbols like would normally be the case. I'll try to narrow
that down further, but this may
On 3/20/07, Dan Nicholson [EMAIL PROTECTED] wrote:
Attached are two patches to add the glibc branch update patch in Ch. 5
and force /usr/include to be used as the preferred system include
directory after the toolchain re-adjustment.
I should mention that I changed the specs adjustment to use
On 3/14/07, Greg Schafer [EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
One of the things that currently doesn't happen in the chroot
toolchain adjustment for LFS is making gcc prefer the new headers in
/usr/include. If you add '-v' to the sanity check output, you'll see
that it's still
On Wednesday 14 March 2007 16:43, Dan Nicholson wrote:
Manuel brought up a recent regression shown by ICA in cc1 and cc1plus.
snip impressive detective work
Dan, thanks for looking into this. It seems pretty clear that we need both
fixes here, i.e. i) Apply the Glibc patch in chapter 5 and
Dan Nicholson wrote:
Manuel brought up a recent regression shown by ICA in cc1 and cc1plus.
snip
Then I remembered one other thing Greg recently tweaked for more purity.
http://www.diy-linux.org/pipermail/diy-linux-dev/2006-December/000967.html
One of the things that currently doesn't
On 3/14/07, Greg Schafer [EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
One of the things that currently doesn't happen in the chroot
toolchain adjustment for LFS is making gcc prefer the new headers in
/usr/include. If you add '-v' to the sanity check output, you'll see
that it's still
On 1/16/06, Ken Moffat [EMAIL PROTECTED] wrote:
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)
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
On 1/16/06, Ken Moffat [EMAIL PROTECTED] wrote:
I was wrong in retracting, my LFS-svn results definitely show this for
all builds after the first. I can't yet see why the symlink is moving
(and I've spent twenty minutes looking at readline's shlib/Makefile and
support/shlib-install).
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 even when I used to upgrade in-place (I have been using
the fakeroot
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 even when I used to
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 library? I don't remember
Dan Nicholson wrote:
Until they finally kick me off their server, I've got a little repo of
stuff trying to track my work on this:
http://students.washington.edu/dbnichol/lfs/
Thanks again, Dan. I've merged all recent changes from trunk into the
alphabetical branch, and I took some small
On 1/4/06, Jeremy Huntwork [EMAIL PROTECTED] wrote:
Would you guys mind giving me a little summary of the progress of the
last week? Also, Chris, I believe you have a patch for the book, right?
Which is the current one?
Until they finally kick me off their server, I've got a little repo of
Dan Nicholson wrote:
Until they finally kick me off their server, I've got a little repo of
stuff trying to track my work on this:
http://students.washington.edu/dbnichol/lfs/
[snip]
For sure take a look at the ChangeLog to see a quick summary.
OK, thanks, Dan. This helps a lot. I'll try
Jeremy Huntwork wrote:
Dan, Chris:
I see you guys have done a lot of work over the past week. Thank you
very much for that. I'm having a little trouble sorting through the
hundreds of emails in my Inbox today and pinpointing exactly what
changes are ready to go into the alpha branch.
Jeremy Huntwork wrote:
This is nearly done, so I will go ahead and post results on this when I
have them. As Greg has explained, this will at least show that the
system can bootstrap itself and produce the same thing. That should have
at least some merit.
Here is the results via Farce:
Jeremy Huntwork wrote:
Well, now to try Greg's method and see what we get.
BTW, Dan, are you going to be running similar tests on the current LFS
build method?
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above
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
On 12/18/05, Jeremy Huntwork [EMAIL PROTECTED] wrote:
Jeremy Huntwork wrote:
Well, now to try Greg's method and see what we get.
BTW, Dan, are you going to be running similar tests on the current LFS
build method?
I think I will, just to see where it stacks up. I maintain scripts
for
Ken Moffat wrote:
The vim one puzzles me a bit. :/ Also, I'm hoping that the stdc++.h.gch
differences are due to the randomness that Ken and Greg talked about.
I think vim might be more of this c++ randomness
I keep hearing randomness? Is this just a result of the kernel option
(defalt
Jeremy Huntwork wrote:
unexpected FAIL: /usr/bin/vim differs after stripping and processing
Looks like optional dependencies (perl library?) differ after chapters 5
and 6. It would be interesting to see differences in ./configure output
and in config.log.
--
Alexander E. Patrakov
--
Matthew Burgess wrote:
What I have trouble understanding is the fact that, apparently, one
shouldn't reboot during the ICA cycle. What I thought was trying to be
proved here was that a) any suitable host can build LFS and b)
regardless of the host, the final LFS system should be more-or-less
Matthew Burgess wrote:
What I have trouble understanding is the fact that, apparently, one
shouldn't reboot during the ICA cycle. What I thought was trying to be
proved here was that a) any suitable host can build LFS
No. IMHO what you refer to there is bootstrapability ie: the ability to
Greg Schafer wrote:
[snip]
this is an assumption). The whole 2 phase build method approach is
designed to try and provide as sane an environment as possible. The goal
is to produce an end result identical to that which would have been
produced as if you had produced it in a sane environment.
Jeremy Huntwork wrote:
Anyway, just finished a build of the new branch this morning, with *all*
tests being run. Going to first look for any failed dependencies, then
index the build via Farce.
Lastly, I'll build again from the new host and compare results.
This is nearly done, so I will
Greg Schafer wrote:
It's amazing how such a simple concept can apparently be troublesome for
some folks to grasp.
What I have trouble understanding is the fact that, apparently, one
shouldn't reboot during the ICA cycle. What I thought was trying to be
proved here was that a) any suitable
46 matches
Mail list logo
