Re: Alphabetical branch status report (LONG)

Ken Moffat wrote: If LC_ALL isn't set correctly, then the results may well not be reliable. But, I'd expect that to show in build or testsuite failures. I will be very surprised if this results in any difference except /usr/share/info/dir when starting from a modern host. -- Alexander E.

Re: Alphabetical branch status report (LONG)

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

Re: Alphabetical branch status report (LONG)

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,

Re: Alphabetical branch status report (LONG)

On 12/16/05, Ken Moffat <[EMAIL PROTECTED]> wrote: > Dan, > > what did I say that makes you think I'm hurt ? I haven't been offended > by your comments, and I hope mine weren't offensive to you, I certainly > didn't intend that. I welcome an opportunity to discuss testing, and I > intended to

Re: Alphabetical branch status report (LONG)

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 o

Re: Alphabetical branch status report (LONG)

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

Re: Alphabetical branch status report (LONG)

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 th

Re: Alphabetical branch status report (LONG)

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.

Re: Alphabetical branch status report (LONG)

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

Re: Alphabetical branch status report (LONG)

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

Re: Alphabetical branch status report (LONG)

On Thu, 2005-12-15 at 19:32 -0500, Jeremy Huntwork wrote: > Also, as I mentioned earlier in this thread, talking with Ryan set me on > a little bit of a purity path. One thing he suggested, however, which > I'm finding hard to put faith in at this point. He mentioned the purity > of the build is s

Re: Alphabetical branch status report (LONG)

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 devices,

Re: Alphabetical branch status report (LONG)

Tushar Teredesai wrote: > > Will this do? > > :) Thanks, Tush. I didn't remember this... -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: S

Re: Alphabetical branch status report (LONG)

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 resu

Re: Alphabetical branch status report (LONG)

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 .a

Re: Alphabetical branch status report (LONG)

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.

Re: Alphabetical branch status report (LONG)

On 12/15/05, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > Anyone have a better suggestion and/or one that will help determine > library or run-time dependencies? For executable, I prefer strace. For libraries, I move all static libraries into /opt/static-libs/$pkg for each package. If a package e

Re: Alphabetical branch status report (LONG)

On Thu, 15 Dec 2005, Jeremy Huntwork wrote: Ken Moffat wrote: I think Jeremy did use the initial release of farce in the early days of the alphabetical branch, despite its bugs. What improvements have you made? Fixed processing of ar archives that appeared to differ, another fix for '/'

Re: Alphabetical branch status report (LONG)

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?

Re: Alphabetical branch status report (LONG)

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 w

Re: Alphabetical branch status report (LONG)

Ken Moffat wrote: > I think Jeremy did use the initial release of farce in the early days > of the alphabetical branch, despite its bugs. What improvements have you made? > Anyway, I suspect that the introduction of randomization into the > toolchain might soon make this idea of subsequent bui

Re: Alphabetical branch status report (LONG)

On Thu, 15 Dec 2005, Matthew Burgess wrote: However, given that this is the Real World, I would be happy enough if someone could complete an ICA of the alphabetical branch. If it passes those tests then I'm in favour of merging it to trunk, as it would fix bug 684. If its impossible to get

Re: Alphabetical branch status report (LONG)

[snipped all the alphabetical branch discussions]. Hi, Apologies for the delay in responding to this very long thread. Firstly, thanks to everyone for a very productive discussion. Here's my thoughts on the topic: The main goal of the alphabetical branch, as I understand it, is to fix bug

Re: Alphabetical branch status report (LONG)

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

Re: Alphabetical branch status report (LONG)

On 12/11/05, Dan Nicholson <[EMAIL PROTECTED]> wrote: > 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

Re: Alphabetical branch status report (LONG)

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

Re: Alphabetical branch status report (LONG)

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 makin

Re: Alphabetical branch status report (LONG)

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 v

Re: Alphabetical branch status report (LONG)

Tushar Teredesai wrote: > > But I thought that all this has already been discussed before and > after discussion the project leads decided to create a branch for the > changes and then merge the changes back to head after the results were > tested. Exactly. And I gave a status report saying that

Re: Alphabetical branch status report (LONG)

Randy McMurchy wrote: > Nobody, until now, has used other folk's opinions in their arguments. > Everybody up until now has relied on their own ability to express > themselves. Rightly, it should be that everyone relies on their own > merit. You've decided to bring others, without their knowledge o

Re: Alphabetical branch status report (LONG)

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

Re: Alphabetical branch status report (LONG)

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 bef

Re: Alphabetical branch status report (LONG)

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

Re: Alphabetical branch status report (LONG)

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 yo

Re: Alphabetical branch status report (LONG)

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

Re: Alphabetical branch status report (LONG)

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 -- http://linuxfromscratch.

Re: Alphabetical branch status report (LONG)

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 u

Re: Alphabetical branch status report (LONG)

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 do

Re: Alphabetical branch status report (LONG)

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

Re: Alphabetical branch status report (LONG)

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 comm

Re: Alphabetical branch status report (LONG)

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

Re: Alphabetical branch status report (LONG)

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)

Re: Alphabetical branch status report (LONG)

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

Re: Alphabetical branch status report (LONG)

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 a

Re: Alphabetical branch status report (LONG)

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 make

Re: Alphabetical branch status report (LONG)

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

Re: Alphabetical branch status report (LONG)

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 seein

Re: Alphabetical branch status report (LONG)

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 i