Re: BLFS libxcb-1.4 configure error cmd terminated
On Tue, 2010-02-16 at 02:07 -0500, stosss wrote: I looked back through the book and see that libxslt is listed as required in libxcb. I was tired and must have missed it. But I saw it and built it under xmlto. oh well, sorry for the noise. Fair enough... I am going to build LFS/BLFS several more times. Each time I do I learn more. I already built LFS to completion one other time and partially built some of BLFS. This is my sceond time with BLFS and I went farther this time and I have learned more. I am building it as a VM this time instead of using one of my boxes. As you get comfortable with building things manually, consider automating parts, or all of it, as you go. Partly for the time saved on updating a system, but as much for what you learn about scripting (shell or otherwise) to achieve it. Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS-6.4RC1 or any
On Tue, 2010-02-16 at 01:32 -0600, Mike McCarty wrote: The issue is trying to hit a moving target. I'm not going to try to do that. If the book is still changing, there is a reason. I may find out what that reason is, before the fix is in. The book will *always* be changing, and the reason is that the book too is trying to hit a moving target. Consider, a new Gnome release tends to come out roughly every six months. Xorg seems to be roughly one big release a year, and KDE seems to be one or two a year, I don't know their schedule. Each of those project put out at least two or three times that number in patches between each major release, and that's ignoring the hundreds of individual packages that follow no particular schedule at all. Short version is, a stable BLFS book is never going to be much more than a snapshot at a point in time. Simon signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS-6.4RC1 or any
On Tue, 2010-02-16 at 17:38 -0600, Randy McMurchy wrote: Right now, GNOME is almost there. X has some changes that need to be done. I'm currently doing many packages. I can actually see a release happening. The Gnome release calendar has 2.30 due out in about 6 weeks. Will BLFS have 2.28 be ready before then? Or will we already be out of date before the next BLFS is published? Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS libxcb-1.4 configure error cmd terminated
On Wed, Feb 17, 2010 at 5:23 AM, Simon Geard delga...@ihug.co.nz wrote: On Tue, 2010-02-16 at 02:07 -0500, stosss wrote: I looked back through the book and see that libxslt is listed as required in libxcb. I was tired and must have missed it. But I saw it and built it under xmlto. oh well, sorry for the noise. Fair enough... I am going to build LFS/BLFS several more times. Each time I do I learn more. I already built LFS to completion one other time and partially built some of BLFS. This is my sceond time with BLFS and I went farther this time and I have learned more. I am building it as a VM this time instead of using one of my boxes. As you get comfortable with building things manually, consider automating parts, or all of it, as you go. Partly for the time saved on updating a system, but as much for what you learn about scripting (shell or otherwise) to achieve it. I have already been building a lot of it with simple bash scripts. I basically copy all the commands for a package into a pair of script and run them. One for the regular user and one for root. That is what I did with LFS chapter 2 - 9. Right now I am trying to figure out why some of the packages in chapter 23 in BLFS won't build. If I can't figure it out I will post a new thread with details. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS-6.4RC1 or any
Simon Geard wrote these words on 02/17/10 04:49 CST: On Tue, 2010-02-16 at 17:38 -0600, Randy McMurchy wrote: Right now, GNOME is almost there. X has some changes that need to be done. I'm currently doing many packages. I can actually see a release happening. The Gnome release calendar has 2.30 due out in about 6 weeks. Will BLFS have 2.28 be ready before then? Or will we already be out of date before the next BLFS is published? If the community's expectations are that we have the most current release of every package in the most recent BLFS book, then the expectations are too high and are unreasonable. Do you really think there will be that much difference between GNOME-2.28 and GNOME-2.30? Enough to say BLFS is out of date? I don't think so, but that is just one man's opinion. -- Randy rmlscsi: [bogomips 1003.22] [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] 08:29:01 up 52 days, 13:37, 5 users, load average: 0.58, 0.15, 0.05 -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS-6.4RC1 or any
On 2/17/2010 6:32 AM, Randy McMurchy wrote: If the community's expectations are that we have the most current release of every package in the most recent BLFS book, then the expectations are too high and are unreasonable. Do you really think there will be that much difference between GNOME-2.28 and GNOME-2.30? Enough to say BLFS is out of date? I don't think so, but that is just one man's opinion. This is the main sticking point for releasing a BLFS that I see...Just my thoughts on the subject but Ill' throw them out there. I've never spoke up but every time the BLFS Release discussion comes up I think Targeted Version Freeze. At some point, maybe in the LFS release cycle, define the versions of major package groups that will be targeted for BLFS and branch. Only allow security and well reasoned updates that exceed the the targets into the branch. I'm not talking about every package in the book, just the major items, KDE, Gnome, Xorg, Mozilla apps, etc. Most of the other common apps are at least feature stable and don't generally cause an upheaval when they make new releases. But trying to ensure support for KMS or yesterdays newly added codec in FFMPEG is a fools game - let it stabilize in the wild first and the project dev's can take care of the growing pains. So often, I see DJ and a few others, working so hard through some very involved package groups only to immediately move on to the next release. Not a dig at DJ, he does great work and works hard. But I think it would be a little more relaxing if he had a defined target, rather than trying to keep up with so many divergent projects. After stabilization and release, trunk will take off again and maybe have to skip a release for some packages - but at least there won't be all of this work going on that is just replaced before it ever sees release. i.e. - Defining a target of the current stable gnome, kde, and xorg, this will indirectly define minimum versions of most supporting dep's included in the book. And work can go into stabilizing rather than version chasing. Another idea is to not worry about versions at all. Only build test and update packages as required to maintain parity with LFS and security errata. It may not be bleeding edge but it would certainly meet the educational goal and provide a usable system. Major updates could still be done as it it makes sense to do so, feature-wise, not just because the external project made a release. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS-6.4RC1 or any
On 17 February 2010 18:11, Rod Waldren rjwald...@gmail.com wrote: Another idea is to not worry about versions at all. Only build test and update packages as required to maintain parity with LFS and security errata. It may not be bleeding edge but it would certainly meet the educational goal and provide a usable system. Major updates could still be done as it it makes sense to do so, feature-wise, not just because the external project made a release. Looking at the security errata, for gnome (and probably in other places - kde has tended to provide official backports for kde3, but I've no idea if that is still true for any of kde4 (and no interest in it) you have essentially two options: (a) update to latest stable series - typically, that means upgrading all the dependencies to be in the latest stable series - this may break other related (e.g. gnome in the example) packages unless they too are updated. (b) hope a distro such as centos or debian-stable is using the old version the book is using, and has an available patch. I've done this a couple of times *when a BLFS release seemed likely* but it's not an enjoyable process and usually leaves me wondering if the fix does indeed solve the problem - without a handy exploit, there's a large element of trust and I've seen a few things where backports looked questionable. ĸen -- After tragedy, and farce, OMG poneys! -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
