Status of HLFS project

Robert Baker bobb at
Tue Sep 19 14:37:39 PDT 2006

	Well I have about the same schedule as you Robert, but I am willing to throw my hat in the ring to help maintain HLFS-Stable. I have a big interest in seeing that we can work out a hardened system capable of being used for stable server environments. I think that starting another branch for Stable is exactly what needs to happen. I am more than willing to sink a good 10-20 hrs a week into maintaining, and I have allready begun working on a branch of the SVN-20060717 build of HLFS. I am taking your suggestions at face value, and making the required adaptations to work from a more stable package set. I will have my edited HLFS-Book ready for review sometime this weekend time permitting. 

Hopefully we can get the ball rolling here, and I would love to help out with what time I have to do so.

Robert Baker

It's active, but I seem to be the only maintainer and I work 55 hours per 
week. There are several things I'd like to complete before a stable 
release... stuff like fixing most of the compiler warnings, finding how to 
get all the testsuites to pass, auditing the patches. The combination of gcc4 
and fortify_source added some bugs that also need to be worked out. Plus I've 
been sidetracked with tempfile handling, and sidetracked again with Gzip's 
lack of maintenance (by gnu). It came to my attention that netbsd's gzip uses 
zlib (and also uses libbz2 for bzip2 decompression support), and I'd like to 
have that (I've had good luck porting bsd features to linux and hopefully it 
won't stop). There's also a conflict between Owl's texinfo and texinfo-cvs. 
Not to mention the lfs utf8 differences.

I'm sorry to say I'm much better being an hlfs-unstable maintainer than 
hlfs-stable maintainer. I'd love to have hlfs-stable, but I never stop 
finding things to break/fix  :-)  If releasing hlfs-stable is a priority then 
it would be a good idea to create a second branch which removes the 
half-working stuff and stabilizes the rest. I honestly don't see an end to 
the instability without a second maintainer  :-\  For an hlfs-stable, at the 
present time, I would suggest something like linux-2.4, glibc-2.4, gcc-3.4, 
and binutils-2.17... or even gcc41 without fortify_source. I would also 
suggest downgrading some packages, like shadow-utils, and adding bugfix 
patches. I'd be happy to help with -stable, but I don't want to 
stop -unstable.


[This E-mail scanned for viruses courtesy of Netslyder, Inc.(]

More information about the hlfs-dev mailing list