Linux From ScratchThis Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I'd kill to see how fast LFS would build on a 12-core Opteron with 32GB of RAM.
I went ahead and tested this scenario. the MIT physics department showed up at my door complaining about a time-rip that my machine had caused. It took them a few hours but they got things patched up, so humanity is safe again.
But they asked me to avoid 'negative build times' on LFS because the reversal of cause and effect can be dangerous.
Some personal rancor is simmering amongst the developers. There has been one departure already. The subsequent comments about that person's exit sort of suggest that it might not be over yet (IMO). I don't know what it means for the project or us (maybe nothing). Just FYI.
P.S.: When LFS 7.4 is final (or maybe even sooner), I may proceed on with a current SVN of BLFS. I doubt that the 7.4 BLFS book release that was mentioned earlier will happen soon (opinion again).
I know only what was plainly and publicly available (at the time) in the mailing lists. Armin Krejzi made some changes to the BLFS book. Bruce Dubbs wanted the changes reverted back. The changes apparently were to important long-standing instructions for Qt which Dubbs felt should have been discussed first. Accusations were traded. Krejzi resigned. A couple of follow-on comments by others seemed to be critical of Dubbs (my opinion of those comments...maybe not).
I think that's a concise, accurate, and neutral summary of it. Anyway, the ordinary daily work in the mailing lists seems to be continuing on as usual with support for users, upgrades to BLFS, and finalizing the new LFS release.
Stand by for another release version (7.4-rc2). Apparently an issue created upstream with glibc was discovered. Workarounds with a sed or a compiler flag have been discussed. Or, maybe a new version of glibc that fixes the issue will come along and be used. Anyway, I'm sort of glad that I haven't started building the BLFS system over this rc1 version yet. It's probably best to wait for the final version now.
It don't think it's related to the glibc matter, but that BLFS v7.4 stable book that was mentioned above is being slipped to later in the year. Just FYI. I plan to proceed on with a current SVN version, as usual, when the underlying LFS system is ready.
The 7.4-rc2 release candidate is available now if anyone wants to build it. The differences from the rc1 version seem to me to be...
1. A sed for glibc to revert that upstream change that caused some weird things to happen in some cases.
2. Patches for automake and texinfo were added to deal with some test suite issues.
3. A new bootscripts file and the only changes in that are the deletion of a duplication in the rc.site file and a note in the ChangeLog file about that.
Honestly, and IMO, the reasons to build a release candidate might be for fun, for practice, from curiosity, or to report typos and issues to the maintainers. When the release candidates are announced, the maintainers also ask users to read the book and test the instructions so they "can make the final release as good as possible". I usually do that and occasionally have reported something at the wiki. Often, no changes happen to the packages, patches, and instructions, so a release candidate system becomes a final version system. Not this time though.
Earlier, you said your current system is working just how you like it. I thought, so is mine. I still went ahead with building the rc1 sort of robotically for the usual reasons, but I've now been thinking about skipping the BLFS rebuild this time. I may concentrate on learning a package management scheme to extend the life of a BLFS system instead of rebuilding the whole thing every six months. I will continue to read LFS release candidates and even test them because those are easy to build, but a BLFS system still takes me a several weeks to build and always has a bunch of new issues to solve. I think I'm not looking forward to that this time.
Distribution: Linux From Scratch, Slackware64, Partedmagic
The fist time I build BLFS I did religiously upgrade it ( which is why I wrote my package manager ), but with the system I've got now I must admit I haven't done any upgrades for some time except for an odd few that I upgrade quite often ( ffmpeg,mplayer,cairo-dock ), I was just going to install my prebuilt BLFS packages but I have had a look at BLFS and quite a lot has changed especially Xorg so I am going through my scripts and updating it all.
My plans at the moment are to keep my current system and run the new 7.4 alongside it as my disaster recovery partition as I would like to get away from using partedmagic, obviously until I have thoroughly tested it I wont delete my old recovery system.