Re: State of Things [was: Re: Gnome-Python]
On Sat, 11 Aug 2007 20:21:14 -0500
Randy McMurchy [EMAIL PROTECTED] wrote:
[cc'd to LFS-Dev as this is supposed to be a nice attaboy to the
LFS devs]
Dan Nicholson wrote these words on 08/11/07 19:45 CST:
It's the least I could do after you powered through so many
commits over the past couple weeks.
Once upon a time, I read a message from Alexander and he said that
(B)LFS was maybe the best 'distro' out there. Not sure when or why,
but I remember him saying that at one time.
At this point in time, I think that the (B)LFS instructions from
the current Development books are as good a combination as there
has ever been. Too bad half the folks that would want to use it
won't because they feel that their 64 bit machines need CLFS
massaging.
I'm really pleased right now with where the books can take you on
X86 platforms. We are really quite modern right now. Other than
the X86 platform is rapidly becoming semi-obsolete.
(this wasn't meant to be a dig on the X86 platform, references are
only because so many probably now use 64 bit machines and don't
think that [B]LFS is for them)
and you should not forget that CLFS could not nor would not
have existed without {B}LFS. The BLFS part is equally as important as
the LFS part to CLFS viability.
It is also true to say that you, personally, have driven this through,
even in the days when you were not the project leader. Your pride in
the 'product' is well founded. (and we have to thank Dan too, who has
been a more recent 'tower of strength')
I don't use 64-bit stuff yet, despite having the hardware. There just
isn't much point to all the extra effort. All my scripts are derived
from BLFS - and I track svn closely to spot stuff I couldn't
possibly spot on my own.
R.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Gnome-Python
- Original Message - From: Alexander E. Patrakov [EMAIL PROTECTED] To: BLFS Development List [EMAIL PROTECTED] Sent: Monday, August 13, 2007 3:15 PM Subject: Re: Gnome-Python Luca wrote: no-reply received Strange. I sent my ideas on improving the proposed XML syntax. Could you please check your spam folder? Due to XML tags, my message could well end up there. -- Alexander E. Patrakov I checked and Spam folder is empty; checked also filters and all is ok. Could try replying to my email address using to post to lfs and blfs lists? Luca -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Gnome-Python
El Lunes, 13 de Agosto de 2007 00:34, Randy McMurchy escribió: Would you recommend that we split this up a bit? Don't should be needed. What is needed is to create a sub-routine to parse Dbus-Bindings and Python-Modules on a different way, like was done for Xorg7. I will try to have it done before BLFS-6.3 release. Perl-Modules is not an issue due that almost all its dependencies are also Perl modules. Im wide open to suggestions or ideas that can help. Though (as I've heard Manuel mention before) I'm not certain we'll ever be able to fully automate BLFS due to the myriad of possibilities each package may have, if there are things that can help, please let us know. Yes, full automatization is impossible, not only due peculiarities on some BLFS pages, but also due that in a lot of packages the build commands need be adjusted based on what dependencies are installed and/or should be used. Plus, we should try to keep the XML structure the most simple possible to not do more hard the editor's work, IMHO. The current XML structure was not designed thinking on automate builds. That requires rigid XML trees with several hocks to can diferentiate each commad type (pre-configuration, patches, seds, configure, binaries build, documentation build, testsuites, binaries install, documentation install, post-configuration, etc...) and a more fine-grained optional dependencies (to add extra features, to allow testsuites run, to build documentation, etc...). A lot of changes and more work for the editors, but at the end the users will need yet to read carefully the book, to decide what internal and external dependencies he want, to review the scripts, and to decide what need be changed to build the package as he want. No, thanks. I someone want a full-automated from sources build, he can use Gentoo and like. Nevertheless, small not-intrusive changes like the ones propossed by Dan for LFS can be evaluated, if all you think that could be beneficial for both the editors, the book users, and jhalfs users. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: State of Things [was: Re: Gnome-Python]
On Sat, Aug 11, 2007 at 08:21:14PM -0500, Randy McMurchy wrote: has ever been. Too bad half the folks that would want to use it won't because they feel that their 64 bit machines need CLFS massaging. Where do you get this information from? I think that most people that use a 64-bit platform realize that except for the occasional missing patch, BLFS works just fine on 64-bit machines. It does just what it is meant to do, provide a reference for the tweaks and custom programs you want for your LFS machine. I don't think as many people are turned off by BLFS as you might think, but then again, that is just a personal opinion. I have no real data to back that up. I do know that even recently there have been people asking for support when trying to build LFS on 64-bit machines, even though they were fully aware of the existence of CLFS. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: State of Things [was: Re: Gnome-Python]
On 8/12/07, Jeremy Huntwork [EMAIL PROTECTED] wrote: I don't think as many people are turned off by BLFS as you might think, but then again, that is just a personal opinion. I have no real data to back that up. I do know that even recently there have been people asking for support when trying to build LFS on 64-bit machines, even though they were fully aware of the existence of CLFS. I can attest to this. I have been trying to get a good compatible build of LFS built on my Athlon 64 machine. I have had fun trying to get a good multilib build, but when it comes down to it, LFS is much more of a known good solution than CLFS, I assume this is mostly due to the sheer numbers of testers. I want to use this system as a more stable build that I can tar up and use as my main working distro. I had to start building the LFS portion in a virtual x86 machine because I didn't know exactly how to force an x86 build on my x86_64. I guess it's time to check the hints. :) Craig Jackson (TheEpitome) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: State of Things [was: Re: Gnome-Python]
Craig Jackson wrote: I can attest to this. I have been trying to get a good compatible build of LFS built on my Athlon 64 machine. I have had fun trying to get a good multilib build, but when it comes down to it, LFS is much more of a known good solution than CLFS, I assume this is mostly due to the sheer numbers of testers. I can't comment on the number of testers of clfs, I honestly don't know, but quandary, my server that clfs is hosted from, runs pure 64 clfs and the main website pulls in around 9000 unique visitors a month. LFS is known good for x86, for other arches and multilib/pure64/etc, clfs will keep you from having to re-invent the wheel and contains extra info. Packages and instructions are not all that different between the books, they are in the same LFS umbrella of projects after all. CLFS just contains more information about various hardware, and type of builds. You can of course use whatever you want. :) Justin -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: State of Things [was: Re: Gnome-Python]
Craig Jackson wrote: I didn't know exactly how to force an x86 build on my x86_64. This is very easy: linux32 bash, and build in this bash. ftp://ftp.x86-64.org/pub/linux-x86_64/tools/linux32 Note that Debian changes #define STUPID_DEFAULT 1 to #define STUPID_DEFAULT 0, because that stupid version of Java is no longer relevant. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
State of Things [was: Re: Gnome-Python]
[cc'd to LFS-Dev as this is supposed to be a nice attaboy to the LFS devs] Dan Nicholson wrote these words on 08/11/07 19:45 CST: It's the least I could do after you powered through so many commits over the past couple weeks. Once upon a time, I read a message from Alexander and he said that (B)LFS was maybe the best 'distro' out there. Not sure when or why, but I remember him saying that at one time. At this point in time, I think that the (B)LFS instructions from the current Development books are as good a combination as there has ever been. Too bad half the folks that would want to use it won't because they feel that their 64 bit machines need CLFS massaging. I'm really pleased right now with where the books can take you on X86 platforms. We are really quite modern right now. Other than the X86 platform is rapidly becoming semi-obsolete. (this wasn't meant to be a dig on the X86 platform, references are only because so many probably now use 64 bit machines and don't think that [B]LFS is for them) -- Randy rmlscsi: [bogomips 1003.26] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 20:16:00 up 9 days, 20:07, 1 user, load average: 0.17, 0.20, 0.13 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
