robert baker robertmbaker at
Wed Apr 21 13:26:48 PDT 2010

Much of the work to bring the HLFS temporary tools up to the package
level of LFS has been done already. There are some minor version bumps
that need to be made to be at or above LFS stable package versions.
The following are the packages in question.

Binutils - bump from 2.19.51 to 2.20 (Compiles clean. Haven't checked
test suite yet)
Gcc - bump from GCC-4.2 snapshot to 4.4.3 (Patches apply cleanly.
Haven't compiled yet.)
Grub - bump from 0.97 to 1.97.2 (Will check what this requires when I get there)
Tar - Bump from 1.21 to 1.22 (No patches, should be simple.)

Obviously GCC would be the major hurdle here. But since the patches
apply cleanly to 4.4.3 we may be in business. I am building a fresh
/tools right now with updated package versions and will update the
list as I make progress.

A cursory milestone layout for Point 1 in my last mail would be as follows.

1. /tools completion. Including all patches intended for toolchain.
2. Bootable /tools completion.
3. Final system build. (LFS Chapter 6)
4. Rebooting to Final system. (Includes LFS Chapters 7 and 8)

These milestones would be broken down into individual action items so
there is a clear sense of direction and purpose in each step to be

>From what I am gathering there are a couple of action items to knock
out to get all of the glibc/gcc patches and options we want applied.
But the bulk of the ground work is laid to reach the /tools completion
milestone quickly. I could see a significant amount of man
hours/compile time going towards gcc and glibc alone so those would be
my biggest concerns on the front end. Once a level of satisfaction has
been reached with those two packages the rest should fall into place
fairly quickly.

I am very interested in hearing feedback on my proposals.


On Wed, Apr 21, 2010 at 12:43 AM, robert baker <robertmbaker at> wrote:
> I am sure everyone understands the position you find yourself in.
> I am interested in playing a more involved role. I know I haven't
> contributed much as of yet, and have been quiet on the list. This was
> mostly due to the lack of a direct project plan and outlined
> milestones. If nothing else I would like to take some time to propose
> short term goals.
> 1. Package refresh up to LFS stable where applicable. (Already in progress.)
> 2. CLFS style Cross compile instructions for x32 and x64. (Groundwork
> laid in 64bit patch updates and temporary bootable /tools.)
> 3. Return to XML style book. (Shell scripts can be generated from XML
> book, or ALFS can be used.)
> 4. Completion of book text.
> I would consider point 3 to be debatable, but my reasoning for that
> point is that it is the single largest divergence from the *LFS books
> as of yet. Generating scripts from the XML files should be a fairly
> reasonable undertaking. ALFS has worked for me in the past, but I am
> not clear on the level of maintenance on that project. Either way I
> think the XML book has it's merits.
> All four of those items can be broken down into a series of milestones
> and man hours can be assigned to each of the tasks leading to the
> milestones. At which point it would be possible to give target dates
> for the completion of each task. Much of this work can be divided
> among anyone who is willing to help, but I think a clear schedule of
> work is the most important factor in pushing the project forward.
> As a show of support and good faith I will be working toward point 1
> starting with a package by package review of what needs updating. I
> will follow up on this mail with a list of packages and what I
> consider a reasonable breakdown of the work involved. I should be able
> to compile that list tomorrow and begin working to toward goal 1 after
> I send a follow up email.
> RBaker
> On Tue, Apr 20, 2010 at 10:11 PM, Robert Connolly
> <robert at> wrote:
>> Hello.
>> When I first got involved with LFS and HLFS I had a lot more free time to
>> contribute, and over the years I have less and less. I have been trying to
>> keep HLFS alive with free time on long weekends, but even this is getting
>> difficult. I haven't been able to maintain HLFS for a long time, and I have
>> been avoiding admitting it.
>> HLFS needs a new maintainer, or maintainers. If anyone wants the job they
>> would have artistic control to do what they want with the project. I'll
>> personally support any changes as long as it stays "Linux from scratch".
>> I want to continue to contribute to, and support, all the LFS based projects
>> to the best of my ability. I'm not quitting or walking away, I'm just not
>> capable of fullfilling my responsibilities to HLFS anymore.
>> robert
>> --
>> FAQ:
>> Unsubscribe: See the above information page

More information about the hlfs-dev mailing list