On Sun, Sep 30, 2007 at 12:44:15PM -0400, Barry Loo wrote: > Directfb is a minimal X substitute that requires several hundred > _fewer_ packages to be built ( and maintain in the blfs book ). I'm > actually requesting that directfb be added to the blfs book--I think > it would benefit many users besides me. > That's what trac is for - (requests for new packages, version upgrades, bug fixes), although "running it up on the list to see if anyone salutes" is a valid initial approach.
From memory, directfb itself was dropped from blfs because it was thought not to work with 2.6 kernels. > > 2) On my last attempt I couldn't build pango--it didn't detect that I > had glib or cairo on my system ( on earlier attempts I made it to the > actual directfb build; but, I don't recall the error ) ISTR that various versions of cairo have caused problems in the past, but if pango cannot detect a _compatible_ glib you seem to have a different problem. As a rule of thumb, keep glib, gtk, atk, pango in step - a point release (e.g. gtk+-2.10.13 from 2.10.12) is ok, but using gtk+-2.8 or 2.12 implies changing the others to match. And keep to even versions (2.8, 2.10, ...) unless you have a need to try development versions. > 3) Yes, in addition to '2)' above, I can't figure out exactly what > those dependencies are. Let me clarify: on > www.directfb.org/wiki/index.php/Projects:GTK_on_DirectFB a tutorial > is written describing how to build from _source_; however, those > instructions require running apt-get to get the source and the binary > packages needed to install them. And there is something about > _developer tools_, too. The great thing about wikis is that they can normally be edited to improve them. You are building from source, so you should know that 'developer tools' mostly means "install the headers, not only the binaries" so you should mainly be ok. Of course, some packages do need extra dependencies - if the package isn't in blfs, you could try reviewing cblfs.cross-lfs.org (like all wikis, handle with care) just in case it helps, and your local gentoo mirror - ebuilds are sort of like Makefiles / specfiles, and usually give enough details (and patches) to work out what is required. Sometimes, using rpm2cpio on an srpm is helpful (particularly for fedora - Suse and mandriva development srpms seem to have a short life and disappear just after google indexes them). If a wiki tells you to use apt-get, you can usually get the source from your local debian (or ubuntu, if appropriate) repository - sometimes, it takes a while to find things, e.g. truetype fonts were -filed under TTF or ttf last time I looked. Sometimes, google can find the source somewhere else, sometimes not. With debian, you will find a source tarball, and probably a gzipped patch. The main part of the patch is docs and things to bring the package into line with the debian guidelines (files in debian/). If they alter the actual source, they supply the patches as scripts - review them to decide if you think they are needed, and if so copy those lines to a new file and edit them so that you can apply them with 'patch'. Mostly, the patches aren't needed on x86. Very occasionally, you need other tools (e.g. recent freefont snapshots need fontforge, which runs under X if you need it). Above all, document what you are doing so that you can repeat the process once you have it working. This is actually one of the hardest parts - a script shows what you are currently doing, but not necessarily why, nor why you changed it. Also, remember that new versions of anything can change their dependencies. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
