<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
<br><br>> From: wwh04660<br>> Date: Sat, 13 Sep 2008 20:56:33 -0500<br>> Subject: Re: [Clfs-dev] CBLFS - query about pages Liba52 / DJBFFT<br>> <br>  << snip >><br>> <br>> I got a comment,<br>> <br>>    Would you like to be our proof reader and super duper link checker?  <br>> I mean this in most sincere regard.<br>> <br>> -William<br>> > <br><br>Sure, I'm glad to help out where-ever I can.<br><br>For the record, I started doing the LFS thang many years ago,<br>can't recall exactly when, but I do remember being number 600<br>-and-something of people who bothered to get counted (;  I had<br>always hoped that (one day) I might find the time to give something<br>back to this community...guess what?....I found some. (and it only<br>took nearly a decade! ;)<br><br>I've just worked my way through CBLFS ...some 396* packages worth<br>anyhow...using this system instance, which is ostensibly a CLFS-1.1.0<br>makeup in X86_64_multilib guise. The new CLFS-1.1.0 release will<br>break some things in the CBLFS wiki. Some (ffmpeg at least) are<br>marked as broken already... (*some not currently in CBLFS)<br><br>ffmpeg -- IIRC, my work-around involved grabbing latest&greatest<br>from their svn/cvs repo...<br><br> mythtv -- 0.21 won't build anymore, 'release-0-21-fixes' of mythtv<br>from their svn/cvs repo does...(instructions on wiki would need<br>changes for this, besides, there should be more here for mythtv<br>overall..ie; the myth{themes,plugins,backend})<br><br>librsvg -- 64bit build breaks<br><br><br>Links....yes, well, as I find them I usually post here lately. If I've<br>got it right, these are the wiki page parts which Joe has locked<br>due to people inadvertantly editting 'the wrong thing'.  Normally<br>speaking, I'd just fix these things, on the fly as it were, equally I<br>sometimes feel to fill in missing package 'homepage' links and<br>short description of the package itself, but and alas the wiki lives<br>in a realm where the word 'normal' doesn't always mean the same<br>thing for all people....<grin>....and the whole thing would, I feel<br>sure, quickly loose the plot if no locks existed at all. I'll keep posting (;<br><br>Proofing....CLFS-1.1.0 is at least 98% or more 'good' IMHO. The<br>CBLFS probably doesn't score that high...yet. As I mentioned in<br>a previous posting, I've been loath to change too much until<br>1.1.0 was actually 'out there' - this time is nigh. I've already made<br>a few minor edits to CBLFS in this regard... <br><br>I imagine most folks try to get X up and running as soon as they<br>can after completing CLFS. I've kept the pristine 1.1.0-rc2 build<br>on another partition. As I mentioned in another posting, the final<br>'Xorg -configure' part failed to work for me here, I'm going to redo<br>all of this with that rc2 build and be a tad more pedantic. I notice<br>a few Xorg packages have been bumped a version lately on their <br>repo...this would leave the strangeness with Xmd.h  I've encountered<br>with a number of CBLFS targets, Qt-3 (32bit build) being one.<br><br>In all cases, the 32bit builds were failing, because it couldn't get<br>this part right - [from Xmd.h];<br><br>#ifdef LONG64                                                                   <br>typedef unsigned long CARD64;                                                   <br>typedef unsigned int CARD32;                                                    <br>#else                                                                           <br>typedef unsigned long CARD32;                                                   <br>#endif <br><br>The 32bit builds of some packages like Qt-3 seem to fail as a result<br>of concluding the #else statement when in fact the code was actually<br>expecting  'typedef unsigned int CARD32; ' instead. Believe me, <br>what I know about c/c++ is rudimentary at best, but I know enough<br>to sometimes find part of the cause, without any idea of how to fix it<br>that's correct for the book. Given the build environment at the time,<br>I figure the conclusion is actually correct, just not what we want, and<br>this only seems to affect one or two subsections of the Qt-3 package<br>tree overall. Same goes for other packages so betangled...<br><br>As said though, I'll re-travel all of this over the coming week, and see <br>if I'm to blame. Be assured that I will proof over the existing texts, <br>and check the accuracy of download/website links therein. <br><br>Regards,<br><br>Don  <br><br /><hr />Find great deals on eBay <a href='http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Frover%2Eebay%2Ecom%2Frover%2F1%2F705%2D10129%2D5668%2D323%2F4%3Fid%3D10&_t=763807330&_r=hotmailTAGLINES&_m=EXT' target='_new'>Net yourself a bargain</a></body>
</html>