On Thu, 15 Dec 2005, Dan Nicholson wrote:
That's my prime objection to Greg's method - we always tell people
fbbg, but the comparison takes a shortcut.
Right, but for the purposes of testing, the environment should be as
consistent as possible. That's standard procedure for running a test
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 differed.
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 assist. I was only arguing the case for doing ICA
for the sake of testing the
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 assist. I was only arguing the
Ryan Oliver wrote:
We require 2.6 for current lfs to build nptl (though not if the initial
toolchain is replaced with a cross-lfs style setup).
So, build a 2.6 kernel and install module-init-tools :P
And yes, there are needed package upgrades that need to be done on the
host from old
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 pertains to the testing, I
On 12/16/05, Ken Moffat [EMAIL PROTECTED] wrote:
On Fri, 16 Dec 2005, Dan Nicholson wrote:
You sound like you've done the recursive build a number of times and
anticipate these differences in farce. I'd rather nip that one in the
bud and just keep the same environment.
Not exactly a
Matthew Burgess wrote:
So, where now? In an ideal world (yeah, that's the one where there
aren't any constraints on time, CPU cycles, etc.!), we would carry out
ICA tests on the current build order and compare them to the results of
the same tests run on an alphabetical build. That way we'd
On 12/15/05, Matthew Burgess [EMAIL PROTECTED] wrote:
weakly justified as trust us, it Just Works. Hmmm, maybe if someone
could write up a How to Perform ICA tests hint we could point to that,
Will this do?
http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2005-November/053989.html
On Thu, 15 Dec 2005, Jeremy Huntwork wrote:
Ken's Farce is probably good enough for our needs. However I did take a
brief look at Greg's scripts and he does a couple of other interesting
things, such as de-compressing all .gz files and un-archiving all .a
files before running the comparison.
On Fri, 16 Dec 2005, Ken Moffat wrote:
On Thu, 15 Dec 2005, Jeremy Huntwork wrote:
Ken's Farce is probably good enough for our needs. However I did take a
brief look at Greg's scripts and he does a couple of other interesting
things, such as de-compressing all .gz files and un-archiving all
On 12/15/05, Jeremy Huntwork [EMAIL PROTECTED] wrote:
Matthew Burgess wrote:
So, where now? In an ideal world (yeah, that's the one where there
aren't any constraints on time, CPU cycles, etc.!), we would carry out
ICA tests on the current build order and compare them to the results of
Tushar Teredesai wrote:
Will this do?
http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2005-November/053989.html
:)
Thanks, Tush. I didn't remember this...
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See
On Thu, 15 Dec 2005, Dan Nicholson wrote:
It sounds like Ken's scripts do a great job of doing the comparison.
What I like about Greg's scripts is deciding what's being compared.
1. The build automatically loops to the beginning, skipping the first
few stages: create symlinks, create
On 12/15/05, Ken Moffat [EMAIL PROTECTED] wrote:
On Thu, 15 Dec 2005, Dan Nicholson wrote:
1. The build automatically loops to the beginning, skipping the first
few stages: create symlinks, create devices, mount file systems,
create directories, etc. for all but the first iteration.
On Sun, Dec 11, 2005 at 08:55:16PM -0500, Jeremy Huntwork wrote:
3) The book will be more technically accurate because it will list the
dependencies of all packages built.
How can it do that? Let's say we've built a toolchain, then built
packageA and that package died on depA. You put depA
On 12/11/05, Greg Schafer [EMAIL PROTECTED] wrote:
Jeremy Huntwork wrote:
I just wanted to report on the status of the alphabetical branch as it
currently stands. For all intents and purposes, I believe it produces a
stable environment. I have built many, many packages on top of it and
Dan Nicholson wrote:
then I won't say another word. Anyway, I applaud your effort on this
even though I'm not behind it right now.
Well, I assume you mean not behind it as things stand right at this
time? Is that correct? Or do you mean that the idea is a futile one?
I'm interested in seeing
On 12/11/05, Jeremy Huntwork [EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
then I won't say another word. Anyway, I applaud your effort on this
even though I'm not behind it right now.
Well, I assume you mean not behind it as things stand right at this
time? Is that correct? Or do you
Dan Nicholson wrote these words on 12/11/05 19:23 CST:
My opinion: Making the build alphabetical is silly. It's a purely
cosmetic change that doesn't do anything for getting a better final
result.
Exactly my sentiments. I'm glad that at least one person has
agreed with me. Not that it makes
Dan Nicholson wrote:
My opinion: Making the build alphabetical is silly. It's a purely
cosmetic change that doesn't do anything for getting a better final
result. Checking that the order a package is built will alter the
final product is a worthy task and should be done. If in the end an
Jeremy Huntwork wrote these words on 12/11/05 19:43 CST:
Once more, for the sake of clarity. The goal of the lfs-alphabetical
branch was *not* solely to make the build alphabetical!
But that is not what folks that have really stopped to consider
the ramifications of such a change think. Your
Randy McMurchy wrote:
It is a lose-lose situation. There is nothing to be gained.
Explain how it is a lose-lose. You don't *know* there will be breakage
and I've already agreed that more testing needs to be done before any
merge is considered. What is lost?
I'll give you what is gained:
1)
Randy McMurchy wrote:
Jeremy Huntwork wrote these words on 12/11/05 19:43 CST:
The real thrust behind this research is to have a rationale for each
package -- *why* it's built *when* it's built. IMO, that's 10 times
better than just saying 'eh, the build order is a huge mess, we don't
know
Randy McMurchy wrote:
But that is not what folks that have really stopped to consider
the ramifications of such a change think. Your proposed build order,
and the name, and the reasons you've offered, and the entire
discussion lead folks to think otherwise. Just look at the last
few comments
Jeremy Huntwork wrote:
The real thrust behind this research is to have a rationale for each
package -- *why* it's built *when* it's built. IMO, that's 10 times
better than just saying 'eh, the build order is a huge mess, we don't
know why this package is before this other one, but it works so
Jeremy Huntwork wrote these words on 12/11/05 19:55 CST:
Why spend the time to verify the purity of a system that we can't
rationalize now?
But everyone but you *can* rationalize the purity of the current
build order. It works. And has been proven to work over the years.
If folks ask, why
Bruce Dubbs wrote:
Sorry Jeremy. We will have to A2D on this one. The rationale that we
came up with an empirical order that works is, IMO, quite valid. It is
not a mess, it is one that works. Others may work too, but I have to
ask so what?
So you won't mind so much when others of us who
Randy McMurchy wrote:
But everyone but you *can* rationalize the purity of the current
build order. It works. And has been proven to work over the years.
You, Dan, and Bruce do not qualify as everyone. Please try not to be so
superlative in your comments.
--
JH
--
Bruce Dubbs wrote:
In BLFS, we do spend a lot of time determining dependencies, but we also
make the assumption that the LFS packages are installed. The LFS
dependencies are not listed for each package.
If the packages were to be listed, and have all the deps mapped out in a
tree, you would
Jeremy Huntwork wrote:
Bruce Dubbs wrote:
Sorry Jeremy. We will have to A2D on this one. The rationale that we
came up with an empirical order that works is, IMO, quite valid. It is
not a mess, it is one that works. Others may work too, but I have to
ask so what?
So you won't mind so
Jeremy Huntwork wrote these words on 12/11/05 20:01 CST:
There are others, but they need to speak up. :/ I'm pretty sure Chris
Staub agrees with me as he's done the majority of work on this. I have a
feeling (though I could be wrong) that Greg Schafer agrees with me,
Nobody, until now, has
On 12/11/05, Jeremy Huntwork [EMAIL PROTECTED] wrote:
The real thrust behind this research is to have a rationale for each
package -- *why* it's built *when* it's built. IMO, that's 10 times
better than just saying 'eh, the build order is a huge mess, we don't
know why this package is before
On 12/11/05, Jeremy Huntwork [EMAIL PROTECTED] wrote:
There are others, but they need to speak up. :/ I'm pretty sure Chris
Staub agrees with me as he's done the majority of work on this. I have a
feeling (though I could be wrong) that Greg Schafer agrees with me,
seeing as how he's the one
Jeremy Huntwork wrote these words on 12/11/05 20:51 CST:
I never said it was ready to merge.
And a few hours earlier said:
How does the community feel about getting these changes into trunk?
Does anyone but me see some contradiction in the two statements?
:-)
--
Randy
rmlscsi: [GNU ld
Dan Nicholson wrote:
[snip]
OK, now I see where me and you are having the disconnect. We're both
interested in tracking down the reasons for the build order and
putting them in such a way that provides the greatest robustness and
documents its exact position. However, I think that making
Randy McMurchy wrote:
Does anyone but me see some contradiction in the two statements?
Alright, you win.
That did sound like I wanted to merge now, and sorry for that -- it's
not quite what I meant. I thought it was given by my asking about binary
analysis that I wanted to test the thing
37 matches
Mail list logo
