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 in any field. And why would you recreate the devices, directories and symlinks if you were still in the chroot? Setting up a test environment is different than putting your system in a production running state. Not recreating devices, directories, symlinks is not the issue - in a regular build the final system is built from a temporary system. For a normal upgrade, the old LFS has to be good enough to build a new temp system, so that was how I began. Greg made a decision on what he wanted to test, I made a different decision. As for booting, you're going to probably change your environment drastically, and that would invalidate the test. If you did a binary diff and found two files to be different, would you be confident enough to tell me that the difference was caused by the building method and not by the altered environment? Or vice versa? I'm not following this, perhaps the 'environment' is throwing me - all I'm interested in are the results of the build - logs, devices, config files are variable data. Programs, libraries, even scripts are not expected to change once installed. Please remember that I've not trained as a tester, only as a programmer and analyst. I'm unclear what changing environment variables is likely to do to an LFS build ? In practice, either the environment is created during the build (e.g. new .bashrc), or a builder probably has a standard pre-existing environment. How about LC_ALL? Creation of /etc/profile in LFS dictates you to set it to your locale, but for the build we've used LC_ALL=C (or POSIX). I don't have an /etc/profile. My LC_ALL is set in my buildscripts, I don't see how the fact that a regular user will have a different LC_ALL alters what is in the files he is comparing. I have no objections to farce. It sounds like you've put a lot of effort into seeing what happens to the files in a second build. I'm arguing for keeping a sane test environment. We all know that LFS builds and boots. This tests the quality of the build, and that test is separate from the two previous questions. Actually, I don't mind if people do object to farce, I'm not overly pleased with it, but it's better than what I had before. Purity was not my major concern when I started trying to improve my analysis of the results - in an average week, two or three unrelated packages are upgraded. As a tester and now as an editor, I need to know that it does indeed still build and boot (and ideally, to know that it builds the parts of blfs I care about - remember bison?). As somebody interested in kernel development, I try to test -rc kernels to make sure the features I use haven't been damaged. To optimise my time, I aim to test everything together because mostly there *aren't* issues (and to be honest, testing the kernels is actually more important). People trained in formal testing are welcome to use their professional techniques. Me, I'm just a journeyman, I pick what I think are appropriate tools for what seems important to me. The main feature of my builds is that something will differ from the instructions in the book (e.g. my last pair of multilib builds used different bzip2 and vim instructions between the builds, and were built with a test kernel). People here who understand the details of Greg's ICA should be encouraged to apply it to LFS builds. Maybe someone has been doing that, and we're just lucky that no problems have showed up for them to comment on, but my assumption is that ICA is poorly understood in lfs circles. 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 page
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. Actually, Greg was told it was because of anonymous namespaces - thread at http://gcc.gnu.org/ml/gcc/2003-08/msg00468.html 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 page
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 the purity of the LFS build. I never meant to imply that you should have been testing this way or that any results you'd gotten we're worthless. OK, I've stated my opinion in this thread a few times. I'm getting out of the way. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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 case for doing ICA for the sake of testing the purity of the LFS build. I never meant to imply that you should have been testing this way or that any results you'd gotten we're worthless. 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 further the discussion. As I said, I'm not overly happy with farce, but it seems to assist _my_ testing. OK, I've stated my opinion in this thread a few times. I'm getting out of the way. -- Dan Please continue to contribute to the discussion. 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 page
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 old systems, such as (OTOH) make and sed... Yes, my point was that in order to get to a place where you can start working with the current book, you have to alter the host to the point that, in many ways, it's no longer old and broken. :P So, in that sense, it doesn't seem worth the time and effort to try to make sure the build works on those old hosts - just stick with the 'it doesn't' and move on. Your work with PLFS shows that we can and do break free from the old host with a fair amount of purity. My goal now is to work out the necessary dependencies and give reasons for our build order. As for the current build method, ch5 was based off ch6 dependencies (fair enough, circa LFS 4) with a lot of sweat instrumenting the build, emphasis was placed on ensuring that where practicible binary deps were satisfied as soon as humanly possible so the new tools were predominately used for building the ch5 packages. Ie: we were trying to mimic the old build ch6 twice approach (build system from itself) as much as possible. Yes, and I intend to make sure that that ideal is kept in the new branch as much as possible. That way we either got a known good binary for use in ch5 (cannot guarantee the host systems), or exposed build bugs due to glibc migration etc early in ch5 as opposed to ch6. Thanks for the feedback, Ryan. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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, I downloaded farce finally and had a look. I like it a lot, and I think it handles the comparison well. In Greg's scripts the comparison is not as detailed; this automates a lot of what I believe he does manually. So, that's very cool. I'm not sure I'll trust the regex replacements until I see it in action, but that doesn't stop me from manually doing the diffs on the files themselves. Not trusting the regexes until you've diffed is good. Maybe farce could generate even more output, to also show what the regexes changed (at the moment the detailed output is only for things that still came up as different). I'll need to think about that. Now, I will still argue about how best to set up the test environment. I'm not a professional tester or analyst either, but it seems common sense to me to minimize the number of variables when hunting down a problem. I agree that it is necessary to reduce the number of variables once a problem has appeared. For this reason, I agree with Greg's decision to stop short of installing all of the configuration files and immediately rebuild while still in the chroot. You mentioned setting LC_ALL in your build scripts. What if someone else doesn't? Are their results reliable? 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. 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 recursive build: if a system builds itself again, to my satisfaction, and builds (once) the parts of blfs I care about, I regard it as ok. The recursive build is, or was, based on three builds to identify which files always differed. I settle for a rebuild. FWIW, this is the method I'll be taking. I'm gonna start hammering out builds on Christmas. I'll be out of town for a week, so there's nothing but spare cycles. Dedication, using all that drinking time ;) 1. Build Ch.5 and Ch. 6. Copy important contents of / to temporary location. I could probably do this with filelist, but I'll still copy anyway. This includes /boot, /bin, /etc, /lib, /opt, /sbin, /usr and /var. Filelist only creates a list of which files exist (for a user, exist and can be read, I think). If you're going to build in-place, you'll HAVE TO copy them somewhere (a tarball will do, but you need the disk space for two trees, or systems, at a time when farce is run, plus a few MB for the results [ diffs of binaries can be big ]. 2. Iterate Ch. 6. Start Ch. 6 at the beginning, ignoring the symlink, device, directory creation and the fs mount since these have already been done. Copy / to another temporary location using the same directories as in 1. Repeat 2 if desired to a predefined number of iterations. *Note: 1 and 2 are ripped from gsbuild. You could probably add Ch. 7 and Ch. 8, but I already explained my interest in minimizing the test environment. 4. Run farce on the temporary locations from the earlier stages. 5. Ponder the exact time in my life when I became a huge geek. Iterate. LOL One last thing. As for running ICA, I think this is only a name. I only use it because most what I know about recursive building comes from reading stuff Greg's done, and that's what he calls it. We're both talking about the same thing as to seeing whether the build can recreate itself. I think the only difference I can see is how to set up the testing environment. We can call it something else if that helps. ICA is Greg's name, AFAIK he had rather a lot to do with it so he gets to name it. If somebody understands it enough, and cares enough, to use it and report back to us, that's great. 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 page
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 exactly a recursive build: if a system builds itself again, to my satisfaction, and builds (once) the parts of blfs I care about, I regard it as ok. The recursive build is, or was, based on three builds to identify which files always differed. I settle for a rebuild. This is no longer true, as far as I can tell, and it was never based on a specified number. Using three or more builds was just to see at what point there stop being differences. The goal is always that the second build would be the same as the first. Only two is necessary to do the diffing, obviously. I guess the one caveat with using less than 3 builds is you wouldn't be 100% sure that certain files will always differ. FWIW, this is the method I'll be taking. I'm gonna start hammering out builds on Christmas. I'll be out of town for a week, so there's nothing but spare cycles. Dedication, using all that drinking time ;) Hey, I'll be drinking plenty! That's what scripts are for. ICA is Greg's name, AFAIK he had rather a lot to do with it so he gets to name it. If somebody understands it enough, and cares enough, to use it and report back to us, that's great. I think you're making a bigger deal out of this than there is. Unless he's implementing a different method on his own than what appears in his build scripts, it's exactly how I described in the previous email. As I said above, the number of builds is inconsequential unless you're trying to guarantee that a file will always differ. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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 we'd know if we've gained anything in terms of reliability/reproducability. 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. I didn't get to take an extended look at it, yet, but I hope to soon. I intend to give my best shot at running an ICA on the branch. I may look at moving procps up in the order first, as perl's testsuite needs it. 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 shown, in part, by being able to build on old and broken hosts, ie, RH 6.2. I can see his point, in that it shows we've broken from that environment and have built ourselves a robust and sane toolchain. However, current LFS has requirements far above RH 6.2, such as a host with a 2.6 kernel because of the step up to NPTL. Also, (at least with RH 6.0; I don't have 6.2) the version of 'make' is too old to even parse the 2.6 kernel's make system. So, to really break free from such an environment, we'd have to first build a sane set of gnu-tools on it. Unless I'm missing something, I don't see how showing purity by building on such old hosts at this time has merit. Lastly, it's easy to determine a package's binary build-time dependencies by setting the PATH to be something like '~/bin' and symlinking binaries into your path as you need them. Run through the installation of the package and symlink until the errors are gone. Anyone have a better suggestion and/or one that will help determine library or run-time dependencies? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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? http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2005-November/053989.html :) -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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. Yeah, gzipped files contain a timestamp - farce does a cmp of the data after the stamp, it just seemed more interesting than decompressing. I'm hopeful that the .a archives are adequately processed now (my fix to make the testar function work again). 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 shown, in part, by being able to build on old and broken hosts, ie, RH 6.2. I can see his point, in that it shows we've broken from that environment and have built ourselves a robust and sane toolchain. However, current LFS has requirements far above RH 6.2, such as a host with a 2.6 kernel because of the step up to NPTL. Also, (at least with RH 6.0; I don't have 6.2) the version of 'make' is too old to even parse the 2.6 kernel's make system. So, to really break free from such an environment, we'd have to first build a sane set of gnu-tools on it. Unless I'm missing something, I don't see how showing purity by building on such old hosts at this time has merit. Interesting comments, I hadn't thought about that. 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 page
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 files before running the comparison. Yeah, gzipped files contain a timestamp - farce does a cmp of the data after the stamp, it just seemed more interesting than decompressing. I'm hopeful that the .a archives are adequately processed now (my fix to make the testar function work again). Forgot to add - thanks for the comment, I'm hopeful that farce will mostly answer the comparison question, but there is an amount of policy in it, particularly the list of files which are allowed to differ - I'm happy with these, but if it gets wider usage people may want to disagree about some of these. -- 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 page
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 results of the same tests run on an alphabetical build. That way we'd know if we've gained anything in terms of reliability/reproducability. 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. I didn't get to take an extended look at it, yet, but I hope to soon. I intend to give my best shot at running an ICA on the branch. I may look at moving procps up in the order first, as perl's testsuite needs it. 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, mount file systems, create directories, etc. for all but the first iteration. 2. For all stages he stops short of installing many of the custom configuration files like /etc/profile, /etc/fstab, etc. Keeps the building environment consistent. This is what I like better than what Ken's tool does. I'm not sure how it removes the variables of kernel, modules, env vars, etc. 3. Copies only the necessary files to a temporary location immediately after the build completes. This is more trivial, but it safeguards you against accidentally making an unalterable change on your system later. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Alphabetical branch status report (LONG)
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 the above information page
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, mount file systems, create directories, etc. for all but the first iteration. That's my prime objection to Greg's method - we always tell people fbbg, but the comparison takes a shortcut. 2. For all stages he stops short of installing many of the custom configuration files like /etc/profile, /etc/fstab, etc. Keeps the building environment consistent. This is what I like better than what Ken's tool does. I'm not sure how it removes the variables of kernel, modules, env vars, etc. Useful, if all you want to do is test it. For me, knowing that a new build boots (and therefore has enough of blfs for me to use it, e.g. dhcp, nfs, ssh) is always a good sign. These files are what I called 'policy' earlier. If you want to use similar buildscripts to only install certain files, or a script to sed the lists of files to compare, farce won't complain. Kernel modules might match, or they might differ, or not be present. I'm trying not to be prescriptive in how farce is used - if these do differ, I expect the builder will know why, and therefore recognise that they changed the .config, or the kernel version. The compressed bzImage is a different matter - I skip that because compiling the same source at a different time will change the date/time which is in the text, and therefore the size of the compressed file can change. I'm unclear what changing environment variables is likely to do to an LFS build ? In practice, either the environment is created during the build (e.g. new .bashrc), or a builder probably has a standard pre-existing environment. For the kernel, apart from not trying to look at differences in bzImage/vmlinuz I just change known kernel version formats into tokens in my infamous regexes. For example, lots of the perl files are actually text telling you the kernel version and date/time when it was compiled. Change these to tokens for known format permutations and you don't lose any information. Yes, if you decide to start building in a different locale, this might alter what goes into the text, and perhaps put it into a different format - if that happens, farce should give you enough information to see which formats changed. Most of this should be reasonably clear from looking at the code (it's only two scripts), although the perl regexes are probably a hard slog when you first meet them. 3. Copies only the necessary files to a temporary location immediately after the build completes. This is more trivial, but it safeguards you against accidentally making an unalterable change on your system later. That _is_ an advantage - lesstif from blfs overwrites a man page from perl (not checked recently, but it used to), which I only noticed when I compared a full system against the minimal system it had built. With farce you can compare as little, or as much, as you wish (subject to adding to expected differences for new file types such as Python code, and new regexes) - it doesn't need a full build, it should be usable for arbitrary packages, and you can use your own buildscripts. 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 page
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. 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 in any field. And why would you recreate the devices, directories and symlinks if you were still in the chroot? Setting up a test environment is different than putting your system in a production running state. 2. For all stages he stops short of installing many of the custom configuration files like /etc/profile, /etc/fstab, etc. Keeps the building environment consistent. This is what I like better than what Ken's tool does. I'm not sure how it removes the variables of kernel, modules, env vars, etc. Useful, if all you want to do is test it. For me, knowing that a new build boots (and therefore has enough of blfs for me to use it, e.g. dhcp, nfs, ssh) is always a good sign. Absolutely, you're right about those things. I certainly don't consider my build complete until I get a handful of BLFS packages in there. You could even add some of those to the test environment. We all know that where LFS ends and BLFS begins is subjective. As for booting, you're going to probably change your environment drastically, and that would invalidate the test. If you did a binary diff and found two files to be different, would you be confident enough to tell me that the difference was caused by the building method and not by the altered environment? Or vice versa? I'm unclear what changing environment variables is likely to do to an LFS build ? In practice, either the environment is created during the build (e.g. new .bashrc), or a builder probably has a standard pre-existing environment. How about LC_ALL? Creation of /etc/profile in LFS dictates you to set it to your locale, but for the build we've used LC_ALL=C (or POSIX). That _is_ an advantage - lesstif from blfs overwrites a man page from perl (not checked recently, but it used to), which I only noticed when I compared a full system against the minimal system it had built. With farce you can compare as little, or as much, as you wish (subject to adding to expected differences for new file types such as Python code, and new regexes) - it doesn't need a full build, it should be usable for arbitrary packages, and you can use your own buildscripts. I have no objections to farce. It sounds like you've put a lot of effort into seeing what happens to the files in a second build. I'm arguing for keeping a sane test environment. We all know that LFS builds and boots. This tests the quality of the build, and that test is separate from the two previous questions. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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 before it, and you know with certainty that packageA requires depA. But now you have to remove both packageA and depA and start with packageB and see if it needs any dependency not covered by the base toolchain. That's like 70 packages you just built and removed iteratively. Eventually you find one that requires depB. Does depB require depA? If not, depA should probably not exist on the system while you iterate through the entire list of packages again, and repeat this ad nauseum. Now, you have a build order that you can say, These are the required dependencies. Now, you have to read every log created for every package and find the non-required dependencies. Ultimately, this can only be accomplished by reading the source, running strace, reading the configure script, etc, and then parsing all that output and making judgment calls. So the scenario becomes packageA requires depB, but can use depC and depD. If depC is in the book, do we move that up? What about depD, and what if depD is not in the book? Once the decision is made, another complete round of testing is in order. And do we stop at compile-time dependencies or do we include run-time dependencies as well? The moral of this story, ignoring any other comments made in this thread as to feasibility or technical accuracy, is that the work on the alphabetical branch as has been laid out cannot possibly answer item 3 above. Only a vast amount of man hours invested in reading the sources, or an even larger amount of man hours invested in the trial and error of: building, stracing, reading logs, and doing binary analysis can possibly hope to list dependencies with any real accuracy. SBU's are not expected to be 100%. Dependencies must be. Note: none of this is directly related to my opinions as to the alphabetical (or substitute the latest name) branch. I think it is a valid goal, but I do not see it as a needed goal or even recommended goal, and definitely not one that deserves such a high allocation of man hours. Keep in mind the maintenance requirements as well. For a nice case-study, look at the perl failure that seems to have gone unnoticed or at least unfixed for a very long time. I have been diffing my build logs to previous build logs for a few years now because simply reading or even attempting to grep for some unknown keywords in the logs to find problems just takes too long to be a maintainable solution for me. Yet, this perl failure says that either I missed a line of diff output (very likely when reading large amounts of cryptically formatted output) or that this problem has shown in my logs for a long time and thus not in the diff output. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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 it and it's working wonderfully. IMHO, a very important aspect of these proposed changes is to check whether Ch 6 can reproduce itself reliably. There is only one way to properly measure reproducibility and that is to do some binary diffing a la ICA (Iterative Comparison Analysis). My techniques (detailed in the gsbuild scripts) are not perfect but they have certainly been good enough over the years to detect quite a few bugs. On this note, I will say that I attempted to do the ICA on the lfs-alpha branch. Unfortunately, I borked it being my first time, so not much conclusive came out. I've been meaning to write you back about it, but I didn't have too much meaningful info. Anyway, here goes. I built the thing word for word out of the branch in Jeremy's home directory. Built fine. I only did the tests on the Ch. 6 toolchain. glibc and gcc had a few failures. Some were known, like the gcc mudflap failures. I'll post them soon, but I don't have access right now. After this, I built a few BLFS packages (dhcp, links, net-tools, openssl, openssh) and booted. Ran fine. At this point, I set up the ICA build. By this I mean I would completely rebuild Ch. 6 after copying the contents of mostly everything except /dev, /sys, /proc, /tmp and /home I think. I actually just implemented Greg's do_ica_prep function manually. Problem here is that to do a good diff, I shouldn't have built the BLFS packages unless I was going to build them again, and I shouldn't have booted the new system (particularly running a different kernel). For instance, one stupid thing was that net-tools overwrote the coreutils hostname binary, then I rebuilt and didn't suppress coreutils from installing hostname again. Stupid, stupid, stupid. Well, one thing that happened the second time was that the some of the glibc test failures were gone. Makes me think that Ch. 5 isn't up to snuff. So, after the binary diff (using Greg's do_ica_work function manually), there were tons of differences. Unfortunately, I can't be certain that they were different because: 1) My environment had changed 2) The alphabetical changes had caused issues 3) The current LFS build is flawed So I never posted anything. I plan to try this again, BUT on the current LFS. It seems that no one's done the purity test on LFS in a long time. At least, I'd like to know what the situation is before making wholesale changes and trying to figure out what the new differences are. Jeremy, earlier you said that the test would be to build the whole lfs-alpha, then rebuild the whole lfs-alpha. I thought about this, and I think this is one worthy test. However, it only really highlights the ability of the Ch. 5 temporary toolchain to separate from the host. I know Ryan Oliver has said many times that he's used a busted up RedHat 6 machine he has to build LFS from. This is only one data point, but it seems that the bootstrapping ability of LFS is relatively good and you should be able to build LFS Ch.5 and Ch.6 from most sane toolchains. To find out whether the final system (Ch. 6) is not subtly broken goes beyond rebuilding LFS from the floor or building packages in BLFS. Passing testsuites is certainly a good indicator and the ICA also seems to be an excellent way to test the final system. I'm not saying this to rant against what you're doing. I think testing the build order of the packages is good if what you're doing is finding out whether it builds a better system or not. But I'd like to see a whole lot more testing before major changes to the build order are done. This order was known at one time to rebuild itself byte-for-byte. We should first find out whether this is the case before changing it. That's all my opinion. If it's deemed that the alphabetical order is the way the group wants to go and that enough testing has been done, then I won't say another word. Anyway, I applaud your effort on this even though I'm not behind it right now. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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 seeing your work, and I'll be looking at doing some of my own. I've taken your point about the chapter 6 purity analysis and will concede. I'll also agree that we're not ready for the change yet - as this thread has shown there's too much testing to do - but I still think that we need to go this direction, which could ultimately help point out bugs in the entire LFS build process. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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 do you mean that the idea is a futile one? 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 order can be made that doesn't alter the final product and can be made alphabetical, then that's fine. I'm interested in seeing your work, and I'll be looking at doing some of my own. I've taken your point about the chapter 6 purity analysis and will concede. I'll also agree that we're not ready for the change yet - as this thread has shown there's too much testing to do - but I still think that we need to go this direction, which could ultimately help point out bugs in the entire LFS build process. Jeremy, I think that a better goal would be to resurrect the purity tests and see how current LFS stacks up. I'll be glad to help on this. I have slow hardware, so doing a complete LFS is an all day affair, and I can't completely devote my one box to this purpose. So, I'll try to help where I can. Next month I hope to be getting a new machine, so maybe my contribution could increase then. I think that if the current LFS passes, then we should look into documenting the build order and changing it if it's possible. You're right that we should get to the bottom of the build order and see if it causes bugs. Ken's farce tool seems like it will do the diffing for you, but I'm not familiar with it. However, I'm much more familiar with Greg's gsbuild system. You can get the current one at http://www.diy-linux.org/downloads/contrib/greg_schafer/gsbuild/gsbuild-20050825.tar.bz2 It can be a bit much to swallow at first because he makes extensive use of variables and functions. Look at the file common_sh.functions file at the bottom to see the ICA functions. Let me know what you think. I've been seriously thinking about doing this for a while now, and I'm trying to get my scripts in shape to automate it. Essentially, this means I'll be ripping off gsbuild :) (Thanks in advance, Greg.) -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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 makes me feel better, it just sort of reaffirms that fact that nothing is gained, and there could be breakage down the road. It is a lose-lose situation. There is nothing to be gained. Jeremy, I think that a better goal would be to resurrect the purity tests and see how current LFS stacks up. I'll be glad to help on this. I have slow hardware, so doing a complete LFS is an all day affair, and I can't completely devote my one box to this purpose. I would be willing to offer CPU cycles for this as well. I'm all for testing the purity of the build, and doing what is necessary to ensure that purity, build after build. I think that if the current LFS passes, then we should look into documenting the build order and changing it if it's possible. You're right that we should get to the bottom of the build order and see if it causes bugs. Me too. And I'm not a me-too poster. I do feel strongly though, that if the current build process is reliable, builds consistently with the same end-result and is completely reproduceable, then it should stay until a newer version is proven to do the same thing. So, that means we need to test the current version first, then try and migrate to a new build order. Which means we need to develop a reliable QC program *before* we need to change the build order. Right? -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 19:25:01 up 78 days, 4:49, 3 users, load average: 0.26, 0.80, 0.81 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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 an order can be made that doesn't alter the final product and can be made alphabetical, then that's fine. Once more, for the sake of clarity. The goal of the lfs-alphabetical branch was *not* solely to make the build alphabetical! (maybe I should have named it differently?) Anyone who still thinks so should go back and review the bug that started this research in the first place. The alphabetical order simply serves to structure and organize the packages where any random order will do and where all dependencies have already been met. It's more than just cosmetic. 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 let's just leave it.' Note, too that in the proposed branch and build order *all* dependencies will be listed - even the ones that are satisfied by the alphabetical order. Nothing will be unknown. Dan, I respect your opinion (and those of others that have already voiced similarly), but I just want to make sure that it is an opinion that is formed after having understood the incentive behind the suggestions. Jeremy, I think that a better goal would be to resurrect the purity tests and see how current LFS stacks up. I'll be glad to help on this. I have slow hardware, so doing a complete LFS is an all day Sure. But I would rather do purity tests on the alphabetical. Current LFS is broken in that no one knows why things are done the way they are. It's a ridiculous position for this project to be in, really. affair, and I can't completely devote my one box to this purpose. So, I'll try to help where I can. Next month I hope to be getting a new machine, so maybe my contribution could increase then. I think that if the current LFS passes, then we should look into documenting the build order and changing it if it's possible. You're I still disagree. I think the *principle* of building LFS, ie, build a sane toolchain and default tools, chroot, build the final toolchain and final tools is set and working - but nearly everything else is an unknown. It's time to start from scratch as it were and re-evaluate the whole thing and *then* test for purity, because only then will we *know* what we're dealing with and only then will we have an answer for everything we do. Current LFS trunk can fend for itself. Ken's farce tool seems like it will do the diffing for you, but I'm not familiar with it. However, I'm much more familiar with Greg's gsbuild system. You can get the current one at http://www.diy-linux.org/downloads/contrib/greg_schafer/gsbuild/gsbuild-20050825.tar.bz2 It can be a bit much to swallow at first because he makes extensive use of variables and functions. Look at the file common_sh.functions file at the bottom to see the ICA functions. Let me know what you think. I've been seriously thinking about doing this for a while now, and I'm trying to get my scripts in shape to automate it. Essentially, this means I'll be ripping off gsbuild :) (Thanks in advance, Greg.) All these suggestions sound fine, and if you want to do it against current trunk, go right ahead. I think the real effort needs to be done against a new build order. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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 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 on this list! 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 let's just leave it.' But, as far as I know, nobody except you thinks that. Right now, I think the build order is because it was developed through years of experience, trial and error and testing. And you are suggesting to throw all that out the window and try a new build order, because your (one person mind you) month or two of casually using a new build order produces, what *you* say is a reliable build order. But, what about the thousands of builds before this that have proven that the existing build works, and doesn't really need to be modified? Doesn't that history and years of experience amount to something that should be dealt with before changing? -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 19:44:00 up 78 days, 5:08, 3 users, load average: 0.07, 0.09, 0.29 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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) We'll know exactly what package depends on which others. 2) Because we want to establish purity, we'll know just how the build stacks up. 3) The book will be more technically accurate because it will list the dependencies of all packages built. Frankly, I don't see what there is to lose. And once more, nothing is going to be blindly merged without fully testing. I'll do the ICA. So, that means we need to test the current version first, then try and migrate to a new build order. Which means we need to develop a reliable QC program *before* we need to change the build order. I agree that a QA process is in order and there is a great need to test purity. But there is also a need to rationalize the build order. You can't see that? Why spend the time to verify the purity of a system that we can't rationalize now? We should get at the root of the problem by starting with the build order and verifying purity from there. If it's shown to be faulty, we adjust and tweak until it is pure and we document as we go. At the end we'll have the answer to every question with LFS and we can defend our decsions by the data we glean. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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't know why this package is before this other one, but it works so let's just leave it.' But, as far as I know, nobody except you thinks that. Right now, I think the build order is because it was developed through years of experience, trial and error and testing. And you are suggesting to throw all that out the window and try a new build order, because your (one person mind you) month or two of casually using a new build order produces, what *you* say is a reliable build order. But, what about the thousands of builds before this that have proven that the existing build works, and doesn't really need to be modified? Doesn't that history and years of experience amount to something that should be dealt with before changing? He isnt alone, I'm curious why the build order is the way it is now, and i'm curious if changing it around a bit can fix it and make a more stable system. Is that not worth investigating? I think it is. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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 comments on this list! Then it is my fault for not being clear. And it is the readers' faults for not going and reading the bug and original thread to which I posted links. But, as far as I know, nobody except you thinks that. Right now, I think the build order is because it was developed through years of experience, trial and error and testing. And you are suggesting to throw all that out the window and try a new build order, because your (one person mind you) month or two of casually using a new build order produces, what *you* say is a reliable build order. 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 that opened the bug. But, what about the thousands of builds before this that have proven that the existing build works, and doesn't really need to be modified? Doesn't that history and years of experience amount to something that should be dealt with before changing? I would agree more readily with you if LFS never changed. But it does -- it's a growing and changing beast and it's nowhere near what it was when it was started. And the build order has become fragmented -- one package put in, a couple taken out, two more put in here, this one now depends on this other package, etc, etc. LFS is *not* what it once was and the historical purity and accuracy of it drifts. You were right in your other assessment. We need a good QA process. One that takes the build order into account and that can justify it regularly. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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 so let's just leave it.' Note, too that in the proposed branch and build order *all* dependencies will be listed - even the ones that are satisfied by the alphabetical order. Nothing will be unknown. 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? I don't see a fundamental issue here that says we must list each and every dependency for every package. 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. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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 does LFS build their system the way they do? The answer is: Because over years of testing it has been determined that it is reproduceable and consistent. What else needs to be said? Why must it change? -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 20:01:00 up 78 days, 5:25, 3 users, load average: 0.77, 0.28, 0.22 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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 us who do see a need for a change, make it. :) -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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 would beable to create a perfect build order the first time around. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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 you won't mind so much when others of us who do see a need for a change, make it. :) No, I won't mind at all. As I originally said, I was merely stating my opinion. This is, after all, an open source project. If you have an itch, go ahead and scratch it. :) -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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 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 or consent, into agreeing with you. I'm not sure that this is going to influence folks to change their minds on this subject. Especially considering that Greg, for example, has his own build (http://www.diy-linux.org/x86-reference-build/), and it much more mimics the current LFS build, than this alphabetical build you are proposing that you say he is in agreement with. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 20:25:01 up 78 days, 5:49, 3 users, load average: 0.16, 0.55, 0.67 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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 before this other one, but it works so let's just leave it.' Note, too that in the proposed branch and build order *all* dependencies will be listed - even the ones that are satisfied by the alphabetical order. Nothing will be unknown. There are reasons. I know Greg opened that bug, but it was his and Ryan's own work on PLFS, using ICA that determined a lot of the ordering. Damned archives are too big! I knew I should have bookmarked more things last time I did this. I'll get links soon. Jeremy, I think that a better goal would be to resurrect the purity tests and see how current LFS stacks up. I'll be glad to help on this. I have slow hardware, so doing a complete LFS is an all day Sure. But I would rather do purity tests on the alphabetical. Current LFS is broken in that no one knows why things are done the way they are. It's a ridiculous position for this project to be in, really. 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 the changes and then testing is going to add way too many variables to the test. Starting from a known good recipe and slowly altering would seem to be a more prudent way, to me. What you're suggesting is completely changing the build (arbitrarily making it alphabetical) and changing it until it becomes pure? Well, it's still crazy, but it's starting to make more sense. I still think it would be worthwhile to do the purity test on current LFS to at least know where the LFS-newbuildorder branch stacks up. Maybe it should be called Ordered LFS or something. Well, count me in! Doing the purity tests and figuring out all the niggles of this baby sounds like a lot of fun. (Man, when did I become such a nerd?) I still plan on doing a current LFS ICA test to see where it stands, but what you and Chris have done seems like a good jumping off point. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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 one that opened the bug. I agree with the reasons behind documenting the build order. I am for documenting all the dependencies so that the person who builds an LFS knows why Package A is built before Package B. I don't like the excuse You the user should trust us the editors. 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. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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 version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 20:55:00 up 78 days, 6:19, 3 users, load average: 0.01, 0.05, 0.13 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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 making the changes and then testing is going to add way too many variables to the test. Starting from a known good recipe and slowly altering would seem to be a more prudent way, to me. What you're suggesting is completely changing the build (arbitrarily making it alphabetical) and changing it until it becomes pure? Not quite. Have you looked at bug 684 yet? :) The idea is, don't change the toolchain, the toolchain is known and the backbone of the system. But as for the rest of the packages, why are they built when they are? Starting with an alphabetical order, Chris (with some small help from me) has put the packages that *need* built first way early in the build order, if it can stand (ie, no run-time/build-time dependencies) to be built where it falls alphebitcally, it stays. So it's not *quite* arbitrary - there is a method to the madness. [snip] Well, count me in! Doing the purity tests and figuring out all the niggles of this baby sounds like a lot of fun. (Man, when did I become such a nerd?) I still plan on doing a current LFS ICA test to see where it stands, but what you and Chris have done seems like a good jumping off point. OK. :) So you want to join my elite team of purity testers? :) (I'll send your mask and cape via FedEX.) I look forward to seeing your results. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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 some more. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
