Towards a BLFS 6.4 release

Ken Moffat ken at
Sat Dec 27 10:39:25 PST 2008

On Sat, Dec 27, 2008 at 01:02:43AM -0600, DJ Lucas wrote:
> Bruce Dubbs wrote:
> > I would like to propose a target date for BLFS-6.4 as March 31st, 2009.  Is this 
> > a reasonable goal?  I'd like to get synergy between editors to make this date or 
> > another target date that we think is realistic.
> >   
> 90 + days.   As of right now, it *seems* reasonable.
 Me too.
> Finally, I have some notes on the Mozilla stack but I think Ken and I 
> are on the same page with that.  Ken, it sounded like you were planning 
> on it at one time.  If not, it is all in the archives for whomever wants 
> to go for it...maybe me later...we'll have to see.
 Unfortunately, I've moved onto multiple pages on this - for my
regular builds I'm using separate nss and nspr (so that I can build
it on ppc).  I had thought I'd managed to get the separate nss to
use the system zlib, but I can't find it in my notes and it
certainly doesn't seem to be linking to

 I suppose I can update to LFS-6.4 on an 32-bit partition on my
mostly-64-bit box, but probably not before the end of January.  So,
anyone who care to pick this up in the meantime, please feel free.

 Firefox2 is now at end of life (no more security updates are

 I'm currently interested in the following for 6.4 :

sqlite (for qt4, probably for qt3, for at least the current
thunderbird, for xulrunner/firefox3, and possibly for python).

jasper (I always thought this was very obscure, but gnome thinks it
should be used, and something (probably gnu-gs) includes its own
copy).  I've extracted a large patch from debian for the current
vulnerabilities, but not yet even tested if it applies).

printing - gnu-ghostscript-8.63, cups-1.3.9, the gimp-2.6.2,
gutenprint-5.2.3 (I haven't tested this, but it looks to have fixed
a lot of issues for non-ascii locales).  The gimp needs babl and
gegl, I guess for the moment they probably don't belong in the book.
Unfortunately, gimp-help was still in the 2.4 series last time I
looked, but it's mostly still appropriate.

If we use gnu-gs-8.63, I think we can drop espgs.

dhcp - I'm currently on 3.1.1 (couldn't get anywhere with 4.0.0).

abiword-2.6, gnumeric-latest, goffice-latest.

gstreamer current (or perhaps that is part of the gnome ticket).
Similarly totem and its playlist parser.

 I'm considering gnash - it works fairly well for me and I read the
other day that fedora are using it - I'd assumed they would use
swfdec.  The dependencies I recall are totem, ag, boost but I'm not
entirely convinced if boost is really needed (and its such a pain
that it really ought to go in the book when required, e.g. it is at
least optional for kdepimlibs - but the kde4.1 idea of 'optional' is
not always true, sometimes it is really 'required').

 Apart from perhaps strengthening our warnings about security, and
discouraging people from unnecessarily leaving static libs lying
around, that just leaves one and a half other things:

Cmake is pretty much still a mystery to me, but I'd like to at least
see the current version in the book, along with a reference to
xmlrpc-c (a minor thing, but cmake takes an "all or nothing"
approach to using (shared) system libraries

which leads in to kde4.  I assume that 4.2 will be a pain to get in
to 6.4 (probably, lots of changes in dependencies or required
versions, and probably some breakage in the initial version).  But I
would like to see something, so 4.1.3.

 I'm hopeful that the following sed in kdelibs will make it use
~/.kde4 so it can exist in parallel with kde3 using ~/.kde -
 sed -i 's/\(\.kde\)/\14/' CMakeLists.txt (untestled!)

 As to identifying dependencies, they are horrendous and I still
find cmake more or less impenetrable.  Lots of things seem to need
kdepimlibs - that wants mysql at runtime, which seems a bizarre
requirement, but is hopefully only for kmail etc).  In my "only add
things when they are known to be required" mood, I'm stuck in
kdebindings - something to do with SIP or PyQT but now that I've
added kdepimlibs it actually fails sooner than it used to.  So, in
terms of building and finding it works I can only vouch for kdelibs,
the kdebase* packages, kdegraphics, kdemultimedia.

 Oh Dear, I think I've just admitted an interest in enough to keep
me going for the whole of 2009.  Everyone else has moved on to kde4,
I think we need to too.

das eine Mal als Tragödie, das andere Mal als Farce

More information about the blfs-dev mailing list